From owner-linux-xfs@oss.sgi.com Fri Feb 1 01:47:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g119lfL27316 for linux-xfs-outgoing; Fri, 1 Feb 2002 01:47:41 -0800 Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g119lad27292 for ; Fri, 1 Feb 2002 01:47:37 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=indonesia.kscanners.no) by indonesia.kscanners.no with esmtp (Exim 3.33 #1) id 16WZLy-0004UU-00 for linux-xfs@oss.sgi.com; Fri, 01 Feb 2002 09:47:26 +0100 Date: Fri, 1 Feb 2002 09:47:25 +0100 From: Toralf Lund To: linux-xfs@oss.sgi.com Subject: Mounting IRIX filesystem with version 1 directories? Message-ID: <20020201094725.A17098@indonesia.kscanners.no> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.3.0 Lines: 15 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From the XFS FAQ, Will I be able to use my old IRIX XFS disks on linux? [ ... ] Linux can only read v2 directories on the moment. Using v1 will probably fail in spectacular ways. I have a large IRIX filesystem that I would like to mount on Linux, but I think it has version 1 directories. Is there any way at all I can get this to work? -- Toralf Lund +47 66 85 51 22 Kongsberg Scanners AS +47 66 85 51 00 (switchboard) http://www.kscanners.no/~toralf +47 66 85 51 01 (fax) From owner-linux-xfs@oss.sgi.com Fri Feb 1 05:35:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11DZID03204 for linux-xfs-outgoing; Fri, 1 Feb 2002 05:35:18 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11DZBd03173 for ; Fri, 1 Feb 2002 05:35:11 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA01304 for ; Fri, 1 Feb 2002 04:34:57 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA36569; Fri, 1 Feb 2002 06:33:49 -0600 (CST) Received: from sgi.com (QaoioY1j2ijXnQXpAhrub26JA8L2TAi8@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA30825; Fri, 1 Feb 2002 06:33:46 -0600 (CST) Message-ID: <3C5A8B22.4070200@sgi.com> Date: Fri, 01 Feb 2002 06:33:38 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Toralf Lund CC: linux-xfs@oss.sgi.com Subject: Re: Mounting IRIX filesystem with version 1 directories? References: <20020201094725.A17098@indonesia.kscanners.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Toralf Lund wrote: > From the XFS FAQ, > > Will I be able to use my old IRIX XFS disks on linux? > > [ ... ] Linux can only read v2 directories on the moment. Using v1 > will probably fail in spectacular ways. > > I have a large IRIX filesystem that I would like to mount on Linux, > but I think it has version 1 directories. Is there any way at all I > can get this to work? > First of all, your Irix filesystem is going to have to meet a few other requirements : o It cannot be xlv or xvm based - there is no linux support for these o the filesystem blocksize needs to be the same as the page size on your linux block, the irix default is 4K, so this is usually not a problem o it should not have the unwritten extent support turned on. You can check the latter 2 with xfs_growfs -n /mnt on irix The directory code should work for the most part, but large directories may suffer problems with readdir on linux - the V1 format passes up 64 bit hash values as directory offsets, and this confuses glibc from time to time. Entries can go missing or you can occassionally get into a loop. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 1 06:31:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11EVxa04432 for linux-xfs-outgoing; Fri, 1 Feb 2002 06:31:59 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11EVtd04410 for ; Fri, 1 Feb 2002 06:31:55 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g11DVh4U097052; Fri, 1 Feb 2002 14:31:48 +0100 (CET) Message-Id: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Feb 2002 14:30:09 +0100 To: "Gabe E. Nydick" , King Kac , From: Seth Mos Subject: Re: undelete - xfsrecover'ing deleted files in xfs In-Reply-To: References: <20020131210325.C966@comotion> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 18:19 31-1-2002 -0800, Gabe E. Nydick wrote: >Pay about 10K anywhere up, depending on the size of the drive to have it >professionally done. Try using grep and dd. I have used that before to rescue data. Unless it's binary data which is really hard to find back. By the time you reboot the box the data may already have been overwritten. XFS reuses the just freed blocks very fast. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Feb 1 06:46:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11Ekpk04812 for linux-xfs-outgoing; Fri, 1 Feb 2002 06:46:51 -0800 Received: from graze.net (graze.net [65.207.24.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Ekjd04783 for ; Fri, 1 Feb 2002 06:46:45 -0800 Received: from graze.net (shepherd.graze.net [127.0.0.1]) by graze.net (8.11.2/8.11.2) with SMTP id g11DggN06275; Fri, 1 Feb 2002 08:42:44 -0500 Received: from 63.118.189.211 (SquirrelMail authenticated user sheep) by graze.net with HTTP; Fri, 1 Feb 2002 08:42:45 -0500 (EST) Message-ID: <61977.63.118.189.211.1012570965.squirrel@graze.net> Date: Fri, 1 Feb 2002 08:42:45 -0500 (EST) Subject: Re: TAKE - fix bitkeeper on xfs From: "Brian C. Huffman" To: In-Reply-To: <200201302055.g0UKtmd17041@jen.americas.sgi.com> References: <200201302055.g0UKtmd17041@jen.americas.sgi.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: Reply-To: sheep@graze.net X-Mailer: SquirrelMail (version 1.2.4) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just an FYI....I was reading this thread with extreme interest and it's looking like I was right. I'm 99.99% sure this fixed the extremely frustrating problem I had been having with VMWare 3.0. This bug surfaced as soon as I installed 2.4.17 and no one until now has been able to say why it was happening, but my Virtual Machine would just commit suicide after about 20 minutes of operation. After this patch, I've been running for 2 days w/o a problem. Thank you! Brian > Date: Wed Jan 30 12:55:07 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:110651a > linux/fs/buffer.c - 1.100 > - Fix up return values used in xfs writepage call, plus a couple > of other tweaks. > > linux/fs/xfs/linux/xfs_iops.c - 1.120 > - Fix up return values used in xfs writepage > > linux/fs/xfs/pagebuf/page_buf_io.c - 1.5 > - No longer return a count of pages written in the write full page > path, > and ensure that we write out pages passed into writepage from the > mmap path. From owner-linux-xfs@oss.sgi.com Fri Feb 1 07:07:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11F7Vh05318 for linux-xfs-outgoing; Fri, 1 Feb 2002 07:07:31 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11F7Qd05296 for ; Fri, 1 Feb 2002 07:07:26 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA05266 for ; Fri, 1 Feb 2002 06:07:13 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA37400; Fri, 1 Feb 2002 08:06:08 -0600 (CST) Received: from sgi.com (wEam5pVZqqYbrMIJ1uLLypn14sMP07NB@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA41230; Fri, 1 Feb 2002 08:06:07 -0600 (CST) Message-ID: <3C5AA0C7.7060706@sgi.com> Date: Fri, 01 Feb 2002 08:05:59 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: sheep@graze.net CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix bitkeeper on xfs References: <200201302055.g0UKtmd17041@jen.americas.sgi.com> <61977.63.118.189.211.1012570965.squirrel@graze.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Brian C. Huffman wrote: >Just an FYI....I was reading this thread with extreme interest and it's >looking like I was right. I'm 99.99% sure this fixed the extremely >frustrating problem I had been having with VMWare 3.0. This bug surfaced as >soon as I installed 2.4.17 and no one until now has been able to say why it >was happening, but my Virtual Machine would just commit suicide after about >20 minutes of operation. > >After this patch, I've been running for 2 days w/o a problem. > >Thank you! >Brian > Yes, it looks like this was a regression in the code introduced sometime in January. I think this time it is running correctly, and I now have a large number of test cases to check before making changes in this area again. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 1 07:16:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11FGKT05654 for linux-xfs-outgoing; Fri, 1 Feb 2002 07:16:20 -0800 Received: from pinga.salk.edu (pinga.salk.edu [192.31.153.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11FGId05632 for ; Fri, 1 Feb 2002 07:16:19 -0800 Received: from xena.salk.edu (xena.salk.edu [192.31.153.191]) by pinga.salk.edu (8.11.6/8.11.6) with SMTP id g11EGGa00526 for ; Fri, 1 Feb 2002 06:16:16 -0800 Date: Fri, 1 Feb 2002 06:16:16 -0800 From: David Chambers To: linux-xfs@oss.sgi.com Subject: Yet another patch question Message-Id: <20020201061616.4b7e70e8.davidc@ccmi.salk.edu> X-Mailer: Sylpheed version 0.7.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk While we are(were!) on the subject of patches, has anyone successfully applied the XFS patch to a rmap12a patched kernel? (or vice versa) Is this even a sane thing to try (okay, no)? I tried yesterday but the few rejects there are look 'orrible - I'm not that good a hacker to figure them out... From owner-linux-xfs@oss.sgi.com Fri Feb 1 08:03:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11G3IZ08146 for linux-xfs-outgoing; Fri, 1 Feb 2002 08:03:18 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11G3Ed08124 for ; Fri, 1 Feb 2002 08:03:14 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g11F36o02509 for ; Fri, 1 Feb 2002 07:03:06 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA38068; Fri, 1 Feb 2002 09:01:50 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA18309; Fri, 1 Feb 2002 09:01:50 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g11ExPU17680; Fri, 1 Feb 2002 08:59:25 -0600 Subject: Re: Yet another patch question From: Steve Lord To: David Chambers Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020201061616.4b7e70e8.davidc@ccmi.salk.edu> References: <20020201061616.4b7e70e8.davidc@ccmi.salk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 08:59:24 -0600 Message-Id: <1012575564.26396.297.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-01 at 08:16, David Chambers wrote: > While we are(were!) on the subject of patches, has anyone successfully > applied the XFS patch to a rmap12a patched kernel? (or vice versa) > > Is this even a sane thing to try (okay, no)? I tried yesterday but the > few rejects there are look 'orrible - I'm not that good a hacker to > figure them out... The tricky part here is that our tree also has kdb in it, if you subtract out kdb then it gets a lot easier in general to apply xfs to other random kernels. Although when it comes to vm changes we have code in buffer.c and vmscan.c which it is essential to get right. kdb patches which you can fairly cleanly reverse apply to an xfs tree are available from oss.sgi.com in projects/kdb. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 09:53:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11HrRB14383 for linux-xfs-outgoing; Fri, 1 Feb 2002 09:53:27 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11HrKd14361 for ; Fri, 1 Feb 2002 09:53:21 -0800 Received: from water.cc.mcgill.ca (water.CC.McGill.CA [132.206.27.29]) 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 IAA04958 for ; Fri, 1 Feb 2002 08:52:52 -0800 (PST) mail_from (kacperw@online.no) Received: from comotion (comotion@[132.216.181.67]) by water.cc.mcgill.ca (8.12.1/8.11.0) with ESMTP id g11GimRG024152 for ; Fri, 1 Feb 2002 11:44:48 -0500 (EST) Date: Fri, 1 Feb 2002 11:47:11 -0500 From: King Kac To: linux-xfs@oss.sgi.com Subject: Re: undelete - xfsrecover'ing deleted files in xfs Message-ID: <20020201114711.A5367@comotion> References: <20020131210325.C966@comotion> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl>; from knuffie@xs4all.nl on Fri, Feb 01, 2002 at 08:30:09 -0500 X-Mailer: Balsa 1.2.3 Lines: 33 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [insert amount of random swearwords] lost data then, eh? 10K is just a little bit above what I can spend, although I was aware of the option :-) Thanks for the help anyways. XFS reuses the freed blocks very fast you say? I'd think that on a striping raid array the blocks wouldn't be as quickly freed... Does this, in essence, mean that if you're stupid and don't back up your data, you lost it forever in xfs? cheers -Kacper On 2002.02.01 08:30 Seth Mos wrote: > At 18:19 31-1-2002 -0800, Gabe E. Nydick wrote: >> Pay about 10K anywhere up, depending on the size of the drive to >> have it >> professionally done. > > Try using grep and dd. I have used that before to rescue data. Unless > it's binary data which is really hard to find back. > > By the time you reboot the box the data may already have been > overwritten. XFS reuses the just freed blocks very fast. > > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > > From owner-linux-xfs@oss.sgi.com Fri Feb 1 10:13:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11IDxD14861 for linux-xfs-outgoing; Fri, 1 Feb 2002 10:13:59 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11IDod14831 for ; Fri, 1 Feb 2002 10:13:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g11HDgY18444 for ; Fri, 1 Feb 2002 09:13:43 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA40034; Fri, 1 Feb 2002 11:12:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA76219; Fri, 1 Feb 2002 11:12:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g11HA0018788; Fri, 1 Feb 2002 11:10:00 -0600 Subject: Re: undelete - xfsrecover'ing deleted files in xfs From: Steve Lord To: King Kac Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020201114711.A5367@comotion> References: <20020131210325.C966@comotion> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <20020201114711.A5367@comotion> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 11:10:00 -0600 Message-Id: <1012583400.26397.373.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-01 at 10:47, King Kac wrote: > [insert amount of random swearwords] > lost data then, eh? 10K is just a little bit above what I can spend, > although I was aware of the option :-) Thanks for the help anyways. > > XFS reuses the freed blocks very fast you say? I'd think that on a > striping raid array the blocks wouldn't be as quickly freed... Does > this, in essence, mean that if you're stupid and don't back up your > data, you lost it forever in xfs? Unfortunately there is no substitute for backups, because xfs uses complex on disk structures it is very difficult to get data back from a file once you remove it. Sure, if you did not allocate anything else in the filesystem it is probably still there, but all the extents which were in the inode have been returned to free space and the inode no longer contains a record of where they were, the inode itself is free too, so finding that is a problem too. There is a reasonable chance that if your files were created at one time (rather than being written in little chunks like a log file) that they were mostly sequential on disk, so finding one part of a file would usually find you the rest of it too. Steve > > cheers > -Kacper > > On 2002.02.01 08:30 Seth Mos wrote: > > At 18:19 31-1-2002 -0800, Gabe E. Nydick wrote: > >> Pay about 10K anywhere up, depending on the size of the drive to > >> have it > >> professionally done. > > > > Try using grep and dd. I have used that before to rescue data. Unless > > it's binary data which is really hard to find back. > > > > By the time you reboot the box the data may already have been > > overwritten. XFS reuses the just freed blocks very fast. > > > > Cheers > > > > -- > > Seth > > Every program has two purposes one for which > > it was written and another for which it wasn't > > I use the last kind. > > > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 10:38:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11Icmc15557 for linux-xfs-outgoing; Fri, 1 Feb 2002 10:38:48 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Ichd15534 for ; Fri, 1 Feb 2002 10:38:43 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g11HcZY22705 for ; Fri, 1 Feb 2002 09:38:35 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA40491; Fri, 1 Feb 2002 11:37:19 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA30276; Fri, 1 Feb 2002 11:37:18 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g11HYqp18821; Fri, 1 Feb 2002 11:34:52 -0600 Subject: RE: nfsd lockups with xfs during SPEC SFS testing From: Steve Lord To: "HABBINGA,ERIK ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 11:34:52 -0600 Message-Id: <1012584892.26363.391.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-01-31 at 16:38, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Steve, > A co-worker of mine sent me a patch containing the CVS bits at 3:21pm > Mountain time 1/30/02, he started the CVS download at 2:37pm Mountain time > 1/30/02 and ended it at 2:38pm Mountain time 1/30/02. I've been working on > a patch to remove the BKL from the nfsd process, and have been seeing > lockups in the xfs code. I saw these lockups with XFS CVS downloads from > 1/10/02 and 1/18/02. I finally started running SPEC tests with out my > nfsd-BKL-removal patch and still got lockups in the XFS code. So, I don't > think this is a regression. > > I ran another test this morning, and got a different profile of lockups. > I've attached the decoded output from alt-sysrq. kupdated is locked up in > xlog_grant_log_space, and all the nfsd processes are locked up either in: > > - fh_lock (all the nfsd3_proc_create->stext_lock->__down_failed->__down > cases) > - nfsd_sync (the nfsd_commit->stext_lock->__down_failed->__down cases) > - pagebuf_grab_lock (the > _pagebuf_find_lockable_buffer->stext_lock->__down_failed->__down cases) > - lock_wait (the xfs_access->mraccessf->lock_wait cases) > - xlog_grant_log_space > > I'll help anyway I can to track this problem down. > > Erik > Are you using anything unusual as the block device here? I would be suspicious of it not coming back with I/O completions. Basically all the places threads are waiting are places we wait blocked for a read or a write to complete. If you have other filesystems on the same device, can you do I/O to them? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 11:03:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11J3RV16061 for linux-xfs-outgoing; Fri, 1 Feb 2002 11:03:27 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11J3Ld16039 for ; Fri, 1 Feb 2002 11:03:21 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g11I3GPC038683; Fri, 1 Feb 2002 19:03:17 +0100 (CET) Message-Id: <4.3.2.7.2.20020201185638.03660ee8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Feb 2002 19:01:38 +0100 To: King Kac , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: undelete - xfsrecover'ing deleted files in xfs In-Reply-To: <20020201114711.A5367@comotion> References: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <20020131210325.C966@comotion> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:47 1-2-2002 -0500, King Kac wrote: >[insert amount of random swearwords] >lost data then, eh? 10K is just a little bit above what I can spend, >although I was aware of the option :-) Thanks for the help anyways. > >XFS reuses the freed blocks very fast you say? I'd think that on a >striping raid array the blocks wouldn't be as quickly freed... Does this, >in essence, mean that if you're stupid and don't back up your data, you >lost it forever in xfs? The odds are against you. Undelete is something that needs to be designed in from the start. That's not possible anymore with XFS. When you delete a file the space that you freed is mostly contigous and thus easily reused for the next file you create. The only that you can do is switch it off as soon as you notice it and then mount the disk read only in another box. Then you start poking it with utilities. If you know the name you might be able to retrieve the file(s). Backups are the only solution to this problem. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Feb 1 11:20:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11JKjn16350 for linux-xfs-outgoing; Fri, 1 Feb 2002 11:20:45 -0800 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11JKed16328 for ; Fri, 1 Feb 2002 11:20:40 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11IKUC10712 for ; Fri, 1 Feb 2002 13:20:30 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11IKSc01748 for ; Fri, 1 Feb 2002 13:20:28 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8Z2Z1D3; Fri, 1 Feb 2002 13:20:22 -0500 Received: from wmery000.ca.nortel.com ([47.131.36.101]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1AADT1SB; Fri, 1 Feb 2002 13:20:22 -0500 Subject: Determining if an XFS FS has been shutdown X-Sybari-Space: 00000000 00000000 00000000 From: "Sean Kormilo" To: Linux XFS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 13:20:22 -0500 Message-Id: <1012587622.23587.37.camel@wmery000.ca.nortel.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm wondering if there is a way I can tell if an XFS filesystem has shut itself down due to errors? I know that logs are generated, but I need a programatic way of doing it and I'd prefer to not have to write a program to parse through the logs. Is there something in /proc? Or is there an XFS command line utility that can tell me when this occurs? Thanks! Sean. -- Sean C. Kormilo, Software Architect, Nortel Networks email: skormilo@nortelnetworks.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 11:33:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11JXl816701 for linux-xfs-outgoing; Fri, 1 Feb 2002 11:33:47 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11JXhd16674 for ; Fri, 1 Feb 2002 11:33:43 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 453A01EC1C; Fri, 1 Feb 2002 19:33:35 +0100 (MET) Date: Fri, 1 Feb 2002 19:33:34 +0100 From: Andi Kleen To: Seth Mos Cc: King Kac , linux-xfs@oss.sgi.com Subject: Re: undelete - xfsrecover'ing deleted files in xfs Message-ID: <20020201193334.A24652@wotan.suse.de> References: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <20020131210325.C966@comotion> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <4.3.2.7.2.20020201185638.03660ee8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20020201185638.03660ee8@pop.xs4all.nl> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 07:01:38PM +0100, Seth Mos wrote: > When you delete a file the space that you freed is mostly contigous and > thus easily reused for the next file you create. If you have enough space left there is nothing that would force reuse of that same space directly afterwards. You could be lucky. When you can find the inode of the deleted file again and its extent btrees are not destroyed it should be possible to reconnect it to a directory. XFS inodes are allocated in chunks of 64 so unless you free a lot of files it is not too unlikely that such a chunk is not completely freed because there is an inode left on it. With that information and some sanity checking it may be possible to write a lsdel function for xfs_db that lists all free inodes in existing chunks that do not look like garbage. When they can be inserted into the inode btree again and xfs_repair is run they should should appear in lost+found. Of course this assumes that there hasn't been that much new IO on the new fs afterwards and doesn't cover all cases, but may be useful for some situations. Just an idea. I don't know how difficult it would be to write an "is this inode garbage" function or to teach xfs_db to insert into btrees (later is probably non trivial). -Andi From owner-linux-xfs@oss.sgi.com Fri Feb 1 12:06:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11K6tl17314 for linux-xfs-outgoing; Fri, 1 Feb 2002 12:06:55 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11K6ld17292 for ; Fri, 1 Feb 2002 12:06:48 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA269402 for ; Fri, 1 Feb 2002 20:06:33 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA41710; Fri, 1 Feb 2002 13:05:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA94634; Fri, 1 Feb 2002 13:05:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g11J2wi18908; Fri, 1 Feb 2002 13:02:58 -0600 Subject: Re: undelete - xfsrecover'ing deleted files in xfs From: Steve Lord To: Andi Kleen Cc: Seth Mos , King Kac , linux-xfs@oss.sgi.com In-Reply-To: <20020201193334.A24652@wotan.suse.de> References: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <20020131210325.C966@comotion> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <4.3.2.7.2.20020201185638.03660ee8@pop.xs4all.nl> <20020201193334.A24652@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 13:02:58 -0600 Message-Id: <1012590178.26396.429.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-01 at 12:33, Andi Kleen wrote: > On Fri, Feb 01, 2002 at 07:01:38PM +0100, Seth Mos wrote: > > When you delete a file the space that you freed is mostly contigous and > > thus easily reused for the next file you create. > > If you have enough space left there is nothing that would force reuse > of that same space directly afterwards. You could be lucky. > > When you can find the inode of the deleted file again and its extent btrees > are not destroyed it should be possible to reconnect it to a directory. Unfortunately when we free an inode we also remove all the extents from it. So even if those extents used to be in the inode, they are not there now. The reason this happens is that deleting a file is an unbounded operation in terms of how complex it is, so it has to be broken up into lots of seperate transactions - and between each transaction the inode needs to be 'correct' so that if we crash in the middle of removing a file we can complete the remove during recovery. So when we unlink a file there is a transaction to put it into a linked list of files to be removed during recovery. Then when its reference count drops to zero we do a sequence of transactions which remove 2 extents each, then finally we do a last transaction to mark the inode free and remove it from the list. Since we never free the inode blocks at all, the inode is definitely still there, there is just not very much in it anymore. Steve > XFS inodes are allocated in chunks of 64 so unless you free a lot of files > it is not too unlikely that such a chunk is not completely freed because > there is an inode left on it. With that information and some sanity checking > it may be possible to write a lsdel function for xfs_db that lists > all free inodes in existing chunks that do not look like garbage. When they > can be inserted into the inode btree again and xfs_repair is run they > should should appear in lost+found. Of course this assumes that there > hasn't been that much new IO on the new fs afterwards and doesn't cover > all cases, but may be useful for some situations. > > Just an idea. I don't know how difficult it would be to write > an "is this inode garbage" function or to teach xfs_db to insert into > btrees (later is probably non trivial). > > -Andi -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 14:40:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11MeLp19715 for linux-xfs-outgoing; Fri, 1 Feb 2002 14:40:21 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11MeEd19690 for ; Fri, 1 Feb 2002 14:40:14 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA278000 for ; Fri, 1 Feb 2002 22:40:01 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA44187; Fri, 1 Feb 2002 15:38:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA21792; Fri, 1 Feb 2002 15:38:53 -0600 (CST) Subject: Re: How long should an xfs_freeze take? From: Eric Sandeen To: Chris Pascoe Cc: linux-xfs@oss.sgi.com In-Reply-To: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> References: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 01 Feb 2002 15:38:53 -0600 Message-Id: <1012599533.10843.20.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Chris - Want to try this? --- /usr/tmp/TmpDir.12545-0/linux/fs/xfs/xfs_fsops.c_1.72 Fri Feb 1 15:33:39 2002 +++ linux/fs/xfs/xfs_fsops.c Fri Feb 1 15:33:51 2002 @@ -563,9 +563,6 @@ /* Flush delalloc and delwri data */ VFS_SYNC(vfsp, SYNC_DELWRI|SYNC_WAIT, sys_cred, error); - /* Flush inactive inodes */ - xfs_iflush_all(mp, XFS_FLUSH_ALL); - /* Pause transaction subsystem */ xfs_start_freeze(mp, XFS_FREEZE_TRANS); It certainly speeds up freeze. And it looks like it still does what it's supposed to do. :) The theory (I think) is that xfs_iflush_all was racing around like mad, waiting for inodes to un-busy, but it was working so hard that the things trying to un-busy the inodes couldn't get in... lather, rinse, repeat. Incidentally, I think that after your 7 hour freeze, things were not in good shape. If I froze, unfroze, then tried to do a "find" through the filesystem, it would blow up - apparently xfs_iflush_all was disconnecting xfs inodes from the linux inodes, and we wound up with null pointer dereferences & oopses. -Eric On Wed, 2002-01-30 at 00:03, Chris Pascoe wrote: > Hi, > > I'm guessing an xfs_freeze shouldn't take this long, am I correct? > > # time xfs_freeze -f /tst1 > > real 344m40.434s > user 0m0.000s > sys 340m40.810s -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Feb 1 15:01:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11N1ql20354 for linux-xfs-outgoing; Fri, 1 Feb 2002 15:01:52 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11N1ld20331 for ; Fri, 1 Feb 2002 15:01:47 -0800 Received: (qmail 22188 invoked by uid 1000); 1 Feb 2002 21:53:52 -0000 Date: Fri, 1 Feb 2002 13:53:51 -0800 To: linux-xfs@oss.sgi.com Subject: xfs + rmap? Message-ID: <20020201215351.GF23997@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm trying to merge Rik van Riel's rmap-12a patch with current CVS, I'm having a couple of problems.. I was wondering if someone could give me a clue how to work these out (or tell me if they can't be) There is a huge hunk of mm/vmscan.c that looks to be totally incompatible, the .rej is about 18 kilobytes. --Adam From owner-linux-xfs@oss.sgi.com Fri Feb 1 15:09:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11N9UX20621 for linux-xfs-outgoing; Fri, 1 Feb 2002 15:09:30 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11N9Od20599 for ; Fri, 1 Feb 2002 15:09:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 OAA25134 for ; Fri, 1 Feb 2002 14:04:58 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA44543; Fri, 1 Feb 2002 16:08:05 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA03152; Fri, 1 Feb 2002 16:08:05 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g11M5b422805; Fri, 1 Feb 2002 16:05:37 -0600 Subject: Re: xfs + rmap? From: Steve Lord To: Adam McKenna Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020201215351.GF23997@flounder.net> References: <20020201215351.GF23997@flounder.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 16:05:36 -0600 Message-Id: <1012601136.26396.452.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-01 at 15:53, Adam McKenna wrote: > I'm trying to merge Rik van Riel's rmap-12a patch with current CVS, I'm > having a couple of problems.. I was wondering if someone could give me a > clue how to work these out (or tell me if they can't be) > > There is a huge hunk of mm/vmscan.c that looks to be totally incompatible, > the .rej is about 18 kilobytes. > > --Adam Well, this is the only change we have in the 2.4.17 vmscan.c --- linux-2.4.17/mm/vmscan.c Fri Dec 21 11:42:05 2001 +++ xfs-linux.2.4/linux/mm/vmscan.c Wed Jan 30 15:49:30 2002 @@ -391,7 +391,7 @@ continue; } - if (PageDirty(page) && is_page_cache_freeable(page) && page->mapping) { + if ((PageDirty(page) || DelallocPage(page)) && is_page_cache_freeable(page) && page->mapping) { /* * It is not critical here to write it only if * the page is unmapped beause any direct writer This is around a call to writepage. There is probably something similar in the rmap version of the kernel. So look for where it deals with dirty pages by calling writepage on them and check for DelallocPage in the same spot. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 15:53:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11NrUW21547 for linux-xfs-outgoing; Fri, 1 Feb 2002 15:53:30 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11NrJd21522 for ; Fri, 1 Feb 2002 15:53:19 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g11MqUk26370; Fri, 1 Feb 2002 16:52:30 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: xfs + rmap? From: Austin Gonyou To: Adam McKenna Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020201215351.GF23997@flounder.net> References: <20020201215351.GF23997@flounder.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5iVMm3Ov6/eJiQ1i1xHm" X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 16:52:30 -0600 Message-Id: <1012603950.25088.72.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-5iVMm3Ov6/eJiQ1i1xHm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'd be happy to help you out. I'm looking to test both -aa and rmap.=20 what is your current procedure for merging this? On Fri, 2002-02-01 at 15:53, Adam McKenna wrote: > I'm trying to merge Rik van Riel's rmap-12a patch with current CVS, I'm > having a couple of problems.. I was wondering if someone could give me > a > clue how to work these out (or tell me if they can't be) >=20 > There is a huge hunk of mm/vmscan.c that looks to be totally > incompatible, > the .rej is about 18 kilobytes. >=20 > --Adam --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-5iVMm3Ov6/eJiQ1i1xHm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Wxwu94g6ZVmFMoIRAr6+AJ98P5oWJrthk3V+R54TY+PNovRp6wCfVv+E lTjXS7ImUJDQYQKsd68sdUc= =nLlD -----END PGP SIGNATURE----- --=-5iVMm3Ov6/eJiQ1i1xHm-- From owner-linux-xfs@oss.sgi.com Fri Feb 1 15:58:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11NwHK21774 for linux-xfs-outgoing; Fri, 1 Feb 2002 15:58:17 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Nw8d21750 for ; Fri, 1 Feb 2002 15:58:08 -0800 Received: (qmail 27165 invoked by uid 1000); 1 Feb 2002 22:50:13 -0000 Date: Fri, 1 Feb 2002 14:50:13 -0800 To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: xfs + rmap? Message-ID: <20020201225013.GH23997@flounder.net> Mail-Followup-To: Austin Gonyou , linux-xfs@oss.sgi.com References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012603950.25088.72.camel@UberGeek> User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 04:52:30PM -0600, Austin Gonyou wrote: > I'd be happy to help you out. I'm looking to test both -aa and rmap. > > what is your current procedure for merging this? Right now I just applied both patches and I am looking at the .rej files. Currently, here are the issues I'm seeing -- I'm using the 2.4.17 snapshot from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/. issue 1 - fs/buffer.c: current code: __mark_buffer_clean(bh); get_bh(bh); set_bit(BH_launder, &bh->b_state); tryagain = write_buffer_locked(bh) == 0; } while ((bh = bh->b_this_page) != head); return tryagain; } .rej file: *************** *** 2533,2542 **** set_bit(BH_launder, &bh->b_state); bh->b_end_io = end_buffer_io_sync; submit_bh(WRITE, bh); - tryagain = 0; } while ((bh = bh->b_this_page) != head); - return tryagain; } /* --- 2525,2533 ---- set_bit(BH_launder, &bh->b_state); bh->b_end_io = end_buffer_io_sync; submit_bh(WRITE, bh); } while ((bh = bh->b_this_page) != head); + return; } /* issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej file. The only other rejections are in Makefile and include/linux/sysctl.h and are both easily fixed. Some patches did apply with a fuzz, I didn't look at them though. I haven't tried building the source yet. --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:02:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1202kk22075 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:02:46 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1202fd22053 for ; Fri, 1 Feb 2002 16:02:42 -0800 Received: (qmail 27518 invoked by uid 1000); 1 Feb 2002 22:54:46 -0000 Date: Fri, 1 Feb 2002 14:54:46 -0800 To: linux-xfs@oss.sgi.com Subject: Re: xfs + rmap? Message-ID: <20020201225446.GI23997@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> <20020201225013.GH23997@flounder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020201225013.GH23997@flounder.net> User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 02:50:13PM -0800, Adam McKenna wrote: > issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej file. If I apply the patches in reverse order (i.e., apply rmap first then xfs), I get the following .rej for vmscan.c: *************** *** 391,397 **** continue; } - if (PageDirty(page) && is_page_cache_freeable(page) && page->mapping) { /* * It is not critical here to write it only if * the page is unmapped beause any direct writer --- 391,397 ---- continue; } + if ((PageDirty(page) || DelallocPage(page)) && is_page_cache_freeable(page) && page->mapping) { /* * It is not critical here to write it only if * the page is unmapped beause any direct writer --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:06:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1206mI22314 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:06:48 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1206dd22290 for ; Fri, 1 Feb 2002 16:06:39 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g11N61P26435; Fri, 1 Feb 2002 17:06:01 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: xfs + rmap? From: Austin Gonyou To: Adam McKenna Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020201225013.GH23997@flounder.net> References: <20020201225013.GH23997@flounder.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0cTiODLxrbO0Zc3KNVdf" X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 17:06:01 -0600 Message-Id: <1012604761.25096.87.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-0cTiODLxrbO0Zc3KNVdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-02-01 at 16:50, Adam McKenna wrote: > On Fri, Feb 01, 2002 at 04:52:30PM -0600, Austin Gonyou wrote: > > I'd be happy to help you out. I'm looking to test both -aa and rmap.=20 > >=20 > > what is your current procedure for merging this? >=20 > Right now I just applied both patches and I am looking at the .rej > files. >=20 > Currently, here are the issues I'm seeing -- I'm using the 2.4.17 > snapshot > from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/. >=20 > issue 1 - fs/buffer.c: >=20 Looks like some rip-n-replace codework there. Should be simple enought. I'd doublecheck this with a vanilla patched kernel just to be sure, but it looks fairly straight forward. >=20 > issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej > file. I'll take a peek and see what's up. Chances are, there's a lot of rip-n-replace here since there's an enourmous chance that a lot of the vmscan.c code is re-worked. When integrating -aa's patch into XFS, I had a 20K .rej, most of which was code that was just located elsewhere. Took a while to find, but I had a lot of replacementcode.=20 >=20 > --=20 > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-0cTiODLxrbO0Zc3KNVdf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Wx9Z94g6ZVmFMoIRAhXpAKDcWD+a/XcemxOSkWddrPY7/7p1owCfT3Fg uhm6aLuDxIgsTqZToJ+wilA= =OH0x -----END PGP SIGNATURE----- --=-0cTiODLxrbO0Zc3KNVdf-- From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:08:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1208vf22462 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:08:57 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1208od22437 for ; Fri, 1 Feb 2002 16:08:50 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g11N83N26454; Fri, 1 Feb 2002 17:08:03 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: xfs + rmap? From: Austin Gonyou To: Adam McKenna Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020201225013.GH23997@flounder.net> References: <20020201225013.GH23997@flounder.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6KSLQKPYg94TybFtxStg" X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 17:08:03 -0600 Message-Id: <1012604883.25088.90.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-6KSLQKPYg94TybFtxStg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-02-01 at 16:50, Adam McKenna wrote: > issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej > file. I just had a look there and it seems I'm correct. I'll bet that you'll just need to find out where the code begins and you can just replace.=20 I had the same problem with vmscan.c and -AA. Not a big deal, but all the xfs code pushed the code needing replacement way out of patche's "fuzz" range.=20 > --=20 > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-6KSLQKPYg94TybFtxStg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Wx/S94g6ZVmFMoIRAhc7AJ9a2a35bPDI1ft85vh/pF/0opAwnACfWchK fTrS/bdjRLEMZmLJKE/fK/8= =FNed -----END PGP SIGNATURE----- --=-6KSLQKPYg94TybFtxStg-- From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:12:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g120C6K22647 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:12:06 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g120Bxd22625 for ; Fri, 1 Feb 2002 16:12:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA274609 for ; Sat, 2 Feb 2002 00:11:34 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA45247; Fri, 1 Feb 2002 17:10:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA05895; Fri, 1 Feb 2002 17:10:34 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g11N86U24074; Fri, 1 Feb 2002 17:08:06 -0600 Subject: Re: xfs + rmap? From: Steve Lord To: Adam McKenna Cc: Austin Gonyou , linux-xfs@oss.sgi.com In-Reply-To: <20020201225013.GH23997@flounder.net> References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> <20020201225013.GH23997@flounder.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 17:08:06 -0600 Message-Id: <1012604886.7434.489.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-01 at 16:50, Adam McKenna wrote: > On Fri, Feb 01, 2002 at 04:52:30PM -0600, Austin Gonyou wrote: > > I'd be happy to help you out. I'm looking to test both -aa and rmap. > > > > what is your current procedure for merging this? > > Right now I just applied both patches and I am looking at the .rej files. > > Currently, here are the issues I'm seeing -- I'm using the 2.4.17 snapshot > from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/. > > issue 1 - fs/buffer.c: > This one is a little nasty in that it seems to remove the possibility of a failure at this point, and with xfs in there we do a write_buffer_locked call in place of the submit_bh we can definitely fail. I am guessing a little bit since I need more context to really work it out, and I am not really feeling like patching up yet another kernel version here. > > issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej file. I think you should just apply the rmap patch to a vanilla kernel and take the resulting vmscan.c, then on the line which does this: if (PageDirty(page) && page->mapping) { right at the end of the patch, change it to: if ((PageDirty(page) || DelallocPage(page)) && page->mapping) { but I would really have to see the whole file to say for sure. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:15:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g120FpX22891 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:15:51 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g120Fed22866 for ; Fri, 1 Feb 2002 16:15:40 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g11NEj426583; Fri, 1 Feb 2002 17:14:45 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: xfs + rmap? From: Austin Gonyou To: linux-xfs@oss.sgi.com In-Reply-To: <1012604886.7434.489.camel@jen.americas.sgi.com> References: <1012604886.7434.489.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-y/rWxxGb3mPuXQgpkt2X" X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 17:14:45 -0600 Message-Id: <1012605285.26510.5.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-y/rWxxGb3mPuXQgpkt2X Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Agreed. That's a vast difference. On Fri, 2002-02-01 at 17:08, Steve Lord wrote: > On Fri, 2002-02-01 at 16:50, Adam McKenna wrote: > > On Fri, Feb 01, 2002 at 04:52:30PM -0600, Austin Gonyou wrote: > > > I'd be happy to help you out. I'm looking to test both -aa and rmap. >=20 > > >=20 > > > what is your current procedure for merging this? > >=20 > > Right now I just applied both patches and I am looking at the .rej > files. > >=20 > > Currently, here are the issues I'm seeing -- I'm using the 2.4.17 > snapshot > > from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/. > >=20 > > issue 1 - fs/buffer.c: > >=20 >=20 > This one is a little nasty in that it seems to remove the possibility of > a failure at this point, and with xfs in there we do a > write_buffer_locked > call in place of the submit_bh we can definitely fail. I am guessing > a little bit since I need more context to really work it out, and I > am not really feeling like patching up yet another kernel version here. >=20 > >=20 > > issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej > file. >=20 > I think you should just apply the rmap patch to a vanilla kernel and > take the resulting vmscan.c, then on the line which does this: >=20 > if (PageDirty(page) && page->mapping) { >=20 > right at the end of the patch, change it to: >=20 > if ((PageDirty(page) || DelallocPage(page)) && page->mapping) { >=20 > but I would really have to see the whole file to say for sure. >=20 > Steve >=20 >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-y/rWxxGb3mPuXQgpkt2X Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8WyFl94g6ZVmFMoIRAvVJAKDfTvKDC3NyaVJOsdZIvNoHv4haWQCg0fUw f1KIsJnYo7vxOIJO0gkR1lI= =cyti -----END PGP SIGNATURE----- --=-y/rWxxGb3mPuXQgpkt2X-- From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:18:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g120IXA23040 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:18:33 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g120IPd23016 for ; Fri, 1 Feb 2002 16:18:25 -0800 Received: (qmail 29055 invoked by uid 1000); 1 Feb 2002 23:10:30 -0000 Date: Fri, 1 Feb 2002 15:10:30 -0800 To: linux-xfs@oss.sgi.com Subject: Re: xfs + rmap? Message-ID: <20020201231030.GJ23997@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> <20020201225013.GH23997@flounder.net> <1012604886.7434.489.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012604886.7434.489.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 05:08:06PM -0600, Steve Lord wrote: > On Fri, 2002-02-01 at 16:50, Adam McKenna wrote: > > On Fri, Feb 01, 2002 at 04:52:30PM -0600, Austin Gonyou wrote: > > > I'd be happy to help you out. I'm looking to test both -aa and rmap. > > > > > > what is your current procedure for merging this? > > > > Right now I just applied both patches and I am looking at the .rej files. > > > > Currently, here are the issues I'm seeing -- I'm using the 2.4.17 snapshot > > from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/. > > > > issue 1 - fs/buffer.c: > > > > This one is a little nasty in that it seems to remove the possibility of > a failure at this point, and with xfs in there we do a write_buffer_locked > call in place of the submit_bh we can definitely fail. I am guessing > a little bit since I need more context to really work it out, and I > am not really feeling like patching up yet another kernel version here. How many have you patched up so far? Does the list include an -ac? :) > > issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej file. > > I think you should just apply the rmap patch to a vanilla kernel and > take the resulting vmscan.c, then on the line which does this: > > if (PageDirty(page) && page->mapping) { > > right at the end of the patch, change it to: > > if ((PageDirty(page) || DelallocPage(page)) && page->mapping) { > > but I would really have to see the whole file to say for sure. Here's the rmap12 code: if (PageDirty(page) && page->mapping) { /* * It is not critical here to write it only if * the page is unmapped beause any direct writer * like O_DIRECT would set the PG_dirty bitflag * on the physical page after having successfully * pinned it and after the I/O to the page is finished, * so the direct writes to the page cannot get lost. */ int (*writepage)(struct page *); writepage = page->mapping->a_ops->writepage; if ((gfp_mask & __GFP_FS) && writepage) { ClearPageDirty(page); SetPageLaunder(page); page_cache_get(page); spin_unlock(&pagemap_lru_lock); writepage(page); page_cache_release(page); spin_lock(&pagemap_lru_lock); continue; } } Does that help? --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:32:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g120WSY23331 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:32:28 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g120WId23307 for ; Fri, 1 Feb 2002 16:32:18 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g11NWAo14525 for ; Fri, 1 Feb 2002 15:32:10 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA45481; Fri, 1 Feb 2002 17:30:51 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA09658; Fri, 1 Feb 2002 17:30:51 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g11NSM324098; Fri, 1 Feb 2002 17:28:22 -0600 Subject: Re: xfs + rmap? From: Steve Lord To: Adam McKenna Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020201231030.GJ23997@flounder.net> References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> <20020201225013.GH23997@flounder.net> <1012604886.7434.489.camel@jen.americas.sgi.com> <20020201231030.GJ23997@flounder.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 17:28:22 -0600 Message-Id: <1012606102.26396.494.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-01 at 17:10, Adam McKenna wrote: > On Fri, Feb 01, 2002 at 05:08:06PM -0600, Steve Lord wrote: > > On Fri, 2002-02-01 at 16:50, Adam McKenna wrote: > > > On Fri, Feb 01, 2002 at 04:52:30PM -0600, Austin Gonyou wrote: > > > > I'd be happy to help you out. I'm looking to test both -aa and rmap. > > > > > > > > what is your current procedure for merging this? > > > > > > Right now I just applied both patches and I am looking at the .rej files. > > > > > > Currently, here are the issues I'm seeing -- I'm using the 2.4.17 snapshot > > > from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/. > > > > > > issue 1 - fs/buffer.c: > > > > > > > This one is a little nasty in that it seems to remove the possibility of > > a failure at this point, and with xfs in there we do a write_buffer_locked > > call in place of the submit_bh we can definitely fail. I am guessing > > a little bit since I need more context to really work it out, and I > > am not really feeling like patching up yet another kernel version here. > > How many have you patched up so far? Does the list include an -ac? :) The rpms on oss.sgi.com are -ac kernels. > > > > issue 2 - vmscan.c - see http://flounder.net/vmscan.c.rej for the .rej file. > > > > I think you should just apply the rmap patch to a vanilla kernel and > > take the resulting vmscan.c, then on the line which does this: > > > > if (PageDirty(page) && page->mapping) { > > > > right at the end of the patch, change it to: > > > > if ((PageDirty(page) || DelallocPage(page)) && page->mapping) { > > > > but I would really have to see the whole file to say for sure. > > Here's the rmap12 code: > > if (PageDirty(page) && page->mapping) { > /* > * It is not critical here to write it only if > * the page is unmapped beause any direct writer > * like O_DIRECT would set the PG_dirty bitflag > * on the physical page after having successfully > * pinned it and after the I/O to the page is finished, > * so the direct writes to the page cannot get lost. > */ > int (*writepage)(struct page *); > > writepage = page->mapping->a_ops->writepage; > if ((gfp_mask & __GFP_FS) && writepage) { > ClearPageDirty(page); > SetPageLaunder(page); > page_cache_get(page); > spin_unlock(&pagemap_lru_lock); > > writepage(page); > page_cache_release(page); > > spin_lock(&pagemap_lru_lock); > continue; > } > } > > Does that help? Yep, just add the DelallocPage(page) test as I described. Steve > > --Adam > > -- > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 1 16:34:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g120Y2023418 for linux-xfs-outgoing; Fri, 1 Feb 2002 16:34:02 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g120Y0d23396 for ; Fri, 1 Feb 2002 16:34:00 -0800 Received: (qmail 349 invoked by uid 1000); 1 Feb 2002 23:26:04 -0000 Date: Fri, 1 Feb 2002 15:26:04 -0800 To: linux-xfs@oss.sgi.com Subject: Re: xfs + rmap? Message-ID: <20020201232604.GK23997@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> <20020201225013.GH23997@flounder.net> <1012604886.7434.489.camel@jen.americas.sgi.com> <20020201231030.GJ23997@flounder.net> <1012606102.26396.494.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012606102.26396.494.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 05:28:22PM -0600, Steve Lord wrote: > The rpms on oss.sgi.com are -ac kernels. Including the 2.4.14 one? > > Does that help? > > Yep, just add the DelallocPage(page) test as I described. OK, thanks.. Just one more to go :) --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Fri Feb 1 17:02:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1212AV24094 for linux-xfs-outgoing; Fri, 1 Feb 2002 17:02:10 -0800 Received: from router.localnet (dsl-att1-114-161.sb.101freeway.net [12.44.114.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12126d24072 for ; Fri, 1 Feb 2002 17:02:06 -0800 Received: from satan (mrbill.localnet [172.16.1.1]) by router.localnet (8.11.6/8.11.1) with SMTP id g1202UV20771 for ; Fri, 1 Feb 2002 16:02:30 -0800 (PST) (envelope-from chandra@ssl.org) Message-Id: <3.0.3.32.20020201160710.01248740@172.16.0.1> X-Sender: chandra@172.16.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 01 Feb 2002 16:07:10 -0800 To: linux-xfs@oss.sgi.com From: "Kevin M. Kilbride" Subject: Re: xfs + rmap? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 03:10 PM 2/1/2002 -0800, you wrote: >How many have you patched up so far? Does the list include an -ac? :) I have. Started with 2.4.17 and applied -pre7-ac2. Patching in XFS to that hybrid was pretty much the same scenario as has been described above. Of course, I subsequently applied the kaio and post/wait patches, which took a bit more work (make sure you don't miss include/asm/unistd.h). Mild torture testing of said kernel has yet to uncover any instability, but please don't make any serious bets, as I'm using gcc-3.0.3 to compile everything (including glibc). | Kevin M. Kilbride | Sapient Systems Laboratories | 259-B Burton Mesa Blvd. | Lompoc, CA 93436-1471 | chandra@ssl.org From owner-linux-xfs@oss.sgi.com Fri Feb 1 17:04:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1214Hf24186 for linux-xfs-outgoing; Fri, 1 Feb 2002 17:04:17 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12145d24140 for ; Fri, 1 Feb 2002 17:04:05 -0800 Received: (qmail 2410 invoked by uid 1000); 1 Feb 2002 23:56:10 -0000 Date: Fri, 1 Feb 2002 15:56:09 -0800 To: linux-xfs@oss.sgi.com Subject: Re: xfs + rmap? Message-ID: <20020201235609.GM23997@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> <20020201225013.GH23997@flounder.net> <1012604886.7434.489.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012604886.7434.489.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 05:08:06PM -0600, Steve Lord wrote: > > issue 1 - fs/buffer.c: > > > > This one is a little nasty in that it seems to remove the possibility of > a failure at this point, and with xfs in there we do a write_buffer_locked > call in place of the submit_bh we can definitely fail. I am guessing > a little bit since I need more context to really work it out, and I > am not really feeling like patching up yet another kernel version here. After looking at the code, it seems like leaving the XFS sync_page_buffers code in as-is would be the right thing to do here and probably would not have any adverse effects, however I'm not even a C programmer, much less a kernel programmer, so I'm not 100% comfortable making that call. Any comments would be appreciated. Here are the two code snippets for informational value: rmap12: static void sync_page_buffers(struct buffer_head *head) { struct buffer_head * bh = head; do { if (!buffer_dirty(bh) && !buffer_locked(bh)) continue; /* Don't start IO first time around.. */ if (!test_and_set_bit(BH_Wait_IO, &bh->b_state)) continue; /* If we cannot lock the buffer just skip it. */ if (test_and_set_bit(BH_Lock, &bh->b_state)) continue; /* Second time through we start actively writing out.. */ if (!atomic_set_buffer_clean(bh)) { unlock_buffer(bh); continue; } __mark_buffer_clean(bh); get_bh(bh); set_bit(BH_launder, &bh->b_state); bh->b_end_io = end_buffer_io_sync; submit_bh(WRITE, bh); } while ((bh = bh->b_this_page) != head); return; } xfs: static int sync_page_buffers(struct buffer_head *head) { struct buffer_head * bh = head; int tryagain = 0; do { if (!buffer_dirty(bh) && !buffer_locked(bh)) continue; /* Don't start IO first time around.. */ if (!test_and_set_bit(BH_Wait_IO, &bh->b_state)) continue; /* Second time through we start actively writing out.. */ if (test_and_set_bit(BH_Lock, &bh->b_state)) { if (!test_bit(BH_launder, &bh->b_state)) continue; wait_on_buffer(bh); tryagain = 1; continue; } if (!atomic_set_buffer_clean(bh)) { unlock_buffer(bh); continue; } __mark_buffer_clean(bh); get_bh(bh); set_bit(BH_launder, &bh->b_state); tryagain = write_buffer_locked(bh) == 0; } while ((bh = bh->b_this_page) != head); return tryagain; } called by: if (sync_page_buffers(bh)) { /* no IO or waiting next time */ gfp_mask = 0; goto cleaned_buffers_try_again; } --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Fri Feb 1 17:05:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1215Yq24295 for linux-xfs-outgoing; Fri, 1 Feb 2002 17:05:34 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1215Td24273 for ; Fri, 1 Feb 2002 17:05:29 -0800 Received: (qmail 3181 invoked from network); 2 Feb 2002 00:05:24 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Feb 2002 00:05:24 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 595843000B8; Sat, 2 Feb 2002 11:05:23 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2DA958E; Sat, 2 Feb 2002 11:05:23 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Steve Lord Cc: David Chambers , linux-xfs@oss.sgi.com Subject: Re: Yet another patch question In-reply-to: Your message of "01 Feb 2002 08:59:24 MDT." <1012575564.26396.297.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Feb 2002 11:05:17 +1100 Message-ID: <16452.1012608317@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 01 Feb 2002 08:59:24 -0600, Steve Lord wrote: >On Fri, 2002-02-01 at 08:16, David Chambers wrote: >> While we are(were!) on the subject of patches, has anyone successfully >> applied the XFS patch to a rmap12a patched kernel? (or vice versa) > >The tricky part here is that our tree also has kdb in it, if you >subtract out kdb then it gets a lot easier in general to apply >xfs to other random kernels. kdb v2.1 (in current xfs tree) should not be a problem with vm changes, I removed the kdb dependency on the vm source code. Module kdb/kdbm_vm.c will be a problem for rmap, so patch kdb/modules/Makefile to remove kdbm_vm.o and just don't build it. >Although when it comes to vm changes >we have code in buffer.c and vmscan.c which it is essential to >get right. /me runs away ;) From owner-linux-xfs@oss.sgi.com Fri Feb 1 17:07:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12172824471 for linux-xfs-outgoing; Fri, 1 Feb 2002 17:07:02 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12170d24449 for ; Fri, 1 Feb 2002 17:07:00 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00506 for ; Fri, 1 Feb 2002 16:08:01 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA55835; Fri, 1 Feb 2002 16:02:12 -0800 (PST) Date: Fri, 1 Feb 2002 18:02:09 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Adam McKenna cc: Subject: Re: xfs + rmap? In-Reply-To: <20020201232604.GK23997@flounder.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 1 Feb 2002, Adam McKenna wrote: > On Fri, Feb 01, 2002 at 05:28:22PM -0600, Steve Lord wrote: > > The rpms on oss.sgi.com are -ac kernels. > > Including the 2.4.14 one? Nope, only the "RH" ones are based on -ac. 2.4.14 is pure, unalancoxified Linux. -Eric From owner-linux-xfs@oss.sgi.com Fri Feb 1 17:34:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g121Yfx24934 for linux-xfs-outgoing; Fri, 1 Feb 2002 17:34:41 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g121YXd24912 for ; Fri, 1 Feb 2002 17:34:33 -0800 Received: (qmail 4620 invoked by uid 1000); 2 Feb 2002 00:26:36 -0000 Date: Fri, 1 Feb 2002 16:26:36 -0800 To: linux-xfs@oss.sgi.com Subject: Re: xfs + rmap? Message-ID: <20020202002636.GP23997@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020201215351.GF23997@flounder.net> <1012603950.25088.72.camel@UberGeek> <20020201225013.GH23997@flounder.net> <1012604886.7434.489.camel@jen.americas.sgi.com> <20020201235609.GM23997@flounder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020201235609.GM23997@flounder.net> User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 03:56:09PM -0800, Adam McKenna wrote: > After looking at the code, it seems like leaving the XFS sync_page_buffers > code in as-is OK, scratch that.. There are a couple of other functions that are missing now. I'm going to go ahead with the rmap12 code for now and do some testing. I did get a successful compile. --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Fri Feb 1 17:55:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g121tZg25320 for linux-xfs-outgoing; Fri, 1 Feb 2002 17:55:35 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g121tWd25297 for ; Fri, 1 Feb 2002 17:55:32 -0800 Received: (qmail 3037 invoked from network); 2 Feb 2002 00:57:34 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 2 Feb 2002 00:57:34 -0000 Subject: Re: xfs + rmap? From: Shawn Starr To: linux-xfs@oss.sgi.com In-Reply-To: <20020201215351.GF23997@flounder.net> References: <20020201215351.GF23997@flounder.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 01 Feb 2002 19:57:33 -0500 Message-Id: <1012611454.26769.10.camel@coredump> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk rmap12a radically changes vmscan.c. Shawn. On Fri, 2002-02-01 at 16:53, Adam McKenna wrote: > I'm trying to merge Rik van Riel's rmap-12a patch with current CVS, I'm > having a couple of problems.. I was wondering if someone could give me a > clue how to work these out (or tell me if they can't be) > > There is a huge hunk of mm/vmscan.c that looks to be totally incompatible, > the .rej is about 18 kilobytes. > > --Adam > > From owner-linux-xfs@oss.sgi.com Fri Feb 1 20:52:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g124qmU27952 for linux-xfs-outgoing; Fri, 1 Feb 2002 20:52:48 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g124qid27930 for ; Fri, 1 Feb 2002 20:52:44 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 8B52BC001C2 for ; Sat, 2 Feb 2002 11:52:39 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 4C333C001C1 for ; Sat, 2 Feb 2002 11:52:38 +0800 (PHT) Date: Sat, 2 Feb 2002 11:52:38 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes In-Reply-To: <20020201101545.G88469@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 1 Feb 2002 at 10:15, Nathan Scott wrote: > Yes, the ondisk formats remain unchanged, incl. the ondisk ACL format > (which is also the same as the IRIX/XFS Posix ACL format). So setups utilizing ACLs won't have to be redone, right? As long as we make sure that when we upgrade to an XFS-enabled kernel using the new system calls we also upgrade the userland stuff or we won't be able to modify or view the ACL rules. Did I get things correctly? :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg From owner-linux-xfs@oss.sgi.com Fri Feb 1 21:11:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g125BB128390 for linux-xfs-outgoing; Fri, 1 Feb 2002 21:11:11 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g125B7d28368 for ; Fri, 1 Feb 2002 21:11:07 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9658E1E07B; Sat, 2 Feb 2002 05:10:59 +0100 (MET) Date: Sat, 2 Feb 2002 05:10:59 +0100 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , Seth Mos , King Kac , linux-xfs@oss.sgi.com Subject: Re: undelete - xfsrecover'ing deleted files in xfs Message-ID: <20020202051059.A32003@wotan.suse.de> References: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <20020131210325.C966@comotion> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <4.3.2.7.2.20020201185638.03660ee8@pop.xs4all.nl> <20020201193334.A24652@wotan.suse.de> <1012590178.26396.429.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012590178.26396.429.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 01:02:58PM -0600, Steve Lord wrote: > > When you can find the inode of the deleted file again and its extent btrees > > are not destroyed it should be possible to reconnect it to a directory. > > Unfortunately when we free an inode we also remove all the extents from > it. So even if those extents used to be in the inode, they are not there > now. The reason this happens is that deleting a file is an unbounded I see. The extents would be in a btree which would be likely rebalanced on the extent freeing and that would destroy them because they're inline in the btree. Is that correct? Thanks, -Andi From owner-linux-xfs@oss.sgi.com Fri Feb 1 23:39:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g127d2T30710 for linux-xfs-outgoing; Fri, 1 Feb 2002 23:39:02 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g127ctd30686 for ; Fri, 1 Feb 2002 23:38:55 -0800 Received: from erbenson.alaska.net (112-pm14.nwc.alaska.net [209.112.141.112]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g126cps33791 for ; Fri, 1 Feb 2002 21:38:51 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id DB1083989 for ; Fri, 1 Feb 2002 21:38:49 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id ECF421023C; Fri, 1 Feb 2002 21:38:49 -0900 (AKST) Date: Fri, 1 Feb 2002 21:38:49 -0900 From: Ethan Benson To: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020201213849.Y14742@plato.local.lan> Mail-Followup-To: Linux XFS Mailing List References: <20020201101545.G88469@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DejVYFcqCV4p9T4J" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Sat, Feb 02, 2002 at 11:52:38AM +0800 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --DejVYFcqCV4p9T4J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 02, 2002 at 11:52:38AM +0800, Federico Sevilla III wrote: > On Fri, 1 Feb 2002 at 10:15, Nathan Scott wrote: > > Yes, the ondisk formats remain unchanged, incl. the ondisk ACL format > > (which is also the same as the IRIX/XFS Posix ACL format). >=20 > So setups utilizing ACLs won't have to be redone, right? As long as we > make sure that when we upgrade to an XFS-enabled kernel using the new > system calls we also upgrade the userland stuff or we won't be able to > modify or view the ACL rules. Did I get things correctly? :) for XFS at least yes. on disk format is unchanged, only the syscalls are different. however it looks like only the extended attributes syscalls have been added to 2.5, there is still no ACL interface. I assume that the ACL userspace will have to change a second time when that API is accepted into the mainline kernel? has the ACL api been more or less agreed on yet? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --DejVYFcqCV4p9T4J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxbiXkACgkQJKx7GixEevzdPACeJ/W0y4pIG0BP/R53DGuVX9nQ 5NAAn2XbNhzMOmKqTu13TgZTrcRCVBV4 =saga -----END PGP SIGNATURE----- --DejVYFcqCV4p9T4J-- From owner-linux-xfs@oss.sgi.com Fri Feb 1 23:58:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g127wYu31094 for linux-xfs-outgoing; Fri, 1 Feb 2002 23:58:34 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g127wQd31072 for ; Fri, 1 Feb 2002 23:58:26 -0800 Received: from box.csee.uq.edu.au (box.csee.uq.edu.au [130.102.79.1]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g126wI726685 for ; Sat, 2 Feb 2002 16:58:18 +1000 (EST) Received: (from nobody@localhost) by box.csee.uq.edu.au (8.11.6/8.11.6) id g126wIL05529 for linux-xfs@oss.sgi.com; Sat, 2 Feb 2002 16:58:18 +1000 (EST) X-Authentication-Warning: box.csee.uq.edu.au: nobody set sender to c.pascoe@itee.uq.edu.au using -f Received: from escher.dstc.edu.au ( [escher.dstc.edu.au]) as user chrisp@imaphost.itee.uq.edu.au by internal.itee.uq.edu.au with HTTP; Sat, 2 Feb 2002 16:58:18 +1000 Message-ID: <1012633098.3c5b8e0a3079f@internal.itee.uq.edu.au> Date: Sat, 2 Feb 2002 16:58:18 +1000 From: Chris Pascoe To: linux-xfs@oss.sgi.com Subject: Permit xfs_repair -n on readonly device MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 130.102.176.6 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, May I suggest this patch to xfs_repair - to make a "xfs_repair -n" actually open the device read-only. This permits running an xfs_repair -n over a readonly snapshot to check if the snapshot is okay. It should be safe to do, as a nomodify repair shouldn't be modifying the filesystem anyway. [root@toy xfs-cmd-20020122]# cvs diff -u cmd/xfsprogs/repair/io.c Index: xfsprogs/repair/io.c =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/repair/io.c,v retrieving revision 1.2 diff -u -r1.2 io.c --- cmd/xfsprogs/repair/io.c 2001/05/09 06:56:06 1.2 +++ cmd/xfsprogs/repair/io.c 2002/02/02 07:46:45 @@ -45,7 +45,7 @@ ASSERT(fs_name != NULL && *fs_name != '\0'); - if ((fs_fd = open (fs_name, O_RDWR)) < 0) { + if ((fs_fd = open (fs_name, (no_modify ? O_RDONLY : O_RDWR))) < 0) { do_error("couldn't open filesystem \"%s\"\n", fs_name); } Regards, Chris From owner-linux-xfs@oss.sgi.com Sat Feb 2 00:02:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1282W431326 for linux-xfs-outgoing; Sat, 2 Feb 2002 00:02:32 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1282Od31304 for ; Sat, 2 Feb 2002 00:02:25 -0800 Received: from box.csee.uq.edu.au (box.csee.uq.edu.au [130.102.79.1]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g1272I727008; Sat, 2 Feb 2002 17:02:18 +1000 (EST) Received: (from nobody@localhost) by box.csee.uq.edu.au (8.11.6/8.11.6) id g1272IA05553; Sat, 2 Feb 2002 17:02:18 +1000 (EST) X-Authentication-Warning: box.csee.uq.edu.au: nobody set sender to c.pascoe@itee.uq.edu.au using -f Received: from escher.dstc.edu.au ( [escher.dstc.edu.au]) as user chrisp@imaphost.itee.uq.edu.au by internal.itee.uq.edu.au with HTTP; Sat, 2 Feb 2002 17:02:18 +1000 Message-ID: <1012633338.3c5b8efa71736@internal.itee.uq.edu.au> Date: Sat, 2 Feb 2002 17:02:18 +1000 From: Chris Pascoe To: Eric Sandeen Cc: Linux XFS Mailing List Subject: Re: How long should an xfs_freeze take? References: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> <1012599533.10843.20.camel@stout.americas.sgi.com> In-Reply-To: <1012599533.10843.20.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 130.102.176.6 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Quoting Eric Sandeen : > Want to try this? > [ Patch to remove xfs_iflush_all call ] > It certainly speeds up freeze. And it looks like it still > does what it's supposed to do. :) Seems to speed everything up here too - after my initial rsync, the freeze takes next to no time! xfs_repair -n's on a snapshot taken just after the freeze seem to suggest everything on the filesystem is consistent too... [root@toy tst1]# rsync -aH -e ssh root@fs:/home/01/ /tst1/ ... [root@toy tst1]# time xfs_freeze -f /tst1 ; xfs_freeze -u /tst1 real 0m0.882s user 0m0.000s sys 0m0.850s If I then proceed to run a find across the fs, I see a slightly increased time to run: [root@toy tst1]# find /tst1 > /dev/null ; time xfs_freeze -f /tst1 ; real 0m23.288s user 0m0.000s sys 0m0.840s But it returns to normal immediately after that: [root@toy tst1]# xfs_freeze -u /tst1 ; time xfs_freeze -f /tst1 real 0m0.372s user 0m0.000s sys 0m0.370s I'm guessing that lengthened freeze is caused by having to sync all the inodes with updated atimes to disk, but as it never exceeds 22 seconds on my filesystem, I'm happy :). > Incidentally, I think that after your 7 hour freeze, things were > not in good shape. If I froze, unfroze, then tried to do a > "find" through the filesystem, it would blow up - apparently > xfs_iflush_all was disconnecting xfs inodes from the linux > inodes, and we wound up with null pointer dereferences & oopses. I must admit, I hadn't actually tried working with the filesystem after going through a long freeze. I was too busy doing the freeze again to make sure I could replicate the problem before reporting it :). Thanks, Chris From owner-linux-xfs@oss.sgi.com Sat Feb 2 02:01:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12A1Gr00401 for linux-xfs-outgoing; Sat, 2 Feb 2002 02:01:16 -0800 Received: from HOLYBOY.SYMMSYS.COM (usr561@[216.51.91.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12A0id32730 for ; Sat, 2 Feb 2002 02:00:44 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1AACB.1DB50131" Subject: RE: XFS SB Validate error content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 31 Jan 2002 21:49:49 -0500 Message-ID: <29800F5ABF5EAC42998190CFF1846AA303C8C7@symlab0-srvr1.SYMMETRY.SYMMSYS.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS SB Validate error Thread-Index: AcGqyMWc2aJ+ekZYQCK4AQhG33axqgAAo9rQ From: "Yom, Francis" To: "Eric Sandeen" Cc: , , Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1AACB.1DB50131 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Eric, Here is the relevant info from syslog: Jan 31 17:21:09 sera kernel: EFSCORRUPTED returned from file xfs_ialloc.c line 1265 Jan 31 17:21:09 sera kernel: xfs_force_shutdown(ide0(3,9),0x8) called from line 1020 of file xfs_trans.c. Return address =3D 0xc02256df Jan 31 17:21:09 sera gconfd (0fyom-1211): Failed to delete old file '/home/users/0fyom/.gconf/apps/galeon/State/prefs_dialog/%gconf.xml.old' : Unknown error 990 Jan 31 17:21:09 sera gconfd (0fyom-1211): Failed to log removal of listener to logfile (most likely harmless, may result in a notification weirdly reappearing): Failed: Failed to open gconfd logfile; won't be able to restore listeners after gconfd shutdown (Input/output error) Jan 31 17:21:09 sera kernel: Corruption of in-memory data detected. Shutting down filesystem: ide0(3,9) Jan 31 17:21:09 sera kernel: Please umount the filesystem, and rectify the problem(s) Jan 31 17:21:09 sera gconfd (0fyom-1211): Failed to log removal of listener to logfile (most likely harmless, may result in a notification weirdly reappearing): Failed: Failed to open gconfd logfile; won't be able to restore listeners after gconfd shutdown (Input/output error) Let me know what you think. Many thanks for your quick reply! Francis -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com]=20 Sent: Thursday, January 31, 2002 9:38 PM To: Yom, Francis Cc: linux-xfs@oss.sgi.com; lord@sgi.com; spstarr@sh0n.net Subject: Re: XFS SB Validate error On Thu, 31 Jan 2002, Yom, Francis wrote: > I have been very happy with XFS and had no problems with it so far. I > have been using this kernel for 2 weeks now, but have been working=20 > with XFS since 2.4.14. Today, while working in my XP VMWare session,=20 > I got an error saying that VMWare could not contact the disk drive. I > went to an X console and checked my syslog and discovered that my=20 > /home partition (3,9) was unmounted my XFS because of a bad=20 > superblock. I had the dreaded SB Validate problem as stated in the=20 > FAQ. Were there any messages in the log about a forced filesystem shutdown? -Eric ------_=_NextPart_001_01C1AACB.1DB50131 Content-Type: text/plain; name="xfserror.txt" Content-Transfer-Encoding: base64 Content-Description: xfserror.txt Content-Disposition: attachment; filename="xfserror.txt" SmFuIDMxIDE3OjIxOjA5IHNlcmEga2VybmVsOiBFRlNDT1JSVVBURUQgcmV0 dXJuZWQgZnJvbSBmaWxlIHhmc19pYWxsb2MuYyBsaW5lIDEyNjUKSmFuIDMx IDE3OjIxOjA5IHNlcmEga2VybmVsOiB4ZnNfZm9yY2Vfc2h1dGRvd24oaWRl MCgzLDkpLDB4OCkgY2FsbGVkIGZyb20gbGluZSAxMDIwIG9mIGZpbGUgeGZz X3RyYW5zLmMuICBSZXR1cm4gYWRkcmVzcyA9IDB4YzAyMjU2ZGYKSmFuIDMx IDE3OjIxOjA5IHNlcmEgZ2NvbmZkICgwZnlvbS0xMjExKTogRmFpbGVkIHRv IGRlbGV0ZSBvbGQgZmlsZSCRL2hvbWUvdXNlcnMvMGZ5b20vLmdjb25mL2Fw cHMvZ2FsZW9uL1N0YXRlL3ByZWZzX2RpYWxvZy8lZ2NvbmYueG1sLm9sZJI6 IFVua25vd24gZXJyb3IgOTkwCkphbiAzMSAxNzoyMTowOSBzZXJhIGdjb25m ZCAoMGZ5b20tMTIxMSk6IEZhaWxlZCB0byBsb2cgcmVtb3ZhbCBvZiBsaXN0 ZW5lciB0byBsb2dmaWxlIChtb3N0IGxpa2VseSBoYXJtbGVzcywgbWF5IHJl c3VsdCBpbiBhIG5vdGlmaWNhdGlvbiB3ZWlyZGx5IHJlYXBwZWFyaW5nKTog RmFpbGVkOiAgRmFpbGVkIHRvIG9wZW4gZ2NvbmZkIGxvZ2ZpbGU7IHdvbpJ0 IGJlIGFibGUgdG8gcmVzdG9yZSBsaXN0ZW5lcnMgYWZ0ZXIgZ2NvbmZkIHNo dXRkb3duIChJbnB1dC9vdXRwdXQgZXJyb3IpCkphbiAzMSAxNzoyMTowOSBz ZXJhIGtlcm5lbDogQ29ycnVwdGlvbiBvZiBpbi1tZW1vcnkgZGF0YSBkZXRl Y3RlZC4gIFNodXR0aW5nIGRvd24gZmlsZXN5c3RlbTogaWRlMCgzLDkpCkph biAzMSAxNzoyMTowOSBzZXJhIGtlcm5lbDogUGxlYXNlIHVtb3VudCB0aGUg ZmlsZXN5c3RlbSwgYW5kIHJlY3RpZnkgdGhlIHByb2JsZW0ocykKSmFuIDMx IDE3OjIxOjA5IHNlcmEgZ2NvbmZkICgwZnlvbS0xMjExKTogRmFpbGVkIHRv IGxvZyByZW1vdmFsIG9mIGxpc3RlbmVyIHRvIGxvZ2ZpbGUgKG1vc3QgbGlr ZWx5IGhhcm1sZXNzLCBtYXkgcmVzdWx0IGluIGEgbm90aWZpY2F0aW9uIHdl aXJkbHkgcmVhcHBlYXJpbmcpOiBGYWlsZWQ6ICBGYWlsZWQgdG8gb3BlbiBn Y29uZmQgbG9nZmlsZTsgd29uknQgYmUgYWJsZSB0byByZXN0b3JlIGxpc3Rl bmVycyBhZnRlciBnY29uZmQgc2h1dGRvd24gKElucHV0L291dHB1dCBlcnJv cikKSmFuIDMxIDE3OjIyOjE5IHNlcmEgbmFtZWRbMjk2XTogQ2xlYW5lZCBj YWNoZSBvZiAwIFJSc2V0cw== ------_=_NextPart_001_01C1AACB.1DB50131-- From owner-linux-xfs@oss.sgi.com Sat Feb 2 02:00:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12A0rP32762 for linux-xfs-outgoing; Sat, 2 Feb 2002 02:00:53 -0800 Received: from HOLYBOY.SYMMSYS.COM (usr561@[216.51.91.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12A0jd32733 for ; Sat, 2 Feb 2002 02:00:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: XFS SB Validate error content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 31 Jan 2002 22:31:53 -0500 Message-ID: <29800F5ABF5EAC42998190CFF1846AA303C8C8@symlab0-srvr1.SYMMETRY.SYMMSYS.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS SB Validate error Thread-Index: AcGqzV3bug2SBzyvTgiLZqZzTO5fVgAAswyw From: "Yom, Francis" To: "Eric Sandeen" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g12A0jd32734 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, In /usr/src/linux/fs/pagebuf/page_buf_io.c, for pagebuf_write_full_page, it says: _unmark_delalloc(page) So it appears to be the forced shutdown, but I don't know what had caused the forced shutdown. It truly is a mystery to me. I run VMWorkstation 3.0 on xfs, could this be a problem. Although the VMWare goons keep telling me that xfs is unsupported, I have never had a problem up to this time. I don't want to make any conlusions just yet either. I am keeping a very careful eye to see if it happens again so I can document it better. This is the very first time I ever encountered SB Validate errors since using xfs from 2.4.14. My kernel also uses the preemptive and RMAP12a patches. Could the Rmap12a patch be a source? This is the last major modification I've made to my 2.4.17 kernel since Monday (4 days ago). I implemented this patch because I was have stability problems when I would push my system to it's memory limit by running multiple VMWare sessions - the VM wouldn't swap properly. The Rmap12a patch completely fixed my VM problems. My system runs very steady now at full RAM utilization. I am not using any neat stuff like xfs_freeze, realtime, etc. etc. although I would love to play with it later. ;-) -Francis -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Thursday, January 31, 2002 10:11 PM To: Yom, Francis Cc: linux-xfs@oss.sgi.com; lord@sgi.com; spstarr@sh0n.net Subject: RE: XFS SB Validate error Ok, a couple things... There have been several changes in 2.4.17 - can you look at the bottom of pagebuf_write_full_page() in page_buf_io.c? About 8 lines from the bottom of the function, does it say block_flush_page(page,0), or _unmark_delalloc(page)? If it's the latter, then it was probably the forced shutdown that caused the corruption, although I'm not sure what's causing the shutdown. Are you doing anything fun with this filesystem? Using LVM snapshots, playing with xfs_freeze, realtime subvolumes? :) -Eric On Thu, 31 Jan 2002, Yom, Francis wrote: > Jan 31 17:21:09 sera kernel: EFSCORRUPTED returned from file > xfs_ialloc.c line 1265 From owner-linux-xfs@oss.sgi.com Sat Feb 2 02:01:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12A10Y00330 for linux-xfs-outgoing; Sat, 2 Feb 2002 02:01:00 -0800 Received: from HOLYBOY.SYMMSYS.COM (usr561@[216.51.91.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12A0jd32736 for ; Sat, 2 Feb 2002 02:00:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: XFS SB Validate error content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Fri, 1 Feb 2002 18:00:45 -0500 Message-ID: <29800F5ABF5EAC42998190CFF1846AA303C8CE@symlab0-srvr1.SYMMETRY.SYMMSYS.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS SB Validate error Thread-Index: AcGqzV3bug2SBzyvTgiLZqZzTO5fVgAAswywACkxVcA= From: "Yom, Francis" To: "Eric Sandeen" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g12A0kd32737 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, In /usr/src/linux/fs/pagebuf/page_buf_io.c, for pagebuf_write_full_page, it says: _unmark_delalloc(page) So it appears to be the forced shutdown, but I don't know what had caused the forced shutdown. It truly is a mystery to me. I run VMWorkstation 3.0 on xfs, could this be a problem. Although the VMWare goons keep telling me that xfs is unsupported, I have never had a problem up to this time. I don't want to make any conlusions just yet either. I am keeping a very careful eye to see if it happens again so I can document it better. This is the very first time I ever encountered SB Validate errors since using xfs from 2.4.14. My kernel also uses the preemptive and RMAP12a patches. Could the Rmap12a patch be a source? This is the last major modification I've made to my 2.4.17 kernel since Monday (4 days ago). I implemented this patch because I was have stability problems when I would push my system to it's memory limit by running multiple VMWare sessions - the VM wouldn't swap properly. The Rmap12a patch completely fixed my VM problems. My system runs very steady now at full RAM utilization. I am not using any neat stuff like xfs_freeze, realtime, etc. etc. although I would love to play with it later. ;-) -Francis -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Thursday, January 31, 2002 10:11 PM To: Yom, Francis Cc: linux-xfs@oss.sgi.com; lord@sgi.com; spstarr@sh0n.net Subject: RE: XFS SB Validate error Ok, a couple things... There have been several changes in 2.4.17 - can you look at the bottom of pagebuf_write_full_page() in page_buf_io.c? About 8 lines from the bottom of the function, does it say block_flush_page(page,0), or _unmark_delalloc(page)? If it's the latter, then it was probably the forced shutdown that caused the corruption, although I'm not sure what's causing the shutdown. Are you doing anything fun with this filesystem? Using LVM snapshots, playing with xfs_freeze, realtime subvolumes? :) -Eric On Thu, 31 Jan 2002, Yom, Francis wrote: > Jan 31 17:21:09 sera kernel: EFSCORRUPTED returned from file > xfs_ialloc.c line 1265 From owner-linux-xfs@oss.sgi.com Sat Feb 2 04:23:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12CN6L02968 for linux-xfs-outgoing; Sat, 2 Feb 2002 04:23:06 -0800 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12CN0d02946 for ; Sat, 2 Feb 2002 04:23:01 -0800 Received: from wwwvis.informatik.uni-stuttgart.de (root@wwwvis [129.69.215.162]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id MAA00495 for ; Sat, 2 Feb 2002 12:22:31 +0100 (MET) Received: from ysabell.wh.vaih (gw-41.wh.uni-stuttgart.de [129.69.166.244]) by wwwvis.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id MAA00492 for ; Sat, 2 Feb 2002 12:22:55 +0100 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.34 #1 (Debian)) id 16Wy74-00014H-00 for ; Sat, 02 Feb 2002 12:13:42 +0100 Date: Sat, 2 Feb 2002 12:13:22 +0100 From: "Marcelo E. Magallon" To: Linux XFS Mailing List Subject: Re: UPDATE: VERY URGENT: "cp -a" creates mysteriously "hidden" files?! Message-ID: <20020202111322.GA4071@ysabell.wh.vaih> Mail-Followup-To: Linux XFS Mailing List References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: Linux ysabell 2.4.16-xfs X-MIME-Autoconverted: from 8bit to quoted-printable by ifi.informatik.uni-stuttgart.de id MAA00495 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g12CN2d02947 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> "Ralf G. R. Bergs" writes: > >What tree did you use (CVS? what date?) > > The SGI CVS tree from Tue, 18 Dec 2001. > > >It's possible you might had checked out a CVS tree just in between two > >fixes where it was broken. > > Ok, maybe I should just have another go?! Hmm... I'm still seeing this with CVS sources from last week (last Friday IIRC). Easy to reproduce for me: $ cd /tmp/ $ touch á $ ls á: File not found (or something like that, I'm going from memory here -- I've downgraded to a previous 2.4.16 kernel I had installed here, it works fine with that) I just need to create a file with accents on it and that's enough to reproduce the problem for me, but I don't recall Ralf mentioning this in his mails... -- Marcelo From owner-linux-xfs@oss.sgi.com Sat Feb 2 05:10:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12DAje03752 for linux-xfs-outgoing; Sat, 2 Feb 2002 05:10:45 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12DAcd03724 for ; Sat, 2 Feb 2002 05:10:38 -0800 Received: (qmail 6784 invoked from network); 2 Feb 2002 12:10:32 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Feb 2002 12:10:31 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id DB95E3000B8; Sat, 2 Feb 2002 23:10:30 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 908848E; Sat, 2 Feb 2002 23:10:30 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Marcelo E. Magallon" Cc: Linux XFS Mailing List Subject: Re: UPDATE: VERY URGENT: "cp -a" creates mysteriously "hidden" files?! In-reply-to: Your message of "Sat, 02 Feb 2002 12:13:22 BST." <20020202111322.GA4071@ysabell.wh.vaih> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 02 Feb 2002 23:10:25 +1100 Message-ID: <1211.1012651825@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2 Feb 2002 12:13:22 +0100, "Marcelo E. Magallon" wrote: > Hmm... I'm still seeing this with CVS sources from last > week (last Friday IIRC). Easy to reproduce for me: > > $ cd /tmp/ > $ touch á > $ ls > á: File not found (or something like that, I'm going from memory here -- I've downgraded to a previous 2.4.16 kernel > I had installed here, it works fine with that) > > I just need to create a file with accents on it and that's > enough to reproduce the problem for me, but I don't recall > Ralf mentioning this in his mails... I am on bleeding edge CVS, from Friday February 1 and it works for me. touch á ls -la á -rw-r--r-- 1 kaos ocs 0 Feb 2 22:57 á From owner-linux-xfs@oss.sgi.com Sat Feb 2 05:21:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12DLOV04061 for linux-xfs-outgoing; Sat, 2 Feb 2002 05:21:24 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12DLJd04039 for ; Sat, 2 Feb 2002 05:21:19 -0800 Received: by monkeyiq.dnsalias.org id g12CNFB24524 ; Sat, 2 Feb 2002 22:23:15 +1000 Date: Sat, 2 Feb 2002 22:23:15 +1000 Message-Id: <200202021223.g12CNFB24524@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com cc: monkeyiq@users.sourceforge.net Subject: Preallocation and Ferris From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, A while back I was talking about adding preallocation support to ferris. I didn't get around to adding it at the time, though the doco seems much better now and I have an application which would be greatly enhanced using it. I have found the calls in xfs(5) XFS_IOC_FSGETXATTR XFS_IOC_RESVSP64 XFS_IOC_UNRESVSP64 I am thinking of adding an interface though Ferris using both Ferris' support for arbitrary creation arguments (see http://witme.sourceforge.net/ferriscreate.paper2001/ ) and also creating a "fake" EA for preallocation-eof which can be set to whatever size is wanted in the preallocation. The main question I have here is how to obtain the current amount of space that is preallocated in the file and not used. It seems from RTFM that XFS_IOC_FSGETXATTR only tells if preallocation is being used. If I can tell how much space a file has preallocated at eof then I can add a new EA and edit it with the client shown here: http://witme.sourceforge.net/libferris.web/Ego-Jan-2002-1.png This would allow a nice interface for preallocation and make scripting easy to be able to check for files that have been written but are smaller than the space originally preallocated to them. Thoughts? -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/index.html From owner-linux-xfs@oss.sgi.com Sat Feb 2 06:08:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12E8HS04810 for linux-xfs-outgoing; Sat, 2 Feb 2002 06:08:17 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12E8Bd04788 for ; Sat, 2 Feb 2002 06:08:11 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16Wzre-0004Xb-00; Sat, 02 Feb 2002 14:05:54 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Marcelo E. Magallon" Date: Sat, 02 Feb 2002 14:05:54 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2402) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020202111322.GA4071@ysabell.wh.vaih> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: UPDATE: VERY URGENT: "cp -a" creates mysteriously "hidden" files?! Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g12E8Cd04789 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Marcelo, On Sat, 2 Feb 2002 12:13:22 +0100, Marcelo E. Magallon wrote: [...] > Hmm... I'm still seeing this with CVS sources from last > week (last Friday IIRC). Easy to reproduce for me: > > $ cd /tmp/ > $ touch   > $ ls >  : File not found (or something like that, I'm going from > memory here -- I've downgraded to a previous 2.4.16 kernel > I had installed here, it works fine with that) > > I just need to create a file with accents on it and that's > enough to reproduce the problem for me, but I don't recall > Ralf mentioning this in his mails... That's right, because my problems were simply due to a broken hardware RAID. :-) The RAID has already been sent back to the manufacturer. We expect to receive a replacement drive in a few days. The problem YOU are facing seems to be related to a bug in XFS relating to signed vs. unsigned chars. As I understand it has already been fixed, so just fetch yourself the current CVS source and you should be set. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Feb 2 06:33:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12EX3606461 for linux-xfs-outgoing; Sat, 2 Feb 2002 06:33:03 -0800 Received: from ente.berdmann.de (frnk-d514e16d.dsl.mediaWays.net [213.20.225.109]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12EWjd06431 for ; Sat, 2 Feb 2002 06:32:46 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16X0HT-00077L-00 for linux-xfs@oss.sgi.com; Sat, 02 Feb 2002 14:32:35 +0100 Message-ID: <3C5BEA25.AAB5D7FE@berdmann.de> Date: Sat, 02 Feb 2002 14:31:17 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: xfsrestore dumps core on cumulative restore with -B (dirattr.c:945) Content-Type: multipart/mixed; boundary="------------E39169F5A6B8380718A93915" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------E39169F5A6B8380718A93915 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I discovered a bug in xfsrestore 1.1.14 - it dumps core when the last level of a cumlative dump is restored using the option "-B" to set mode on . of the dumped filesystem. (gdb) bt #0 0x40040d21 in __kill () from /lib/libc.so.6 #1 0x40040996 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x400420b8 in abort () at ../sysdeps/generic/abort.c:88 #3 0x4003abae in __assert_fail () at assert.c:59 #4 0x8076ec0 in dirattr_get (dah=4294967295) at dirattr.c:945 #5 0x8076dff in dirattr_get_xflags (dah=4294967295) at dirattr.c:901 #6 0x807c52a in setdirattr (dah=4294967295, path=0x8094dc4 ".") at tree.c:2464 #7 0x807c416 in tree_setattr (path=0x80acc48 "") at tree.c:2402 #8 0x806a154 in finalize (path1=0x80acc48 "", path2=0x80aec50 "") at content.c:3503 #9 0x80690cd in content_stream_restore (thrdix=0) at content.c:2490 #10 0x805c2ce in main (argc=7, argv=0xbffffaf4) at main.c:623 And here's a snippet from xfsrestore -v 4: /home/be/bin/xfsprogs/sbin/xfsrestore: restoring non-directory files /home/be/bin/xfsprogs/sbin/xfsrestore: media file 0 in object 0 of stream 0 /home/be/bin/xfsprogs/sbin/xfsrestore: file 0 in stream, file 0 in dump 0 on object /home/be/bin/xfsprogs/sbin/xfsrestore: Media_end: pos==3 /home/be/bin/xfsprogs/sbin/xfsrestore: drive_simple end_read( ) /home/be/bin/xfsprogs/sbin/xfsrestore: getting next media file for non-dir restore /home/be/bin/xfsprogs/sbin/xfsrestore: Media_mfile_next: purp==2 pos==0 /home/be/bin/xfsprogs/sbin/xfsrestore: tree finalize xfsrestore: dirattr.c:945: dirattr_get: Assertion `dah != ( ( size32_t ) ( ( ( 1ull << ( ( unsigned long long )sizeof( size32_t ) * ( unsigned long long )8 - ( 0ull + 1ull ))) - 1ull ) * 2ull + 1ull ))' failed. Please find the details in the attached README. The relevant files (xfsrestore, it's output, the core file and the README) are ready for download on http://berdmann.dyndns.org/xfsdump/xfsrestore-dumps-core-on-B/ --------------E39169F5A6B8380718A93915 Content-Type: text/plain; charset=us-ascii; name="README" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="README" Sat Feb 02, 2002: - xfsrestore 1.1.14 dumps core when applying level 3 of a cumulative dump We have the following backups of the filesystem mounted to /export/ftp.redhat.com: $ amadmin be find ente /export/ftp.redhat.com Scanning /dumps/amanda... date host disk lv tape or file file status 2002-01-17 ente /export/ftp.redhat.com 1 BE22 7 OK 2002-01-17 ente /export/ftp.redhat.com 1 BE21 26 [out of tape] 2002-01-18 ente /export/ftp.redhat.com 1 BE23 33 OK 2002-01-19 ente /export/ftp.redhat.com 1 BE25 28 OK 2002-01-20 ente /export/ftp.redhat.com 1 BE27 26 OK 2002-01-21 ente /export/ftp.redhat.com 0 BE29 33 [out of tape] 2002-01-21 ente /export/ftp.redhat.com 0 BE00 1 OK 2002-01-22 ente /export/ftp.redhat.com 1 BE01 7 OK 2002-01-23 ente /export/ftp.redhat.com 1 BE02 7 [out of tape] 2002-01-23 ente /export/ftp.redhat.com 1 BE03 1 OK 2002-01-24 ente /export/ftp.redhat.com 1 BE04 29 OK 2002-01-25 ente /export/ftp.redhat.com 2 BE05 24 OK 2002-01-26 ente /export/ftp.redhat.com 2 BE07 27 OK 2002-01-27 ente /export/ftp.redhat.com 3 BE10 8 OK 2002-02-01 ente /export/ftp.redhat.com 0 BE17 26 [out of tape] 2002-02-01 ente /export/ftp.redhat.com 0 BE18 1 OK 2002-02-02 ente /export/ftp.redhat.com 1 BE19 1 OK The dumps of 01-21 (0), 01-24 (1), 01-26 (2) were restored to . with: /usr/sbin/amrestore -p $TAPE ente /export/ftp.redhat.com | /sbin/xfsrestore -r - . The dump of 01-27 (3) was restored to . with the following line: /usr/sbin/amrestore -p $TAPE ente /export/ftp.redhat.com | /sbin/xfsrestore -r -B - . xfsrestore dumped core during this operation. A debug build (LDFLAGS="-g") of xfsdump was done and xfsrestore was installed to ~be/bin/xfsprogs/sbin/xfsrestore. The dumps were performed using xfsdump 1.1.7. The cumulative restore of the levels 0-2 was done once more and saved to another filesystem (tar cf - . | (cd somewhere && tar xpf -)). The debug build of xfsrestore was invoked with -B to restore the mode of . to apply the level 3 dump: /usr/sbin/amrestore -p $TAPE ente /export/ftp.redhat.com | ~be/bin/xfsprogs/sbin/xfsrestore -r -B -v 4 - . > /net/scratch/xfsrestore.debug 2>&1 See the core file (core.gz), the xfsrestore binary (xfsrestore.gz) and xfsrestore.debug attached. This issue does not happen when "-B" is not used during restore of level 3. Backtrace with gdb: $ gdb xfsrestore core GNU gdb 19991004 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 `/home/be/bin/xfsprogs/sbin/xfsrestore -r -B -v 4 - .'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libhandle.so.0...done. Reading symbols from /lib/libattr.so.0...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x40040d21 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x40040d21 in __kill () from /lib/libc.so.6 #1 0x40040996 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x400420b8 in abort () at ../sysdeps/generic/abort.c:88 #3 0x4003abae in __assert_fail () at assert.c:59 #4 0x8076ec0 in dirattr_get (dah=4294967295) at dirattr.c:945 #5 0x8076dff in dirattr_get_xflags (dah=4294967295) at dirattr.c:901 #6 0x807c52a in setdirattr (dah=4294967295, path=0x8094dc4 ".") at tree.c:2464 #7 0x807c416 in tree_setattr (path=0x80acc48 "") at tree.c:2402 #8 0x806a154 in finalize (path1=0x80acc48 "", path2=0x80aec50 "") at content.c:3503 #9 0x80690cd in content_stream_restore (thrdix=0) at content.c:2490 #10 0x805c2ce in main (argc=7, argv=0xbffffaf4) at main.c:623 --------------E39169F5A6B8380718A93915-- From owner-linux-xfs@oss.sgi.com Sat Feb 2 06:37:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12EbB506624 for linux-xfs-outgoing; Sat, 2 Feb 2002 06:37:11 -0800 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12Eb8d06602 for ; Sat, 2 Feb 2002 06:37:08 -0800 Received: from wwwvis.informatik.uni-stuttgart.de (root@wwwvis [129.69.215.162]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id OAA02324 for ; Sat, 2 Feb 2002 14:36:39 +0100 (MET) Received: from techno.informatik.uni-stuttgart.de (magallon@techno.informatik.uni-stuttgart.de [129.69.218.24]) by wwwvis.informatik.uni-stuttgart.de (8.9.3/2.2) with SMTP id OAA03028 for ; Sat, 2 Feb 2002 14:37:04 +0100 Received: by techno.informatik.uni-stuttgart.de (sSMTP sendmail emulation); Sat, 2 Feb 2002 14:37:03 +0100 Date: Sat, 2 Feb 2002 14:37:03 +0100 From: "Marcelo E. Magallon" To: Linux XFS Mailing List Subject: Re: UPDATE: VERY URGENT: "cp -a" creates mysteriously "hidden" files?! Message-ID: <20020202133703.GA11478@informatik.uni-stuttgart.de> Mail-Followup-To: "Marcelo E. Magallon" , Linux XFS Mailing List References: <20020202111322.GA4071@ysabell.wh.vaih> <1211.1012651825@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1211.1012651825@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.25i X-Operating-System: Linux techno 2.4.17 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Keith Owens writes: > I am on bleeding edge CVS, from Friday February 1 and it works for me. Yes, I was catching up with old mail and I didn't notice the other thread concerned with this. It's indeed fixed. -- Marcelo From owner-linux-xfs@oss.sgi.com Sat Feb 2 10:53:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12IrFA13218 for linux-xfs-outgoing; Sat, 2 Feb 2002 10:53:15 -0800 Received: from maileb.eb.com.pl (mail.grupazywiec.pl [217.153.117.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12IrAd13193 for ; Sat, 2 Feb 2002 10:53:11 -0800 Subject: XFS - failed to find log head To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Wydanie 5.0.5 22 =?iso-8859-2?Q?wrze=B6nia_2000?= Message-ID: From: Adam.Jablonski@GrupaZywiec.pl Date: Sat, 2 Feb 2002 19:03:16 +0100 X-MIMETrack: Serialize by Router on EMAIL/Elbrewery(Release 5.0.7 |March 21, 2001) at 02/02/2002 06:43:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just installed RH 7.2 from iso image . After some reboots - kernel panic. Unable to mount root partition. So, I tried to xfs_repair - the result is in the title plus xlog_find_tail returned error 5. How to heal my root partition? I've already tried varous options on xfs_repair only -n works fine but doesn't flush any changes Regards Adam Jablonski From owner-linux-xfs@oss.sgi.com Sat Feb 2 12:02:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12K2RF14489 for linux-xfs-outgoing; Sat, 2 Feb 2002 12:02:27 -0800 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12K2Ld14466 for ; Sat, 2 Feb 2002 12:02:21 -0800 Received: (qmail 4066 invoked by uid 500); 2 Feb 2002 19:02:26 -0000 Date: Sat, 2 Feb 2002 14:02:26 -0500 From: "Nathan J. Mehl" To: Adam.Jablonski@GrupaZywiec.pl Cc: linux-xfs@oss.sgi.com Subject: Re: XFS - failed to find log head Message-ID: <20020202140226.G23992@blank.org> Mail-Followup-To: Adam.Jablonski@GrupaZywiec.pl, linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Adam.Jablonski@GrupaZywiec.pl on Sat, Feb 02, 2002 at 07:03:16PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Adam.Jablonski@GrupaZywiec.pl (Adam.Jablonski@GrupaZywiec.pl): > I've just installed RH 7.2 from iso image . After some reboots - kernel > panic. Unable to mount root partition. > So, I tried to xfs_repair - the result is in the title plus xlog_find_tail > returned error 5. > How to heal my root partition? I've already tried varous options on > xfs_repair only -n works fine but doesn't flush any changes This is a bug in the version of xfs_repair that comes with the SGI 1.0.2 iso images. It's fixed in the current CVS sources -- just check out the CVS module from sgi and build the "tools" subdirectory. Drop the xfs_repair binary it makes onto a floppy (you'll need to strip and/or gzip it) and off you go. -n, been there, done that, got blood on the tshirt ------------------------------------------------------------ If people are deciding whether or not to use your service on the basis of whether they can get it in HTML, it's not a sign that HTML is about to take over the world. It's a sign that you have boring content. (--Tim Pierce) ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sat Feb 2 12:40:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12KeQB17103 for linux-xfs-outgoing; Sat, 2 Feb 2002 12:40:26 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12KeJd17078 for ; Sat, 2 Feb 2002 12:40:20 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g12JeCo28884 for ; Sat, 2 Feb 2002 11:40:12 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA54427; Sat, 2 Feb 2002 13:38:48 -0600 (CST) Received: from sgi.com (J6vuXEvYMVgarStaB/SH3XHGOJ9cCbZK@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA02358; Sat, 2 Feb 2002 13:38:45 -0600 (CST) Message-ID: <3C5C4044.8040309@sgi.com> Date: Sat, 02 Feb 2002 13:38:44 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: monkeyiq CC: linux-xfs@oss.sgi.com Subject: Re: Preallocation and Ferris References: <200202021223.g12CNFB24524@monkeyiq.dnsalias.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk monkeyiq wrote: >Hi, > A while back I was talking about adding preallocation support to >ferris. I didn't get around to adding it at the time, though the >doco seems much better now and I have an application which would >be greatly enhanced using it. > >I have found the calls in xfs(5) >XFS_IOC_FSGETXATTR >XFS_IOC_RESVSP64 >XFS_IOC_UNRESVSP64 > >I am thinking of adding an interface though Ferris using both >Ferris' support for arbitrary creation arguments >(see http://witme.sourceforge.net/ferriscreate.paper2001/ ) >and also creating a "fake" EA for preallocation-eof >which can be set to whatever size is wanted in the preallocation. >The main question I have here is how to obtain the current >amount of space that is preallocated in the file and not used. > >It seems from RTFM that XFS_IOC_FSGETXATTR only tells if >preallocation is being used. If I can tell how much space >a file has preallocated at eof then I can add a new EA and >edit it with the client shown here: >http://witme.sourceforge.net/libferris.web/Ego-Jan-2002-1.png > >This would allow a nice interface for preallocation and make >scripting easy to be able to check for files that have been >written but are smaller than the space originally preallocated >to them. > >Thoughts? > It is possible to query xfs to find out all sorts of stuff about the layout of a file, take a look at the xfs_bmap program and its source code. If you are not creating files with holes in then a simple stat system call will suffice, the st_blocks will include preallocated space beyond the end of file. Steve From owner-linux-xfs@oss.sgi.com Sat Feb 2 12:53:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12KrZ117423 for linux-xfs-outgoing; Sat, 2 Feb 2002 12:53:35 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12KrSd17401 for ; Sat, 2 Feb 2002 12:53:28 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g12JrLo29087 for ; Sat, 2 Feb 2002 11:53:21 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA54691; Sat, 2 Feb 2002 13:51:49 -0600 (CST) Received: from sgi.com (kiCYI+L7dgxyxY5impOXkjvzc4BUPZ8W@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA04669; Sat, 2 Feb 2002 13:51:22 -0600 (CST) Message-ID: <3C5C4339.4010306@sgi.com> Date: Sat, 02 Feb 2002 13:51:21 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Andi Kleen CC: Seth Mos , King Kac , linux-xfs@oss.sgi.com Subject: Re: undelete - xfsrecover'ing deleted files in xfs References: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <20020131210325.C966@comotion> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <4.3.2.7.2.20020201185638.03660ee8@pop.xs4all.nl> <20020201193334.A24652@wotan.suse.de> <1012590178.26396.429.camel@jen.americas.sgi.com> <20020202051059.A32003@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andi Kleen wrote: >On Fri, Feb 01, 2002 at 01:02:58PM -0600, Steve Lord wrote: > >>>When you can find the inode of the deleted file again and its extent btrees >>>are not destroyed it should be possible to reconnect it to a directory. >>> >>Unfortunately when we free an inode we also remove all the extents from >>it. So even if those extents used to be in the inode, they are not there >>now. The reason this happens is that deleting a file is an unbounded >> > >I see. The extents would be in a btree which would be likely rebalanced >on the extent freeing and that would destroy them because they're inline >in the btree. Is that correct? > Well, how deep do you want to go ;-) For a file with a few extents the extents are held in the inode, we then move to a single block, and then to a btree of blocks. There are also two forks - one for data and one for extended attributes if you have them. Most files probably fit inside the inode - default inode size is 256 bytes, there is room for about 8 extents in there I think, each extent takes 16 bytes of space. As the extents are freed they get removed from the inode and placed back into the free space btrees of the allocation group in the filesystem they are located in - insertion into this tree can mean they get merged with surrounding free space. So the inode is generally stamped on as space is removed - various memmove operations take place, and the free space is fare game for any subsequent allocation for which it is a good match. The memmoves as stuff is deleted probably really mess things up. Steve > > >Thanks, >-Andi > From owner-linux-xfs@oss.sgi.com Sun Feb 3 00:24:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g138OvW05584 for linux-xfs-outgoing; Sun, 3 Feb 2002 00:24:57 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g138OrA05562 for ; Sun, 3 Feb 2002 00:24:53 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA22268 for ; Sat, 2 Feb 2002 18:36:50 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01015; Sun, 3 Feb 2002 13:39:57 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA80009; Sun, 3 Feb 2002 12:52:54 +1100 (AEDT) Date: Sun, 3 Feb 2002 12:52:54 +1100 From: Nathan Scott To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020203125254.A104828@wobbly.melbourne.sgi.com> References: <20020201101545.G88469@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Sat, Feb 02, 2002 at 11:52:38AM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Feb 02, 2002 at 11:52:38AM +0800, Federico Sevilla III wrote: > On Fri, 1 Feb 2002 at 10:15, Nathan Scott wrote: > > Yes, the ondisk formats remain unchanged, incl. the ondisk ACL format > > (which is also the same as the IRIX/XFS Posix ACL format). > > So setups utilizing ACLs won't have to be redone, right? As long as we > make sure that when we upgrade to an XFS-enabled kernel using the new > system calls we also upgrade the userland stuff or we won't be able to > modify or view the ACL rules. Did I get things correctly? :) > yes. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 3 00:33:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g138XRm05841 for linux-xfs-outgoing; Sun, 3 Feb 2002 00:33:27 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g138XDA05817 for ; Sun, 3 Feb 2002 00:33:13 -0800 Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) 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 VAA00160 for ; Sat, 2 Feb 2002 21:11:13 -0800 (PST) mail_from (ahead@bigpond.net.au) Message-Id: <200202030511.VAA00160@sgi.com> Received: from there ([144.135.25.87]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GQXYKF00.0U4; Sun, 3 Feb 2002 15:14:39 +1000 Received: from CPE-144-137-137-94.qld.bigpond.net.au ([144.137.137.94]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/4449689); 03 Feb 2002 15:07:26 From: Adrian Head To: linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: LVM1 & XFS Date: Sun, 3 Feb 2002 15:07:20 +1000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_88YXYKDH4JI8V9O7UVAD" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --------------Boundary-00=_88YXYKDH4JI8V9O7UVAD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit This is just a heads up for others... Early 2002 I was trying to get LVM1, ext3, resierfs & XFS coexisting. The SGI guys were able to generate a patch that fixed issues with LVM & XFS which can be found in the mailing list archives and modified lvm-snap.c. At that time I was able to run a series of tests by hand and everything was OK; whereas if I put the cammands in a script it would die a death. Because of other priorities I had to leave this ... so since LVM-1.0.2 was out and the XFS CVS keeps marching along and I had a few hours to spare I thought I would see if any of the issues have been resolved. I have got the latest XFS from CVS (2002-02-02) and the latest LVM (1.0.2) from CVS and ran through my tests. The tests outline follows: # This is to test operational aspects of LVM # 1. Create LV # 2. mkfs on LV # 3. mount LV # 3a. ls LV # 4. copy data onto LV # 4a ls LV # 5. copy data across LV # 5a ls LV # 6. copy data off LV # 6a ls LV # 7. overfill LV # 7a. ls LV # 8. create snapshot # 9. mount snapshot # 10. ls snapshot # 11. overfill snapshot # 12. ls snapshot There still seems to be problems as I can run the tests by hand successfully but as soon as I put the commands in a script I get Oopses. The positive side is that LVM-1.0.2 is way more robust than LVM-1.0.1 as when overflowing the snapshot fails; there are no kernel panics on the next reboot and no need for rescuing the LV associated with the snapshot. However, when it does Oops it seems to hold the original LV open and therefore, the LV cannot be umounted properly - a reboot is the only way of getting the LV back to a usable state. I have tried both vanilla linux-xfs+lvm-1.0.2 as well as linux-xfs+lvm-1.0.2+lvm-snap.c.patch and it still dies in the same place but the backtraces are different. The question I would like to ask any LVM gurus is why would there be a difference between running the tests by hand and running them in a script? Attached is the test script... -- Adrian Head (Public Key available on request.) --------------Boundary-00=_88YXYKDH4JI8V9O7UVAD Content-Type: application/x-shellscript; name="lvm_test.sh" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lvm_test.sh" IyEvYmluL3NoCgojIFRoaXMgaXMgdG8gdGVzdCBvcGVyYXRpb25hbCBhc3Bl Y3RzIG9mIExWTQojICAxLiAgQ3JlYXRlIExWCiMgIDIuICBta2ZzIG9uIExW CiMgIDMuICBtb3VudCBMVgojICAzYS4gbHMgTFYKIyAgNC4gIGNvcHkgZGF0 YSBvbnRvIExWCiMgIDRhICBscyBMVgojICA1LiAgY29weSBkYXRhIGFjcm9z cyBMVgojICA1YSAgbHMgTFYKIyAgNi4gIGNvcHkgZGF0YSBvZmYgTFYKIyAg NmEgIGxzIExWCiMgIDcuICBvdmVyZmlsbCBMVgojICA3YS4gbHMgTFYKIyAg OC4gIGNyZWF0ZSBzbmFwc2hvdAojICA5LiAgbW91bnQgc25hcHNob3QKIyAg MTAuIGxzIHNuYXBzaG90CiMgIDExLiBvdmVyZmlsbCBzbmFwc2hvdAojICAx Mi4gbHMgc25hcHNob3QKCmVjaG8gQWJvdXQgdG8gY3JlYXRlIFRFU1QgTFYu Li4KbHZjcmVhdGUgLUwgMUcgLW4gVEVTVCAvZGV2L0hEQQplY2hvIFRFU1Qg TFYgc2hvdWxkIGhhdmUgYmVlbiBjcmVhdGVkLi4uCgplY2hvIEFib3V0IHRv IG1rZnMgb24gVEVTVCBMVi4uLgpta2ZzIC10IHhmcyAvZGV2L0hEQS9URVNU CmVjaG8gbWtmcyBzaG91bGQgaGF2ZSBiZWVuIHJ1biBvbiBURVNUIExWLi4u CgplY2hvIEFib3V0IHRvIG1vdW50IFRFU1QgTFYuLi4KbW91bnQgLXQgeGZz IC9kZXYvSERBL1RFU1QgL21udC90ZXN0CnRhaWwgL3Zhci9sb2cvbWVzc2Fn ZXMKZWNobyBURVNUIExWIHNob3VsZCBoYXZlIGJlZW4gbW91bnRlZC4uLgoK Y2QgL21udC90ZXN0CgplY2hvIEFib3V0IHRvIGxzIFRFU1QgTFYuLi4KbHMg LWxhaAoKZWNobyBBYm91dCB0byBjb3B5IGRhdGEgdG8gVEVTVCBMVi4uLgpj cCAvY2hyb290LzAxLnRhci5iejIgL21udC90ZXN0CmNwIC9jaHJvb3QvTUQ1 U1VNIC9tbnQvdGVzdAplY2hvIDI2ME0gb2YgZGF0YSBzaG91bGQgaGF2ZSBi ZWVuIGNvcGllZC4uLgoKZWNobyBBYm91dCB0byB2ZXJpZnkgZGF0YSBvbiBU RVNUIExWLi4uCm1kNXN1bSAvbW50L3Rlc3QvMDEudGFyLmJ6MgpjYXQgL21u dC90ZXN0L01ENVNVTQplY2hvIC4uLiB3ZWxsIGFyZSB0aGV5IGRpZmZlcmVu dD8KCmVjaG8gQWJvdXQgdG8gY29weSBkYXRhIGFjcm9zcyB0aGUgVEVTVCBM Vi4uLgp0YXIgLWp4ZiAwMS50YXIuYnoyCmxzIC1sYWgKdGFyIC1qY2YgMDIu dGFyLmJ6MiAwMQpscyAtbGFoCm1kNXN1bSAwMi50YXIuYnoyCmNhdCAvbW50 L3Rlc3QvTUQ1U1VNCgplY2hvIEFib3V0IHRvIG92ZXJmbG93IFRFU1QgTFYu Li4KY3AgLWZyIDAxIDAyID4vZGV2L251bGwgIDI+JjEKZWNobyBzaG91bGQg c3RpbGwgYmUgc3RhbmRpbmcuLi4KCmxzIC1sYWgKCmVjaG8gQ29vbCAtIHN0 aWxsIHN0YW5kaW5nLi4uCgplY2hvIEFib3V0IHRvIGNsZWFuLXVwLi4uCnJt IC1mciAwMgoKZWNobyBBYm91dCB0byBjcmVhdGUgc25hcHNob3QuLi4KbHZj cmVhdGUgLUw1ME0gLXMgLW4gU05BUCAvZGV2L0hEQS9URVNUCmVjaG8gc25h cHNob3QgTFYgc2hvdWxkIGhhdmUgYmVlbiBjcmVhdGVkLi4uCgplY2hvIEFi b3V0IHRvIG1vdW50IHNuYXBzaG90Li4uCm1vdW50IC10IHhmcyAtbyBub3V1 aWQsbm9yZWNvdmVyeSAvZGV2L0hEQS9TTkFQIC9tbnQvc25hcHNob3QKZWNo byBTbmFwc2hvdCBzaG91bGQgaGF2ZSBiZWVuIG1vdW50ZWQuLi4KCmVjaG8g QWJvdXQgdG8gbHMgc25hcHNob3QuLi4KbHMgLWxhaCAvbW50L3NuYXBzaG90 CgplY2hvIEFib3V0IHRvIG92ZXJmbG93IHNuYXBzaG90Li4uCmNwIC1mciAw MSAwMiA+L2Rldi9udWxsICAyPiYxCmVjaG8gc2hvdWxkIHN0aWxsIGJlIHN0 YW5kaW5nLi4uCgpscyAtbGFoCgplY2hvIENvb2wgLSBzdGlsbCBzdGFuZGlu Zy4uLgoKZWNobyBBYm91dCB0byBjbGVhbi11cC4uLgpybSAtZnIgMDIKCmVj aG8gQ29vbCAtIHN0aWxsIHN0YW5kaW5nLi4uCgplY2hvIGxldHMgY2xlYW4g dXAgZXZlcnl0aGluZy4uLgoKY2QgLwp1bW91bnQgL21udC9zbmFwc2hvdAp1 bW91bnQgL21udC90ZXN0Cmx2cmVtb3ZlIC1mIC9kZXYvSERBL1NOQVAKbHZy ZW1vdmUgLWYgL2Rldi9IREEvVEVTVAoKZWNobyBhbGwgZmluaXNoZWQuLi4= --------------Boundary-00=_88YXYKDH4JI8V9O7UVAD-- From owner-linux-xfs@oss.sgi.com Sun Feb 3 00:43:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g138hON05999 for linux-xfs-outgoing; Sun, 3 Feb 2002 00:43:24 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g138hKA05974 for ; Sun, 3 Feb 2002 00:43:20 -0800 Received: from lynx.adilger.int ([24.64.69.240]) 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 WAA09317 for ; Sat, 2 Feb 2002 22:01:38 -0800 (PST) mail_from (adilger@turbolabs.com) Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g135vii23990; Sat, 2 Feb 2002 22:57:44 -0700 Date: Sat, 2 Feb 2002 22:57:44 -0700 From: Andreas Dilger To: Adrian Head Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Re: [linux-lvm] LVM1 & XFS Message-ID: <20020202225744.P763@lynx.adilger.int> Mail-Followup-To: Adrian Head , linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ahead@bigpond.net.au on Sun, Feb 03, 2002 at 03:07:20PM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Feb 03, 2002 15:07 +1000, Adrian Head wrote: > There still seems to be problems as I can run the tests by hand successfully > but as soon as I put the commands in a script I get Oopses. Well, running the oops through ksymoops and posting it would be a good start to figuring out where the problems are. > The question I would like to ask any LVM gurus is why would there be a > difference between running the tests by hand and running them in a script? Timing issues. Maybe it isaccessing memory that has been freed already. Maybe it isn't getting a lock on some stuct and if you do it slowly, the operation has a chance to complete before another one deletes the struct. Who knows, the ksymoops output will hopefully point us where to look. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Sun Feb 3 00:43:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g138htd06126 for linux-xfs-outgoing; Sun, 3 Feb 2002 00:43:55 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g138hoA06104 for ; Sun, 3 Feb 2002 00:43:50 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA02867 for ; Sat, 2 Feb 2002 18:42:21 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01017; Sun, 3 Feb 2002 13:39:59 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA77111; Sun, 3 Feb 2002 12:57:39 +1100 (AEDT) Date: Sun, 3 Feb 2002 12:57:39 +1100 From: Nathan Scott To: Ethan Benson Cc: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020203125739.B104828@wobbly.melbourne.sgi.com> References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <20020201213849.Y14742@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020201213849.Y14742@plato.local.lan>; from erbenson@alaska.net on Fri, Feb 01, 2002 at 09:38:49PM -0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 09:38:49PM -0900, Ethan Benson wrote: > On Sat, Feb 02, 2002 at 11:52:38AM +0800, Federico Sevilla III wrote: > > On Fri, 1 Feb 2002 at 10:15, Nathan Scott wrote: > > > Yes, the ondisk formats remain unchanged, incl. the ondisk ACL format > > > (which is also the same as the IRIX/XFS Posix ACL format). > > > > So setups utilizing ACLs won't have to be redone, right? As long as we > > make sure that when we upgrade to an XFS-enabled kernel using the new > > system calls we also upgrade the userland stuff or we won't be able to > > modify or view the ACL rules. Did I get things correctly? :) > > for XFS at least yes. on disk format is unchanged, only the syscalls > are different. > > however it looks like only the extended attributes syscalls have been > added to 2.5, there is still no ACL interface. I assume that the ACL > userspace will have to change a second time when that API is accepted > into the mainline kernel? has the ACL api been more or less agreed on yet? > We will be moving to the acl.bestbits.at implementation of ACLs which uses the extended attributes interfaces directly for ACLs, rather than separate syscalls as we have currently in the XFS tree. So, there will be no second change for ACL userspace, it will all be done in one big step. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 3 01:33:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g139Xp307054 for linux-xfs-outgoing; Sun, 3 Feb 2002 01:33:51 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g139XmA07032 for ; Sun, 3 Feb 2002 01:33:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g134Wqo26710 for ; Sat, 2 Feb 2002 20:32:52 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA61986 for linux-xfs@oss.sgi.com; Sun, 3 Feb 2002 15:31:35 +1100 (EST) Date: Sun, 3 Feb 2002 15:31:35 +1100 (EST) From: Nathan Scott Message-Id: <200202030431.PAA61986@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sat Feb 2 20:29:50 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:110889a xfsprogs/repair/io.c - 1.3 - xfs_repair in no-modify mode opens the filesystem device read-only now (fix from Chris Pascoe). From owner-linux-xfs@oss.sgi.com Sun Feb 3 02:31:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13AVI813236 for linux-xfs-outgoing; Sun, 3 Feb 2002 02:31:18 -0800 Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13AVBA13212 for ; Sun, 3 Feb 2002 02:31:11 -0800 Received: from erbenson.alaska.net (240-pm32.nwc.alaska.net [209.112.158.240]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g139V6i00381 for ; Sun, 3 Feb 2002 00:31:07 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 7BBF83938 for ; Sun, 3 Feb 2002 00:31:05 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 3FEBB1023C; Sun, 3 Feb 2002 00:31:05 -0900 (AKST) Date: Sun, 3 Feb 2002 00:31:05 -0900 From: Ethan Benson To: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020203003105.B14742@plato.local.lan> Mail-Followup-To: Linux XFS Mailing List References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <20020201213849.Y14742@plato.local.lan> <"from erbenson"@alaska.net> <20020203125739.B104828@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rsGyAQ90QqnfMsmV" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020203125739.B104828@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Sun, Feb 03, 2002 at 12:57:39PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --rsGyAQ90QqnfMsmV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2002 at 12:57:39PM +1100, Nathan Scott wrote: >=20 > We will be moving to the acl.bestbits.at implementation of > ACLs which uses the extended attributes interfaces directly > for ACLs, rather than separate syscalls as we have currently > in the XFS tree. >=20 > So, there will be no second change for ACL userspace, it will > all be done in one big step. ah i see, so there will be no acl syscalls in the kernel, all of that will be handled entirly in the userspace libacl, which uses the xattr API just added yes? does that mean libacl will need to know about the on disk format for ACL extended attributes for each filesystem it supports?=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --rsGyAQ90QqnfMsmV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxdA1kACgkQJKx7GixEevzl6ACfV6aWfViHc8JV9qnMnsYj44Pd fd4AnRxotvIcKv7GT72X2nhA8z0z5ziP =5tRr -----END PGP SIGNATURE----- --rsGyAQ90QqnfMsmV-- From owner-linux-xfs@oss.sgi.com Sun Feb 3 02:52:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13Aqej15817 for linux-xfs-outgoing; Sun, 3 Feb 2002 02:52:40 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13Aq1A15791 for ; Sun, 3 Feb 2002 02:52:01 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with SMTP id g139pKY05383 for ; Sun, 3 Feb 2002 01:51:20 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA02271; Sun, 3 Feb 2002 20:50:01 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA05425; Sun, 3 Feb 2002 20:50:00 +1100 (AEDT) Date: Sun, 3 Feb 2002 20:49:59 +1100 From: Nathan Scott To: Ethan Benson Cc: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020203204959.A104774@wobbly.melbourne.sgi.com> References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <20020201213849.Y14742@plato.local.lan> <"from <20020203125739.B104828@wobbly.melbourne.sgi.com> <20020203003105.B14742@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020203003105.B14742@plato.local.lan>; from erbenson@alaska.net on Sun, Feb 03, 2002 at 12:31:05AM -0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 12:31:05AM -0900, Ethan Benson wrote: > On Sun, Feb 03, 2002 at 12:57:39PM +1100, Nathan Scott wrote: > > > > We will be moving to the acl.bestbits.at implementation of > > ACLs which uses the extended attributes interfaces directly > > for ACLs, rather than separate syscalls as we have currently > > in the XFS tree. > > > > So, there will be no second change for ACL userspace, it will > > all be done in one big step. > > ah i see, so there will be no acl syscalls in the kernel, all of that > will be handled entirly in the userspace libacl, which uses the xattr > API just added yes? yup. > > does that mean libacl will need to know about the on disk format for > ACL extended attributes for each filesystem it supports? > No, we'll convert to/from a common (VFS) format into the XFS-specific format before writing / after reading the ACL. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 3 02:57:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13AvwT16500 for linux-xfs-outgoing; Sun, 3 Feb 2002 02:57:58 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13AvsA16478 for ; Sun, 3 Feb 2002 02:57:54 -0800 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 BAA07652 for ; Sun, 3 Feb 2002 01:58:57 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA49384 for linux-xfs@oss.sgi.com; Sun, 3 Feb 2002 20:56:34 +1100 (EST) Date: Sun, 3 Feb 2002 20:56:34 +1100 (EST) From: Nathan Scott Message-Id: <200202030956.UAA49384@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You'll need to do a make realclean after this... Date: Sun Feb 3 01:54:01 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:110895a xfsprogs/db/hash.h - 1.2 xfsprogs/include/xfs_da_btree.h - 1.2 xfsprogs/include/libxfs.h - 1.8 xfsprogs/include/platform_defs.h.in - 1.6 xfsprogs/include/xfs_inode.h - 1.12 xfsprogs/libxfs/xfs_da_btree.c - 1.5 - sync with recent kernel changes (uchar) - noop change cos we build userspace with -funsigned-char anyway. From owner-linux-xfs@oss.sgi.com Sun Feb 3 03:01:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13B1gD16735 for linux-xfs-outgoing; Sun, 3 Feb 2002 03:01:42 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13B1YA16711 for ; Sun, 3 Feb 2002 03:01:35 -0800 Received: from erbenson.alaska.net (240-pm32.nwc.alaska.net [209.112.158.240]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g13A1Vs98715 for ; Sun, 3 Feb 2002 01:01:31 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 826BB3938 for ; Sun, 3 Feb 2002 01:01:29 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 059231023C; Sun, 3 Feb 2002 01:01:30 -0900 (AKST) Date: Sun, 3 Feb 2002 01:01:29 -0900 From: Ethan Benson To: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020203010129.C14742@plato.local.lan> Mail-Followup-To: Linux XFS Mailing List References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <20020201213849.Y14742@plato.local.lan> <"from erbenson"@alaska.net> <20020203204959.A104774@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6dGMKdYe2Ft9UtxE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020203204959.A104774@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Sun, Feb 03, 2002 at 08:49:59PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --6dGMKdYe2Ft9UtxE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2002 at 08:49:59PM +1100, Nathan Scott wrote: > > does that mean libacl will need to know about the on disk format for > > ACL extended attributes for each filesystem it supports?=20 > >=20 >=20 > No, we'll convert to/from a common (VFS) format into the XFS-specific > format before writing / after reading the ACL. hmm, but as im understanding this libacl will just be writing an extended attribute to a file, how will XFS, or whatever know this attribute is for ACLs rather then just some arbitrary attribute?=20 the acl.bestbits.at site is rather light on technical info.. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --6dGMKdYe2Ft9UtxE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxdCnkACgkQJKx7GixEevyEAwCghLHqD1EpnVV64objUO39TbYt WQAAmwWHAkzwUxEibZKCgT1fOqm404hu =I/Bu -----END PGP SIGNATURE----- --6dGMKdYe2Ft9UtxE-- From owner-linux-xfs@oss.sgi.com Sun Feb 3 03:25:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13BP7b18977 for linux-xfs-outgoing; Sun, 3 Feb 2002 03:25:07 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13BP2A18865 for ; Sun, 3 Feb 2002 03:25:02 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with SMTP id g13AOso14718 for ; Sun, 3 Feb 2002 02:24:54 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02379; Sun, 3 Feb 2002 21:23:35 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA05484; Sun, 3 Feb 2002 21:23:34 +1100 (AEDT) Date: Sun, 3 Feb 2002 21:23:33 +1100 From: Nathan Scott To: Ethan Benson Cc: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020203212333.B104774@wobbly.melbourne.sgi.com> References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <20020201213849.Y14742@plato.local.lan> <"from <20020203204959.A104774@wobbly.melbourne.sgi.com> <20020203010129.C14742@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020203010129.C14742@plato.local.lan>; from erbenson@alaska.net on Sun, Feb 03, 2002 at 01:01:29AM -0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 01:01:29AM -0900, Ethan Benson wrote: > On Sun, Feb 03, 2002 at 08:49:59PM +1100, Nathan Scott wrote: > > > does that mean libacl will need to know about the on disk format for > > > ACL extended attributes for each filesystem it supports? > > > > > > > No, we'll convert to/from a common (VFS) format into the XFS-specific > > format before writing / after reading the ACL. > > hmm, but as im understanding this libacl will just be writing an > extended attribute to a file, how will XFS, or whatever know this > attribute is for ACLs rather then just some arbitrary attribute? attributes in the system namespace will need to be converted to the native filesystem format before/after being written/read. > the acl.bestbits.at site is rather light on technical info.. yes, we'll need to improve some areas of the documentation - several people have pointed this out now. cheers. -- eNathan From owner-linux-xfs@oss.sgi.com Sun Feb 3 03:58:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13BwWc21889 for linux-xfs-outgoing; Sun, 3 Feb 2002 03:58:32 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13BwRA21865 for ; Sun, 3 Feb 2002 03:58:27 -0800 Received: from erbenson.alaska.net (240-pm32.nwc.alaska.net [209.112.158.240]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g13AwMs21260 for ; Sun, 3 Feb 2002 01:58:23 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 488173938 for ; Sun, 3 Feb 2002 01:58:19 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 9EB451023C; Sun, 3 Feb 2002 01:58:19 -0900 (AKST) Date: Sun, 3 Feb 2002 01:58:19 -0900 From: Ethan Benson To: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020203015819.B27218@plato.local.lan> Mail-Followup-To: Linux XFS Mailing List References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <20020201213849.Y14742@plato.local.lan> <"from erbenson"@alaska.net> <20020203212333.B104774@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fOHHtNG4YXGJ0yqR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020203212333.B104774@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Sun, Feb 03, 2002 at 09:23:33PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --fOHHtNG4YXGJ0yqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2002 at 09:23:33PM +1100, Nathan Scott wrote: >=20 > attributes in the system namespace will need to be converted to > the native filesystem format before/after being written/read. yes, i was wondering where this conversion happens, libacl, or the kernel.=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --fOHHtNG4YXGJ0yqR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxdF8sACgkQJKx7GixEevyfvwCePCqoBdiZqy2qfIJgg18XpOgf VYQAninZKutCR7HSipeEiG0JAlxJzC0v =Ckw0 -----END PGP SIGNATURE----- --fOHHtNG4YXGJ0yqR-- From owner-linux-xfs@oss.sgi.com Sun Feb 3 05:50:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13Do3A02614 for linux-xfs-outgoing; Sun, 3 Feb 2002 05:50:03 -0800 Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13DnwA02589 for ; Sun, 3 Feb 2002 05:49:58 -0800 Message-Id: <200202031349.g13DnwA02589@oss.sgi.com> Received: from there ([144.135.25.84]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GQYJZ000.7MJ; Sun, 3 Feb 2002 22:57:00 +1000 Received: from CPE-144-137-137-94.qld.bigpond.net.au ([144.137.137.94]) by psmam06.mailsvc.email.bigpond.com(MailRouter V3.0h 116/2236259); 03 Feb 2002 22:49:48 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] LVM1 & XFS Date: Sun, 3 Feb 2002 22:49:23 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020202225744.P763@lynx.adilger.int> In-Reply-To: <20020202225744.P763@lynx.adilger.int> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Andreas for answering my questions. The email was just a heads up to see if other people had seen something simular. Chris Pascoe suggested a few modifications in the XFS code and this seems to have fixed this problem for the moment - so I will be giving more info to the XFS guys and see what happens. Thanks Andreas. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Sun Feb 3 05:59:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13Dxbe03172 for linux-xfs-outgoing; Sun, 3 Feb 2002 05:59:37 -0800 Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13DxUA03150 for ; Sun, 3 Feb 2002 05:59:30 -0800 Message-Id: <200202031359.g13DxUA03150@oss.sgi.com> Received: from there ([144.135.25.87]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GQYKEX00.0OE for ; Sun, 3 Feb 2002 23:06:33 +1000 Received: from CPE-144-137-137-94.qld.bigpond.net.au ([144.137.137.94]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/4755084); 03 Feb 2002 22:59:20 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@oss.sgi.com Subject: Re: LVM1 & XFS Date: Sun, 3 Feb 2002 22:59:16 +1000 X-Mailer: KMail [version 1.3.1] References: <200202030511.VAA00160@sgi.com> In-Reply-To: <200202030511.VAA00160@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 3 Feb 2002 15:07, you wrote: > Early 2002 I was trying to get LVM1, ext3, resierfs & XFS coexisting. The > SGI guys were able to generate a patch that fixed issues with LVM & XFS > which can be found in the mailing list archives and modified lvm-snap.c. > At that time I was able to run a series of tests by hand and everything was > OK; whereas if I put the cammands in a script it would die a death. > Because of other priorities I had to leave this ... so since LVM-1.0.2 was > out and the XFS CVS keeps marching along and I had a few hours to spare I > thought I would see if any of the issues have been resolved. > > I have got the latest XFS from CVS (2002-02-02) and the latest LVM (1.0.2) > from CVS and ran through my tests. After following a suggestion from Chris Pascoe and using the patch from Eric with regards to the xfs_freeze problem the issue of the LVM snapshot overflow failing in a script has been resolved. However, now the snapshot is not consistent after the freeze. I believe that Chris will be sending an email with more information to Eric. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Sun Feb 3 07:32:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13FWkD04272 for linux-xfs-outgoing; Sun, 3 Feb 2002 07:32:46 -0800 Received: from milagro.lanl.gov (milagro.lanl.gov [128.165.51.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13FWgA04250 for ; Sun, 3 Feb 2002 07:32:42 -0800 Received: from localhost (sam@localhost) by milagro.lanl.gov (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id HAA53277 for ; Sun, 3 Feb 2002 07:17:12 -0700 (MST) Date: Sun, 3 Feb 2002 07:17:12 -0700 (MST) From: Frank Samuelson To: linux-xfs@oss.sgi.com Subject: mounting disk as read-write after boot. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I installed a system with the RedHat-XFS disks. It works great. All file systems are xfs. But when I compile my own kernel (2.4.17 with xfs patch) and install it, and reboot, the root disk stays in read-only mode. Obviously at some point the bootup just stops. No syslog error message are available (nothing is written). XFS is compiled in (with quota support). It is obvious that the kernel mounts the root disk (which is XFS) and reads its contents on bootup, but it never switches it to read-write. Any suggestions would be very helpful. Thanks for the great file system. Frank Samuelson From owner-linux-xfs@oss.sgi.com Sun Feb 3 11:04:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13J4rf25579 for linux-xfs-outgoing; Sun, 3 Feb 2002 11:04:53 -0800 Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13J4kA25443 for ; Sun, 3 Feb 2002 11:04:47 -0800 Received: from kitsune (cs189114.pp.htv.fi [213.243.189.114]) by posti.pp.htv.fi (8.9.3/8.9.3) with ESMTP id UAA02627; Sun, 3 Feb 2002 20:03:43 +0200 (EET) Received: by kitsune (Postfix, from userid 1000) id B2B21C023F7; Sun, 3 Feb 2002 20:03:41 +0200 (EET) To: Frank Samuelson Cc: linux-xfs@oss.sgi.com Subject: Re: mounting disk as read-write after boot. References: From: Arto Jantunen Date: 03 Feb 2002 20:03:41 +0200 In-Reply-To: Message-ID: <87pu3mh282.fsf@welho.com> Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Frank Samuelson writes: > I installed a system with the RedHat-XFS disks. > It works great. All file systems are xfs. > > But when I compile my own kernel (2.4.17 with xfs patch) > and install it, and reboot, > the root disk stays in read-only mode. Obviously > at some point the bootup just stops. No syslog error > message are available (nothing is written). > > XFS is compiled in (with quota support). It is obvious that the kernel > mounts the root disk (which is XFS) and reads its contents on bootup, but > it never switches it to read-write. > > Any suggestions would be very helpful. Thanks for the great > file system. Add "rw" to the kernel command line. -- Arto Jantunen From owner-linux-xfs@oss.sgi.com Sun Feb 3 13:13:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13LDpA32082 for linux-xfs-outgoing; Sun, 3 Feb 2002 13:13:51 -0800 Received: from web13005.mail.yahoo.com (web13005.mail.yahoo.com [216.136.174.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13LDkA32060 for ; Sun, 3 Feb 2002 13:13:46 -0800 Message-ID: <20020203201344.89018.qmail@web13005.mail.yahoo.com> Received: from [216.40.239.142] by web13005.mail.yahoo.com via HTTP; Sun, 03 Feb 2002 12:13:44 PST Date: Sun, 3 Feb 2002 12:13:44 -0800 (PST) From: Darius Stout Subject: XFS with md device on RAID5 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi SGI Technical Person!!!!!! Thank you very much for your XFS port. It is really what Linux needed!!!!!! The reason that I am writing to you is because of a FAQ that I read on your site that states that using RAID5 on a "md" device makes "writes" slow. BUT that the performance can be "normalized" by setting up an external log device. I need help here because I have never configuraed one before. My machine is a 1.8 P4 running two arrays of 12 100GB data drives each. I am running Adaptec 3940UW SCSI adapters. I installed your 1.02 SGI Installer with Redhat 7.2. I reconfigured everything to a vanilla 2.4.10 kernel and everything is running well. The System drives are 60GB EIDE in RAID1 mode. Everything is XFS. I have about 40GB of room left on the system drives. Can I put the external logging for the two large arrays on the system drives? Could you show me the steps necessary to do this? This project is for a customer that is to be delivered by the end of the month. Thank You very much for your consideration!!!!!!! Your Friend in SGI, Darius Stout __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From owner-linux-xfs@oss.sgi.com Sun Feb 3 13:17:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13LHDj00767 for linux-xfs-outgoing; Sun, 3 Feb 2002 13:17:13 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13LHAA00737 for ; Sun, 3 Feb 2002 13:17:10 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id MAA03586 for ; Sun, 3 Feb 2002 12:18:13 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA04292; Mon, 4 Feb 2002 07:15:50 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA05794; Mon, 4 Feb 2002 07:15:49 +1100 (AEDT) Date: Mon, 4 Feb 2002 07:15:48 +1100 From: Nathan Scott To: Ethan Benson Cc: Linux XFS Mailing List Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020204071548.A98946@wobbly.melbourne.sgi.com> References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <20020201213849.Y14742@plato.local.lan> <"from <20020203212333.B104774@wobbly.melbourne.sgi.com> <20020203015819.B27218@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020203015819.B27218@plato.local.lan>; from erbenson@alaska.net on Sun, Feb 03, 2002 at 01:58:19AM -0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 01:58:19AM -0900, Ethan Benson wrote: > On Sun, Feb 03, 2002 at 09:23:33PM +1100, Nathan Scott wrote: > > > > attributes in the system namespace will need to be converted to > > the native filesystem format before/after being written/read. > > yes, i was wondering where this conversion happens, libacl, or the > kernel. In the kernel (inside XFS). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 3 13:36:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13Lal203806 for linux-xfs-outgoing; Sun, 3 Feb 2002 13:36:47 -0800 Received: from downtown.oche.de (root@downtown.oche.de [194.94.253.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13LagA03783 for ; Sun, 3 Feb 2002 13:36:43 -0800 Received: (from uucp@localhost) by downtown.oche.de (8.9.3/8.9.3/Debian 8.9.3-21) with UUCP id VAA22839 for linux-xfs@oss.sgi.com; Sun, 3 Feb 2002 21:36:38 +0100 Received: (from martin@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id VAA01317; Sun, 3 Feb 2002 21:36:04 +0100 (MET) Date: Sun, 3 Feb 2002 21:36:04 +0100 (MET) Message-Id: <200202032036.VAA01317@foehn.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: XFS with md device on RAID5 X-Newsgroups: list.linux-xfs In-Reply-To: Organization: home User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (SunOS/5.5.1 (sun4m)) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > [...] BUT that > the performance can be "normalized" by setting up an > external log device. I need help here because I have > never configuraed one before. # man mkfs.xfs [...] mkfs.xfs -l logdev=/dev/,size= /dev/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Feb 3 13:59:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13LxkC13279 for linux-xfs-outgoing; Sun, 3 Feb 2002 13:59:46 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13LxgA13200 for ; Sun, 3 Feb 2002 13:59:42 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16XTjb-0007cs-00; Sun, 03 Feb 2002 21:59:35 +0100 Date: Sun, 3 Feb 2002 21:59:35 +0100 To: Martin Spott Cc: linux-xfs@oss.sgi.com Subject: Re: XFS with md device on RAID5 Message-ID: <20020203205935.GY14687@muaddib.localnet> References: <200202032036.VAA01317@foehn.quickstep.oche.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202032036.VAA01317@foehn.quickstep.oche.de> User-Agent: Mutt/1.3.25i From: Ingo Juergensmann X-Scanner: exiscan *16XTjb-0007cs-00*I1Tw/W0/Jpk* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 09:36:04PM +0100, Martin Spott wrote: > # man mkfs.xfs > [...] > mkfs.xfs -l logdev=/dev/,size= /dev/ Is it possible to transfer the log to another device without making the fs new? My / is on a XFS-Raid5 and transferring log with making new fs would make it quite time consuming... ;) -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Sun Feb 3 14:06:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13M6s616496 for linux-xfs-outgoing; Sun, 3 Feb 2002 14:06:54 -0800 Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13M6oA16473 for ; Sun, 3 Feb 2002 14:06:50 -0800 Message-Id: <200202032206.g13M6oA16473@oss.sgi.com> Received: from there ([144.135.25.84]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GQZ6Z500.AFE; Mon, 4 Feb 2002 07:13:53 +1000 Received: from CPE-144-137-137-94.qld.bigpond.net.au ([144.137.137.94]) by psmam06.mailsvc.email.bigpond.com(MailRouter V3.0h 116/2438996); 04 Feb 2002 07:06:40 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Ingo Juergensmann , Martin Spott Subject: Re: XFS with md device on RAID5 Date: Mon, 4 Feb 2002 07:06:37 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <200202032036.VAA01317@foehn.quickstep.oche.de> <20020203205935.GY14687@muaddib.localnet> In-Reply-To: <20020203205935.GY14687@muaddib.localnet> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 4 Feb 2002 06:59, Ingo Juergensmann wrote: > On Sun, Feb 03, 2002 at 09:36:04PM +0100, Martin Spott wrote: > > # man mkfs.xfs > > [...] > > mkfs.xfs -l logdev=/dev/,size= > > /dev/ > > Is it possible to transfer the log to another device without making the fs > new? My / is on a XFS-Raid5 and transferring log with making new fs would > make it quite time consuming... ;) Steve Lord talked about this and for memory had a solution quite some time ago. I tihink it was in the 1st half of last year - have a search through the mail archives. It was not an easy procedure if I remember correctly. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Sun Feb 3 14:07:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13M7n217045 for linux-xfs-outgoing; Sun, 3 Feb 2002 14:07:49 -0800 Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13M7fA16894 for ; Sun, 3 Feb 2002 14:07:41 -0800 Message-Id: <200202032207.g13M7fA16894@oss.sgi.com> Received: from there ([144.135.25.87]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GQZ70L00.082 for ; Mon, 4 Feb 2002 07:14:45 +1000 Received: from CPE-144-137-137-94.qld.bigpond.net.au ([144.137.137.94]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/4942547); 04 Feb 2002 07:07:32 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Linux XFS Mailing List Subject: Fwd: Re: XFS with md device on RAID5 Date: Mon, 4 Feb 2002 07:07:29 +1000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 4 Feb 2002 06:13, you wrote: > My machine is a 1.8 P4 running two arrays of 12 100GB > data drives each. I am running Adaptec 3940UW SCSI > adapters. I installed your 1.02 SGI Installer with > Redhat 7.2. I reconfigured everything to a vanilla > 2.4.10 kernel and everything is running well. The > System drives are 60GB EIDE in RAID1 mode. Everything > is XFS. > > I have about 40GB of room left on the system drives. > Can I put the external logging for the two large > arrays on the system drives? Could you show me the > steps necessary to do this? Creating an external log AFAIK can only be done during a mkfs.xfs. An example showing mkfs.xfs and mount options can be found here: http://marc.theaimsgroup.com/?l=linux-xfs&m=101221434621411&w=2 I expect you could have the logs on the system disks - you have to remember that the logs have to be in their own partitions. It is also nice to have the logs on a raid1 device for fault tolerance. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Sun Feb 3 14:24:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13MO2322565 for linux-xfs-outgoing; Sun, 3 Feb 2002 14:24:02 -0800 Received: from foehn.plesnik.bonsai.de (mail.plesnik.de [212.117.70.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13MNrA22536 for ; Sun, 3 Feb 2002 14:23:54 -0800 Received: (from mas@localhost) by foehn.plesnik.bonsai.de (8.9.1/8.9.1) id WAA25403 for linux-xfs@oss.sgi.com; Sun, 3 Feb 2002 22:21:54 +0100 Message-ID: <20020203222154.A25197@foehn.plesnik.bonsai.de> Date: Sun, 3 Feb 2002 22:21:54 +0100 From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: XFS with md device on RAID5 References: <200202032036.VAA01317@foehn.quickstep.oche.de> <20020203205935.GY14687@muaddib.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <20020203205935.GY14687@muaddib.localnet>; from Ingo Juergensmann on Sun, Feb 03, 2002 at 09:59:35PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 09:59:35PM +0100, Ingo Juergensmann wrote: > On Sun, Feb 03, 2002 at 09:36:04PM +0100, Martin Spott wrote: > > > # man mkfs.xfs > > [...] > > mkfs.xfs -l logdev=/dev/,size= /dev/ > > Is it possible to transfer the log to another device without making the fs > new? My / is on a XFS-Raid5 and transferring log with making new fs would > make it quite time consuming... ;) Even if it would work I might not trust such a procedure. I believe a proper backup is your friend - especially with mor than 2 TB of space .... Hmmm, It appeared to me that you were building a new filesystem !? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Feb 3 14:59:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13MxTf30890 for linux-xfs-outgoing; Sun, 3 Feb 2002 14:59:29 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13MxMA30686 for ; Sun, 3 Feb 2002 14:59:23 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16XUfJ-0007oe-00; Sun, 03 Feb 2002 22:59:13 +0100 Date: Sun, 3 Feb 2002 22:59:13 +0100 To: Martin Spott Cc: linux-xfs@oss.sgi.com Subject: Re: XFS with md device on RAID5 Message-ID: <20020203215913.GA14687@muaddib.localnet> References: <200202032036.VAA01317@foehn.quickstep.oche.de> <20020203205935.GY14687@muaddib.localnet> <20020203222154.A25197@foehn.plesnik.bonsai.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020203222154.A25197@foehn.plesnik.bonsai.de> User-Agent: Mutt/1.3.25i From: Ingo Juergensmann X-Scanner: exiscan *16XUfJ-0007oe-00*seAmtu3SLh.* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 10:21:54PM +0100, Martin Spott wrote: > > Is it possible to transfer the log to another device without making the fs > > new? My / is on a XFS-Raid5 and transferring log with making new fs would > > make it quite time consuming... ;) > Even if it would work I might not trust such a procedure. I believe a proper > backup is your friend - especially with mor than 2 TB of space .... Oh, well, 2 TB would be nice to have it in my DSL router... but there are just 4x 2 GB SCSI + 1x 9 GB in that HP Netserver 5/133 LS... ;) > Hmmm, It appeared to me that you were building a new filesystem !? Me? No, must have been a different person... ;) Well, so I will remake the FS somewhen when I find the time to backup and restore all that stuff... :) -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Sun Feb 3 15:24:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13NOFT04886 for linux-xfs-outgoing; Sun, 3 Feb 2002 15:24:15 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13NO1A04861 for ; Sun, 3 Feb 2002 15:24:02 -0800 Received: by monkeyiq.dnsalias.org id g13MPr427241 ; Mon, 4 Feb 2002 08:25:53 +1000 Date: Mon, 4 Feb 2002 08:25:53 +1000 Message-Id: <200202032225.g13MPr427241@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Cc: monkeyiq Subject: Re: Preallocation and Ferris From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen Lord writes: > monkeyiq wrote: > > > found the calls in xfs(5) > > >XFS_IOC_FSGETXATTR > >XFS_IOC_RESVSP64 > >XFS_IOC_UNRESVSP64 > > > > ... > > > It is possible to query xfs to find out all sorts of stuff about the layout of a > > file, take a look at the xfs_bmap program and its source code. If you are > not creating files with holes in then a simple stat system call will suffice, > > the st_blocks will include preallocated space beyond the end of file. > > Steve I had a look at bmap, very nice. BTW as an aside the man pages dont document -p or -V (and -v though that one is not even in bmap --help) for bmap [xfsprogs-1.3.17-0]. After looking through xfs_mkfile I came to the conclusion that code like the following #include #include #include #include #include int main(int argc, char **argv) { int size = 1024; int oflags = O_CREAT|O_TRUNC|O_WRONLY; int fd=0; xfs_flock64_t flck; flck.l_whence = SEEK_SET; flck.l_start = 0LL; flck.l_len = size; fd = open( "/home/ben/tmp/testf", oflags, 0600); ioctl(fd, XFS_IOC_RESVSP64, &flck); close(fd); exit( 0 ); } would preallocate space. This seems to work ok, but files created using and -p xfs_mkfile always have a size==the preallocation size. I am only wondering if this example is correct because in xfs_mkfile.c it casts away the return value of ioctl() so there is no way to tell if the preallocation was a success. For example [XFS]$ ./a.out [XFS]$ /usr/sbin/xfs_mkfile -p 1k ~/tmp/testf.x [XFS]$ xfs_bmap -v ~/tmp/testf ~/tmp/testf.x /home/ben/tmp/testf: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 1528856..1528863 1 (759752..759759) 8 /home/ben/tmp/testf.x: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 1404072..1404079 1 (634968..634975) 8 [ben@kloof XFS]$ stat ~/tmp/testf ~/tmp/testf.x File: "/home/ben/tmp/testf" Size: 0 Blocks: 8 Regular File Access: (0600/-rw-------) Uid: ( 500/ ben) Gid: ( 1006/ ben) Device: 305 Inode: 3626363 Links: 1 Access: Mon Feb 4 08:13:08 2002 Modify: Mon Feb 4 08:13:08 2002 Change: Mon Feb 4 08:13:08 2002 File: "/home/ben/tmp/testf.x" Size: 1024 Blocks: 8 Regular File Access: (0600/-rw-------) Uid: ( 500/ ben) Gid: ( 1006/ ben) Device: 305 Inode: 3626366 Links: 1 Access: Mon Feb 4 08:13:15 2002 Modify: Mon Feb 4 08:13:15 2002 Change: Mon Feb 4 08:13:15 2002 And using /usr/sbin/xfs_mkfile -v -n -p 1k testf.x2 [tmp]$ stat testf.x2 File: "testf.x2" Size: 1024 Blocks: 128 Regular File Access: (0600/-rw-------) Uid: ( 500/ ben) Gid: ( 1006/ ben) Device: 305 Inode: 3626373 Links: 1 Access: Mon Feb 4 08:20:04 2002 Modify: Mon Feb 4 08:22:00 2002 Change: Mon Feb 4 08:22:00 2002 [tmp]$ bmap -v testf.x2 testf.x2: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..127]: 1771048..1771175 2 (232840..232967) 128 So I presume that the -n nobytes is causing a different Allocation Group for the last file (prehaps holey files are in AG2 for that fs by default). ------------------------------------------------------- Story at 11 http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Sun Feb 3 17:09:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1419kc29319 for linux-xfs-outgoing; Sun, 3 Feb 2002 17:09:46 -0800 Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1419eA29254 for ; Sun, 3 Feb 2002 17:09:40 -0800 Message-Id: <200202040109.g1419eA29254@oss.sgi.com> Received: from there ([144.135.25.81]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GQZFFV00.CZB; Mon, 4 Feb 2002 10:16:43 +1000 Received: from CPE-144-137-137-94.qld.bigpond.net.au ([144.137.137.94]) by psmam05.mailsvc.email.bigpond.com(MailRouter V3.0h 107/2964743); 04 Feb 2002 10:09:30 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Ingo Juergensmann , Martin Spott Subject: Re: XFS with md device on RAID5 Date: Mon, 4 Feb 2002 10:09:27 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <20020203205935.GY14687@muaddib.localnet> <200202032206.g13M6oA16473@oss.sgi.com> In-Reply-To: <200202032206.g13M6oA16473@oss.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 4 Feb 2002 07:06, Adrian Head wrote: > On Mon, 4 Feb 2002 06:59, Ingo Juergensmann wrote: > > On Sun, Feb 03, 2002 at 09:36:04PM +0100, Martin Spott wrote: > > > # man mkfs.xfs > > > [...] > > > mkfs.xfs -l logdev=/dev/,size= > > > /dev/ > > > > Is it possible to transfer the log to another device without making the > > fs new? My / is on a XFS-Raid5 and transferring log with making new fs > > would make it quite time consuming... ;) > > Steve Lord talked about this and for memory had a solution quite some time > ago. I tihink it was in the 1st half of last year - have a search through > the mail archives. It was not an easy procedure if I remember correctly. Here are the details on moving an internal log to the external log as per Steve's email early last year. http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721116479&w=2 -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Sun Feb 3 17:18:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g141ILj01300 for linux-xfs-outgoing; Sun, 3 Feb 2002 17:18:21 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g141IGA01197 for ; Sun, 3 Feb 2002 17:18:16 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16XWpa-0008G5-00; Mon, 04 Feb 2002 01:17:58 +0100 Date: Mon, 4 Feb 2002 01:17:58 +0100 To: Adrian Head Cc: linux-xfs@oss.sgi.com Subject: Re: XFS with md device on RAID5 Message-ID: <20020204001758.GC14687@muaddib.localnet> References: <20020203205935.GY14687@muaddib.localnet> <200202032206.g13M6oA16473@oss.sgi.com> <200202040007.g14070w13619@aaa.ahws.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202040007.g14070w13619@aaa.ahws.de> User-Agent: Mutt/1.3.25i From: Ingo Juergensmann X-Scanner: exiscan *16XWpa-0008G5-00*bSCRuxcooz.* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 10:09:27AM +1000, Adrian Head wrote: > > Steve Lord talked about this and for memory had a solution quite some time > > ago. I tihink it was in the 1st half of last year - have a search through > > the mail archives. It was not an easy procedure if I remember correctly. > Here are the details on moving an internal log to the external log as per > Steve's email early last year. > http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721116479&w=2 Ah, thx... but as far as I understood this, this is only practiciable with partitions other than / 'cos unmounting is demanded - which of course interfere with being /-device within all of the others dirs like /bin, /home, /sbin and such... ;) But thx for the link :)) -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Sun Feb 3 18:47:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g142lQD32576 for linux-xfs-outgoing; Sun, 3 Feb 2002 18:47:26 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g142lKA32450 for ; Sun, 3 Feb 2002 18:47:20 -0800 Received: (qmail 741 invoked from network); 4 Feb 2002 01:47:15 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Feb 2002 01:47:15 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id B805F3000B8; Mon, 4 Feb 2002 12:47:13 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 804118E for ; Mon, 4 Feb 2002 12:47:13 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: New XFS Survey Response In-reply-to: Your message of "Sun, 03 Feb 2002 13:19:21 -0800." <200202032119.g13LJLa01414@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Feb 2002 12:47:08 +1100 Message-ID: <16228.1012787228@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >Some kind of automated patch dump would be nice. I use the benh kernel >for powerpc, so merging by hand is a necessity, and sometimes it's >difficult to find a good set of xfs patches for a given version. See ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/README. To patch other trees you need XFS split into its components which is what you get in patches/2.4.*. It is quite a bit of work to take the CVS tree and separate the various components, it has to be done by hand. These snapshots are only created for major kernel releases and when we believe that XFS is stable on that release, they are not up to date. For automated patch dumps, fetch all of XFS CVS and diff it against a pristine Marcelo/Linus tree. From owner-linux-xfs@oss.sgi.com Sun Feb 3 20:33:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g144Xlr26846 for linux-xfs-outgoing; Sun, 3 Feb 2002 20:33:47 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g144XhA26764 for ; Sun, 3 Feb 2002 20:33:43 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g143XZo10865 for ; Sun, 3 Feb 2002 19:33:35 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA77706; Sun, 3 Feb 2002 19:33:03 -0800 (PST) Date: Sun, 3 Feb 2002 21:33:02 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Ingo Juergensmann cc: Adrian Head , Subject: Re: XFS with md device on RAID5 In-Reply-To: <20020204001758.GC14687@muaddib.localnet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 4 Feb 2002, Ingo Juergensmann wrote: > Ah, thx... but as far as I understood this, this is only practiciable with > partitions other than / 'cos unmounting is demanded - which of course > interfere with being /-device within all of the others dirs like /bin, > /home, /sbin and such... ;) Well, if you were going to try this (and again, it's a bit risky in the first place) you would need to boot from a rescue disk. -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 3 22:17:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g146HVQ08571 for linux-xfs-outgoing; Sun, 3 Feb 2002 22:17:31 -0800 Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g146HLA08357 for ; Sun, 3 Feb 2002 22:17:21 -0800 Received: from erbenson.alaska.net (15-pm33.nwc.alaska.net [209.112.159.15]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g145Gsv65007 for ; Sun, 3 Feb 2002 20:16:54 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 6807A3939 for ; Sun, 3 Feb 2002 20:16:53 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 42AAD10242; Sun, 3 Feb 2002 20:16:53 -0900 (AKST) Date: Sun, 3 Feb 2002 20:16:53 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: New XFS Survey Response Message-ID: <20020203201653.E14742@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200202032119.g13LJLa01414@oss.sgi.com> <16228.1012787228@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UOi+gfmBpEZPw9cU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <16228.1012787228@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Mon, Feb 04, 2002 at 12:47:08PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --UOi+gfmBpEZPw9cU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 04, 2002 at 12:47:08PM +1100, Keith Owens wrote: > >Some kind of automated patch dump would be nice. I use the benh kernel > >for powerpc, so merging by hand is a necessity, and sometimes it's > >difficult to find a good set of xfs patches for a given version. >=20 > See ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/README. To > patch other trees you need XFS split into its components which is what > you get in patches/2.4.*. >=20 > It is quite a bit of work to take the CVS tree and separate the various > components, it has to be done by hand. These snapshots are only > created for major kernel releases and when we believe that XFS is > stable on that release, they are not up to date. For automated patch > dumps, fetch all of XFS CVS and diff it against a pristine > Marcelo/Linus tree. once 2.4.18 is released there will be no reason to run the benh kernel tree on powerpc anyway, all the powerpc changes are merged mainline. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --UOi+gfmBpEZPw9cU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxeGUUACgkQJKx7GixEevzKoQCfVEzkR5SFXYoA3yvUzeIQtMu9 MQ8Ani2DRGHHVLtQBeALA20PyEP96304 =r0G3 -----END PGP SIGNATURE----- --UOi+gfmBpEZPw9cU-- From owner-linux-xfs@oss.sgi.com Mon Feb 4 03:53:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14Bren13700 for linux-xfs-outgoing; Mon, 4 Feb 2002 03:53:40 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14BrSA13523 for ; Mon, 4 Feb 2002 03:53:28 -0800 Received: by monkeyiq.dnsalias.org id g14At5409376 ; Mon, 4 Feb 2002 20:55:05 +1000 Date: Mon, 4 Feb 2002 20:55:05 +1000 Message-Id: <200202041055.g14At5409376@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Cc: monkeyiq Subject: Re: Preallocation and Ferris From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, After looking at the xfs_bmap code a little and working out my next move I noticed in xfs_fs.h struct getbmapx { __s64 bmv_offset; /* file offset of segment in blocks */ __s64 bmv_block; /* starting block (64-bit daddr_t) */ __s64 bmv_length; /* length of segment, blocks */ __s32 bmv_count; /* # of entries in array incl. 1st */ __s32 bmv_entries; /* # of entries filled in (output). */ __s32 bmv_iflags; /* input flags (1st structure) */ __s32 bmv_oflags; /* output flags (after 1st structure)*/ __s32 bmv_unused1; /* future use */ __s32 bmv_unused2; /* future use */ }; /* bmv_iflags values - set by XFS_IOC_GETBMAPX caller. */ #define BMV_IF_ATTRFORK 0x1 /* return attr fork rather than data */ #define BMV_IF_NO_DMAPI_READ 0x2 /* Do not generate DMAPI read event */ #define BMV_IF_PREALLOC 0x4 /* rtn status BMV_OF_PREALLOC if req */ #define BMV_IF_VALID (BMV_IF_ATTRFORK|BMV_IF_NO_DMAPI_READ|BMV_IF_PREALLOC) #ifdef __KERNEL__ #define BMV_IF_EXTENDED 0x40000000 /* getpmapx if set */ #endif /* bmv_oflags values - returned for for each non-header segment */ #define BMV_OF_PREALLOC 0x1 /* segment = unwritten pre-allocation */ I have tried using BMV_IF_PREALLOC and just dumping out map[i+1].bmv_oflags for each extent listed though its *always* 0. This is using the official 1.0.2 (IIRC) 2.4.14 kernel stuff and xfsprogs-1.3.17-0. I suspect that maybe the prealloc stuff is not being sent to userland and I can not work out how to get xfs_bmap to show me a flag for an extent that is preallocation. BTW I now have preallocation switch working for file creation in ferris :) it shows a 0 byte file with an extent that is the preallocation size rounded up to next block. How "experimental" is the real time file support? I am wondering if there are other sweet xfs features that I should make available in ferris :) The interface to make preallocated files uses the ferriscreate GUI, http://witme.sourceforge.net/ferriscreate.paper2001/ I will make new screenshots of that soon using preallocation and anything else I throw in there for my xfs and other enjoyment. Though I would like to expose the final preallocation extent as fake EA in ferris to allow a easy interface to expand/reduce preallocation from a cute GUI ;) BTW what is the mood on acceptance of a patch for xfs_bmap to have an --xml option to dump the same info from -v as an XML 1.0 document? this would make it nice and easy to make an extent viewer as either a gtk+ app or a php4 app. -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Feb 4 06:34:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14EY9w07884 for linux-xfs-outgoing; Mon, 4 Feb 2002 06:34:09 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14EXhA07440 for ; Mon, 4 Feb 2002 06:33:44 -0800 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g14DXcH23373 for ; Mon, 4 Feb 2002 13:33:38 GMT Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g14DUYg24829; Mon, 4 Feb 2002 13:30:34 GMT Message-ID: <3C5E8CFA.CACF28C3@soton.ac.uk> Date: Mon, 04 Feb 2002 13:30:34 +0000 From: "Ian D. Hardy" Organization: University of Southampton 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 CC: idh@soton.ac.uk Subject: XFS NFS server Oops Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Anyone any ideas on the following Oops (processed with ksymoops 2.4.3). It is from a NFS server (Dual 1Ghz Supermicro LE, 1Gbyte RAM, 40Gbyte Maxtor IDE system disk, Zero-D/GForce RI Fibrechannel to IDE hardware RAID-5 500Gbyte disk unit). It is running the Linux 2.4.17-xfs kernel taken as a CVS image on 27th January. The main area of disk it is serving is on the HW RAID unit, which is the only XFS filesystem on the system. The system had been up for just over 3 days when it crashed. I reported a very similar failure a few weeks ago, at that time running a 2.4.9 based kernel, Steve Lord suggested that we tried the latest CVS image as this had fixed some memory alloacation problems. The machine is essentially an NFS fileserver to a computational cluster. Though of possible interest is the 'save' process that was running on one of the processes, this is the Legato Networker backup client process (which was performing a full backup of the XFS filesystem at the time). I don't think this is significant as I was seeing these crashes (at ~4 to 12 day intervals) with the 2.4.9 kernel not dependant upon a 'save' session running. Oops details: c012fefb *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010002 eax: 00000000 ebx: 00000001 ecx: c3969910 edx: c1000000 esi: f8e34000 edi: 00000286 ebp: 00000000 esp: f7ee3e2c ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=f7ee3000) Stack: f8e34000 d7b574e8 c01beb99 c01bee54 d7b57574 d7b57534 d7b574e8 00000000 c01c1d49 f8e34000 00014010 d7b574e8 00000001 00000000 c01c1db7 d7b574e8 00000000 d7b574e8 c01dbdb5 d7b574e8 d7b574e8 c6b36f00 00000000 c01dbc72 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 13 3b 53 04 73 0e 89 74 93 08 ff 03 eb 3c 8d b6 00 00 00 <1>Unable to handle kernel paging request at virtual address fcdff82f printing eip: c012a147 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Not taintedUnable to handle kernel NULL pointer dereference at virtual address 00000001 EFLAGS: 00010286 eax: fcdff827 ebx: c5d334d0 ecx: 00000012 c012fefb *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: 00000000 ebx: 00000001 ecx: c3969910 edx: c1000000 esi: f8e34000 edi: 00000286 ebp: 00000000 esp: f7ee3e2c ds: 0018 es: 0018 ss: 0018 edx: 0002ef8f esi: 00005451 edi: 0000545e ebp: f7fbbe3c Process kswapd (pid: 5, stackpage=f7ee3000) Stack: f8e34000 d7b574e8 c01beb99 c01bee54 d7b57574 d7b57534 d7b574e8 00000000 esp: cd6b3e40 ds: 0018 es: 0018 ss: 0018 Process save (pid: c01c1d49 f8e34000 00014010 d7b574e8 00000001 00000000 c01c1db7 d7b574e8 00000000 d7b574e8 c01dbdb5 d7b574e8 d7b574e8 c6b36f00 00000000 c01dbc72 Call Trace: [] [] [] [] [] [] [] [] [] [] [] 20987, stackpage=cd6b3000) Stack: dffc54e0 0000000d 00005451 dff [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 13 3b 53 04 73 0e 89 74 93 08 ff 03 eb 3c 8d b6 00 00 00 c54e0 00000020 c012a7c5 0000001f 0000828f c5d33420 c1f38440 c5d334d0 00005432 c012aa37 00000001 dffc54e0 c5d33420 c1f38440 00001000 00000001 00000000 00000000 c5d33420 af244e98 ffffffff Call Trace: [] [] [] [] [] [] [] [] Code: 39 58 08 75 f4 39 78 0c 75 ef c6 05 00 e6 32 c0 01 85 c0 75 >>EIP; c012fefa <===== Trace; c01beb98 Trace; c01bee54 Trace; c01c1d48 Trace; c01c1db6 Trace; c01dbdb4 Trace; c01dbc72 Trace; c01eb430 Trace; c01eb8b6 Trace; c01eba02 Trace; c01ea9da Trace; c014c124 Trace; c014b4fe Trace; c014c1b0 Trace; c014c408 Trace; c014c450 Trace; c013138e Trace; c01313ec Trace; c0131490 Trace; c0131506 Trace; c0131640 Trace; c01315a0 Trace; c0105000 <_stext+0/0> Trace; c0105826 Trace; c01315a0 Code; c012fefa 00000000 <_EIP>: Code; c012fefa <===== 0: 8b 13 mov (%ebx),%edx <===== Code; c012fefc 2: 3b 53 04 cmp 0x4(%ebx),%edx Code; c012fefe 5: 73 0e jae 15 <_EIP+0x15> c012ff0e Code; c012ff00 7: 89 74 93 08 mov %esi,0x8(%ebx,%edx,4) Code; c012ff04 b: ff 03 incl (%ebx) Code; c012ff06 d: eb 3c jmp 4b <_EIP+0x4b> c012ff44 Code; c012ff08 f: 8d b6 00 00 00 00 lea 0x0(%esi),%esi <1>Unable to handle kernel paging request at virtual address fcdff82f c012a147 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010286 eax: fcdff827 ebx: c5d334d0 ecx: 00000012 edx: 0002ef8f esi: 00005451 edi: 0000545e ebp: f7fbbe3c esp: cd6b3e40 ds: 0018 es: 0018 ss: 0018 Process save (pid: 20987, stackpage=cd6b3000) Stack: dffc54e0 0000000d 00005451 dffc54e0 00000020 c012a7c5 0000001f 0000828f c5d33420 c1f38440 c5d334d0 00005432 c012aa37 00000001 dffc54e0 c5d33420 c1f38440 00001000 00000001 00000000 00000000 c5d33420 af244e98 ffffffff Call Trace: [] [] [] [] [] [] [] [] Code: 39 58 08 75 f4 39 78 0c 75 ef c6 05 00 e6 32 c0 01 85 c0 75 >>EIP; c012a146 <===== Trace; c012a7c4 Trace; c012aa36 Trace; c012afdc Trace; c012ae80 Trace; c01e6d30 Trace; c01e324e Trace; c0138496 Trace; c010712a Code; c012a146 00000000 <_EIP>: Code; c012a146 <===== 0: 39 58 08 cmp %ebx,0x8(%eax) <===== Code; c012a148 3: 75 f4 jne fffffff9 <_EIP+0xfffffff9> c012a13e Code; c012a14a 5: 39 78 0c cmp %edi,0xc(%eax) Code; c012a14e 8: 75 ef jne fffffff9 <_EIP+0xfffffff9> c012a13e Code; c012a150 a: c6 05 00 e6 32 c0 01 movb $0x1,0xc032e600 Code; c012a156 11: 85 c0 test %eax,%eax Code; c012a158 13: 75 00 jne 15 <_EIP+0x15> c012a15a -- Any ideas? Thanks Ian Hardy From owner-linux-xfs@oss.sgi.com Mon Feb 4 07:25:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14FPRa25141 for linux-xfs-outgoing; Mon, 4 Feb 2002 07:25:27 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14FPLA25085 for ; Mon, 4 Feb 2002 07:25:21 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA01890 for ; Mon, 4 Feb 2002 06:26:24 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA60119; Mon, 4 Feb 2002 06:24:46 -0800 (PST) Date: Mon, 4 Feb 2002 08:24:45 -0600 (CST) From: Eric Sandeen X-X-Sender: To: monkeyiq cc: Subject: Re: Preallocation and Ferris In-Reply-To: <200202041055.g14At5409376@monkeyiq.dnsalias.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 4 Feb 2002, monkeyiq wrote: > How "experimental" is the real time file support? I am wondering > if there are other sweet xfs features that I should make available > in ferris :) The interface to make preallocated files uses the It's still not well tested on Linux... I'll check in a fix soon for a fairly serious bug in RT - if you open an RT file and write to it without O_DIRECT, it writes to the main data device, not the RT device. Not so good. I'm trying to do more thorough testing in the next few days. > BTW what is the mood on acceptance of a patch for xfs_bmap to have > an --xml option to dump the same info from -v as an XML 1.0 document? > this would make it nice and easy to make an extent viewer as either > a gtk+ app or a php4 app. Sounds interesting to me. Do you have such a patch? -Eric From owner-linux-xfs@oss.sgi.com Mon Feb 4 08:52:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14Gq3I13803 for linux-xfs-outgoing; Mon, 4 Feb 2002 08:52:03 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14GpuA13646 for ; Mon, 4 Feb 2002 08:51:56 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA424213 for ; Mon, 4 Feb 2002 16:50:36 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA74313; Mon, 4 Feb 2002 09:50:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA37097; Mon, 4 Feb 2002 09:50:34 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g14Fldb21692; Mon, 4 Feb 2002 09:47:39 -0600 Subject: Re: mounting disk as read-write after boot. From: Steve Lord To: Frank Samuelson Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Feb 2002 09:47:39 -0600 Message-Id: <1012837659.26397.557.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-02-03 at 08:17, Frank Samuelson wrote: > I installed a system with the RedHat-XFS disks. > It works great. All file systems are xfs. > > But when I compile my own kernel (2.4.17 with xfs patch) > and install it, and reboot, > the root disk stays in read-only mode. Obviously > at some point the bootup just stops. No syslog error > message are available (nothing is written). > > XFS is compiled in (with quota support). It is obvious that the kernel > mounts the root disk (which is XFS) and reads its contents on bootup, but > it never switches it to read-write. > > Any suggestions would be very helpful. Thanks for the great > file system. > > Frank Samuelson > > Well, the linux user spaces I am familiar with expect to come up with a read only root, and then remount it rw after doing some checks. The remount should be being initiated from user space, and xfs does respond to this. I would suspect your user space here and not the kernel. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Feb 4 08:51:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14GprI13571 for linux-xfs-outgoing; Mon, 4 Feb 2002 08:51:53 -0800 Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14GpSA13007 for ; Mon, 4 Feb 2002 08:51:28 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id C9025805296 for ; Mon, 4 Feb 2002 10:51:15 -0500 (EST) Received: from sa-bwmail1.esr.hp.com (sa-bwmail1.esr.hp.com [15.1.192.32]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 5E7AE4000A2 for ; Mon, 4 Feb 2002 10:51:15 -0500 (EST) Received: by sa-bwmail1.esr.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 10:48:57 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B53904602B7F@sa-bwmail1.esr.hp.com> From: "Christian, Chip" To: "Linux XFS (E-mail)" Subject: kernel Oops Date: Mon, 4 Feb 2002 10:48:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are running RedHat Linux 7.1 with XFS Release 1.0.2. Custom kernel built from kernel-source-2.4.9-12SGI_XFS_1.0.2. Got the following Oops(es) this am. Can anyone give me a hand tracking it down? Thanks. -Chip ksymoops 2.4.0 on i686 2.4.9-12SGI_XFS_1.0.2custom. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.9-12SGI_XFS_1.0.2custom/ (default) -m /boot/System.map (specified) Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says 40270d30, System.map says 40157c70. Ignoring ksyms_base entry Feb 3 04:02:00 nas2 nmbd[6817]: Got SIGHUP dumping debug info. Feb 4 00:05:35 nas2 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000074 Feb 4 00:05:35 nas2 kernel: 4012cb87 Feb 4 00:05:35 nas2 kernel: *pde = 00000000 Feb 4 00:05:35 nas2 kernel: Oops: 0000 Feb 4 00:05:35 nas2 kernel: CPU: 0 Feb 4 00:05:35 nas2 kernel: EIP: 0010:[kfree+55/144] Not tainted Feb 4 00:05:35 nas2 kernel: EIP: 0010:[<4012cb87>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Feb 4 00:05:35 nas2 kernel: EFLAGS: 00010006 Feb 4 00:05:35 nas2 kernel: eax: 00000000 ebx: 40800000 ecx: 00000000 edx: 0004097e Feb 4 00:05:35 nas2 kernel: esi: 8097e000 edi: 00000286 ebp: 6a65ce80 esp: 7f8c1e6c Feb 4 00:05:35 nas2 kernel: ds: 0018 es: 0018 ss: 0018 Feb 4 00:05:35 nas2 kernel: Process umount (pid: 25981, stackpage=7f8c1000) Feb 4 00:05:35 nas2 kernel: Stack: 8097e000 00000206 40800000 5d8ea400 8097e000 40800000 8097e000 00000001 Feb 4 00:05:35 nas2 kernel: 401de2ac 8097e000 00008203 633ea2c0 5d8ea400 00000000 00000001 79dac860 Feb 4 00:05:35 nas2 kernel: 401dd3d4 6a65ce80 5d8ea400 5d8ea400 67278cc0 401e4fe1 5d8ea400 5d8ea400 Feb 4 00:05:35 nas2 kernel: Call Trace: [xlog_unalloc_log+60/192] Feb 4 00:05:35 nas2 kernel: Call Trace: [<401de2ac>] Feb 4 00:05:35 nas2 kernel: [<401dd3d4>] Feb 4 00:05:35 nas2 kernel: [<401e4fe1>] Feb 4 00:05:35 nas2 kernel: [<401ed3da>] Feb 4 00:05:35 nas2 kernel: [<401f7134>] Feb 4 00:05:35 nas2 kernel: [<401fe3df>] Feb 4 00:05:35 nas2 kernel: [<4013a5cf>] Feb 4 00:05:35 nas2 kernel: [<4013e899>] Feb 4 00:05:35 nas2 kernel: [<4014bb29>] Feb 4 00:05:35 nas2 kernel: [<4014bc1b>] Feb 4 00:05:35 nas2 kernel: [<401259a3>] Feb 4 00:05:35 nas2 kernel: [<4014bc4c>] Feb 4 00:05:35 nas2 kernel: [<4010714b>] Feb 4 00:05:35 nas2 kernel: Code: 8b 5c 81 74 85 db 74 37 8b 13 3b 53 04 73 0a 89 74 93 08 ff >>EIP; 4012cb87 <===== Trace; 401de2ac Trace; 401dd3d4 Trace; 401e4fe1 Trace; 401ed3da Trace; 401f7134 Trace; 401fe3df Trace; 4013a5cf Trace; 4013e899 Trace; 4014bb29 Trace; 4014bc1b Trace; 401259a3 Trace; 4014bc4c Trace; 4010714b Code; 4012cb87 00000000 <_EIP>: Code; 4012cb87 <===== 0: 8b 5c 81 74 mov 0x74(%ecx,%eax,4),%ebx <===== Code; 4012cb8b 4: 85 db test %ebx,%ebx Code; 4012cb8d 6: 74 37 je 3f <_EIP+0x3f> 4012cbc6 Code; 4012cb8f 8: 8b 13 mov (%ebx),%edx Code; 4012cb91 a: 3b 53 04 cmp 0x4(%ebx),%edx Code; 4012cb94 d: 73 0a jae 19 <_EIP+0x19> 4012cba0 Code; 4012cb96 f: 89 74 93 08 mov %esi,0x8(%ebx,%edx,4) Code; 4012cb9a 13: ff 00 incl (%eax) Feb 4 00:05:36 nas2 kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000074 Feb 4 00:05:36 nas2 kernel: 4012cb87 Feb 4 00:05:36 nas2 kernel: *pde = 00000000 Feb 4 00:05:36 nas2 kernel: Oops: 0000 Feb 4 00:05:36 nas2 kernel: CPU: 0 Feb 4 00:05:36 nas2 kernel: EIP: 0010:[kfree+55/144] Not tainted Feb 4 00:05:36 nas2 kernel: EIP: 0010:[<4012cb87>] Not tainted Feb 4 00:05:36 nas2 kernel: EFLAGS: 00010006 Feb 4 00:05:36 nas2 kernel: eax: 00000000 ebx: 80988000 ecx: 00000000 edx: 00040992 Feb 4 00:05:36 nas2 kernel: esi: 80992000 edi: 00000286 ebp: 6a65c580 esp: 7f8c1e6c Feb 4 00:05:36 nas2 kernel: ds: 0018 es: 0018 ss: 0018 Feb 4 00:05:36 nas2 kernel: Process umount (pid: 25983, stackpage=7f8c1000) Feb 4 00:05:36 nas2 kernel: Stack: 80992000 00000206 80988000 5505f800 80992000 80988000 80992000 00000001 Feb 4 00:05:36 nas2 kernel: 401de2ac 80992000 00008203 633ea740 5505f800 00000000 00000001 74bc46a0 Feb 4 00:05:36 nas2 kernel: 401dd3d4 6a65c580 5505f800 5505f800 67278c60 401e4fe1 5505f800 5505f800 Feb 4 00:05:36 nas2 kernel: Call Trace: [xlog_unalloc_log+60/192] Feb 4 00:05:36 nas2 kernel: Call Trace: [<401de2ac>] Feb 4 00:05:36 nas2 kernel: [<401dd3d4>] Feb 4 00:05:36 nas2 kernel: [<401e4fe1>] Feb 4 00:05:36 nas2 kernel: [<401ed3da>] Feb 4 00:05:36 nas2 kernel: [<401f7134>] Feb 4 00:05:36 nas2 kernel: [<401fe3df>] Feb 4 00:05:36 nas2 kernel: [<4013a5cf>] Feb 4 00:05:36 nas2 kernel: [<4013e899>] Feb 4 00:05:36 nas2 kernel: [<4014bb29>] Feb 4 00:05:36 nas2 kernel: [<4014bc1b>] Feb 4 00:05:36 nas2 kernel: [<401259a3>] Feb 4 00:05:36 nas2 kernel: [<4014bc4c>] Feb 4 00:05:36 nas2 kernel: [<4010714b>] Feb 4 00:05:36 nas2 kernel: Code: 8b 5c 81 74 85 db 74 37 8b 13 3b 53 04 73 0a 89 74 93 08 ff >>EIP; 4012cb87 <===== Trace; 401de2ac Trace; 401dd3d4 Trace; 401e4fe1 Trace; 401ed3da Trace; 401f7134 Trace; 401fe3df Trace; 4013a5cf Trace; 4013e899 Trace; 4014bb29 Trace; 4014bc1b Trace; 401259a3 Trace; 4014bc4c Trace; 4010714b Code; 4012cb87 00000000 <_EIP>: Code; 4012cb87 <===== 0: 8b 5c 81 74 mov 0x74(%ecx,%eax,4),%ebx <===== Code; 4012cb8b 4: 85 db test %ebx,%ebx Code; 4012cb8d 6: 74 37 je 3f <_EIP+0x3f> 4012cbc6 Code; 4012cb8f 8: 8b 13 mov (%ebx),%edx Code; 4012cb91 a: 3b 53 04 cmp 0x4(%ebx),%edx Code; 4012cb94 d: 73 0a jae 19 <_EIP+0x19> 4012cba0 Code; 4012cb96 f: 89 74 93 08 mov %esi,0x8(%ebx,%edx,4) Code; 4012cb9a 13: ff 00 incl (%eax) Feb 4 06:11:53 nas2 kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 4 06:11:53 nas2 kernel: 401136b3 Feb 4 06:11:53 nas2 kernel: *pde = 00000000 Feb 4 06:11:53 nas2 kernel: Oops: 0000 Feb 4 06:11:53 nas2 kernel: CPU: 1 Feb 4 06:11:53 nas2 kernel: EIP: 0010:[__wake_up+51/192] Not tainted Feb 4 06:11:53 nas2 kernel: EIP: 0010:[<401136b3>] Not tainted Feb 4 06:11:53 nas2 kernel: EFLAGS: 00010097 Feb 4 06:11:53 nas2 kernel: eax: 5f6b6a07 ebx: 416f4241 ecx: 00000000 edx: 00000000 Feb 4 06:11:53 nas2 kernel: esi: 75228de0 edi: 5f6b6a03 ebp: 71e9ff4c esp: 71e9ff34 Feb 4 06:11:53 nas2 kernel: ds: 0018 es: 0018 ss: 0018 Feb 4 06:11:53 nas2 kernel: Process rpciod (pid: 26080, stackpage=71e9f000) Feb 4 06:11:53 nas2 kernel: Stack: 00000001 00000206 00000003 5f6b6863 75228de0 76bb5014 76bb5010 402b6294 Feb 4 06:11:53 nas2 kernel: 76bb5000 76bb5014 401892d4 75228de0 76bb5000 00001770 76bb5008 718fe6a0 Feb 4 06:11:53 nas2 kernel: 718fe6f4 718fe6a0 71e9e000 00000002 402b394a 718fe6a0 71e9e000 7fffc000 Feb 4 06:11:53 nas2 kernel: Call Trace: [svc_wake_up+84/144] Feb 4 06:11:53 nas2 kernel: Call Trace: [<402b6294>] Feb 4 06:11:53 nas2 kernel: [<401892d4>] Feb 4 06:11:53 nas2 kernel: [<402b394a>] Feb 4 06:11:53 nas2 kernel: [<402b3bc8>] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; 401136b3 <__wake_up+33/c0> <===== Trace; 402b6294 Trace; 401892d4 Trace; 402b394a <__rpc_execute+29a/320> Trace; 402b3bc8 <__rpc_schedule+188/1d0> Feb 4 08:49:18 nas2 kernel: cpu: 0, clocks: 1324510, slice: 441503 Feb 4 08:49:18 nas2 kernel: cpu: 1, clocks: 1324510, slice: 441503 Feb 4 08:49:18 nas2 kernel: SGI XFS with ACLs, EAs, quota, no debug enabled 2 warnings issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Mon Feb 4 08:54:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14Gspa17068 for linux-xfs-outgoing; Mon, 4 Feb 2002 08:54:51 -0800 Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14GsZA16707 for ; Mon, 4 Feb 2002 08:54:36 -0800 Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11]) by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id QAA11904 for ; Mon, 4 Feb 2002 16:54:31 +0100 Received: from eigner.com (crusher.ep-ka.de [194.120.231.18]) by ep-ag.com (8.9.3/8.9.3) with ESMTP id QAA06660 for ; Mon, 4 Feb 2002 16:54:31 +0100 (MET) Message-ID: <3C5EAEB6.5010005@eigner.com> Date: Mon, 04 Feb 2002 16:54:30 +0100 From: Klaus Strebel Organization: EIGNER User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en, de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Compiler Issues - 1st planned as: Actual CVS and LVM-1.0.2 snapshot problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everybody, today i updated LVM-1.0.2 and my cvs tree for xfs and started playing around with snapshots (i'm shure it worked with a little patch for lvm-snap.c of lvm-1.0.1 quite some weeks ago, replacing blocks with iobuf->blocks in the calls for lvm_snapshot_prepare_blocks and __brw_kiovec for raw_read and raw_write). Actually, mounting a snapshot of a XFS-filesystem works great, but the umount segfaults and in the syslog i found this: Feb 1 15:29:11 stb-mobil kernel: Mounting filesystem "lvm(58,9)" in no-recovery mode. Filesystem will be inconsistent. Feb 1 15:29:23 stb-mobil kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/snap Feb 1 15:29:23 stb-mobil kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/snap Feb 1 15:29:23 stb-mobil kernel: I/O error in filesystem ("lvm(58,9)") meta-data dev 0x3a09 block 0x200020 Feb 1 15:29:23 stb-mobil kernel: ("xlog_iodone") error 5 buf count 1024 Feb 1 15:29:23 stb-mobil kernel: xfs_force_shutdown(lvm(58,9),0x2) called from line 939 of file xfs_log.c. Return address = 0xd11250f6 Feb 1 15:29:23 stb-mobil kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,9) Feb 1 15:29:23 stb-mobil kernel: Please umount the filesystem, and rectify the problem(s) Feb 1 15:29:23 stb-mobil kernel: kernel BUG at buffer.c:597! Feb 1 15:29:23 stb-mobil kernel: invalid operand: 0000 Feb 1 15:29:23 stb-mobil kernel: CPU: 0 Feb 1 15:29:23 stb-mobil kernel: EIP: 0010:[] Not tainted Feb 1 15:29:23 stb-mobil kernel: EFLAGS: 00010282 Feb 1 15:29:23 stb-mobil kernel: eax: 0000001c ebx: c0250f94 ecx: c01fc2e0 edx: 000046d1 Feb 1 15:29:23 stb-mobil kernel: esi: cca8bd80 edi: 00000002 ebp: 00000001 esp: ccff3ed4 Feb 1 15:29:23 stb-mobil kernel: ds: 0018 es: 0018 ss: 0018 Feb 1 15:29:23 stb-mobil kernel: Process umount (pid: 1416, stackpage=ccff3000) Feb 1 15:29:23 stb-mobil kernel: Stack: c01d4c59 00000255 00000002 cca8bd80 cca8bd80 c0130dd0 cca8bd80 00000002 Feb 1 15:29:23 stb-mobil kernel: cca8bd80 00000400 c0130de2 cca8bd80 c0131689 cca8bd80 00000035 cd08cbc0 Feb 1 15:29:23 stb-mobil kernel: 00000035 00000000 00000400 00000000 c0131b20 cd08cbc0 c133d780 00000000 Feb 1 15:29:23 stb-mobil kernel: Call Trace: [] [] [] [] [] Feb 1 15:29:23 stb-mobil kernel: [] [] Feb 1 15:29:23 stb-mobil kernel: Feb 1 15:29:23 stb-mobil kernel: Code: 0f 0b 83 c4 08 83 3b 00 75 05 89 33 89 76 24 8b 03 89 46 20 (as you can see, i just mounted the fs, looked if its there and umounted). I tried it with the patch mentioned above and without, with DMAPI as a module and without. then ... i found that i compiled using gcc-2.95.2, the standard of SuSE 7.3 distribution (former compiles i made with kgcc from RedHat, but a month ago i removed my patched and patched kernel-tree and pulled linux-2.4-xfs anew (and forgot to uncommend the line for kgcc). Conclusion: if you want to be sure, that all works right, compile the whole stuff using kgcc resp 2.91.66 ! Ciao Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@eigner.com EIGNER - Precision Lifecycle Management - From owner-linux-xfs@oss.sgi.com Mon Feb 4 09:40:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14He3v31447 for linux-xfs-outgoing; Mon, 4 Feb 2002 09:40:03 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14HdwA31368 for ; Mon, 4 Feb 2002 09:39:58 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 IAA20146 for ; Mon, 4 Feb 2002 08:35:31 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA75616 for ; Mon, 4 Feb 2002 10:38:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA33038 for ; Mon, 4 Feb 2002 10:38:40 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g14Gcep26535; Mon, 4 Feb 2002 10:38:40 -0600 Message-Id: <200202041638.g14Gcep26535@stout.americas.sgi.com> Date: Mon, 4 Feb 2002 10:38:40 -0600 From: Eric Sandeen Subject: TAKE - Fix realtime bug Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you created a realtime file & wrote to it with buffered I/O, it could wind up on the wrong device due to a check that did not allow bmaps for block zero. Block zero on the realtime is perfectly valid, and only pbm_bn < 0 reflects a special situation such as delalloc. Also clean up the "weird blockno" check in set_buffer_dirty_uptodate() so that it won't complain about block zero if it looks like this might be destined for the realtime device. And move the whole check into #ifdef PAGEBUF_DEBUG for good measure. Date: Mon Feb 4 08:31:54 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110920a linux/fs/xfs/pagebuf/page_buf_io.c - 1.6 - Allow block zero in __pb_block_prepare_write_async Move block zero check into PAGEBUF_DEBUG, make it a bit smarter. From owner-linux-xfs@oss.sgi.com Mon Feb 4 09:45:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14HjdE06017 for linux-xfs-outgoing; Mon, 4 Feb 2002 09:45:39 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14HjaA05911 for ; Mon, 4 Feb 2002 09:45:36 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 IAA21160 for ; Mon, 4 Feb 2002 08:41:08 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA75657 for ; Mon, 4 Feb 2002 10:44:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA49053 for ; Mon, 4 Feb 2002 10:44:17 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g14GiH526615; Mon, 4 Feb 2002 10:44:17 -0600 Message-Id: <200202041644.g14GiH526615@stout.americas.sgi.com> Date: Mon, 4 Feb 2002 10:44:17 -0600 From: Eric Sandeen Subject: TAKE - Remove xfs_iflush_all() from xfs_fs_freeze() Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There are still some problems with xfs_freeze, but this solves part of the problem. Even with this change, people are still seeing consistency problems on a frozen filesystem, so don't trust xfs_freeze just yet. Date: Mon Feb 4 08:39:30 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110921a linux/fs/xfs/xfs_fsops.c - 1.73 - Remove xfs_iflush_all() from xfs_fs_freeze(). This doesn't play well with Linux, leaving us with dentries no longer connected to xfs_inodes. From owner-linux-xfs@oss.sgi.com Mon Feb 4 13:58:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14LwHc15009 for linux-xfs-outgoing; Mon, 4 Feb 2002 13:58:17 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14LwBA14981 for ; Mon, 4 Feb 2002 13:58:11 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 NAA02098 for ; Mon, 4 Feb 2002 13:53:46 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA80626; Mon, 4 Feb 2002 15:56:54 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA46567; Mon, 4 Feb 2002 15:56:54 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g14Lrup31504; Mon, 4 Feb 2002 15:53:56 -0600 Subject: Re: Compiler Issues - 1st planned as: Actual CVS and LVM-1.0.2 snapshot problem From: Steve Lord To: Klaus Strebel Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C5EAEB6.5010005@eigner.com> References: <3C5EAEB6.5010005@eigner.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Feb 2002 15:53:56 -0600 Message-Id: <1012859636.21193.679.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-02-04 at 09:54, Klaus Strebel wrote: > Hi everybody, > > today i updated LVM-1.0.2 and my cvs tree for xfs and started playing > around with snapshots (i'm shure it worked with a little patch for > lvm-snap.c of lvm-1.0.1 quite some weeks ago, replacing blocks with > iobuf->blocks in the calls for lvm_snapshot_prepare_blocks and > __brw_kiovec for raw_read and raw_write). > > > then ... i found that i compiled using gcc-2.95.2, the standard of SuSE > 7.3 distribution (former compiles i made with kgcc from RedHat, but a > month ago i removed my patched and patched kernel-tree and pulled > linux-2.4-xfs anew (and forgot to uncommend the line for kgcc). > > Conclusion: if you want to be sure, that all works right, compile the > whole stuff using kgcc resp 2.91.66 ! Just a comment here that I am currently using gcc-2.96-101 which contains a bug fix for a compiler problem which was known to be tripped by some xfs code. It has not failed me yet, but I am only building for a single architecture here. Steve > > Ciao > Klaus > -- > Klaus Strebel > UNIX-Engineer > klaus.strebel@eigner.com > EIGNER - Precision Lifecycle Management - > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Feb 4 13:57:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14LvVS14926 for linux-xfs-outgoing; Mon, 4 Feb 2002 13:57:31 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14LvRA14904 for ; Mon, 4 Feb 2002 13:57:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with SMTP id g14LvLY06740 for ; Mon, 4 Feb 2002 13:57:21 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA11388; Tue, 5 Feb 2002 08:56:05 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA89746; Tue, 5 Feb 2002 08:56:04 +1100 (AEDT) Date: Tue, 5 Feb 2002 08:56:03 +1100 From: Nathan Scott To: monkeyiq Cc: linux-xfs@oss.sgi.com Subject: Re: Preallocation and Ferris Message-ID: <20020205085603.A107204@wobbly.melbourne.sgi.com> References: <200202041055.g14At5409376@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202041055.g14At5409376@monkeyiq.dnsalias.org>; from monkeyiq@users.sourceforge.net on Mon, Feb 04, 2002 at 08:55:05PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 08:55:05PM +1000, monkeyiq wrote: > ... > BTW what is the mood on acceptance of a patch for xfs_bmap to have > an --xml option to dump the same info from -v as an XML 1.0 document? > this would make it nice and easy to make an extent viewer as either > a gtk+ app or a php4 app. Would this introduce a new dependency on libxml? If so, it shouldn't be added into the xfsprogs xfs_bmap - I'd suggest making a new program based on xfs_bmap.c (its only ~400 lines or so), add the new code in there, and distribute that separately. We have always tried to keep xfsprogs' dependencies to the bare minimum, so that people can avoid installing software they don't necessarily want. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 4 14:11:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14MBZs15450 for linux-xfs-outgoing; Mon, 4 Feb 2002 14:11:35 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14MBQA15428 for ; Mon, 4 Feb 2002 14:11:26 -0800 Received: by monkeyiq.dnsalias.org id g14MDOD01235 ; Tue, 5 Feb 2002 08:13:24 +1000 Date: Tue, 5 Feb 2002 08:13:24 +1000 Message-Id: <200202042213.g14MDOD01235@monkeyiq.dnsalias.org> To: Eric Sandeen Cc: monkeyiq , Subject: Re: Preallocation and Ferris From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen writes: > On Mon, 4 Feb 2002, monkeyiq wrote: > > > How "experimental" is the real time file support? I am wondering > > if there are other sweet xfs features that I should make available > > in ferris :) The interface to make preallocated files uses the > > It's still not well tested on Linux... I'll check in a fix soon for a > fairly serious bug in RT - if you open an RT file and write to it without > O_DIRECT, it writes to the main data device, not the RT device. Not so > good. I'm trying to do more thorough testing in the next few days. Ok, so it deserves the experimental tag then ;) > > > BTW what is the mood on acceptance of a patch for xfs_bmap to have > > an --xml option to dump the same info from -v as an XML 1.0 document? > > this would make it nice and easy to make an extent viewer as either > > a gtk+ app or a php4 app. > > Sounds interesting to me. Do you have such a patch? not yet, I usually ask if there is much/any interest in patches to other folks code before I create the patch. I don't like maintaining forks of code so I generally like to know interest prior to the coding ;) I'll be at LCA for the next 4 days starting tommorow, so it might be a week before I send the patch. What version of xfs_bmap is best for patching against? cvs? > > -Eric > -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Feb 4 14:45:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14MjH617212 for linux-xfs-outgoing; Mon, 4 Feb 2002 14:45:17 -0800 Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14MitA17169 for ; Mon, 4 Feb 2002 14:44:55 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id E9A8DA00930 for ; Mon, 4 Feb 2002 17:44:49 -0500 (EST) Received: from sa-bwmail1.esr.hp.com (sa-bwmail1.esr.hp.com [15.1.192.32]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id BA2B511A for ; Mon, 4 Feb 2002 17:44:49 -0500 (EST) Received: by sa-bwmail1.esr.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 17:42:31 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B53904602B8C@sa-bwmail1.esr.hp.com> From: "Christian, Chip" To: "Linux XFS (E-mail)" Subject: RE: kernel Oops Date: Mon, 4 Feb 2002 17:42:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Oh, and the compiler in use is gcc-2.96-85. -----Original Message----- From: Christian, Chip [mailto:chip_christian@hp.com] Sent: Monday, February 04, 2002 10:49 AM To: Linux XFS (E-mail) Subject: kernel Oops We are running RedHat Linux 7.1 with XFS Release 1.0.2. Custom kernel built from kernel-source-2.4.9-12SGI_XFS_1.0.2. Got the following Oops(es) this am. Can anyone give me a hand tracking it down? Thanks. -Chip ksymoops 2.4.0 on i686 2.4.9-12SGI_XFS_1.0.2custom. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.9-12SGI_XFS_1.0.2custom/ (default) -m /boot/System.map (specified) Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says 40270d30, System.map says 40157c70. Ignoring ksyms_base entry Feb 3 04:02:00 nas2 nmbd[6817]: Got SIGHUP dumping debug info. Feb 4 00:05:35 nas2 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000074 Feb 4 00:05:35 nas2 kernel: 4012cb87 Feb 4 00:05:35 nas2 kernel: *pde = 00000000 Feb 4 00:05:35 nas2 kernel: Oops: 0000 Feb 4 00:05:35 nas2 kernel: CPU: 0 Feb 4 00:05:35 nas2 kernel: EIP: 0010:[kfree+55/144] Not tainted Feb 4 00:05:35 nas2 kernel: EIP: 0010:[<4012cb87>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Feb 4 00:05:35 nas2 kernel: EFLAGS: 00010006 Feb 4 00:05:35 nas2 kernel: eax: 00000000 ebx: 40800000 ecx: 00000000 edx: 0004097e Feb 4 00:05:35 nas2 kernel: esi: 8097e000 edi: 00000286 ebp: 6a65ce80 esp: 7f8c1e6c Feb 4 00:05:35 nas2 kernel: ds: 0018 es: 0018 ss: 0018 Feb 4 00:05:35 nas2 kernel: Process umount (pid: 25981, stackpage=7f8c1000) Feb 4 00:05:35 nas2 kernel: Stack: 8097e000 00000206 40800000 5d8ea400 8097e000 40800000 8097e000 00000001 Feb 4 00:05:35 nas2 kernel: 401de2ac 8097e000 00008203 633ea2c0 5d8ea400 00000000 00000001 79dac860 Feb 4 00:05:35 nas2 kernel: 401dd3d4 6a65ce80 5d8ea400 5d8ea400 67278cc0 401e4fe1 5d8ea400 5d8ea400 Feb 4 00:05:35 nas2 kernel: Call Trace: [xlog_unalloc_log+60/192] Feb 4 00:05:35 nas2 kernel: Call Trace: [<401de2ac>] Feb 4 00:05:35 nas2 kernel: [<401dd3d4>] Feb 4 00:05:35 nas2 kernel: [<401e4fe1>] Feb 4 00:05:35 nas2 kernel: [<401ed3da>] Feb 4 00:05:35 nas2 kernel: [<401f7134>] Feb 4 00:05:35 nas2 kernel: [<401fe3df>] Feb 4 00:05:35 nas2 kernel: [<4013a5cf>] Feb 4 00:05:35 nas2 kernel: [<4013e899>] Feb 4 00:05:35 nas2 kernel: [<4014bb29>] Feb 4 00:05:35 nas2 kernel: [<4014bc1b>] Feb 4 00:05:35 nas2 kernel: [<401259a3>] Feb 4 00:05:35 nas2 kernel: [<4014bc4c>] Feb 4 00:05:35 nas2 kernel: [<4010714b>] Feb 4 00:05:35 nas2 kernel: Code: 8b 5c 81 74 85 db 74 37 8b 13 3b 53 04 73 0a 89 74 93 08 ff >>EIP; 4012cb87 <===== Trace; 401de2ac Trace; 401dd3d4 Trace; 401e4fe1 Trace; 401ed3da Trace; 401f7134 Trace; 401fe3df Trace; 4013a5cf Trace; 4013e899 Trace; 4014bb29 Trace; 4014bc1b Trace; 401259a3 Trace; 4014bc4c Trace; 4010714b Code; 4012cb87 00000000 <_EIP>: Code; 4012cb87 <===== 0: 8b 5c 81 74 mov 0x74(%ecx,%eax,4),%ebx <===== Code; 4012cb8b 4: 85 db test %ebx,%ebx Code; 4012cb8d 6: 74 37 je 3f <_EIP+0x3f> 4012cbc6 Code; 4012cb8f 8: 8b 13 mov (%ebx),%edx Code; 4012cb91 a: 3b 53 04 cmp 0x4(%ebx),%edx Code; 4012cb94 d: 73 0a jae 19 <_EIP+0x19> 4012cba0 Code; 4012cb96 f: 89 74 93 08 mov %esi,0x8(%ebx,%edx,4) Code; 4012cb9a 13: ff 00 incl (%eax) Feb 4 00:05:36 nas2 kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000074 Feb 4 00:05:36 nas2 kernel: 4012cb87 Feb 4 00:05:36 nas2 kernel: *pde = 00000000 Feb 4 00:05:36 nas2 kernel: Oops: 0000 Feb 4 00:05:36 nas2 kernel: CPU: 0 Feb 4 00:05:36 nas2 kernel: EIP: 0010:[kfree+55/144] Not tainted Feb 4 00:05:36 nas2 kernel: EIP: 0010:[<4012cb87>] Not tainted Feb 4 00:05:36 nas2 kernel: EFLAGS: 00010006 Feb 4 00:05:36 nas2 kernel: eax: 00000000 ebx: 80988000 ecx: 00000000 edx: 00040992 Feb 4 00:05:36 nas2 kernel: esi: 80992000 edi: 00000286 ebp: 6a65c580 esp: 7f8c1e6c Feb 4 00:05:36 nas2 kernel: ds: 0018 es: 0018 ss: 0018 Feb 4 00:05:36 nas2 kernel: Process umount (pid: 25983, stackpage=7f8c1000) Feb 4 00:05:36 nas2 kernel: Stack: 80992000 00000206 80988000 5505f800 80992000 80988000 80992000 00000001 Feb 4 00:05:36 nas2 kernel: 401de2ac 80992000 00008203 633ea740 5505f800 00000000 00000001 74bc46a0 Feb 4 00:05:36 nas2 kernel: 401dd3d4 6a65c580 5505f800 5505f800 67278c60 401e4fe1 5505f800 5505f800 Feb 4 00:05:36 nas2 kernel: Call Trace: [xlog_unalloc_log+60/192] Feb 4 00:05:36 nas2 kernel: Call Trace: [<401de2ac>] Feb 4 00:05:36 nas2 kernel: [<401dd3d4>] Feb 4 00:05:36 nas2 kernel: [<401e4fe1>] Feb 4 00:05:36 nas2 kernel: [<401ed3da>] Feb 4 00:05:36 nas2 kernel: [<401f7134>] Feb 4 00:05:36 nas2 kernel: [<401fe3df>] Feb 4 00:05:36 nas2 kernel: [<4013a5cf>] Feb 4 00:05:36 nas2 kernel: [<4013e899>] Feb 4 00:05:36 nas2 kernel: [<4014bb29>] Feb 4 00:05:36 nas2 kernel: [<4014bc1b>] Feb 4 00:05:36 nas2 kernel: [<401259a3>] Feb 4 00:05:36 nas2 kernel: [<4014bc4c>] Feb 4 00:05:36 nas2 kernel: [<4010714b>] Feb 4 00:05:36 nas2 kernel: Code: 8b 5c 81 74 85 db 74 37 8b 13 3b 53 04 73 0a 89 74 93 08 ff >>EIP; 4012cb87 <===== Trace; 401de2ac Trace; 401dd3d4 Trace; 401e4fe1 Trace; 401ed3da Trace; 401f7134 Trace; 401fe3df Trace; 4013a5cf Trace; 4013e899 Trace; 4014bb29 Trace; 4014bc1b Trace; 401259a3 Trace; 4014bc4c Trace; 4010714b Code; 4012cb87 00000000 <_EIP>: Code; 4012cb87 <===== 0: 8b 5c 81 74 mov 0x74(%ecx,%eax,4),%ebx <===== Code; 4012cb8b 4: 85 db test %ebx,%ebx Code; 4012cb8d 6: 74 37 je 3f <_EIP+0x3f> 4012cbc6 Code; 4012cb8f 8: 8b 13 mov (%ebx),%edx Code; 4012cb91 a: 3b 53 04 cmp 0x4(%ebx),%edx Code; 4012cb94 d: 73 0a jae 19 <_EIP+0x19> 4012cba0 Code; 4012cb96 f: 89 74 93 08 mov %esi,0x8(%ebx,%edx,4) Code; 4012cb9a 13: ff 00 incl (%eax) Feb 4 06:11:53 nas2 kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 4 06:11:53 nas2 kernel: 401136b3 Feb 4 06:11:53 nas2 kernel: *pde = 00000000 Feb 4 06:11:53 nas2 kernel: Oops: 0000 Feb 4 06:11:53 nas2 kernel: CPU: 1 Feb 4 06:11:53 nas2 kernel: EIP: 0010:[__wake_up+51/192] Not tainted Feb 4 06:11:53 nas2 kernel: EIP: 0010:[<401136b3>] Not tainted Feb 4 06:11:53 nas2 kernel: EFLAGS: 00010097 Feb 4 06:11:53 nas2 kernel: eax: 5f6b6a07 ebx: 416f4241 ecx: 00000000 edx: 00000000 Feb 4 06:11:53 nas2 kernel: esi: 75228de0 edi: 5f6b6a03 ebp: 71e9ff4c esp: 71e9ff34 Feb 4 06:11:53 nas2 kernel: ds: 0018 es: 0018 ss: 0018 Feb 4 06:11:53 nas2 kernel: Process rpciod (pid: 26080, stackpage=71e9f000) Feb 4 06:11:53 nas2 kernel: Stack: 00000001 00000206 00000003 5f6b6863 75228de0 76bb5014 76bb5010 402b6294 Feb 4 06:11:53 nas2 kernel: 76bb5000 76bb5014 401892d4 75228de0 76bb5000 00001770 76bb5008 718fe6a0 Feb 4 06:11:53 nas2 kernel: 718fe6f4 718fe6a0 71e9e000 00000002 402b394a 718fe6a0 71e9e000 7fffc000 Feb 4 06:11:53 nas2 kernel: Call Trace: [svc_wake_up+84/144] Feb 4 06:11:53 nas2 kernel: Call Trace: [<402b6294>] Feb 4 06:11:53 nas2 kernel: [<401892d4>] Feb 4 06:11:53 nas2 kernel: [<402b394a>] Feb 4 06:11:53 nas2 kernel: [<402b3bc8>] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; 401136b3 <__wake_up+33/c0> <===== Trace; 402b6294 Trace; 401892d4 Trace; 402b394a <__rpc_execute+29a/320> Trace; 402b3bc8 <__rpc_schedule+188/1d0> Feb 4 08:49:18 nas2 kernel: cpu: 0, clocks: 1324510, slice: 441503 Feb 4 08:49:18 nas2 kernel: cpu: 1, clocks: 1324510, slice: 441503 Feb 4 08:49:18 nas2 kernel: SGI XFS with ACLs, EAs, quota, no debug enabled 2 warnings issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Mon Feb 4 16:21:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g150LNp06574 for linux-xfs-outgoing; Mon, 4 Feb 2002 16:21:23 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g150LBA06552 for ; Mon, 4 Feb 2002 16:21:13 -0800 Received: by monkeyiq.dnsalias.org id g150Iqm01237 ; Tue, 5 Feb 2002 10:18:52 +1000 Date: Tue, 5 Feb 2002 10:18:52 +1000 Message-Id: <200202050018.g150Iqm01237@monkeyiq.dnsalias.org> To: Nathan Scott Cc: monkeyiq , linux-xfs@oss.sgi.com Subject: Re: Preallocation and Ferris From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott writes: > On Mon, Feb 04, 2002 at 08:55:05PM +1000, monkeyiq wrote: > > ... > > BTW what is the mood on acceptance of a patch for xfs_bmap to have > > an --xml option to dump the same info from -v as an XML 1.0 document? > > this would make it nice and easy to make an extent viewer as either > > a gtk+ app or a php4 app. > > Would this introduce a new dependency on libxml? If so, No. I was just going to build the xml using snprintf() not the DOM interface. So there would only be a slight increase in exe size due to code similar to the -v code being there to make XML. there would be no new libs or dependancies. Though the manner in which the extents are obtained in xfs_bmap yells out to me that there should be a library call something like struct getbmapx* getExtents( int fd ); because that little bit of code that does a similar thing in xfs_bmap seems hairy enough to only want it in one function that is available to all xfs users rather than replicated throughout many xfs using apps. Maybe if there was a libxfsprogs.a the clients could statically link to that lib and thus appear just as they do now, only there would be a static lib for other xfs client apps to link to and enjoy. But, one step at a time :) > it shouldn't be added into the xfsprogs xfs_bmap - I'd > suggest making a new program based on xfs_bmap.c (its only > ~400 lines or so), add the new code in there, and distribute > that separately. > > We have always tried to keep xfsprogs' dependencies to the > bare minimum, so that people can avoid installing software > they don't necessarily want. > > cheers. > > -- > Nathan > -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Feb 4 16:32:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g150Woq06817 for linux-xfs-outgoing; Mon, 4 Feb 2002 16:32:50 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g150WkA06795 for ; Mon, 4 Feb 2002 16:32:46 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id BAA453688 for ; Tue, 5 Feb 2002 01:31:26 +0100 (CET) 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 LAA12550; Tue, 5 Feb 2002 11:31:26 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA06839; Tue, 5 Feb 2002 11:31:25 +1100 (AEDT) Date: Tue, 5 Feb 2002 11:31:24 +1100 From: Nathan Scott To: monkeyiq Cc: linux-xfs@oss.sgi.com Subject: Re: Preallocation and Ferris Message-ID: <20020205113124.I107204@wobbly.melbourne.sgi.com> References: <200202050018.g150Iqm01237@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202050018.g150Iqm01237@monkeyiq.dnsalias.org>; from monkeyiq@users.sourceforge.net on Tue, Feb 05, 2002 at 10:18:52AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 10:18:52AM +1000, monkeyiq wrote: > Nathan Scott writes: > > > On Mon, Feb 04, 2002 at 08:55:05PM +1000, monkeyiq wrote: > > > ... > > > BTW what is the mood on acceptance of a patch for xfs_bmap to have > > > an --xml option to dump the same info from -v as an XML 1.0 document? > > > this would make it nice and easy to make an extent viewer as either > > > a gtk+ app or a php4 app. > > > > Would this introduce a new dependency on libxml? If so, > > No. I was just going to build the xml using snprintf() not the DOM > interface. So there would only be a slight increase in exe size due > to code similar to the -v code being there to make XML. there would > be no new libs or dependancies. That sounds OK then. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 4 17:47:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g151lfb08321 for linux-xfs-outgoing; Mon, 4 Feb 2002 17:47:41 -0800 Received: from sunny.pacific.net.au (sunny-legacy.pacific.net.au [210.23.129.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g151lcA08299 for ; Mon, 4 Feb 2002 17:47:38 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g151la0Z015844 for ; Tue, 5 Feb 2002 12:47:36 +1100 (EST) Received: from jdc.local (ppp47.dyn148.pacific.net.au [210.23.148.47]) by wisma.pacific.net.au with ESMTP id MAA23556 for ; Tue, 5 Feb 2002 12:47:35 +1100 (EST) Received: from jdc.local (LOCALHOST [127.0.0.1]) by jdc.local (8.12.1/8.12.1/Debian -5) with ESMTP id g151lXie000816 for ; Tue, 5 Feb 2002 12:47:33 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g151lWbL000808; Tue, 5 Feb 2002 12:47:32 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15455.14771.836730.466452@jdc.local> Date: Tue, 5 Feb 2002 12:47:31 +1100 To: linux-xfs@oss.sgi.com Subject: Re: Preallocation and Ferris In-Reply-To: <20020205113124.I107204@wobbly.melbourne.sgi.com> References: <200202050018.g150Iqm01237@monkeyiq.dnsalias.org> <20020205113124.I107204@wobbly.melbourne.sgi.com> X-Mailer: VM 6.96 under Emacs 20.7.2 Reply-To: Jason White Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Perhaps it could be a compile-time option, thereby satisfying everyone. From owner-linux-xfs@oss.sgi.com Mon Feb 4 20:30:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g154UrM11373 for linux-xfs-outgoing; Mon, 4 Feb 2002 20:30:53 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g154UmA11349 for ; Mon, 4 Feb 2002 20:30:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g154Ufo02629 for ; Mon, 4 Feb 2002 20:30:41 -0800 Received: (from ivanr@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA59589 for linux-xfs@oss.sgi.com; Tue, 5 Feb 2002 15:29:23 +1100 (EST) Date: Tue, 5 Feb 2002 15:29:23 +1100 (EST) From: Ivan Rayner Message-Id: <200202050429.PAA59589@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump/xfsrestore document -q QIC tape option Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The -q option tells xfsdump/xfsrestore that the tape is a QIC tape. QIC tapes use only 512 byte blocksizes, so xfsdump/xfsrestore need to make special allowances for this. This is a Linux only option. On IRIX, xfsdump/xfsrestore are able to automatically detect QIC tapes. If you get messages like: xfsdump: unable to set block size to 1048576 or try to specify a 512 byte blocksize with -b, and then get an assertion error like: xfsdump: drive_scsitape.c:1985: do_get_write_buf: Assertion `contextp->dc_nextp < contextp->dc_recendp' failed. then you _might_ have a QIC tape that requires this option. This option has been in the Linux xfsdump/xfsrestore since the initial port, but hasn't been documented. Thanks to Mike Burger for bringing this to our attention. Ivan Date: Mon Feb 4 20:19:14 PST 2002 Workarea: snort.melbourne.sgi.com:/home/ivanr/isms/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:110998a cmd/xfsdump/doc/CHANGES - 1.33 cmd/xfsdump/man/man8/xfsrestore.8 - 1.9 cmd/xfsdump/man/man8/xfsdump.8 - 1.11 cmd/xfsdump/common/main.c - 1.18 - document -q QIC tape option From owner-linux-xfs@oss.sgi.com Mon Feb 4 22:02:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1562hP13414 for linux-xfs-outgoing; Mon, 4 Feb 2002 22:02:43 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1562cA13392 for ; Mon, 4 Feb 2002 22:02:38 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA16603 for ; Mon, 4 Feb 2002 21:58:09 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g1561Vm13282; Tue, 5 Feb 2002 17:01:31 +1100 Date: Tue, 5 Feb 2002 17:01:31 +1100 From: Keith Owens Message-Id: <200202050601.g1561Vm13282@sherman.melbourne.sgi.com> Subject: TAKE - Remove fragment of ia64 patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A fragment of the ia64 patch had crept into the XFS tree and was causing problems for the ia64 trees. Date: Mon Feb 4 21:58:59 PST 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111005a linux/Makefile - 1.164 From owner-linux-xfs@oss.sgi.com Mon Feb 4 22:11:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g156BcT13685 for linux-xfs-outgoing; Mon, 4 Feb 2002 22:11:38 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g156BRA13661 for ; Mon, 4 Feb 2002 22:11:28 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g156ApI12478; Tue, 5 Feb 2002 00:10:51 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: [OT] Qlogic drivers and 2.4.17-xfs From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BeAia02UvYpERPwwoNm2" X-Mailer: Evolution/1.0.2 Date: 05 Feb 2002 00:10:51 -0600 Message-Id: <1012889451.11995.10.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-BeAia02UvYpERPwwoNm2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I can't get the 4.46 or 5.36 drivers to compile at all. Any help on this would be appreciated. I think it may have something to do with HIGHMEM and HIGHMEM I/O. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-BeAia02UvYpERPwwoNm2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8X3dq94g6ZVmFMoIRAkrqAJ9LBkLs8Y3uzPb9YeT5VXGDunVa7wCfSMAn HaJDAcTZiZnRTBCbFM3eY5c= =/DTM -----END PGP SIGNATURE----- --=-BeAia02UvYpERPwwoNm2-- From owner-linux-xfs@oss.sgi.com Mon Feb 4 22:23:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g156NWw14141 for linux-xfs-outgoing; Mon, 4 Feb 2002 22:23:32 -0800 Received: from rznetnotserv1.rznet.de ([62.156.207.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g156NQA14118 for ; Mon, 4 Feb 2002 22:23:26 -0800 To: linux-xfs@oss.sgi.com Subject: Filesystem hangs, xfs would not mount. X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Frank Warzecha" Message-ID: Date: Tue, 5 Feb 2002 07:23:32 +0100 X-MIMETrack: Serialize by Router on RZNetNotServ1/RZNet(Release 5.0.6a |January 17, 2001) at 05.02.2002 07:23:45, Serialize complete at 05.02.2002 07:23:45 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g156NRA14119 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We are using SuSE Linux 7.2, with Kernel 2.4.14 (SMP) with the official 1.0.2 XFS patches, compiled with gcc 2.95.3. Machine is an IBM X240 with ServeRaid 4 adapter. It has two CPUs and 2 GB ram. We had problems when writing with multiple processes to a single file, (with the 1.0.1 Release), but that is history now. Since we did the update, the system had been running fine for 70 days, a pretty heavily loaded webserver with a database (on block devices) A few days ago, I gzipped the logs (files with size of about 1 GB), and processes started to be in "D" status. They piled up and when the load was 40, I rebooted the system the hard way (reboot -d -f -n). The system was working fine (except for everything in /var). Neither dmesg, nor system logs said anything. The xfs filesystem mounted on /var (about 9 GB) could not be mounted, the system just hanged while starting up. I started with runlevel s, did xfs_repair and everything worked okay. Now I am trying to reproduce the problem on a similar machine, but I thought you might help as well. Thanks for a great filesystem, except for this failure, we had very good experiences with xfs. Mit freundlichen Grüßen / With regards, Frank Warzecha ------------------------------------- Frank Warzecha, Team Betriebssysteme RZNet AG, Kerpen, Germany >>>>>>>>>>>>>>>Neue Telefon Nummer: >>>>>>>>Tel:02273-603172 http://www.rznet.de From owner-linux-xfs@oss.sgi.com Tue Feb 5 03:09:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15B9YL23358 for linux-xfs-outgoing; Tue, 5 Feb 2002 03:09:34 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15B9UA23333 for ; Tue, 5 Feb 2002 03:09:30 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA04215 for ; Sat, 2 Feb 2002 18:40:05 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01013; Sun, 3 Feb 2002 13:39:56 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA03636; Sun, 3 Feb 2002 12:59:58 +1100 (AEDT) Date: Sun, 3 Feb 2002 12:59:57 +1100 From: Nathan Scott To: Chris Pascoe Cc: linux-xfs@oss.sgi.com Subject: Re: Permit xfs_repair -n on readonly device Message-ID: <20020203125957.C104828@wobbly.melbourne.sgi.com> References: <1012633098.3c5b8e0a3079f@internal.itee.uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1012633098.3c5b8e0a3079f@internal.itee.uq.edu.au>; from c.pascoe@itee.uq.edu.au on Sat, Feb 02, 2002 at 04:58:18PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Feb 02, 2002 at 04:58:18PM +1000, Chris Pascoe wrote: > Hi, > > May I suggest this patch to xfs_repair - to make a "xfs_repair -n" > actually open the device read-only. This permits running an > xfs_repair -n over a readonly snapshot to check if the snapshot is > okay. It should be safe to do, as a nomodify repair shouldn't be > modifying the filesystem anyway. > Thanks Chris - I'll put this in soon. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 5 04:12:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15CCSL32123 for linux-xfs-outgoing; Tue, 5 Feb 2002 04:12:28 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15CCLA32086 for ; Tue, 5 Feb 2002 04:12:21 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-239.quicknet.nl [212.58.163.239]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g15CCJcq050451; Tue, 5 Feb 2002 13:12:19 +0100 (CET) Message-Id: <4.3.2.7.2.20020205130156.02bce4e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Feb 2002 13:10:33 +0100 To: "Frank Warzecha" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Filesystem hangs, xfs would not mount. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:23 5-2-2002 +0100, Frank Warzecha wrote: >Neither dmesg, nor system logs said anything. Correct. >The xfs filesystem mounted on /var (about 9 GB) could not be mounted, the >system just hanged while starting up. I started with runlevel s, did >xfs_repair and everything worked okay. I have had this exact same problem once in which I believe 2 files in a squid cache were "damaged" which caused this exact behaviour. This also means that the size of the file does not really matter since my files were just a few K large. I did not have a kernel with kdb or had the brilliant idea of running mount through strace. So untill someone encounters this behaviour and debugs it I have no clue whatsoever. >Now I am trying to reproduce the problem on a similar machine, but I >thought you might help as well. The squid cache was not heavily loaded or very large and was already working for more the 6 months. I guess something broke in mysterious ways. This box is also running XFS 1.0.2 it was also the /var partition but just 1.5GB large. I have faith in the hardware since this box ran fine for over a year. The mount problem is not really a problem with the 1.0.2 release perse since the Linuxcare Bootable Toolbox CD (see FAQ) has a different kernel althogether. >Thanks for a great filesystem, except for this failure, we had very good >experiences with xfs. It was my first failure I have seen of a XFS filesystem that I did not cause myself. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Feb 5 07:20:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15FK8B15282 for linux-xfs-outgoing; Tue, 5 Feb 2002 07:20:08 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15FK4A15253 for ; Tue, 5 Feb 2002 07:20:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA508022 for ; Tue, 5 Feb 2002 16:18:46 +0100 (CET) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA98078 for ; Tue, 5 Feb 2002 09:18:45 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.34 #1 (Debian)) id 16Y7Mq-0001ku-00 for ; Tue, 05 Feb 2002 09:18:44 -0600 Subject: TAKE - Remove fragment of ia64 patch Message-Id: From: Nathan Straz To: linux-xfs@oss.sgi.com Date: Tue, 05 Feb 2002 09:18:44 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove fragment of ia64 patch Date: Tue Feb 5 07:16:19 PST 2002 Workarea: maine.americas.sgi.com:/extra/wa/xfs-2.5.x Author: kaos Merged by: nstraz Merged mods: 2.4.x-xfs:slinx:111005a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:111005a linux/Makefile - 1.182 - Merge of 2.4.x-xfs:slinx:111005a by nstraz. From owner-linux-xfs@oss.sgi.com Tue Feb 5 07:34:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15FYLw17315 for linux-xfs-outgoing; Tue, 5 Feb 2002 07:34:21 -0800 Received: from relay4.kornet.net ([211.48.62.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15FYGA17278 for ; Tue, 5 Feb 2002 07:34:17 -0800 Received: from jinrae (61.74.91.147) by relay4.kornet.net; 6 Feb 2002 00:34:09 +0900 Message-ID: <3c5ffb713c6ba30c@relay4.kornet.net> (added by relay4.kornet.net) From: =?ks_c_5601-1987?B?RC5ILiBBbg==?= To: linux-xfs@oss.sgi.com Subject: =?ks_c_5601-1987?B?U2hpcCByZWxhdGVkIGluZm9ybWF0aW9uIMirurg=?= Date: Wed, 06 Feb 2002 00:37:19 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear Sir/Ms ; This mail will be sent just for once. Is this information in shipbroker.net useful for you ? Now, there are 1314 cargoes and open vessels, 14 new shipbuilding wanted, 1643 vessels on sale, 513 vessels wanted, and other ship related business information. http://www.shipbroker.net operater@shipbroker.net Operator D.H. An [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Feb 5 11:15:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15JFBv22629 for linux-xfs-outgoing; Tue, 5 Feb 2002 11:15:11 -0800 Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JEvA22503 for ; Tue, 5 Feb 2002 11:15:03 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=indonesia.kscanners.no) by indonesia.kscanners.no with esmtp (Exim 3.33 #1) id 16YAz6-0006Ph-00; Tue, 05 Feb 2002 20:10:28 +0100 Date: Tue, 5 Feb 2002 20:10:28 +0100 From: Toralf Lund To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Mounting IRIX filesystem with version 1 directories? Message-ID: <20020205201028.A24388@indonesia.kscanners.no> References: <20020201094725.A17098@indonesia.kscanners.no> <3C5A8B22.4070200@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <3C5A8B22.4070200@sgi.com>; from lord@sgi.com on Fri, Feb 01, 2002 at 13:33:38 +0100 X-Mailer: Balsa 1.3.0 Lines: 47 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 01/02 2002 13:33 Stephen Lord wrote: > Toralf Lund wrote: > >> From the XFS FAQ, >> >> Will I be able to use my old IRIX XFS disks on linux? >> >> [ ... ] Linux can only read v2 directories on the moment. Using v1 will >> probably fail in spectacular ways. >> >> I have a large IRIX filesystem that I would like to mount on Linux, but >> I think it has version 1 directories. Is there any way at all I can get >> this to work? >> > First of all, your Irix filesystem is going to have to meet a few other > requirements : > > o It cannot be xlv or xvm based - there is no linux support for these > o the filesystem blocksize needs to be the same as the page size on > your linux block, > the irix default is 4K, so this is usually not a problem > o it should not have the unwritten extent support turned on. > I know, but as far as I can tell, all those requirements are met. I wasn't able to mount the file system on a Red Hat 7.2 box with kernel-2.4.9-13SGI_XFS_1.0.2, though. I didn't have the opportunity to experiment a lot, though, as someone needed the data pretty fast (the file system in question had to be moved from an Origin server due to SCSI problems. Ideally, I wanted to put it on a Linux hosts, but it ended up on an O2 workstation, at least temporarily.) Are the precompiled kernels supposed to support everything needed? > You can check the latter 2 with xfs_growfs -n /mnt on irix That one's new to me. I used xfs_db to check... > > The directory code should work for the most part, but large directories > may suffer > problems with readdir on linux - the V1 format passes up 64 bit hash > values as > directory offsets, and this confuses glibc from time to time. Entries > can go > missing or you can occassionally get into a loop. Is there any way to convert the existing directories, or at least mix version 1 and 2? - Toralf From owner-linux-xfs@oss.sgi.com Tue Feb 5 11:19:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15JJIY24823 for linux-xfs-outgoing; Tue, 5 Feb 2002 11:19:18 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JJDA24801 for ; Tue, 5 Feb 2002 11:19:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 LAA01639 for ; Tue, 5 Feb 2002 11:14:46 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA08721; Tue, 5 Feb 2002 13:17:53 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA47421; Tue, 5 Feb 2002 13:17:53 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g15JEk621933; Tue, 5 Feb 2002 13:14:47 -0600 Subject: Re: Mounting IRIX filesystem with version 1 directories? From: Steve Lord To: Toralf Lund Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020205201028.A24388@indonesia.kscanners.no> References: <20020201094725.A17098@indonesia.kscanners.no> <3C5A8B22.4070200@sgi.com> <20020205201028.A24388@indonesia.kscanners.no> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Feb 2002 13:14:46 -0600 Message-Id: <1012936486.21193.715.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-05 at 13:10, Toralf Lund wrote: > On 01/02 2002 13:33 Stephen Lord wrote: > I know, but as far as I can tell, all those requirements are met. I wasn't > able to mount the file system on a Red Hat 7.2 box with > kernel-2.4.9-13SGI_XFS_1.0.2, though. I didn't have the opportunity to > experiment a lot, though, as someone needed the data pretty fast (the file > system in question had to be moved from an Origin server due to SCSI > problems. Ideally, I wanted to put it on a Linux hosts, but it ended up on > an O2 workstation, at least temporarily.) Are the precompiled kernels > supposed to support everything needed? Can you report the error? The other requirement is you need a clean log, the linux and irix log formats are not the same - they are host byte ordered. So you cannot mount a dirty filesystem from one os on the other. xfs_repair is the only way to force that, it zeros the log. > > The directory code should work for the most part, but large directories > > may suffer > > problems with readdir on linux - the V1 format passes up 64 bit hash > > values as > > directory offsets, and this confuses glibc from time to time. Entries > > can go > > missing or you can occassionally get into a loop. > Is there any way to convert the existing directories, or at least mix > version 1 and 2? Errm, dump/restore I am afraid, it is a major on disk change not something we can do to a live filesystem. Steve > > - Toralf -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 5 13:57:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Lv4v15963 for linux-xfs-outgoing; Tue, 5 Feb 2002 13:57:04 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15Lv0A15941 for ; Tue, 5 Feb 2002 13:57:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA03493 for ; Tue, 5 Feb 2002 13:58:07 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA10502 for ; Tue, 5 Feb 2002 15:55:42 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA93956 for ; Tue, 5 Feb 2002 15:55:42 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g15LqYQ29756; Tue, 5 Feb 2002 15:52:34 -0600 Message-Id: <200202052152.g15LqYQ29756@jen.americas.sgi.com> Date: Tue, 5 Feb 2002 15:52:34 -0600 Subject: TAKE - more memory allocation cleanup To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk remove KM_SLEEP_IO flag. This was a previous attempt at determining which flags to use on memory allocations, it turns out it was getting in the way of the new code and actually slowing things down. This was worth about 10% on a particular dbench setup. Date: Tue Feb 5 13:52:14 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.back The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111101a linux/fs/xfs/xfs_da_btree.c - 1.121 linux/fs/xfs/xfs_vfsops.c - 1.333 linux/fs/xfs/xfs_iget.c - 1.150 linux/fs/xfs/xfs_mount.c - 1.267 linux/fs/xfs/xfs_inode.c - 1.325 linux/fs/xfs/xfs_dir2_leaf.c - 1.24 linux/fs/xfs/xfs_trans.c - 1.128 linux/fs/xfs_support/kmem.c - 1.21 linux/include/linux/xfs_support/kmem.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Feb 5 14:09:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15M9GT16559 for linux-xfs-outgoing; Tue, 5 Feb 2002 14:09:16 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15M91A16537 for ; Tue, 5 Feb 2002 14:09:02 -0800 Received: from piaskowy.internal.prz.rzeszow.pl (promien.prz.rzeszow.pl [212.160.98.116]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA05235 for ; Tue, 5 Feb 2002 14:04:32 -0800 (PST) mail_from (mzieba@prz-rzeszow.pl) Received: from piaskowy.internal.prz.rzeszow.pl (localhost [127.0.0.1]) by piaskowy.internal.prz.rzeszow.pl (8.12.1/8.12.1/Debian -5) with ESMTP id g15M8Q0L007107 for ; Tue, 5 Feb 2002 23:08:28 +0100 Received: (from mzieba@localhost) by piaskowy.internal.prz.rzeszow.pl (8.12.1/8.12.1/Debian -5) id g15M86a7007106 for linux-xfs@oss.sgi.com; Tue, 5 Feb 2002 23:08:06 +0100 From: Marcin Zieba Date: Tue, 5 Feb 2002 23:08:06 +0100 To: linux-xfs@oss.sgi.com Subject: Disappearing /, /home Message-ID: <20020205220806.GA7060@prz-rzeszow.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Oopsy.mail" User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm running Linux piaskowy 2.4.17-xfs #1 Thu Jan 3 13:53:36 CET 2002 i586 unknown, compiled with gcc 2.95.4 (Debian Sid) and my partition /home, where /var is symlinked (it's my workstation, and on /home i've got plenty of space), disappeared, second time in a month, so i think, it looks like repeatable bug. (due to /var on /home, i don't have much logs..) Here follows what I have: ksymoops -m /boot/System.map-2.4.17-xfs : Code; 00000000 Before first symbol 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) Code; 00000006 Before first symbol 7: 00 Code; 00000008 Before first symbol 8: 75 10 jne 1a <_EIP+0x1a> 0000001a Before first symbol Code; 0000000a Before first symbol a: 80 a3 50 01 00 00 f7 andb $0xf7,0x150(%ebx) Code; 00000010 Before first symbol 11: 53 push %ebx Code; 00000012 Before first symbol 12: e8 27 00 00 00 call 3e <_EIP+0x3e> 0000003e Before first symbol Then: Feb 3 19:06:24 piaskowy kernel: Warning: buffer 0xc6e5cdc4 with weird blockno (0) Feb 3 19:06:25 piaskowy kernel: Warning: buffer 0xc6e5cdc4 with weird blockno (0) [...] Feb 3 19:40:41 piaskowy kernel: Warning: buffer 0xca950334 with weird blockno (0) Feb 3 21:29:26 piaskowy kernel: EFSCORRUPTED returned from file xfs_ialloc.c line 1265 Kernel is tainted by NVdriver, but when it "striked" first time, I didn't use that. After disappearing, mount won't find superblock, xfs_repair reconstruct superblock from secondary, I was unable to play log to fs, xfs_repair -L do the trick, but due to fs corruption, I got many directores/files in lost+found. I have found previous oops, hope it's helpful maybe.. or not. Jan 12 18:20:02 piaskowy kernel: cmn_err level 1 Filesystem "ide0(3,2)": xfs_iflush: Bad inode 70394 magic number 0xb062, ptr 0xcc20aa00 Jan 12 18:20:02 piaskowy kernel: xfs_force_shutdown(ide0(3,2),0x8) called from line 3064 of file xfs_inode.c. Return address = 0xc01a82f2 Jan 12 18:20:02 piaskowy kernel: Fatal error on root filesystem Jan 12 18:20:02 piaskowy kernel: Corruption of in-memory data detected. Shutting down filesystem: ide0(3,2) Jan 12 18:20:02 piaskowy kernel: Please umount the filesystem, and rectify the problem(s) ksymoops -m /boot/System.map-2.4.17-xfs ] Tainted: PF Using defaults from ksymoops -t elf32-i386 -a i386 Jan 12 18:20:02 piaskowy kernel: EFLAGS: 00010286 Jan 12 18:20:02 piaskowy kernel: eax: 00000000 ebx: 00000000 ecx: c0354000 edx: 00000000 Jan 12 18:20:02 piaskowy kernel: esi: c284639c edi: 00000000 ebp: 00000000 esp: d24a9dd8 Jan 12 18:20:02 piaskowy kernel: ds: 0018 es: 0018 ss: 0018 Jan 12 18:20:02 piaskowy kernel: Process sh (pid: 22605, stackpage=d24a9000) Jan 12 18:20:02 piaskowy kernel: Stack: c01e4fac c0354000 00000000 c284639c c284639c 00000008 00000000 c10fd8c0 Jan 12 18:20:02 piaskowy kernel: c01e5011 00000000 c284639c d24a9e30 00000000 00000001 c015b79a 00000000 Jan 12 18:20:02 piaskowy kernel: c284639c c10fd8c0 c17042dc 00000024 c16e14fc c170422c c284639c 00000001 Jan 12 18:20:02 piaskowy kernel: Call Trace: [generic_make_request+296/312] [submit_bh+85/112] [pagebuf_read_full_page+322/340] [__alloc_pages+54/352] [add_to_page_cache_unique+108/116] Jan 12 18:20:02 piaskowy kernel: Code: Bad EIP value. >>EIP; 00000000 Before first symbol And some hours ago, / disappeared. The same story, lost superblock, cannot play log, fs corrupted. And I have no logs with todays Oops. Any hints? ;) (please CC:, i'm not a subscriber) -- Marcin Zieba From owner-linux-xfs@oss.sgi.com Tue Feb 5 14:46:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Mkti18660 for linux-xfs-outgoing; Tue, 5 Feb 2002 14:46:55 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15MklA18613 for ; Tue, 5 Feb 2002 14:46:47 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 OAA24359 for ; Tue, 5 Feb 2002 14:42:19 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA10960; Tue, 5 Feb 2002 16:45:28 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA31142; Tue, 5 Feb 2002 16:45:28 -0600 (CST) Subject: Re: Disappearing /, /home From: Eric Sandeen To: Marcin Zieba Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020205220806.GA7060@prz-rzeszow.pl> References: <20020205220806.GA7060@prz-rzeszow.pl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 05 Feb 2002 16:45:27 -0600 Message-Id: <1012949128.5437.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Marcin - Looks like you hit a couple of bugs. :) _something_ caused a forced shutdown on your filesystem, and there was a bug in xfs around Jan 3 which would write data to block zero after a forced shutdown - and that's where your superblock lives. Actually, it overwrote the first 4k, so there's a bit more important FS data there... The good news is this forced shutdown bug is fixed in CVS now, so if you shut down again, your filesystem should be happier. The bigger question is, why did your filesystem shut down... Jan 12 18:20:02 piaskowy kernel: cmn_err level 1 Filesystem "ide0(3,2)": xfs_iflush: Bad inode 70394 magic number 0xb062, ptr 0xcc20aa00 Jan 12 18:20:02 piaskowy kernel: xfs_force_shutdown(ide0(3,2),0x8) called from line 3064 of file xfs_inode.c. Return address = 0xc01a82f2 Jan 12 18:20:02 piaskowy kernel: Fatal error on root filesystem Jan 12 18:20:02 piaskowy kernel: Corruption of in-memory data detected. Shutting down filesystem: ide0(3,2) Those are the details, but it's not clear what the cause may be. -Eric On Tue, 2002-02-05 at 16:08, Marcin Zieba wrote: > Hi, > I'm running Linux piaskowy 2.4.17-xfs #1 Thu Jan 3 13:53:36 CET 2002 > i586 unknown, compiled with gcc 2.95.4 (Debian Sid) > and my partition /home, where /var is symlinked (it's my workstation, > and on /home i've got plenty of space), disappeared, second time in a > month, so i think, it looks like repeatable bug. (due to /var on /home, > i don't have much logs..) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 5 15:04:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15N4tY21967 for linux-xfs-outgoing; Tue, 5 Feb 2002 15:04:55 -0800 Received: from dns.securities.com (mail01.securities.com [57.69.12.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15N4pA21941 for ; Tue, 5 Feb 2002 15:04:51 -0800 Received: from securities.com (IDENT:root@localhost [127.0.0.1]) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g15N4mx29374 for ; Tue, 5 Feb 2002 18:04:48 -0500 Message-ID: <3C6064C7.2050301@securities.com> Date: Tue, 05 Feb 2002 18:03:35 -0500 From: Benito Venegas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and RAID performance (off-topic??) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys : Question (tunninng XFs on RAID controllers:) Have you ever did some tune into RAID controllers like write or cache policy to have a better performance using Journal FS?? (obvious, XFS ;) I read some article 3 or 4 months ago (or more) in LinuxJournal, but I don't remember what they said at this momment. We are working in some new server. They need to be in production in 2 month more,so I have time to test some configs. Any feedback one of you "gurues"?? Thanks in advance -- Benito Venegas System Engineer, Technology 488 Madison Ave. New York, NY 10022 A Euromoney Institutional Investor company. From owner-linux-xfs@oss.sgi.com Tue Feb 5 15:13:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15NDjY22310 for linux-xfs-outgoing; Tue, 5 Feb 2002 15:13:45 -0800 Received: from ente.berdmann.de (frnk-d514e112.dsl.mediaWays.net [213.20.225.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15NDfA22288 for ; Tue, 5 Feb 2002 15:13:42 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16YEmN-0002YT-00; Wed, 06 Feb 2002 00:13:35 +0100 Message-ID: <3C60671E.6152A923@berdmann.de> Date: Wed, 06 Feb 2002 00:13:34 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Benito Venegas CC: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID performance (off-topic??) References: <3C6064C7.2050301@securities.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Have you ever did some tune into RAID controllers like write or cache > policy to have a better performance using Journal FS?? (obvious, XFS ;) I've got some filesystems on software raid5 which is told to perform badly without an external log not being on soft raid5. I'll set up a raid1 volume and make another volume group of it to put all the log volumes into it. Some other boxes are running hardware raid (ICP Vortex oder Compaq SmartArray 5300). But I haven't done any tuning or measurements with them. From owner-linux-xfs@oss.sgi.com Tue Feb 5 17:37:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g161bNU04644 for linux-xfs-outgoing; Tue, 5 Feb 2002 17:37:23 -0800 Received: from sunny.pacific.net.au (sunny-legacy.pacific.net.au [210.23.129.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g161bFA04615 for ; Tue, 5 Feb 2002 17:37:16 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g161bD0Z026339 for ; Wed, 6 Feb 2002 12:37:13 +1100 (EST) Received: from jdc.local (ppp254.dyn224.pacific.net.au [203.100.224.254]) by wisma.pacific.net.au with ESMTP id MAA20726 for ; Wed, 6 Feb 2002 12:37:11 +1100 (EST) Received: from jdc.local (LOCALHOST [127.0.0.1]) by jdc.local (8.12.1/8.12.1/Debian -5) with ESMTP id g161b9YH004578 for ; Wed, 6 Feb 2002 12:37:09 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g161UQSn004331; Wed, 6 Feb 2002 12:30:26 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.34610.41991.980114@jdc.local> Date: Wed, 6 Feb 2002 12:30:26 +1100 To: linux-xfs@oss.sgi.com Subject: Re: Disappearing /, /home In-Reply-To: <1012949128.5437.16.camel@stout.americas.sgi.com> References: <20020205220806.GA7060@prz-rzeszow.pl> <1012949128.5437.16.camel@stout.americas.sgi.com> X-Mailer: VM 6.96 under Emacs 20.7.2 Reply-To: jasonw@ariel.ucs.unimelb.edu.au Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So, to summarize the current state of XFS, would I be correcting in saying the following? The data-corrupting bug (overwriting the first blocks of an XFS file system upon forced shutdown) has been fixed. There are still some problems with spurious forced shutdowns, however, that remain to be traced. I think there are still difficulties with kernel Oopses as well again without a clear cause? Beyond this, there are compatibility issues with LVM that are still being addressed. >From reading the list, this at least is my impression of where the ongoing issues lie. Of course it is probably also true that XFS is working reliably for most users. From owner-linux-xfs@oss.sgi.com Tue Feb 5 22:03:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1663xS09451 for linux-xfs-outgoing; Tue, 5 Feb 2002 22:03:59 -0800 Received: from piaskowy.internal.prz.rzeszow.pl (promien.prz.rzeszow.pl [212.160.98.116]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1663rA09428 for ; Tue, 5 Feb 2002 22:03:54 -0800 Received: from pluszowy.puchatek.net (localhost [127.0.0.1]) by piaskowy.internal.prz.rzeszow.pl (8.12.1/8.12.1/Debian -5) with ESMTP id g1663n0L008737 for ; Wed, 6 Feb 2002 07:03:51 +0100 Message-ID: <3C60C745.90705@pluszowy.puchatek.net> Date: Wed, 06 Feb 2002 07:03:49 +0100 From: Marcin Zieba Reply-To: marcin@prz-rzeszow.pl User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.7) Gecko/20020203 X-Accept-Language: pl, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Disappearing /, /home References: <20020205220806.GA7060@prz-rzeszow.pl> <1012949128.5437.16.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Eric Sandeen wrote: > > _something_ caused a forced shutdown on your filesystem, and there was a > bug in xfs around Jan 3 which would write data to block zero after a > forced shutdown - and that's where your superblock lives. Actually, it > overwrote the first 4k, so there's a bit more important FS data there... > > The good news is this forced shutdown bug is fixed in CVS now, so if you > shut down again, your filesystem should be happier. The bigger question > is, why did your filesystem shut down... > Thanks for that info, I'll sync with cvs (it's fixed in linux-2.4-xfs, right?) asap, and i'll watch, what happens. ;) -- Marcin Zieba (please CC, i'm not a subscriber) From owner-linux-xfs@oss.sgi.com Wed Feb 6 00:19:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g168JY212115 for linux-xfs-outgoing; Wed, 6 Feb 2002 00:19:34 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g168JSA12089 for ; Wed, 6 Feb 2002 00:19:28 -0800 Received: (qmail 31219 invoked by uid 1000); 6 Feb 2002 08:25:01 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Feb 2002 08:25:01 -0000 Date: Wed, 6 Feb 2002 10:25:01 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Benito Venegas cc: Subject: Re: XFS and RAID performance (off-topic??) In-Reply-To: <3C6064C7.2050301@securities.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi read Software-RAID-HOWTO and specially the RAID chunksize combining with man mkfs.xfs with the stride/stripe options On Tue, 5 Feb 2002, Benito Venegas wrote: > Hi guys : > > Question (tunninng XFs on RAID controllers:) > > Have you ever did some tune into RAID controllers like write or cache > policy to have a better performance using Journal FS?? (obvious, XFS ;) > > I read some article 3 or 4 months ago (or more) in LinuxJournal, but I > don't remember what they said at this momment. > > We are working in some new server. They need to be in production in 2 > month more,so I have time to test some configs. > > Any feedback one of you "gurues"?? > > Thanks in advance > -- > Benito Venegas > System Engineer, Technology > 488 Madison Ave. New York, NY 10022 > A Euromoney Institutional Investor company. > > ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Wed Feb 6 05:50:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16DoNB21159 for linux-xfs-outgoing; Wed, 6 Feb 2002 05:50:23 -0800 Received: from relay.realtor3d.odessa.ua (mir.od.anything3d.com [195.138.164.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16DoHA21137 for ; Wed, 6 Feb 2002 05:50:17 -0800 Received: from leshats.od.anything3d.com (leshats.od.anything3d.com [195.114.135.5]) by relay.realtor3d.odessa.ua (8.11.5/8.11.5) with ESMTP id g16DoBN23689 for ; Wed, 6 Feb 2002 15:50:13 +0200 Date: Wed, 6 Feb 2002 15:47:46 +0200 (EET) From: Alexey Tsiban X-X-Sender: To: Subject: Big file support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-TrAVCheck: mir.od.anything3d.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Sorry for maybe offtopic, but what should I update in my slackware 8.0 to really support files >2G? I have xfs filesystem, tar can generate archive, say, 4G size but I can not take it by ftp or samba or scp. Split works. So some programs work with this files but many other dont. May be I need to update glibs or something else? Slackware 8.0, glibs 2.2.3 Thank you, --- Alexey Tsyban Realtor3D Corp. System administrator. ICQ 10195188 From owner-linux-xfs@oss.sgi.com Wed Feb 6 06:14:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16EEYc21977 for linux-xfs-outgoing; Wed, 6 Feb 2002 06:14:34 -0800 Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16EETA21954 for ; Wed, 6 Feb 2002 06:14:29 -0800 Received: from Lehigh.EDU (hooch.CC.lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.2/8.12.2) with ESMTP id g16EDobm010541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Feb 2002 09:13:56 -0500 Message-ID: <3C613A1E.9010109@Lehigh.EDU> Date: Wed, 06 Feb 2002 09:13:50 -0500 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: jasonw@ariel.ucs.unimelb.edu.au CC: linux-xfs@oss.sgi.com Subject: Re: Disappearing /, /home References: <20020205220806.GA7060@prz-rzeszow.pl> <1012949128.5437.16.camel@stout.americas.sgi.com> <15456.34610.41991.980114@jdc.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jason White wrote: > So, to summarize the current state of XFS, would I be correcting in > saying the following? > > The data-corrupting bug (overwriting the first blocks of an XFS file > system upon forced shutdown) has been fixed. There are still some > problems with spurious forced shutdowns, however, that remain to be traced. > > I think there are still difficulties with kernel Oopses as well again > without a clear cause? Beyond this, there are compatibility issues > with LVM that are still being addressed. > >>From reading the list, this at least is my impression of where the > ongoing issues lie. Of course it is probably also true that XFS is > working reliably for most users. > Well Jason, I'm quite happy with vanilla 2.4.17 + xfs-2.4.17-split, dated 22 Jan, I think. I've almost 300G now on top of LVM on top of hardware raid on a very busy 8-way 8.5G production mail server and haven't seen any funnies yet. Just a data point, and thanks to the XFS team. Jim From owner-linux-xfs@oss.sgi.com Wed Feb 6 06:29:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16ETIC22368 for linux-xfs-outgoing; Wed, 6 Feb 2002 06:29:18 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16ETCA22339 for ; Wed, 6 Feb 2002 06:29:12 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g16ESuAt013604; Wed, 6 Feb 2002 15:29:02 +0100 (CET) Message-Id: <4.3.2.7.2.20020206151754.02cceea0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Feb 2002 15:27:05 +0100 To: Alexey Tsiban , From: Seth Mos Subject: Re: Big file support In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:47 6-2-2002 +0200, Alexey Tsiban wrote: >Hi, > >Sorry for maybe offtopic, but what should I update in my slackware 8.0 to >really support files >2G? > >I have xfs filesystem, tar can generate archive, say, 4G size but I can >not take it by ftp or samba or scp. Split works. So some programs work >with this files but many other dont. May be I need to update glibs or >something else? > >Slackware 8.0, glibs 2.2.3 Your program is probably not compiled against glibc with BIG_FILE. This might be fixed in -current but every program needs to be compiled with large file support. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Feb 6 09:03:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16H3tE26406 for linux-xfs-outgoing; Wed, 6 Feb 2002 09:03:55 -0800 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16H3iA26384 for ; Wed, 6 Feb 2002 09:03:44 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g16H3ea18954 for ; Wed, 6 Feb 2002 18:03:40 +0100 Date: Wed, 6 Feb 2002 18:03:40 +0100 (CET) From: Matteo Centonza To: Subject: nfsd & xfsdump strike again Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, this oops come from 2.4.14-xfs-1 (XFS 1.0.2) and xfsdump-1.1.14-0. Feb 5 20:07:20 embeh kernel: Unable to handle kernel NULL pointer dereference at virtual a Feb 5 20:07:20 embeh kernel: 00000000 Feb 5 20:07:20 embeh kernel: *pde = 00000000 Feb 5 20:07:20 embeh kernel: Oops: 0000 Feb 5 20:07:20 embeh kernel: CPU: 0 Feb 5 20:07:20 embeh kernel: EIP: 0010:[agp_frontend_cleanup+0/96] Not tainted Feb 5 20:07:20 embeh kernel: EIP: 0010:[<00000000>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Feb 5 20:07:20 embeh kernel: EFLAGS: 00210282 Feb 5 20:07:20 embeh kernel: eax: 00000000 ebx: df47d140 ecx: df47d59c edx: c04a79c0 Feb 5 20:07:20 embeh kernel: esi: df47d540 edi: df47d140 ebp: df47d140 esp: ddf6be50 Feb 5 20:07:20 embeh kernel: ds: 0018 es: 0018 ss: 0018 Feb 5 20:07:20 embeh kernel: Process nfsd (pid: 721, stackpage=ddf6b000) Feb 5 20:07:20 embeh kernel: Stack: c01887a4 de5d27c0 df47d540 ddf84e04 dee58000 c0188bf6 df47d140 ddf84e04 Feb 5 20:07:20 embeh kernel: 00000002 ddfc3800 11270000 db33f300 dee581f0 00000002 c0188f19 dee58000 Feb 5 20:07:20 embeh kernel: ddf84e14 00000002 00000001 00000001 00000008 00000008 de1f9ccc ddf84e04 Feb 5 20:07:20 embeh kernel: Call Trace: [nfsd_findparent+52/224] [find_fh_dentry+502/784] Feb 5 20:07:20 embeh kernel: Call Trace: [] [] [] [] [] [] [] [] [] Feb 5 20:07:20 embeh kernel: [] Feb 5 20:07:20 embeh kernel: Code: Bad EIP value. >>EIP; 00000000 Before first symbol Trace; c01887a4 Trace; c0188bf6 Trace; c0188f19 Trace; c0110e42 Trace; c018f7ae Trace; c01915e0 Trace; c0186d83 xfsdump was doing incrementals. Probably the last one from the ``conflicting'' interaction between nfsd and xfsdump ;-). As a side note, searching with google i've noticed that similar Oops have a reference to agp_frontend_cleanup. Is that a coincidence? Thanks for any insight. Ciao, -m From owner-linux-xfs@oss.sgi.com Wed Feb 6 23:56:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g177uo216379 for linux-xfs-outgoing; Wed, 6 Feb 2002 23:56:50 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g177uhA16353 for ; Wed, 6 Feb 2002 23:56:43 -0800 Received: (qmail 10477 invoked by uid 1000); 7 Feb 2002 08:02:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Feb 2002 08:02:15 -0000 Date: Thu, 7 Feb 2002 10:02:15 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Alexey Tsiban cc: Subject: Re: Big file support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 6 Feb 2002, Alexey Tsiban wrote: > > Hi, > > Sorry for maybe offtopic, but what should I update in my slackware 8.0 to > really support files >2G? > > I have xfs filesystem, tar can generate archive, say, 4G size but I can > not take it by ftp or samba or scp. Split works. So some programs work > with this files but many other dont. May be I need to update glibs or > something else? > > Slackware 8.0, glibs 2.2.3 > > Thank you, glibc from slack 8 has support for LARGE FILE (thats why tar works). for ftp you need to compile ftpd with large file support (if it has any) and also your ftp clients ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Thu Feb 7 06:22:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17EMqB23476 for linux-xfs-outgoing; Thu, 7 Feb 2002 06:22:52 -0800 Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17EMlA23453 for ; Thu, 7 Feb 2002 06:22:47 -0800 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17EMdH25084 for ; Thu, 7 Feb 2002 09:22:39 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17EMaG08657 for ; Thu, 7 Feb 2002 09:22:36 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NNLJM92; Thu, 7 Feb 2002 09:22:35 -0500 Received: from wmery000.ca.nortel.com ([47.131.36.101]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1MRS5PY6; Thu, 7 Feb 2002 09:22:43 -0500 Subject: Re: Determining if an XFS FS has been shutdown X-Sybari-Space: 00000000 00000000 00000000 From: "Sean Kormilo" To: Linux XFS In-Reply-To: <1012587622.23587.37.camel@wmery000.ca.nortel.com> References: <1012587622.23587.37.camel@wmery000.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Feb 2002 09:22:36 -0500 Message-Id: <1013091756.2563.32.camel@wmery000.ca.nortel.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does the lack of response indicate that there is no way to determine that an XFS FS has been shutdown other than to parse throught the /var/log/messages? Thanks! Sean. > Hi, > > I'm wondering if there is a way I can tell if an XFS filesystem has shut > itself down due to errors? > > I know that logs are generated, but I need a programatic way of doing it > and I'd prefer to not have to write a program to parse through the logs. > > Is there something in /proc? Or is there an XFS command line utility > that can tell me when this occurs? > > Thanks! > > Sean. > > -- > > Sean C. Kormilo, Software Architect, Nortel Networks > email: skormilo@nortelnetworks.com > > -- Sean C. Kormilo, Software Architect, Nortel Networks email: skormilo@nortelnetworks.com From owner-linux-xfs@oss.sgi.com Thu Feb 7 06:45:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17EjVE24068 for linux-xfs-outgoing; Thu, 7 Feb 2002 06:45:31 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17EjRA24045 for ; Thu, 7 Feb 2002 06:45:27 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04269 for ; Thu, 7 Feb 2002 06:46:36 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA29622; Thu, 7 Feb 2002 08:44:09 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA01398; Thu, 7 Feb 2002 08:44:09 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g17Ei1911040; Thu, 7 Feb 2002 08:44:01 -0600 Subject: Re: Determining if an XFS FS has been shutdown From: Steve Lord To: Sean Kormilo Cc: Linux XFS In-Reply-To: <1013091756.2563.32.camel@wmery000.ca.nortel.com> References: <1012587622.23587.37.camel@wmery000.ca.nortel.com> <1013091756.2563.32.camel@wmery000.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Feb 2002 08:44:01 -0600 Message-Id: <1013093041.4092.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-07 at 08:22, Sean Kormilo wrote: > Does the lack of response indicate that there is no way to determine > that an XFS FS has been shutdown other than to parse throught the > /var/log/messages? > > Thanks! The lack of response is more to do with being incredibly busy on Irix stuff at the moment. If a filesystem gets shutdown due to detecting internal memory corruption, on disk corruption, or I/O errors accessing the device, then pretty much any system call which accesses the filesystem will get back EFSCORRUPTED (990). Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 7 10:32:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17IWdg28382 for linux-xfs-outgoing; Thu, 7 Feb 2002 10:32:39 -0800 Received: from exchange.timesys.com ([64.211.104.184]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17IWZA28360 for ; Thu, 7 Feb 2002 10:32:35 -0800 Received: from wvh.timesys.com ([65.117.135.98]) by exchange.timesys.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Feb 2002 13:26:35 -0500 Subject: New Book on "Linux Filesystems" From: Bill von Hagen To: Linux XFS Cc: William von Hagen Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 07 Feb 2002 13:29:26 -0500 Message-Id: <1013106566.26717.26.camel@wvh.timesys> Mime-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2002 18:26:35.0265 (UTC) FILETIME=[F956AF10:01C1B004] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've lurked on this list for a long time, and have learned many details on installing and using XFS. Thanks! I'm finally posting to solicit feedback on my recently-published book on "Linux Filesystems" (SAMS, ISBN 0672322722). This book discusses the use, theory, installation, and integration of journaling and distributed filesystems on Linux, and also discusses what I call 'filesystem adapters' - things like Samba, the NCP tools, and netatalk, which graft together existing filesystems from multiple platforms. The book talks about the Ext3, JFS, the ReiserFS, and XFS journaling filesystems (overview, patching the kernel, administering, using, etc.). It also talks about OpenAFS and NFS.I also give some benchmark results (Bonnie, Postmark, etc.) to do some empirical comparison. This isn't purely a promotional posting - I'd sincerely appreciate feedback and suggestions if you know anyone who is trying to use one of these filesystems and needs a how-to book and a reference. This list is great for people who are already in the know, but I'm hoping that a usable book on the subject will help popularize the use of filesystems such as these. Thanks! Bill von Hagen From owner-linux-xfs@oss.sgi.com Thu Feb 7 12:38:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17KcqI05757 for linux-xfs-outgoing; Thu, 7 Feb 2002 12:38:52 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17KcmA05735 for ; Thu, 7 Feb 2002 12:38:49 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g17Kcgnh086740; Thu, 7 Feb 2002 21:38:42 +0100 (CET) Message-Id: <4.3.2.7.2.20020207213641.02f956c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Feb 2002 21:36:50 +0100 To: "Sean Kormilo", Linux XFS From: Seth Mos Subject: Re: Determining if an XFS FS has been shutdown In-Reply-To: <1013091756.2563.32.camel@wmery000.ca.nortel.com> References: <1012587622.23587.37.camel@wmery000.ca.nortel.com> <1012587622.23587.37.camel@wmery000.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:22 7-2-2002 -0500, Sean Kormilo wrote: >Does the lack of response indicate that there is no way to determine >that an XFS FS has been shutdown other than to parse throught the >/var/log/messages? Yes. Sorry. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Feb 7 14:49:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17Mnn808335 for linux-xfs-outgoing; Thu, 7 Feb 2002 14:49:49 -0800 Received: from relay.realtor3d.odessa.ua (mir.od.anything3d.com [195.138.164.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17MngA08312 for ; Thu, 7 Feb 2002 14:49:43 -0800 Received: from od.anything3d.com (sat.od.anything3d.com [195.138.164.36]) by relay.realtor3d.odessa.ua (8.11.5/8.11.5) with SMTP id g17MnmN17136 for ; Fri, 8 Feb 2002 00:49:48 +0200 Received: from 195.66.202.195 (proxying for 192.168.3.27) (SquirrelMail authenticated user leshats) by webmail.od.anything3d.com with HTTP; Fri, 8 Feb 2002 00:49:37 +0200 (EET) Message-ID: <1240.195.66.202.195.1013122177.squirrel@webmail.od.anything3d.com> Date: Fri, 8 Feb 2002 00:49:37 +0200 (EET) Subject: From: "Alexey Tsyban" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.3) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-TrAVCheck: mir.od.anything3d.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, What does this xfs check results mean? File missing? Can I run xfs on this hardware or I need another filesystem? 019 - output mismatch (see 019.out.bad) 42,46d41 < File: "./directory/file_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_2" < Size: 5 Filetype: Regular File < Mode: (0755/-rwxr-xr-x) Uid: (3) Gid: (1) < Device: Inode: Links: 1 < 75,79d69 < Device: Inode: Links: 1 < < File: "./symlink" < Size: 7 Filetype: Symbolic Link < Mode: (0123/l--x-w--wx) Uid: (0) Gid: (0) Thank you. -- Alexey Tsyban Realtor3D Corp. System Administrator ICQ 10195188 From owner-linux-xfs@oss.sgi.com Thu Feb 7 15:41:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17NfLk09394 for linux-xfs-outgoing; Thu, 7 Feb 2002 15:41:21 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17NfAA09372 for ; Thu, 7 Feb 2002 15:41:10 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g180f5xV017760 for ; Thu, 7 Feb 2002 16:41:05 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA36458; Thu, 7 Feb 2002 17:39:46 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA60683; Thu, 7 Feb 2002 17:39:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g17NdWg24275; Thu, 7 Feb 2002 17:39:32 -0600 Subject: Re: test 019 failure From: Steve Lord To: Alexey Tsyban Cc: linux-xfs@oss.sgi.com In-Reply-To: <1240.195.66.202.195.1013122177.squirrel@webmail.od.anything3d.com> References: <1240.195.66.202.195.1013122177.squirrel@webmail.od.anything3d.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Feb 2002 17:39:32 -0600 Message-Id: <1013125172.21881.54.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-07 at 16:49, Alexey Tsyban wrote: > > Hi, > > What does this xfs check results mean? File missing? Can I run xfs on this > hardware or I need another filesystem? > > 019 - output mismatch (see 019.out.bad) > 42,46d41 > < File: "./directory/file_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_2" > < Size: 5 Filetype: Regular File > < Mode: (0755/-rwxr-xr-x) Uid: (3) Gid: (1) > < Device: Inode: Links: 1 > < > 75,79d69 > < Device: Inode: Links: 1 > < > < File: "./symlink" > < Size: 7 Filetype: Symbolic Link > < Mode: (0123/l--x-w--wx) Uid: (0) Gid: (0) > > > Thank you. > > -- > Alexey Tsyban > Realtor3D Corp. System Administrator > ICQ 10195188 This test is checking the functionality of a feature of the xfs mkfs program to take a filesystem prototype and make a filesystem which already has files in it. It is not something that is really used on linux (it is used on irix to make root filesystem images). Possibilities are that it just did not work, or that the user space on your system is not compatible with the scripts used by the tests to verify the output. How did the rest of the tests run? You could also try running the script by itself rather than through the check program and see what output it reports and what it places in the filesystem it made. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 7 15:56:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17NuPe09775 for linux-xfs-outgoing; Thu, 7 Feb 2002 15:56:25 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17NuGA09750 for ; Thu, 7 Feb 2002 15:56:16 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1169089 for ; Fri, 8 Feb 2002 00:55:11 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA36647; Thu, 7 Feb 2002 17:54:55 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA94209; Thu, 7 Feb 2002 17:54:54 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g17Nsgp24422; Thu, 7 Feb 2002 17:54:42 -0600 Subject: Oopses in kfree From: Steve Lord To: "Ian D. Hardy" , chip_christian@hp.com Cc: linux-xfs@oss.sgi.com, idh@soton.ac.uk In-Reply-To: <3C5E8CFA.CACF28C3@soton.ac.uk> References: <3C5E8CFA.CACF28C3@soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Feb 2002 17:54:42 -0600 Message-Id: <1013126082.21881.65.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-02-04 at 07:30, Ian D. Hardy wrote: > Hi, > > Anyone any ideas on the following Oops (processed with ksymoops 2.4.3). It is > from a NFS server (Dual 1Ghz Supermicro LE, 1Gbyte RAM, 40Gbyte Maxtor IDE > system disk, Zero-D/GForce RI Fibrechannel to IDE hardware RAID-5 500Gbyte > disk unit). It is running the Linux 2.4.17-xfs kernel taken as a CVS image > on 27th January. The main area of disk it is serving is on the HW RAID unit, > which is the only XFS filesystem on the system. The system had been up > for just over 3 days when it crashed. > > I reported a very similar failure a few weeks ago, at that time running a > 2.4.9 based kernel, Steve Lord suggested that we tried the latest CVS image > as this had fixed some memory alloacation problems. > > The machine is essentially an NFS fileserver to a computational cluster. Though > of possible interest is the 'save' process that was running on one of the > processes, this is the Legato Networker backup client process (which was > performing a full backup of the XFS filesystem at the time). I don't think > this is significant as I was seeing these crashes (at ~4 to 12 day intervals) > with the 2.4.9 kernel not dependant upon a 'save' session running. > > You have not been forgotten, just trying to do too many things at once around here right now. But both of you ended up with an oops in kfree, would it be possible to turn on CONFIG_DEBUG_SLAB. This will turn on a number of memory checking features and might make things fall over at a different - and more inciteful point. In Chip's case I suspect the config flag does not exist, so hand edit mm/slab.c and turn on the DEBUG options in there. On a side note, today I experienced an oops due to what appeared to be a failure to allocate a buffer - we had been assuming these were caused by being out of memory, but in my case I had plenty of available memory, it turns out to be a bug in the pagebuf code when we reallocate metadata space. I am thrashing the fix on some test boxes now, but it is possible that those really were not out of memory cases people were seeing, but due to this bug. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 7 16:20:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g180KkU10265 for linux-xfs-outgoing; Thu, 7 Feb 2002 16:20:46 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g180KXA10242 for ; Thu, 7 Feb 2002 16:20:33 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA02233 for ; Thu, 7 Feb 2002 16:19:27 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08382; Fri, 8 Feb 2002 11:16:51 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA17494; Fri, 8 Feb 2002 11:16:48 +1100 (AEDT) Date: Fri, 8 Feb 2002 11:16:47 +1100 From: Nathan Scott To: Alexey Tsyban Cc: linux-xfs@oss.sgi.com Subject: Re: test 019 failure Message-ID: <20020208111647.D118930@wobbly.melbourne.sgi.com> References: <1240.195.66.202.195.1013122177.squirrel@webmail.od.anything3d.com> <1013125172.21881.54.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1013125172.21881.54.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Feb 07, 2002 at 05:39:32PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Feb 07, 2002 at 05:39:32PM -0600, Steve Lord wrote: > On Thu, 2002-02-07 at 16:49, Alexey Tsyban wrote: > > > > Hi, > > > > What does this xfs check results mean? File missing? Can I run xfs on this > > hardware or I need another filesystem? > > > > 019 - output mismatch (see 019.out.bad) > > 42,46d41 > > < File: "./directory/file_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_2" > > < Size: 5 Filetype: Regular File > > < Mode: (0755/-rwxr-xr-x) Uid: (3) Gid: (1) > > < Device: Inode: Links: 1 > > < > > 75,79d69 > > < Device: Inode: Links: 1 > > < > > < File: "./symlink" > > < Size: 7 Filetype: Symbolic Link > > < Mode: (0123/l--x-w--wx) Uid: (0) Gid: (0) > > [very odd, never seen this test fail before] > > This test is checking the functionality of a feature of the xfs > mkfs program to take a filesystem prototype and make a filesystem > which already has files in it. It is not something that is really > used on linux (it is used on irix to make root filesystem images). > > Possibilities are that it just did not work, or that the user > space on your system is not compatible with the scripts used > by the tests to verify the output. How did the rest of the > tests run? > > You could also try running the script by itself rather than through > the check program and see what output it reports and what it places > in the filesystem it made. > You might also find more useful information to help diagnose the problem in "019.full". cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 7 17:20:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g181KqJ11409 for linux-xfs-outgoing; Thu, 7 Feb 2002 17:20:52 -0800 Received: from vonhagen.org (vonhagen.org [209.95.107.208]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g181KmA11387 for ; Thu, 7 Feb 2002 17:20:48 -0800 Received: from distfs.vonhagen.org (12-226-227-159.client.attbi.com [12.226.227.159]) by vonhagen.org (8.9.3/8.9.3) with ESMTP id RAA24556 for ; Thu, 7 Feb 2002 17:20:46 -0800 (PST) Subject: New Book on "Linux Filesystems" From: William von Hagen To: Linux XFS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 07 Feb 2002 20:20:53 -0500 Message-Id: <1013131259.1570.16.camel@distfs.vonhagen.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've lurked on this list for a long time, and have learned many details on installing and using XFS. Thanks! I'm finally posting to solicit feedback on my recently-published book on "Linux Filesystems" (SAMS, ISBN 0672322722). This book discusses the use, theory, installation, and integration of journaling and distributed filesystems on Linux, and also discusses what I call 'filesystem adapters' - things like Samba, the NCP tools, and netatalk, which graft together existing filesystems from multiple platforms. The book talks about the XFS, Ext3, JFS, and ReiserFS journaling filesystems (overview, patching the kernel as needed, administering, using, etc.). It also talks about OpenAFS and NFS.I also provide some benchmark results (Bonnie, Postmark, etc.) to give some empirical comparison. This isn't purely a promotional posting - I'd sincerely appreciate feedback and suggestions if you know anyone who is trying to use one of these filesystems and needs a how-to book and a reference. This list is great for people who are already in the know, but I'm hoping that a usable book on the subject will help popularize the use of filesystems such as these. Thanks! Bill von Hagen From owner-linux-xfs@oss.sgi.com Thu Feb 7 18:14:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g182Exq12700 for linux-xfs-outgoing; Thu, 7 Feb 2002 18:14:59 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g182ErA12677 for ; Thu, 7 Feb 2002 18:14:54 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA28336 for ; Thu, 7 Feb 2002 18:10:26 -0800 (PST) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09030; Fri, 8 Feb 2002 13:13:33 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA85947; Fri, 8 Feb 2002 13:13:32 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Fri, 8 Feb 2002 13:13:31 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: "Bernhard R. Erdmann" cc: Linux XFS Mailing List Subject: Re: xfsrestore dumps core on cumulative restore with -B (dirattr.c:945) In-Reply-To: <3C5BEA25.AAB5D7FE@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2 Feb 2002, Bernhard R. Erdmann wrote: > I discovered a bug in xfsrestore 1.1.14 - it dumps core when the last > level of a cumlative dump is restored using the option "-B" to set mode > on . of the dumped filesystem. I couldn't reproduce the problem here, but judging by your core file, the following patch should avoid the core dump. I shall have a chat to Tim (the xfsrestore expert) next week, and see if we can get a better solution. --- /usr/tmp/TmpDir.13642-0/cmd/xfsdump/restore/tree.c_1.12 Fri Feb 8 13:10:00 2002 +++ cmd/xfsdump/restore/tree.c Fri Feb 8 10:56:56 2002 @@ -2461,6 +2461,9 @@ struct fsxattr fsxattr; /* can we get rid of this? */ intgen_t rval; + if ( dah == DAH_NULL ) + return; + fsxattr.fsx_xflags = dirattr_get_xflags( dah ); fsxattr.fsx_extsize = dirattr_get_extsize( dah ); Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 8 00:54:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g188scr23611 for linux-xfs-outgoing; Fri, 8 Feb 2002 00:54:38 -0800 Received: from relay.realtor3d.odessa.ua (mir.od.anything3d.com [195.138.164.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g188sRA23589 for ; Fri, 8 Feb 2002 00:54:27 -0800 Received: from od.anything3d.com (sat.od.anything3d.com [195.138.164.36]) by relay.realtor3d.odessa.ua (8.11.5/8.11.5) with SMTP id g188sPN22499 for ; Fri, 8 Feb 2002 10:54:25 +0200 Received: from 195.66.202.195 (proxying for 192.168.3.27) (SquirrelMail authenticated user leshats) by webmail.od.anything3d.com with HTTP; Fri, 8 Feb 2002 10:54:20 +0200 (EET) Message-ID: <3095.195.66.202.195.1013158460.squirrel@webmail.od.anything3d.com> Date: Fri, 8 Feb 2002 10:54:20 +0200 (EET) Subject: Re: test 019 failure From: "Alexey Tsyban" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.3) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-TrAVCheck: mir.od.anything3d.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I did this test again and get the same results in 019 test 019 - output mismatch (see 019.out.bad) 42,46d41 < File: "./directory/file_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_2" < Size: 5 Filetype: Regular File < Mode: (0755/-rwxr-xr-x) Uid: (3) Gid: (1) < Device: Inode: Links: 1 < 75,79d69 < Device: Inode: Links: 1 < < File: "./symlink" < Size: 7 Filetype: Symbolic Link < Mode: (0123/l--x-w--wx) Uid: (0) Gid: (0) And now 028 test allso goes wrong: 028 - output mismatch (see 028.out.bad) 131c131 < pathname: DUMP_FILE --- > pathname: /tmpSCRATCH_MNT613.dumpfile 155c155 < pathname: DUMP_FILE --- > pathname: /tmpSCRATCH_MNT613.dumpfile 179c179 < pathname: DUMP_FILE --- > pathname: /tmpSCRATCH_MNT613.dumpfile 203c203 < pathname: DUMP_FILE --- > pathname: /tmpSCRATCH_MNT613.dumpfile 227c227 < pathname: DUMP_FILE --- > pathname: /tmpSCRATCH_MNT613.dumpfile 293c293 < pathname: DUMP_FILE --- > pathname: /tmpSCRATCH_MNT613.dumpfile 317c317 < pathname: DUMP_FILE --- > pathname: /tmpSCRATCH_MNT613.dumpfile And: 032 - output mismatch (see 032.out.bad) 2a3 > Failed - overwrote fs type msdos! 055 [not run] mt -f @ failed I will send .full test dumps to list or anywhere you want. I cant unredstand them myself. But there is no 019.full file. This is Dell PowerEdge 1550 with PERC3/DCL RAID (AMI MegaRAID 64M cache) and 3 36G disks in RAID5. Dual PIII 1000 with 1Gb RAM There is no tape here, so I didn't do tape tests. Linux slackware 8.0 with glibc 2.2.5 and linux 2.4.17 kernel from xfs cvs tree. I am to put this server in web hosting in next few days, so please help me to understand what is goes wrong. -- Alexey Tsyban Realtor3D Corp. System Administrator ICQ 10195188 From owner-linux-xfs@oss.sgi.com Fri Feb 8 02:18:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18AIKh25345 for linux-xfs-outgoing; Fri, 8 Feb 2002 02:18:20 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18AIDA25323 for ; Fri, 8 Feb 2002 02:18:13 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g18AI7tm016778 for ; Fri, 8 Feb 2002 02:18:07 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA11353; Fri, 8 Feb 2002 21:16:51 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA20650; Fri, 8 Feb 2002 21:16:49 +1100 (AEDT) Date: Fri, 8 Feb 2002 21:16:49 +1100 From: Nathan Scott To: Alexey Tsyban Cc: linux-xfs@oss.sgi.com Subject: Re: test 019 failure Message-ID: <20020208211648.A120743@wobbly.melbourne.sgi.com> References: <3095.195.66.202.195.1013158460.squirrel@webmail.od.anything3d.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3095.195.66.202.195.1013158460.squirrel@webmail.od.anything3d.com>; from leshats@od.anything3d.com on Fri, Feb 08, 2002 at 10:54:20AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 08, 2002 at 10:54:20AM +0200, Alexey Tsyban wrote: > > I did this test again and get the same results in 019 test > > ... > And now 028 test allso goes wrong: > > 028 - output mismatch (see 028.out.bad) > 131c131 > < pathname: DUMP_FILE > --- > > pathname: /tmpSCRATCH_MNT613.dumpfile What is your scratch filesystem mount point? Looks like this test has a broken output filter (Tim/Ivan?) Its nothing to worry about by the look of it, broken test. > > I will send .full test dumps to list or anywhere you want. I cant > unredstand them myself. But there is no 019.full file. > Just noticed that 019 removes its .full file 3 lines from the end of the test - if you comment out that line it'll be there at the end - I'd be interested in having a look at 019.full. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Feb 8 02:21:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18ALPH25540 for linux-xfs-outgoing; Fri, 8 Feb 2002 02:21:25 -0800 Received: from relay.realtor3d.odessa.ua (mir.od.anything3d.com [195.138.164.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18ALGA25517 for ; Fri, 8 Feb 2002 02:21:16 -0800 Received: from od.anything3d.com (sat.od.anything3d.com [195.138.164.36]) by relay.realtor3d.odessa.ua (8.11.5/8.11.5) with SMTP id g18ALHN23763 for ; Fri, 8 Feb 2002 12:21:17 +0200 Received: from 195.66.202.195 (proxying for 192.168.3.27) (SquirrelMail authenticated user leshats) by webmail.od.anything3d.com with HTTP; Fri, 8 Feb 2002 12:21:11 +0200 (EET) Message-ID: <4904.195.66.202.195.1013163671.squirrel@webmail.od.anything3d.com> Date: Fri, 8 Feb 2002 12:21:11 +0200 (EET) Subject: XFS performance From: "Alexey Tsyban" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.3) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-TrAVCheck: mir.od.anything3d.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just have tested performance of xfs and ext3 on my new Dell PowerEdge 1550 RERC3/DLC RAID with 3 36Gb disks in RAID5, Dual PIII 1000. Running linux slackware 8.0 glibc 2.2.5 with linux 2.4.17 from cvs tree. Mkfs options -l size=8192b, partition size 30Gb mount options logbufs=4,osyncisdsync Bonnie++ XFS results: Version 1.02a ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP power 2G 6938 49 8949 4 7944 6 10619 74 34052 12 437.0 2 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 380 6 +++++ +++ 426 6 393 6 +++++ +++ 348 5 power,2G,6938,49,8949,4,7944,6,10619,74,34052,12,437.0,2,16,380,6,+++++,+++,426,6,393,6,+++++,+++,348,5 And ext3 results: Version 1.02a ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP power 2G 10386 77 13076 11 7428 5 14116 98 25365 8 399.4 2 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 545 97 +++++ +++ +++++ +++ 573 97 +++++ +++ 2459 94 power,2G,10386,77,13076,11,7428,5,14116,98,25365,8,399.4,2,16,545,97,+++++,+++,+++++,+++,573,97,+++++,+++,2459,94 As I see ext3 is match faster. Why?? May be I should use another mount options or mkfs options to have better performance? Thank you. -- Alexey Tsyban Realtor3D Corp. System Administrator ICQ 10195188 From owner-linux-xfs@oss.sgi.com Fri Feb 8 02:36:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18AaU725930 for linux-xfs-outgoing; Fri, 8 Feb 2002 02:36:30 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18AaMA25907 for ; Fri, 8 Feb 2002 02:36:22 -0800 Received: from relay.realtor3d.odessa.ua (mir.od.anything3d.com [195.138.164.35]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA00914 for ; Fri, 8 Feb 2002 02:31:55 -0800 (PST) mail_from (leshats@od.anything3d.com) Received: from od.anything3d.com (sat.od.anything3d.com [195.138.164.36]) by relay.realtor3d.odessa.ua (8.11.5/8.11.5) with SMTP id g18AS2N23872; Fri, 8 Feb 2002 12:28:02 +0200 Received: from 195.66.202.195 (proxying for 192.168.3.27) (SquirrelMail authenticated user leshats) by webmail.od.anything3d.com with HTTP; Fri, 8 Feb 2002 12:27:56 +0200 (EET) Message-ID: <1104.195.66.202.195.1013164076.squirrel@webmail.od.anything3d.com> Date: Fri, 8 Feb 2002 12:27:56 +0200 (EET) Subject: Re: test 019 failure From: "Alexey Tsyban" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.3) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-TrAVCheck: mir.od.anything3d.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > What is your scratch filesystem mount point? Looks like > this test has a broken output filter (Tim/Ivan?) > /.1 :) sorry for this > Its nothing to worry about by the look of it, broken test. > >> >> I will send .full test dumps to list or anywhere you want. I cant >> unredstand them myself. But there is no 019.full file. >> > > Just noticed that 019 removes its .full file 3 lines from > the end of the test - if you comment out that line it'll > be there at the end - I'd be interested in having a look > at 019.full. > 019 - output mismatch (see 019.out.bad) 42,46d41 < File: "./directory/file_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_2" < Size: 5 Filetype: Regular File < Mode: (0755/-rwxr-xr-x) Uid: (3) Gid: (1) < Device: Inode: Links: 1 < 75,79d69 < Device: Inode: Links: 1 < < File: "./symlink" < Size: 7 Filetype: Symbolic Link < Mode: (0123/l--x-w--wx) Uid: (0) Gid: (0) and 019.full: *** mkfs *** meta-data=/dev/sda7 isize=256 agcount=32, agsize=262144 blks data = bsize=4096 blocks=8279491, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 *** mount *** *** umount *** > cheers. > > -- > Nathan -- Alexey Tsyban Realtor3D Corp. System Administrator ICQ 10195188 From owner-linux-xfs@oss.sgi.com Fri Feb 8 04:10:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18CAQ829369 for linux-xfs-outgoing; Fri, 8 Feb 2002 04:10:26 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18CAGA29344 for ; Fri, 8 Feb 2002 04:10:16 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g18DABxV005852 for ; Fri, 8 Feb 2002 05:10:11 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/8.9.3) with ESMTP id GAA40912; Fri, 8 Feb 2002 06:08:54 -0600 (CST) Received: from sgi.com (NaJovuRjGbwzMcvC4NAWZnmsaaiR0+hA@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA43882; Fri, 8 Feb 2002 06:08:53 -0600 (CST) Message-ID: <3C63BFED.60606@sgi.com> Date: Fri, 08 Feb 2002 06:09:17 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexey Tsyban CC: linux-xfs@oss.sgi.com Subject: Re: XFS performance References: <4904.195.66.202.195.1013163671.squirrel@webmail.od.anything3d.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alexey Tsyban wrote: > >Hi, > >I just have tested performance of xfs and ext3 on my new Dell PowerEdge 1550 >RERC3/DLC RAID with 3 36Gb disks in RAID5, Dual PIII 1000. Running linux >slackware 8.0 glibc 2.2.5 with linux 2.4.17 from cvs tree. >Mkfs options -l size=8192b, partition size 30Gb >mount options logbufs=4,osyncisdsync > Numbers removed > >As I see ext3 is match faster. Why?? >May be I should use another mount options or mkfs options to have better >performance? > With software raid5, xfs does not like having its log in the middle of the drive, the raid5 code and xfs log writes do not interact well, but that should not be an issue here. Some of those numbers my puny little scsi drive beats quite nicely, and on others I ran out of cpu power (2 x 450MHz PIII with 128M). You say you have 3 drives configured as raid5 - how? What is the stripe unit? I do not know for certain, but 3 seems like a funny number. Can you run xfs_growfs -n /xxx where /xxx is the mount point? It is possible to teach xfs about stripe units of raid devices, but getting it right can be tricky. Are you running ext3 with data journalling or without? Steve From owner-linux-xfs@oss.sgi.com Fri Feb 8 04:21:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18CLMV29640 for linux-xfs-outgoing; Fri, 8 Feb 2002 04:21:22 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18CLCA29618 for ; Fri, 8 Feb 2002 04:21:12 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id NAA16414; Fri, 8 Feb 2002 13:21:09 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id NAA12022; Fri, 8 Feb 2002 13:21:09 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 4552B57306; Fri, 8 Feb 2002 13:20:57 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 7355325835; Fri, 8 Feb 2002 13:20:56 +0100 (CET) Message-ID: <3C63C2A8.3F21C6DD@ch.sauter-bc.com> Date: Fri, 08 Feb 2002 13:20:56 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Alexey Tsyban Cc: linux-xfs Subject: Re: XFS performance References: <4904.195.66.202.195.1013163671.squirrel@webmail.od.anything3d.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I don't know exactly how you made your test. I have made my own tests on a DELL PE1400 with Hardware and Software RAID1+5 in every possible combination and I got almost the same result for both ext3 and XFS. When using XFS and Software RAID5, it is very important to have an external logdev on a Software RAID1, which can stay on the same disk. Beside that there was no big difference with both filesystems in my very mixed load test. I mean tests with network load, CPU load, IO load and all of them at the same time. The interesting point was that XFS was always slightly better and much better whith high disk IO load while using less CPU power which is very important when you have applications like DB servers. -Simon Alexey Tsyban schrieb: > > Hi, > > I just have tested performance of xfs and ext3 on my new Dell PowerEdge 1550 > RERC3/DLC RAID with 3 36Gb disks in RAID5, Dual PIII 1000. Running linux > slackware 8.0 glibc 2.2.5 with linux 2.4.17 from cvs tree. > Mkfs options -l size=8192b, partition size 30Gb > mount options logbufs=4,osyncisdsync > > Bonnie++ XFS results: > Version 1.02a ------Sequential Output------ --Sequential Input- > --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP > /sec %CP > power 2G 6938 49 8949 4 7944 6 10619 74 34052 12 > 437.0 2 > ------Sequential Create------ --------Random > Create-------- > -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > /sec %CP > 16 380 6 +++++ +++ 426 6 393 6 +++++ +++ > 348 5 > power,2G,6938,49,8949,4,7944,6,10619,74,34052,12,437.0,2,16,380,6,+++++,+++,426,6,393,6,+++++,+++,348,5 > And ext3 results: > > Version 1.02a ------Sequential Output------ --Sequential Input- > --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP > /sec %CP > power 2G 10386 77 13076 11 7428 5 14116 98 25365 8 > 399.4 2 > ------Sequential Create------ --------Random > Create-------- > -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > /sec %CP > 16 545 97 +++++ +++ +++++ +++ 573 97 +++++ +++ > 2459 94 > power,2G,10386,77,13076,11,7428,5,14116,98,25365,8,399.4,2,16,545,97,+++++,+++,+++++,+++,573,97,+++++,+++,2459,94 > As I see ext3 is match faster. Why?? > May be I should use another mount options or mkfs options to have better > performance? > > Thank you. > > -- > Alexey Tsyban > Realtor3D Corp. System Administrator > ICQ 10195188 From owner-linux-xfs@oss.sgi.com Fri Feb 8 04:30:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18CUvn29879 for linux-xfs-outgoing; Fri, 8 Feb 2002 04:30:57 -0800 Received: from relay.realtor3d.odessa.ua (mir.od.anything3d.com [195.138.164.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18CUlA29856 for ; Fri, 8 Feb 2002 04:30:48 -0800 Received: from od.anything3d.com (sat.od.anything3d.com [195.138.164.36]) by relay.realtor3d.odessa.ua (8.11.5/8.11.5) with SMTP id g18CRYN25818; Fri, 8 Feb 2002 14:27:34 +0200 Received: from 195.66.202.195 (proxying for 192.168.3.27) (SquirrelMail authenticated user leshats) by webmail.od.anything3d.com with HTTP; Fri, 8 Feb 2002 14:27:26 +0200 (EET) Message-ID: <1604.195.66.202.195.1013171246.squirrel@webmail.od.anything3d.com> Date: Fri, 8 Feb 2002 14:27:26 +0200 (EET) Subject: Re: XFS performance From: "Alexey Tsyban" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.3) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-TrAVCheck: mir.od.anything3d.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Alexey Tsyban wrote: > >> >>Hi, >> >>I just have tested performance of xfs and ext3 on my new Dell PowerEdge >>1550 RERC3/DLC RAID with 3 36Gb disks in RAID5, Dual PIII 1000. Running >>linux slackware 8.0 glibc 2.2.5 with linux 2.4.17 from cvs tree. >>Mkfs options -l size=8192b, partition size 30Gb >>mount options logbufs=4,osyncisdsync >> > Numbers removed > >> >>As I see ext3 is match faster. Why?? >>May be I should use another mount options or mkfs options to have >>better performance? >> > > With software raid5, xfs does not like having its log in the middle of > the drive, > the raid5 code and xfs log writes do not interact well, but that should > not be an issue > here. > > Some of those numbers my puny little scsi drive beats quite nicely, and > on others I ran out of cpu power (2 x 450MHz PIII with 128M). > > You say you have 3 drives configured as raid5 - how? What is the stripe > unit? I do not know for certain, but 3 seems like a funny number. Can > you run xfs_growfs -n /xxx where /xxx is the mount point? It is > possible to teach xfs about stripe units of raid devices, but getting > it right can be tricky. > raid5 is maked by PERC3/DCL (AMI Megaraid) setup utility. I dont know what is spripe unit. Yes, 5 disks is better than 3 but in this type of server there is only 4 disk holes and I have only 3 disks. xfs_growfs -n /.0 meta-data=/.0 isize=256 agcount=30, agsize=262144 blks data = bsize=4096 blocks=7681070, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=8192 realtime =none extsz=65536 blocks=0, rtextents=0 > Are you running ext3 with data journalling or without? > ext3 has a default configuration, so only metadata is jornaling I think. Alex -- Alexey Tsyban Realtor3D Corp. System Administrator ICQ 10195188 From owner-linux-xfs@oss.sgi.com Fri Feb 8 04:40:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18Ce7m30169 for linux-xfs-outgoing; Fri, 8 Feb 2002 04:40:07 -0800 Received: from lifesci.ucsb.edu (root@lifesci.lscf.ucsb.edu [128.111.226.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18CdwA30140 for ; Fri, 8 Feb 2002 04:39:58 -0800 Received: from lifesci.ucsb.edu (sour.lscf.ucsb.edu [128.111.226.35]) by lifesci.ucsb.edu (8.11.4/8.11.4) with ESMTP id g18CduM04752 for ; Fri, 8 Feb 2002 04:39:56 -0800 (PST) Message-ID: <3C63C717.5040506@lifesci.ucsb.edu> Date: Fri, 08 Feb 2002 04:39:51 -0800 From: Christopher Jones User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump, xfsrestore segmentation faults Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Passed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everyone, I'm experiencing some problems with XFS on a Redhat 7.2 installation using the SGI supplied installer, and was hoping that someone might be able to provide some advice. I've had the system up for 2 months now, but in the last 2 weeks, have fould that both xfsdump and xfsrestore will crash the system. I had consistently been doing backups just fine, until around January 28th, during a dump, the system load peaked up in the 40's as reported by top (although cpu and memory were fine). My typical dump would look like (sans the escapes): /sbin/xfsdump -F -o -l 9 -L session091 \ -M tue-2002-02-08 \ -f /dev/nst0 /home and a restore: xfsrestore -if /dev/nst0 /home I have two LVM volumes (home and /scratch01): Filesystem Size Used Avail Use% Mounted on /dev/sda1 1.9G 368M 1.5G 19% / /dev/sda6 97M 4.8M 92M 5% /boot /dev/sda7 9.8G 4.9G 4.9G 50% /usr /dev/sda8 3.9G 243M 3.6G 7% /var /dev/sda10 55G 18G 36G 33% /d01 none 753M 0 753M 0% /dev/shm /dev/vg03/lv03 98G 64G 33G 66% /home /dev/vg00/lv00 78G 70G 8.7G 89% /scratch01 Sytem software: Linux 2.4.9-13SGI_XFS_1.0.2smp i686 lvm_1.0.1-rc4 xfsdump-1.1.12-0 xfsprogs-1.3.16-0 xfsprogs-devel-1.3.16-0 After the first time the dump seg faulted, I did an xfs_repair, which found many orphaned inodes, and placed them in lost+found (on the order of 200). Here's the output from one of the failed dumps: [root@mistral log]# /sbin/xfsdump -F -o -l 0 -L session087 -M tue-2002-02-08 -f /dev/nst0 / /sbin/xfsdump: using scsi tape (drive_scsitape) strategy /sbin/xfsdump: version 3.0 - Running single-threaded /sbin/xfsdump: level 0 dump of mistral:/ /sbin/xfsdump: dump date: Fri Feb 8 03:35:18 2002 /sbin/xfsdump: session id: e04d9485-3601-4d5b-86f0-1a946c5f117f /sbin/xfsdump: session label: "session087" /sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) /sbin/xfsdump: ino map phase 2: constructing initial dump list /sbin/xfsdump: ino map phase 3: skipping (no pruning necessary) /sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2) /sbin/xfsdump: ino map phase 5: skipping (only one dump stream) /sbin/xfsdump: ino map construction complete /sbin/xfsdump: estimated dump size: 382444928 bytes /sbin/xfsdump: preparing drive /sbin/xfsdump: WARNING: media may contain data. Overwrite option specified Segmentation fault I've tried the -v trace, but don't get any different output. Is anyone else having problems with these cominations? Can anyone suggest a next step in troubleshooting? Thanks very much in advance, Chris From owner-linux-xfs@oss.sgi.com Fri Feb 8 04:57:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18Cvnr30699 for linux-xfs-outgoing; Fri, 8 Feb 2002 04:57:49 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18CvaA30674 for ; Fri, 8 Feb 2002 04:57:36 -0800 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g18CvUH18885; Fri, 8 Feb 2002 12:57:30 GMT Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g18Cv8g08159; Fri, 8 Feb 2002 12:57:08 GMT Message-ID: <3C63CB24.8CC2AB2D@soton.ac.uk> Date: Fri, 08 Feb 2002 12:57:08 +0000 From: "Ian D. Hardy" Organization: University of Southampton 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: chip_christian@hp.com, linux-xfs@oss.sgi.com, idh@soton.ac.uk Subject: Re: Oopses in kfree References: <3C5E8CFA.CACF28C3@soton.ac.uk> <1013126082.21881.65.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve +, No problems, if only I could find the time to look at all the problems that come my way the same day or week (or often month!). I'll compile up the latest CVS XFS kernel later with CONFIG_DEBUG_SLAB set and hopefully setup a test load over the weekend. I had another crash on my production server this morning (~6.5 days up). This seemed to produce a similar Oops as the last one, but I failed to capture the full details. What was interesting (?) was the following messages in the system log: Feb 8 09:32:56 blue00 kernel: 08:01: rw=1, want=1791743140, limit=560282908 Feb 8 09:32:56 blue00 kernel: attempt to access beyond end of device Feb 8 09:32:56 blue00 kernel: 08:01: rw=1, want=1791743160, limit=560282908 >From just before it crashed (~1minute). I can't remember seeing any similar messages before (checked back at some logs and can't find anything). The configuration of the filesystem (which is on a GFORCE RI hardware FC/IDE RAID-5 unit) is: # xfs_info /scratch meta-data=/scratch isize=256 agcount=535, agsize=261815 blks data = bsize=4096 blocks=140070727, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=17098 realtime =none extsz=65536 blocks=0, rtextents=0 Which I guess agrees with the limit referred to in the error message (140070727 * 4K blocks = 560282908K), though why would the kernel try to reference something at 1791743140K (I guess I need some downtime to run a offline xfs_check) . May give you some pointers? Your observation of a Oops in a memory allocation is interesting, like in your case my system has lots of memory 1G, though the majority (~910Mb) is used as filesystem cache (cached): # cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 1054031872 1044246528 9785344 0 6295552 936423424 Swap: 1052794880 1261568 1051533312 MemTotal: 1029328 kB MemFree: 9556 kB MemShared: 0 kB Buffers: 6148 kB Cached: 914356 kB SwapCached: 120 kB Active: 54540 kB Inactive: 872776 kB HighTotal: 131008 kB HighFree: 1028 kB LowTotal: 898320 kB LowFree: 8528 kB SwapTotal: 1028120 kB SwapFree: 1026888 kB Though I have noticed that at times the amount of memory in use for 'Cached' (and Buffers) decreases (down to ~400Mbytes), with no increase in free memory or observable increase in memory used by processes, it does recover (but normally back to 600-800Mbytes against cached rather than the 900Mbytes+ that we can see on a recently booted system. Could this be connected with the memory allocation problems? -- Thanks Ian -- Steve, Steve Lord wrote: > > > You have not been forgotten, just trying to do too many things at once > around here right now. But both of you ended up with an oops in kfree, > would it be possible to turn on CONFIG_DEBUG_SLAB. > This will turn on a number of memory checking features and might make > things fall over at a different - and more inciteful point. > > In Chip's case I suspect the config flag does not exist, so hand edit > mm/slab.c and turn on the DEBUG options in there. > > On a side note, today I experienced an oops due to what appeared to be > a failure to allocate a buffer - we had been assuming these were caused > by being out of memory, but in my case I had plenty of available memory, > it turns out to be a bug in the pagebuf code when we reallocate metadata > space. I am thrashing the fix on some test boxes now, but it is possible > that those really were not out of memory cases people were seeing, but > due to this bug. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Computing Services Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Fri Feb 8 06:22:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18EMCp32315 for linux-xfs-outgoing; Fri, 8 Feb 2002 06:22:12 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18EM0A32288 for ; Fri, 8 Feb 2002 06:22:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g18FLsxV009883 for ; Fri, 8 Feb 2002 07:21:55 -0800 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA12671; Sat, 9 Feb 2002 01:20:36 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id BAA88195; Sat, 9 Feb 2002 01:20:36 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Sat, 9 Feb 2002 01:20:35 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Christopher Jones cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump, xfsrestore segmentation faults In-Reply-To: <3C63C717.5040506@lifesci.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 8 Feb 2002, Christopher Jones wrote: > Hi everyone, > > I'm experiencing some problems with XFS on a Redhat 7.2 installation > using the SGI supplied installer, and was hoping that someone might be > able to provide some advice. Could you try reproducing the core dump with the latest xfsdump version, and then send me the core file and xfsdump binary? I'll take a look at them next week. Thanks, Ivan > > I've had the system up for 2 months now, but in the last 2 weeks, have > fould that both xfsdump and xfsrestore will crash the system. I had > consistently been doing backups just fine, until around January 28th, > during a dump, the system load peaked up in the 40's as reported by top > (although cpu and memory were fine). > > My typical dump would look like (sans the escapes): > > /sbin/xfsdump -F -o -l 9 -L session091 \ > -M tue-2002-02-08 \ > -f /dev/nst0 /home > > and a restore: > > xfsrestore -if /dev/nst0 /home > > I have two LVM volumes (home and /scratch01): > > Filesystem Size Used Avail Use% Mounted on > /dev/sda1 1.9G 368M 1.5G 19% / > /dev/sda6 97M 4.8M 92M 5% /boot > /dev/sda7 9.8G 4.9G 4.9G 50% /usr > /dev/sda8 3.9G 243M 3.6G 7% /var > /dev/sda10 55G 18G 36G 33% /d01 > none 753M 0 753M 0% /dev/shm > /dev/vg03/lv03 98G 64G 33G 66% /home > /dev/vg00/lv00 78G 70G 8.7G 89% /scratch01 > > Sytem software: > > Linux 2.4.9-13SGI_XFS_1.0.2smp i686 > > lvm_1.0.1-rc4 > xfsdump-1.1.12-0 > xfsprogs-1.3.16-0 > xfsprogs-devel-1.3.16-0 > > After the first time the dump seg faulted, I did an xfs_repair, which > found many orphaned inodes, and placed them in lost+found (on the order > of 200). > > Here's the output from one of the failed dumps: > > [root@mistral log]# /sbin/xfsdump -F -o -l 0 -L session087 -M > tue-2002-02-08 -f > /dev/nst0 / > /sbin/xfsdump: using scsi tape (drive_scsitape) strategy > /sbin/xfsdump: version 3.0 - Running single-threaded > /sbin/xfsdump: level 0 dump of mistral:/ > /sbin/xfsdump: dump date: Fri Feb 8 03:35:18 2002 > /sbin/xfsdump: session id: e04d9485-3601-4d5b-86f0-1a946c5f117f > /sbin/xfsdump: session label: "session087" > /sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) > /sbin/xfsdump: ino map phase 2: constructing initial dump list > /sbin/xfsdump: ino map phase 3: skipping (no pruning necessary) > /sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2) > /sbin/xfsdump: ino map phase 5: skipping (only one dump stream) > /sbin/xfsdump: ino map construction complete > /sbin/xfsdump: estimated dump size: 382444928 bytes > /sbin/xfsdump: preparing drive > /sbin/xfsdump: WARNING: media may contain data. Overwrite option specified > Segmentation fault > > I've tried the -v trace, but don't get any different output. > > Is anyone else having problems with these cominations? > > Can anyone suggest a next step in troubleshooting? > > Thanks very much in advance, > > Chris > > -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 8 11:04:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18J4iJ07464 for linux-xfs-outgoing; Fri, 8 Feb 2002 11:04:44 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18J4eA07442 for ; Fri, 8 Feb 2002 11:04:41 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA47404 for ; Fri, 8 Feb 2002 14:01:26 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g18J4XW64576 for ; Fri, 8 Feb 2002 12:04:33 -0700 Subject: DMAPI remove event To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Fri, 8 Feb 2002 13:04:25 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/08/2002 12:04:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When receiving a 'remove' event using the DMAPI the mode is always returned as 0 (actually it's the ne_mode field of the dm_namesp_event_t extracted from the event). This makes it impossible to determine if the event refers to a file, directory, symlink, etc. I don't know if this is a problem with other types of DMAPI events as well, but it is serious. Is this an easy fix? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Fri Feb 8 11:04:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18J4JV07433 for linux-xfs-outgoing; Fri, 8 Feb 2002 11:04:19 -0800 Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18J4GA07411 for ; Fri, 8 Feb 2002 11:04:16 -0800 Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA04022; Fri, 8 Feb 2002 13:04:31 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA60878; Fri, 8 Feb 2002 13:04:12 -0600 Received: from localhost.localdomain (granite.austin.ibm.com [9.53.216.66]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id NAA26470; Fri, 8 Feb 2002 13:04:12 -0600 Subject: repairing / From: Hollis Blanchard To: seth.mos@xs4all.nl Cc: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Feb 2002 13:04:17 -0600 Message-Id: <1013195057.544.4.camel@granite> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Per the thread at http://marc.theaimsgroup.com/?l=linux-xfs&m=100754969025805&w=2 , *please* add a note to the XFS FAQ. It took me a while to discover that what I need to do is simply not possible without an alternate root device. I think that's very important to point out. -Hollis From owner-linux-xfs@oss.sgi.com Fri Feb 8 11:16:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18JG8B07854 for linux-xfs-outgoing; Fri, 8 Feb 2002 11:16:08 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18JG3A07829 for ; Fri, 8 Feb 2002 11:16:03 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-239.quicknet.nl [212.58.163.239]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g18JFxdG049988; Fri, 8 Feb 2002 20:15:59 +0100 (CET) Message-Id: <4.3.2.7.2.20020208201315.02c59de0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Feb 2002 20:14:03 +0100 To: Hollis Blanchard , seth.mos@xs4all.nl From: Seth Mos Subject: Re: repairing / Cc: linux-xfs@oss.sgi.com In-Reply-To: <1013195057.544.4.camel@granite> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:04 8-2-2002 -0600, Hollis Blanchard wrote: >Per the thread at >http://marc.theaimsgroup.com/?l=linux-xfs&m=100754969025805&w=2 , >*please* add a note to the XFS FAQ. It took me a while to discover that >what I need to do is simply not possible without an alternate root >device. I think that's very important to point out. Makes sense. I will mention something like this and the GRUB boot support. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Feb 8 11:31:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18JVId08124 for linux-xfs-outgoing; Fri, 8 Feb 2002 11:31:18 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18JVEA08102 for ; Fri, 8 Feb 2002 11:31:14 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g18JUbW28206; Fri, 8 Feb 2002 13:30:37 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: rt_sigsuspend From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Feb 2002 13:30:36 -0600 Message-Id: <1013196636.28093.18.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There are some issues around rt_sigsuspend, which I'd like to as the SGI XFS team if they have any insight into if this has been fixed. Ulrich Drepper has had some info on this, but it was from more than 2 yr ago. I was curious if there was more recent info on rt_sigsuspend breakage. Thanks for the time. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Fri Feb 8 11:44:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18Jit908384 for linux-xfs-outgoing; Fri, 8 Feb 2002 11:44:55 -0800 Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18JilA08362 for ; Fri, 8 Feb 2002 11:44:47 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 030C3642; Fri, 8 Feb 2002 14:44:42 -0500 (EST) Received: from sa-bwmail1.esr.hp.com (sa-bwmail1.esr.hp.com [15.1.192.32]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 79EC14000B4; Fri, 8 Feb 2002 14:44:41 -0500 (EST) Received: by sa-bwmail1.esr.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 14:42:17 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B53908818AB0@sa-bwmail1.esr.hp.com> From: "Christian, Chip" To: Steve Lord , "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com, idh@soton.ac.uk Subject: RE: Oopses in kfree Date: Fri, 8 Feb 2002 14:42:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just recently pulled down the latest cvs 2.4.17 as well, and plan to deploy it, hopefully next Thursday am. Will add that config option. Thanks for all your patient assistance. -Chip -----Original Message----- From: Steve Lord [mailto:lord@sgi.com] Sent: Thursday, February 07, 2002 6:55 PM To: Ian D. Hardy; chip_christian@hp.com Cc: linux-xfs@oss.sgi.com; idh@soton.ac.uk Subject: Oopses in kfree On Mon, 2002-02-04 at 07:30, Ian D. Hardy wrote: > Hi, > > Anyone any ideas on the following Oops (processed with ksymoops 2.4.3). It is > from a NFS server (Dual 1Ghz Supermicro LE, 1Gbyte RAM, 40Gbyte Maxtor IDE > system disk, Zero-D/GForce RI Fibrechannel to IDE hardware RAID-5 500Gbyte > disk unit). It is running the Linux 2.4.17-xfs kernel taken as a CVS image > on 27th January. The main area of disk it is serving is on the HW RAID unit, > which is the only XFS filesystem on the system. The system had been up > for just over 3 days when it crashed. > > I reported a very similar failure a few weeks ago, at that time running a > 2.4.9 based kernel, Steve Lord suggested that we tried the latest CVS image > as this had fixed some memory alloacation problems. > > The machine is essentially an NFS fileserver to a computational cluster. Though > of possible interest is the 'save' process that was running on one of the > processes, this is the Legato Networker backup client process (which was > performing a full backup of the XFS filesystem at the time). I don't think > this is significant as I was seeing these crashes (at ~4 to 12 day intervals) > with the 2.4.9 kernel not dependant upon a 'save' session running. > > You have not been forgotten, just trying to do too many things at once around here right now. But both of you ended up with an oops in kfree, would it be possible to turn on CONFIG_DEBUG_SLAB. This will turn on a number of memory checking features and might make things fall over at a different - and more inciteful point. In Chip's case I suspect the config flag does not exist, so hand edit mm/slab.c and turn on the DEBUG options in there. On a side note, today I experienced an oops due to what appeared to be a failure to allocate a buffer - we had been assuming these were caused by being out of memory, but in my case I had plenty of available memory, it turns out to be a bug in the pagebuf code when we reallocate metadata space. I am thrashing the fix on some test boxes now, but it is possible that those really were not out of memory cases people were seeing, but due to this bug. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 8 11:51:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18JpQQ08549 for linux-xfs-outgoing; Fri, 8 Feb 2002 11:51:26 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18Jp7A08525 for ; Fri, 8 Feb 2002 11:51:07 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKTV2R>; Fri, 8 Feb 2002 11:53:13 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F08F@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'linux-xfs@oss.sgi.com'" , "'linux-lvm@sistina.com'" Subject: Oops unmounting snapshot of xfs filesystem Date: Fri, 8 Feb 2002 11:53:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B0DA.3DC711A0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B0DA.3DC711A0 Content-Type: text/plain; charset="iso-8859-1" I have been running into an oops when umounting the snapshot of an xfs filesystem, or following the umount. For instance, a umount followed by an lvremove will oops in the lvremove, while a mount/umount/mount/umount sequence will oops on the second or third umount. What does seem consistent is the error message logged on each umount. Here are the messages from a mount/umount sequence: <4> Feb 7 11:20:00 kernel: Mounting filesystem "lvm(58,1)" in no-recovery mode. Filesystem will be inconsistent. <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/volgr0/lvol1 <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/volgr0/lvol1 <4> Feb 7 11:20:02 kernel: I/O error in filesystem ("lvm(58,1)") meta-data dev 0x3a01 block 0xa00020 <4> Feb 7 11:20:02 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 7 11:20:02 kernel: xfs_force_shutdown(lvm(58,1),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01b3cbc <4> Feb 7 11:20:02 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,1) <4> Feb 7 11:20:02 kernel: Please umount the filesystem, and rectify the problem(s) I've attached the oops (run through ksymoops) from this particular umount. The snapshot is mounted ro,nouuid,norecovery. The source of the snapshot contains an unmounted xfs filesystem, which was unmounted at the time of snapshot creation. There has been no intentional I/O activity to the snapshot, either. It looks to me like xfs is trying to flush something to disk on the umount, even though the filesystem is read only and no recovery. I would not have expected this. Is it correct behavior? I made the snapshot writeable, but kept the mount options the same. I was able to mount/umount many times without oops, I/O errors, or xfs_force_shutdown. I did notice similar behavior when a full snapshot returns an I/O error -- xfs_force_shutdown, with an oops following soon thereafter. System details: Celeron with 512 MB of RAM and WD 45GB harddrives. 128 MB swap, one vg consisting of a one-drive RAID 0. Kernel 2.4.16 with 12/14/01 xfs CVS. LVM CVS of 1/21/02 (functionally identical to 1.0.2, I believe). LVM's linux-2.4.11-VFS-lock.patch. xfs_fs_freeze() patch posted by Eric Sandeen. Anselm Kruis' writable snapshot patch. Dale J. Stephenson steph@snapserver.com ------_=_NextPart_000_01C1B0DA.3DC711A0 Content-Type: application/octet-stream; name="oops.out" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="oops.out" ksymoops 2.4.0 on i686 2.4.9-2buildsmp. Options used -V (default) -k ksyms (specified) -L (specified) -O (specified) -M (specified) Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/net/ap= pletalk/appletalk.o) for appletalk Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/adm1024.o) for adm1024 Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/i2c-proc.o) for i2c-proc Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/i2c-dev.o) for i2c-dev Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/i2c-core.o) for i2c-core Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/net/eepro100.o) for eepro100 Unable to handle kernel NULL pointer dereference at virtual address 0000002= 0=20 c012ffe3=20 *pde =3D 00000000=20 Oops: 0000=20 CPU: 0=20 EIP: 0010:[] Not tainted=20 Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206=20 eax: 00003a01 ebx: 00000000 ecx: 00000160 edx: 00000000=20 esi: 00000011 edi: 00000000 ebp: 00000000 esp: c2217d48=20 ds: 0018 es: 0018 ss: 0018=20 Process umount (pid: 2010, stackpage=3Dc2217000)=20 Stack: 00003a01 00000000 00000000 c0133dc4 00003a01 c033b120 00000160 c3e40= 360=20=20 00000001 c2216000 c132e000 c01300df c3e40360 00000001 c3722200 00000= 000=20=20 c016fb50 00003a01 00000001 00000000 c01cab1d c3722200 c132e000 c1240= 000=20=20 Call Trace: [] [] [] [] [= ]=20=20 [] [] [] [] [] []=20=20 [] [] [] [] [] []=20=20 [] [] [] [] [] []=20=20 [] [] []=20=20 Code: 8b 7b 20 66 39 43 0c 0f 85 86 00 00 00 8b 53 30 85 d2 0f 84=20=20 >>EIP; c012ffe3 <=3D=3D=3D=3D=3D Trace; c0133dc4 Trace; c01300df <__invalidate_buffers+1f/a0> Trace; c016fb50 Trace; c01cab1d Trace; c01b3cbc Trace; c016c628 Trace; c016cfa5 Trace; c01b3cf4 Trace; c01b4407 Trace; c01c93d2 Trace; c01bfb31 Trace; c01b3b8b Trace; c01b5834 Trace; c01b598c Trace; c01b35e9 Trace; c01bb211 Trace; c01c25ea Trace; c01cc2e4 Trace; c01d33cf Trace; c01335ac Trace; c0136f78 Trace; c0142a71 Trace; c012e573 Trace; c0121752 Trace; c0142a8c Trace; c0106efb <__up_wakeup+112f/2474> Code; c012ffe3 00000000 <_EIP>: Code; c012ffe3 <=3D=3D=3D=3D=3D 0: 8b 7b 20 mov 0x20(%ebx),%edi <=3D=3D=3D=3D=3D Code; c012ffe6 3: 66 39 43 0c cmp %ax,0xc(%ebx) Code; c012ffea 7: 0f 85 86 00 00 00 jne 93 <_EIP+0x93> c0130076 Code; c012fff0 d: 8b 53 30 mov 0x30(%ebx),%edx Code; c012fff3 10: 85 d2 test %edx,%edx Code; c012fff5 12: 0f 84 00 00 00 00 je 18 <_EIP+0x18> c012fffb 6 errors issued. Results may not be reliable. ------_=_NextPart_000_01C1B0DA.3DC711A0-- From owner-linux-xfs@oss.sgi.com Fri Feb 8 11:51:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18Jpb308577 for linux-xfs-outgoing; Fri, 8 Feb 2002 11:51:37 -0800 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18JpZA08555 for ; Fri, 8 Feb 2002 11:51:35 -0800 Received: from [192.168.168.136] ([192.168.168.136]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id LAA12838 for ; Fri, 8 Feb 2002 11:51:35 -0800 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Fri, 08 Feb 2002 11:51:54 -0800 Subject: Confused about which patch to take From: "Gabe E. Nydick" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I need to try an upgrade to 2.4.17, but when I go to ftp://oss.sgi.com, in the Release-1.0.2 dir, there is only a patch for 2.4.14. Then when I look in patches, there is linux-2.4.17-xfs-2002-02-03.cvs-patch.bz2 which looks like an entire patched kernel. Then in the patches/2.4.17 dir there is 2.4.17 but from Jan 23, not Feb 03. What do I get????? Thanks, Gabe From owner-linux-xfs@oss.sgi.com Fri Feb 8 12:09:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18K9ie09121 for linux-xfs-outgoing; Fri, 8 Feb 2002 12:09:44 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18K9bA09098 for ; Fri, 8 Feb 2002 12:09:37 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g18K9Wtm006506 for ; Fri, 8 Feb 2002 12:09:32 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA46538; Fri, 8 Feb 2002 14:08:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA06519; Fri, 8 Feb 2002 14:08:16 -0600 (CST) Subject: Re: Confused about which patch to take From: Eric Sandeen To: "Gabe E. Nydick" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Feb 2002 14:08:16 -0600 Message-Id: <1013198896.18726.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-08 at 13:51, Gabe E. Nydick wrote: > I need to try an upgrade to 2.4.17, but when I go to ftp://oss.sgi.com, in > the Release-1.0.2 dir, there is only a patch for 2.4.14. Then when I look > in patches, there is linux-2.4.17-xfs-2002-02-03.cvs-patch.bz2 which looks > like an entire patched kernel. Then in the patches/2.4.17 dir there is > 2.4.17 but from Jan 23, not Feb 03. What do I get????? That depends on what you want. According to the READMEs in the aforementioned directories... Release-1.0.2/README (paraphrased) This dir contains the 1.0.2 release. This release supports 2 kernels, 2.4.14 and Red Hat's 2.4.9 kernel. If you want "Released" XFS, these are your choices. patches/README Everything under here is a snapshot. linux-2.4.x-xfs-.cvs-patch.bz2 CVS seed patch: patch a vanilla linux 2.4.x tree to a "cvs update -d" capable tree. The resulting tree includes all kernel and userspace code for XFS. You probably do not want to use this patch unless you need to seed a CVS tree to stay up to date with XFS development on a i regular basis. patches/2.4.17/README This directory contains a snapshot of the XFS CVS tree at the start of kernel 2.4.17. The snapshot can be downloaded as a single patch containing all the XFS kernel code, it has also been split into several patches to make it easier to port XFS to other architectures and for distributors to include XFS in their distributions. You can apply the -all-i386 (ia64) patch to get a snapshot of XFS for 2.4.17-i386 (ia64) as of 2002-01-23 04:32 UTC. so: do you want "released" XFS, or a snapshot? Do you want a snapshot of the entire CVS tree as of 2/3/2001, or would you like patches split up by functionality, as of 1/23/2001? Options abound. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Feb 8 12:15:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18KFDi09293 for linux-xfs-outgoing; Fri, 8 Feb 2002 12:15:13 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18KF8A09271 for ; Fri, 8 Feb 2002 12:15:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g18KF3tm006696 for ; Fri, 8 Feb 2002 12:15:03 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA34223; Fri, 8 Feb 2002 14:13:46 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.34 #1 (Debian)) id 16ZHOz-0005z6-00; Fri, 08 Feb 2002 14:13:45 -0600 Date: Fri, 8 Feb 2002 14:13:45 -0600 From: Nathan Straz To: "Gabe E. Nydick" Cc: linux-xfs@oss.sgi.com Subject: Re: Confused about which patch to take Message-ID: <20020208201345.GD32315@sgi.com> Mail-Followup-To: "Gabe E. Nydick" , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 08, 2002 at 11:51:54AM -0800, Gabe E. Nydick wrote: > I need to try an upgrade to 2.4.17, but when I go to ftp://oss.sgi.com, in > the Release-1.0.2 dir, there is only a patch for 2.4.14. Then when I look > in patches, there is linux-2.4.17-xfs-2002-02-03.cvs-patch.bz2 which looks > like an entire patched kernel. Then in the patches/2.4.17 dir there is > 2.4.17 but from Jan 23, not Feb 03. What do I get????? Release-1.0.2 Our last fully tested release patches/linux-2.4.17-xfs-2002-02-03.cvs-patch.bz2 A diff from 2.4.17 with our CVS repository on Feb 03. This includes all of the CVS directories so you can run `cvs up` patches/2.4.17/ Patches that are split based on functional area. These take a lot of work and are done on an as needed basis. They help others interested in integrating XFS into their kernels understand what makes up the XFS patch. If you need to move up to 2.4.17, I would suggest the patches in patches/2.4.17. Test the kernel thoroughly before putting it in a production environment. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Fri Feb 8 12:51:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18Kp4m09928 for linux-xfs-outgoing; Fri, 8 Feb 2002 12:51:04 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18Kp1A09906 for ; Fri, 8 Feb 2002 12:51:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g18Kostm008084 for ; Fri, 8 Feb 2002 12:50:55 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA46975 for ; Fri, 8 Feb 2002 14:49:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA74737 for ; Fri, 8 Feb 2002 14:49:38 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g18KnHK18165; Fri, 8 Feb 2002 14:49:17 -0600 Message-Id: <200202082049.g18KnHK18165@jen.americas.sgi.com> Date: Fri, 8 Feb 2002 14:49:17 -0600 Subject: TAKE - make some dmapi code version neutral to: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Use signal interface rather than looking directly at sigpending field this allows us to keep the same code between 2.4 and 2.5 here. Date: Fri Feb 8 12:47:14 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111425a linux/fs/xfs_dmapi/dmapi_session.c - 1.4 linux/fs/xfs_dmapi/dmapi_register.c - 1.4 From owner-linux-xfs@oss.sgi.com Fri Feb 8 16:37:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g190btV13392 for linux-xfs-outgoing; Fri, 8 Feb 2002 16:37:55 -0800 Received: from mail.gmx.net (sproxy.gmx.net [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g190boA13370 for ; Fri, 8 Feb 2002 16:37:50 -0800 Received: (qmail 21942 invoked by uid 0); 9 Feb 2002 00:37:44 -0000 Received: from b1d54.pppool.de (HELO gmx.de) (213.7.29.84) by mail.gmx.net (mp010-rz3) with SMTP; 9 Feb 2002 00:37:44 -0000 Message-ID: <3C646F3E.A448A326@gmx.de> Date: Sat, 09 Feb 2002 01:37:18 +0100 From: Martin Stricker Organization: http://martin-stricker.de/ http://www.surfo.net/ http://www.masterportal24.com/cgi-bin/YaBB.cgi X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [OT] XFS for Red Hat Linux installer - how did you do it? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry for the off-topic, please respond to me in private. Thank you! On the mailing list for the current Red Hat Linux version (enigma-list@redhat.com) we started an attempt to make an installer designed to run on low-memory machines (the current installer needs at least 32 MB RAM). The project is called RULE, see http://spazioweb.inwind.it/marco_web/ , where you also can join our mailing list. Some people from SGI did create a custom installer for the XFS filesystem. We also want to make a custom installer, so I am very thankful on *any* hints on how to do it and what needs to be changed or tweaked. Thank you very much! Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ RULE run up2date Linux everywhere: http://spazioweb.inwind.it/marco_web/ Registered Linux user #210635: http://counter.li.org/ From owner-linux-xfs@oss.sgi.com Fri Feb 8 16:44:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g190iMT13577 for linux-xfs-outgoing; Fri, 8 Feb 2002 16:44:22 -0800 Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g190iHA13554 for ; Fri, 8 Feb 2002 16:44:17 -0800 Message-Id: <200202090044.g190iHA13554@oss.sgi.com> Received: from there ([144.135.25.87]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GR8Q1L00.9NN; Sat, 9 Feb 2002 10:44:09 +1000 Received: from CPE-144-137-128-87.qld.bigpond.net.au ([144.137.128.87]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/3100349); 09 Feb 2002 10:44:09 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: "Stephenson, Dale" , "'linux-xfs@oss.sgi.com'" , "'linux-lvm@sistina.com'" Subject: Re: Oops unmounting snapshot of xfs filesystem Date: Sat, 9 Feb 2002 10:44:02 +1000 X-Mailer: KMail [version 1.3.1] References: <2D0AFEFEE711D611923E009027D39F2B02F08F@cdserv.meridian-data.com> In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F08F@cdserv.meridian-data.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Kernel 2.4.16 with 12/14/01 xfs CVS. There has been heaps of work with respect to XFS and LVM since December last year; therefore, I recommend that you try the current 2.4.17-xfs CVS. If you don't like CVS kernels then use the split patches for 2.4.17-xfs (these however, won't have all the latest bug fixes). I am running 2.4.17-xfs (CVS) with LVM-1.0.2 with the xfs_fs_freeze patch and I'm not seening your exact problem. However, there is a bug at the moment that doesn't flush all inodes to disk on a freeze so the snapshot is not consistant. The SGI guys are working on this at the moment. PS. I think the xfs_fs_freeze patch is actually in the CVS now. > LVM CVS of 1/21/02 (functionally identical to 1.0.2, I believe). > LVM's linux-2.4.11-VFS-lock.patch. > xfs_fs_freeze() patch posted by Eric Sandeen. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Fri Feb 8 16:58:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g190wIN13797 for linux-xfs-outgoing; Fri, 8 Feb 2002 16:58:18 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g190wDA13775 for ; Fri, 8 Feb 2002 16:58:13 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16ZLqE-0002KW-00; Fri, 08 Feb 2002 19:58:10 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g190w8t17974; Fri, 8 Feb 2002 19:58:08 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Martin Stricker Cc: linux-xfs@oss.sgi.com Subject: Re: [OT] XFS for Red Hat Linux installer - how did you do it? References: <3C646F3E.A448A326@gmx.de> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 08 Feb 2002 19:58:08 -0500 In-Reply-To: <3C646F3E.A448A326@gmx.de> Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Martin" == Martin Stricker writes: Martin> Sorry for the off-topic, please respond to me in Martin> private. Thank you! On the mailing list for the current Red Martin> Hat Linux version (enigma-list@redhat.com) we started an Martin> attempt to make an installer designed to run on low-memory Martin> machines (the current installer needs at least 32 MB RAM). Good luck with XFS on low-memory systems <:) Martin> Some people from SGI did create a custom installer for the XFS Martin> filesystem. We also want to make a custom installer, so I am Martin> very thankful on *any* hints on how to do it and what needs to Martin> be changed or tweaked. The whole shebang is in the anaconda SRPM. Apart from that, there's Red Hat's anaconda mailing list plus (a slightly outdated, iirc) anaconda hacking howto. If you have specific questions, feel free to shoot me a mail. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Feb 8 18:36:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g192aTL14605 for linux-xfs-outgoing; Fri, 8 Feb 2002 18:36:29 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g192aMA14583 for ; Fri, 8 Feb 2002 18:36:23 -0800 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Feb 2002 18:36:15 -0800 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Feb 2002 18:36:15 -0800 Subject: kernel panic (corruption of task struct) From: Thomas Duffy To: Linux XFS Mailing List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Feb 2002 18:34:19 -0800 Message-Id: <1013222059.2794.35.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2002 02:36:15.0701 (UTC) FILETIME=[8BDB3050:01C1B112] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am running the 2.4.9-13SGI_XFS_1.0.2smp xfs kernel on a 2P athlon box. I have been seeing random lockups every now and again for a few months now (ever since upgrading to redhat 7.2) I enabled kdb to see what happened. Basically, cc1 is always the offending process. I have seen this thrice now. It is causing the task_struct to be munged. At offset 0x1c into the struct, 4 copies of the uid and 4 copies of gid of the user who is running the cc1 are being slammed in...causing the machine to panic. I don't know if this is XFS related or not, but I thought I would inquire on this list before taking it to a larger (lkml) audience. Any help would be great. Thanks! -tduffy -- begin super_secret_message.doc Tom Duffy, Engineer Afara Websystems, A Delaware Company end From owner-linux-xfs@oss.sgi.com Sat Feb 9 02:31:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19AV1d18601 for linux-xfs-outgoing; Sat, 9 Feb 2002 02:31:01 -0800 Received: from web21102.mail.yahoo.com (web21102.mail.yahoo.com [216.136.227.104]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19AUtA18579 for ; Sat, 9 Feb 2002 02:30:55 -0800 Message-ID: <20020209103055.43335.qmail@web21102.mail.yahoo.com> Received: from [213.114.149.4] by web21102.mail.yahoo.com via HTTP; Sat, 09 Feb 2002 02:30:55 PST Date: Sat, 9 Feb 2002 02:30:55 -0800 (PST) From: Friedrisch Muller Subject: How to undelete a file? To: linux-xfs@oss.sgi.com Cc: friedrischm@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've accidentially deleted a file on my XFS 1.0.2 filesystem under RedHat Linux 7.2 2.4.9-21 i686. I know the exact name of the file and the exact place of the file in the directory tree. After the accidential "rm myfile.txt" I directly unmounted the filesystem. Is there a way to get it back? For example under Linux ext2fs it is quite easy (this is documented in a mini-howto from linuxdoc): 1. Unmount the filesystem. 2. Start "debugfs". 3. Walk to the directory. 4. Dump the directory content data (debugfs: dump /tmp/dirdata). 5. Exit debugfs. 6. Load the data into a hexeditor. 7. Check the inode of my deleted file (it is still there in the directory data, only the "pointer" to the next entry in the directory has increased so it now points after my deleted file's directory entry). 8. Start debugfs again. 9. Add the file to a directory under a certain name with the old inode number (debugfs: modify_inode ) 10. Set deletion time to 0 and link count to 1. 11. Dump my deleted file (debugfs: dump /tmp/mydeletedfile) Please, help... Regards / Friedrisch __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-linux-xfs@oss.sgi.com Sat Feb 9 03:39:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19BdrC19155 for linux-xfs-outgoing; Sat, 9 Feb 2002 03:39:53 -0800 Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19BdlA19132 for ; Sat, 9 Feb 2002 03:39:47 -0800 Received: from xs3.xs4all.nl (dirk@xs3.xs4all.nl [194.109.6.44]) by mxzilla4.xs4all.nl (8.12.0/8.12.0) with ESMTP id g19BdjIa056382 for ; Sat, 9 Feb 2002 12:39:45 +0100 (CET) Received: (from dirk@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) id MAA29979 for linux-xfs@oss.sgi.com; Sat, 9 Feb 2002 12:39:45 +0100 (CET) Date: Sat, 9 Feb 2002 12:39:45 +0100 From: dirk To: xfs ml Subject: vmlinux.lds question Message-ID: <20020209123944.A26476@xs4all.nl> Mail-Followup-To: xfs ml Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, When trying to recompile my 2.4.14 kernel I had a linking error. I have succeeded in the past to compile this kernel and as of now it doesn't work anymore. I am using debian woody and I think that my current ld differs somewhat from the one that I used when I succeeded in the kernel compile. (last one 7 Dec, 2001) ld complains about some "undefined reference to `local symbols in discarded section .text.exit'" In vmlinux.lds there is a "section to be discarded" section, there ".text.exit" is mentioned. What I did was comment out the line with ".text.exit" and this works. But... to be honest I have no clue what I am doing. Can someone enlighten me? Also, can I trust this kernel? Actually I just wanted to make some additional modules and ran in this problem, so a better question is, can trust modules that I build this way? Of course I can just try it out but before that I want to understand a little what I have done. Maybe useful: ld is 2.11.92.0.12.3 ggc is 2.95.4 TIA, Dirk From owner-linux-xfs@oss.sgi.com Sat Feb 9 04:03:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19C30c19635 for linux-xfs-outgoing; Sat, 9 Feb 2002 04:03:00 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19C2uA19613 for ; Sat, 9 Feb 2002 04:02:57 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 86C811E118; Sat, 9 Feb 2002 13:02:50 +0100 (MET) Date: Sat, 9 Feb 2002 13:02:50 +0100 From: Andi Kleen To: dirk Cc: xfs ml Subject: Re: vmlinux.lds question Message-ID: <20020209130250.A8948@wotan.suse.de> References: <20020209123944.A26476@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020209123944.A26476@xs4all.nl> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > What I did was comment out the line with ".text.exit" and > this works. But... to be honest I have no clue what I am > doing. Can someone enlighten me? Also, can I trust this > kernel? Actually I just wanted to make some additional It's ok. You can trust the kernel with that change. The problem is that Debian woody uses too new binutils which added this warning for a situation that was previously not warned about. When XFS switches to a 2.4.18 based kernel it should be fixed there too. -Andi From owner-linux-xfs@oss.sgi.com Sat Feb 9 04:09:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19C9Ff19792 for linux-xfs-outgoing; Sat, 9 Feb 2002 04:09:15 -0800 Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19C98A19770 for ; Sat, 9 Feb 2002 04:09:09 -0800 Received: from xs3.xs4all.nl (dirk@xs3.xs4all.nl [194.109.6.44]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g19C95Fr086867 for ; Sat, 9 Feb 2002 13:09:06 +0100 (CET) Received: (from dirk@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) id NAA06218 for linux-xfs@oss.sgi.com; Sat, 9 Feb 2002 13:09:05 +0100 (CET) Date: Sat, 9 Feb 2002 13:09:05 +0100 From: dirk To: xfs ml Subject: Re: vmlinux.lds question Message-ID: <20020209130905.B26476@xs4all.nl> Mail-Followup-To: xfs ml References: <20020209123944.A26476@xs4all.nl> <20020209130250.A8948@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020209130250.A8948@wotan.suse.de>; from ak@suse.de on Sat, Feb 09, 2002 at 01:02:50PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Feb 09, 2002 at 01:02:50PM +0100, Andi Kleen wrote: > > What I did was comment out the line with ".text.exit" and > > this works. But... to be honest I have no clue what I am > > doing. Can someone enlighten me? Also, can I trust this > > > kernel? Actually I just wanted to make some additional > > It's ok. You can trust the kernel with that change. > Good news! > The problem is that Debian woody uses too new binutils which added this Too new binutils?? These are not tolerant enough then? Thanks for your quick reaction. Dirk From owner-linux-xfs@oss.sgi.com Sat Feb 9 08:57:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19GvKC22109 for linux-xfs-outgoing; Sat, 9 Feb 2002 08:57:20 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19GvGA22072 for ; Sat, 9 Feb 2002 08:57:16 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 13B51C001C6; Sun, 10 Feb 2002 00:57:11 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id E79C6C001C2; Sun, 10 Feb 2002 00:57:09 +0800 (PHT) Date: Sun, 10 Feb 2002 00:57:09 +0800 (PHT) From: Federico Sevilla III To: dirk Cc: xfs ml Subject: Re: vmlinux.lds question In-Reply-To: <20020209123944.A26476@xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Feb 2002 at 12:39, dirk wrote: > ld complains about some "undefined reference to `local symbols in > discarded section .text.exit'" In vmlinux.lds there is a "section to be > discarded" section, there ".text.exit" is mentioned. This actually has nothing to do with XFS. It's a known incompatibility with the existing 2.4 kernels and the latest release of binutils. It's partially fixed in 2.4.17 and supposed to be completely fixed in 2.4.18. You can download the binutils package from potato and do a manual dpkg installation. The build will work. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg From owner-linux-xfs@oss.sgi.com Sat Feb 9 09:01:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19H1SC22301 for linux-xfs-outgoing; Sat, 9 Feb 2002 09:01:28 -0800 Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19H1KA22279 for ; Sat, 9 Feb 2002 09:01:20 -0800 Received: from user-2iniaag.dialup.mindspring.com ([165.121.41.80] helo=waltsathlon.localhost.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16ZasJ-0004em-00 for linux-xfs@oss.sgi.com; Sat, 09 Feb 2002 12:01:19 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 61D2CE01936; Sat, 9 Feb 2002 09:00:33 -0800 (PST) Message-ID: <3C6555B1.1000004@mindspring.com> Date: Sat, 09 Feb 2002 09:00:33 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Friedrisch Muller Cc: linux-xfs@oss.sgi.com Subject: Re: How to undelete a file? References: <20020209103055.43335.qmail@web21102.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Unfortunately, from what I recall, there's not an easy way to recover deleted files short of having a good, recent backup around. Check out: http://marc.theaimsgroup.com/?l=linux-xfs&w=2&r=1&s=undelete&q=b for more info on the subject. -Walt Friedrisch Muller wrote: > Hi, > > I've accidentially deleted a file on my XFS 1.0.2 > filesystem under RedHat Linux 7.2 2.4.9-21 i686. > > I know the exact name of the file and the exact place > of the file in the directory tree. After the > accidential "rm myfile.txt" I directly unmounted the > filesystem. > > Is there a way to get it back? > > For example under Linux ext2fs it is quite easy (this > is documented in a mini-howto from linuxdoc): > > 1. Unmount the filesystem. > 2. Start "debugfs". > 3. Walk to the directory. > 4. Dump the directory content data > (debugfs: dump /tmp/dirdata). > 5. Exit debugfs. > 6. Load the data into a hexeditor. > 7. Check the inode of my deleted file (it is still > there in the directory data, only the "pointer" to the > next entry in the directory has increased so it now > points after my deleted file's directory entry). > 8. Start debugfs again. > 9. Add the file to a directory under a certain name > with the old inode number (debugfs: modify_inode > ) > 10. Set deletion time to 0 and link count to 1. > 11. Dump my deleted file > (debugfs: dump > > /tmp/mydeletedfile) > > Please, help... > > Regards / Friedrisch > > __________________________________________________ > Do You Yahoo!? > Send FREE Valentine eCards with Yahoo! Greetings! > http://greetings.yahoo.com > > From owner-linux-xfs@oss.sgi.com Sat Feb 9 11:46:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19JkhC23794 for linux-xfs-outgoing; Sat, 9 Feb 2002 11:46:43 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19JkcA23772 for ; Sat, 9 Feb 2002 11:46:38 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA03662 for ; Sat, 9 Feb 2002 11:47:50 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA54443; Sat, 9 Feb 2002 13:45:22 -0600 (CST) Received: from sgi.com (99ibqLzLVrO31N6+VsL8hS41wQVOp6cA@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA47426; Sat, 9 Feb 2002 13:45:21 -0600 (CST) Message-ID: <3C657C70.9050300@sgi.com> Date: Sat, 09 Feb 2002 13:45:52 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Duffy CC: Linux XFS Mailing List Subject: Re: kernel panic (corruption of task struct) References: <1013222059.2794.35.camel@tduffy-lnx.afara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Duffy wrote: >I am running the 2.4.9-13SGI_XFS_1.0.2smp xfs kernel on a 2P athlon box. > >I have been seeing random lockups every now and again for a few months >now (ever since upgrading to redhat 7.2) > >I enabled kdb to see what happened. > >Basically, cc1 is always the offending process. I have seen this thrice >now. It is causing the task_struct to be munged. At offset 0x1c into >the struct, 4 copies of the uid and 4 copies of gid of the user who is >running the cc1 are being slammed in...causing the machine to panic. > >I don't know if this is XFS related or not, but I thought I would >inquire on this list before taking it to a larger (lkml) audience. > >Any help would be great. > >Thanks! > >-tduffy > Stack overflow looks likely here. I don't know of any in xfs, but xfs in combination with other things might cause problems. We had one case in LVM snapshotting where LVM was putting large chunks of stuff on the stack. That code should not be in your kernel though, unless you added it. Steve From owner-linux-xfs@oss.sgi.com Sat Feb 9 13:49:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19Ln2R24898 for linux-xfs-outgoing; Sat, 9 Feb 2002 13:49:02 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19LlqA24869 for ; Sat, 9 Feb 2002 13:47:52 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1573499 for ; Sat, 9 Feb 2002 22:47:49 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA54840 for ; Sat, 9 Feb 2002 15:46:34 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA11815 for ; Sat, 9 Feb 2002 15:46:33 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g19Lk2e29384; Sat, 9 Feb 2002 15:46:03 -0600 Message-Id: <200202092146.g19Lk2e29384@jen.americas.sgi.com> Date: Sat, 9 Feb 2002 15:46:03 -0600 Subject: TAKE - merge up to 2.5.4-pre5 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Time to catch up on 2.5 a little! Date: Sat Feb 9 13:42:31 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:111466a linux/drivers/input/joystick/grip.c - 1.1 linux/drivers/input/joystick/gf2k.c - 1.1 linux/drivers/input/joystick/gamecon.c - 1.1 linux/drivers/input/joystick/db9.c - 1.1 linux/drivers/input/joystick/cobra.c - 1.1 linux/drivers/input/joystick/analog.c - 1.1 linux/drivers/input/joystick/amijoy.c - 1.1 linux/drivers/input/joystick/adi.c - 1.1 linux/drivers/input/joystick/a3d.c - 1.1 linux/drivers/input/joystick/Makefile - 1.1 linux/drivers/input/joystick/Config.in - 1.1 linux/drivers/input/joystick/Config.help - 1.1 linux/drivers/input/joystick/iforce.c - 1.1 linux/drivers/input/joystick/interact.c - 1.1 linux/drivers/input/gameport/pcigame.c - 1.1 linux/drivers/input/gameport/ns558.c - 1.1 linux/drivers/input/gameport/lightning.c - 1.1 linux/drivers/input/gameport/gameport.c - 1.1 linux/drivers/input/gameport/emu10k1-gp.c - 1.1 linux/drivers/input/gameport/cs461x.c - 1.1 linux/drivers/input/gameport/Makefile - 1.1 linux/drivers/input/gameport/Config.in - 1.1 linux/drivers/input/gameport/Config.help - 1.1 linux/drivers/input/joystick/magellan.c - 1.1 linux/drivers/input/joystick/sidewinder.c - 1.1 linux/drivers/input/joystick/spaceball.c - 1.1 linux/drivers/input/joystick/spaceorb.c - 1.1 linux/drivers/input/joystick/stinger.c - 1.1 linux/drivers/input/joystick/tmdc.c - 1.1 linux/include/linux/zutil.h - 1.1 linux/include/linux/zconf.h - 1.1 linux/include/linux/thread_info.h - 1.1 linux/drivers/input/joystick/turbografx.c - 1.1 linux/include/linux/stringify.h - 1.1 linux/drivers/input/joystick/warrior.c - 1.1 linux/drivers/input/serio/Config.help - 1.1 linux/drivers/input/serio/Config.in - 1.1 linux/drivers/input/serio/Makefile - 1.1 linux/drivers/input/serio/serio.c - 1.1 linux/drivers/input/serio/serport.c - 1.1 linux/include/asm-i386/thread_info.h - 1.1 linux/scripts/header.tk - 1.8 linux/net/x25/af_x25.c - 1.24 linux/net/wanrouter/wanproc.c - 1.20 linux/net/wanrouter/wanmain.c - 1.15 linux/net/unix/garbage.c - 1.11 linux/net/unix/af_unix.c - 1.40 linux/net/sunrpc/svc.c - 1.10 linux/net/sunrpc/sched.c - 1.26 linux/net/socket.c - 1.30 linux/net/rose/af_rose.c - 1.22 linux/net/packet/af_packet.c - 1.29 linux/net/netrom/af_netrom.c - 1.21 linux/net/netlink/netlink_dev.c - 1.14 linux/net/ipv6/ndisc.c - 1.18 linux/net/ipv6/mcast.c - 1.16 linux/net/ipv6/icmp.c - 1.17 linux/net/ax25/af_ax25.c - 1.23 linux/mm/swapfile.c - 1.51 linux/mm/slab.c - 1.30 linux/kernel/sysctl.c - 1.48 linux/kernel/signal.c - 1.25 linux/kernel/sched.c - 1.57 linux/kernel/panic.c - 1.16 linux/kernel/ksyms.c - 1.132 linux/kernel/fork.c - 1.47 linux/kernel/exit.c - 1.39 linux/kernel/exec_domain.c - 1.18 linux/init/main.c - 1.73 linux/include/net/sock.h - 1.27 linux/include/linux/swap.h - 1.52 linux/include/linux/stat.h - 1.3 linux/include/linux/serialP.h - 1.15 linux/include/linux/sched.h - 1.60 linux/include/linux/proc_fs.h - 1.32 linux/include/linux/pci.h - 1.55 linux/include/linux/nfsd/export.h - 1.10 linux/include/linux/nfs_fs.h - 1.19 linux/include/linux/net.h - 1.9 linux/include/linux/ncp_fs.h - 1.13 linux/include/linux/msdos_fs.h - 1.16 linux/include/linux/kernel.h - 1.32 linux/include/linux/hpfs_fs_sb.h - 1.3 linux/include/linux/hfs_fs.h - 1.9 linux/include/linux/fs.h - 1.148 linux/include/asm-sparc64/unistd.h - 1.16 linux/include/asm-sparc64/siginfo.h - 1.7 linux/include/asm-sparc64/scatterlist.h - 1.7 linux/include/asm-sparc64/mmu_context.h - 1.15 linux/include/asm-sparc64/bitops.h - 1.12 linux/include/asm-sparc/unistd.h - 1.14 linux/include/asm-sparc/siginfo.h - 1.8 linux/include/asm-sparc/scatterlist.h - 1.9 linux/include/asm-ppc/unistd.h - 1.17 linux/include/asm-ppc/siginfo.h - 1.8 linux/include/asm-ppc/scatterlist.h - 1.7 linux/include/asm-mips/unistd.h - 1.11 linux/include/asm-mips/siginfo.h - 1.7 linux/include/asm-mips/scatterlist.h - 1.4 linux/include/asm-m68k/unistd.h - 1.12 linux/include/asm-m68k/siginfo.h - 1.7 linux/include/asm-m68k/semaphore.h - 1.9 linux/include/asm-m68k/scatterlist.h - 1.4 linux/include/asm-i386/unistd.h - 1.20 linux/include/asm-i386/uaccess.h - 1.14 linux/include/asm-i386/spinlock.h - 1.22 linux/include/asm-i386/softirq.h - 1.14 linux/include/asm-i386/smp.h - 1.17 linux/include/asm-i386/siginfo.h - 1.7 linux/include/asm-i386/semaphore.h - 1.16 linux/include/asm-i386/scatterlist.h - 1.4 linux/include/asm-i386/processor.h - 1.31 linux/include/asm-i386/io.h - 1.23 linux/include/asm-i386/floppy.h - 1.8 linux/include/asm-i386/current.h - 1.3 linux/include/asm-arm/siginfo.h - 1.7 linux/include/asm-arm/scatterlist.h - 1.6 linux/include/asm-alpha/unistd.h - 1.16 linux/include/asm-alpha/siginfo.h - 1.5 linux/include/asm-alpha/scatterlist.h - 1.5 linux/fs/vfat/vfatfs_syms.c - 1.7 linux/fs/vfat/namei.c - 1.25 linux/fs/ufs/super.c - 1.25 linux/fs/ufs/file.c - 1.10 linux/fs/super.c - 1.75 linux/fs/stat.c - 1.22 linux/fs/smbfs/sock.c - 1.10 linux/fs/smbfs/inode.c - 1.28 linux/fs/smbfs/file.c - 1.25 linux/fs/romfs/inode.c - 1.30 linux/fs/read_write.c - 1.17 linux/fs/qnx4/inode.c - 1.30 linux/fs/proc/root.c - 1.25 linux/fs/proc/inode.c - 1.17 linux/fs/proc/generic.c - 1.25 linux/fs/proc/base.c - 1.32 linux/fs/proc/array.c - 1.36 linux/fs/pipe.c - 1.25 linux/fs/ntfs/fs.c - 1.38 linux/fs/nfsd/vfs.c - 1.43 linux/fs/nfsd/nfsctl.c - 1.24 linux/fs/nfsd/export.c - 1.24 linux/fs/nfs/write.c - 1.37 linux/fs/nfs/read.c - 1.29 linux/fs/nfs/nfsroot.c - 1.11 linux/fs/nfs/inode.c - 1.37 linux/fs/nfs/file.c - 1.28 linux/fs/nfs/dir.c - 1.32 linux/fs/ncpfs/sock.c - 1.10 linux/fs/ncpfs/inode.c - 1.25 linux/fs/ncpfs/file.c - 1.18 linux/fs/msdos/namei.c - 1.24 linux/fs/msdos/msdosfs_syms.c - 1.8 linux/fs/minix/inode.c - 1.29 linux/fs/lockd/svc.c - 1.15 linux/fs/isofs/inode.c - 1.32 linux/fs/hfs/super.c - 1.14 linux/fs/hfs/mdb.c - 1.5 linux/fs/hfs/hfs.h - 1.7 linux/fs/hfs/file_hdr.c - 1.13 linux/fs/hfs/file_cap.c - 1.13 linux/fs/hfs/extent.c - 1.5 linux/fs/hfs/catalog.c - 1.6 linux/fs/file_table.c - 1.17 linux/fs/fat/fatfs_syms.c - 1.12 linux/fs/ext2/super.c - 1.25 linux/fs/devpts/inode.c - 1.13 linux/fs/dcache.c - 1.32 linux/fs/coda/inode.c - 1.20 linux/fs/block_dev.c - 1.40 linux/fs/binfmt_misc.c - 1.18 linux/fs/autofs/inode.c - 1.11 linux/fs/autofs/init.c - 1.8 linux/fs/autofs/autofs_i.h - 1.9 linux/fs/affs/super.c - 1.19 linux/fs/adfs/super.c - 1.17 linux/fs/Config.in - 1.77 linux/drivers/zorro/proc.c - 1.12 linux/drivers/video/Config.in - 1.32 linux/drivers/usb/usb.c - 1.67 linux/drivers/usb/uhci.c - 1.59 linux/drivers/usb/hub.c - 1.43 linux/drivers/usb/audio.c - 1.39 linux/drivers/sound/opl3sa2.c - 1.13 linux/drivers/sound/Config.in - 1.29 linux/drivers/scsi/wd7000.c - 1.15 linux/drivers/scsi/ultrastor.c - 1.12 linux/drivers/scsi/st.c - 1.40 linux/drivers/scsi/sgiwd93.c - 1.13 linux/drivers/scsi/sg.c - 1.29 linux/drivers/scsi/seagate.c - 1.16 linux/drivers/scsi/scsiiom.c - 1.5 linux/drivers/scsi/scsi.h - 1.26 linux/drivers/scsi/scsi.c - 1.51 linux/drivers/scsi/pci2220i.c - 1.23 linux/drivers/scsi/megaraid.h - 1.14 linux/drivers/scsi/mca_53c9x.c - 1.10 linux/drivers/scsi/inia100.c - 1.18 linux/drivers/scsi/ini9100u.c - 1.17 linux/drivers/scsi/ide-scsi.c - 1.25 linux/drivers/scsi/ibmmca.c - 1.16 linux/drivers/scsi/gdth.c - 1.20 linux/drivers/scsi/esp.c - 1.20 linux/drivers/scsi/eata_dma.c - 1.19 linux/drivers/scsi/eata.c - 1.22 linux/drivers/scsi/atp870u.c - 1.20 linux/drivers/scsi/aha1740.c - 1.10 linux/drivers/scsi/aha1542.c - 1.22 linux/drivers/scsi/advansys.c - 1.25 linux/drivers/scsi/BusLogic.c - 1.15 linux/drivers/scsi/AM53C974.c - 1.14 linux/drivers/scsi/53c7,8xx.c - 1.18 linux/drivers/sbus/char/flash.c - 1.15 linux/drivers/pci/proc.c - 1.23 linux/drivers/pci/pci.c - 1.52 linux/drivers/net/yellowfin.c - 1.29 linux/drivers/net/via-rhine.c - 1.32 linux/drivers/net/tlan.c - 1.24 linux/drivers/net/slip.c - 1.21 linux/drivers/net/sk_g16.c - 1.15 linux/drivers/net/rrunner.c - 1.18 linux/drivers/net/rcpci45.c - 1.21 linux/drivers/net/pcnet32.c - 1.30 linux/drivers/net/ni65.c - 1.12 linux/drivers/net/ni52.c - 1.15 linux/drivers/net/ne3210.c - 1.14 linux/drivers/net/lne390.c - 1.15 linux/drivers/net/lance.c - 1.22 linux/drivers/net/hp100.c - 1.19 linux/drivers/net/epic100.c - 1.27 linux/drivers/net/eepro100.c - 1.37 linux/drivers/net/defxx.c - 1.20 linux/drivers/net/de4x5.c - 1.24 linux/drivers/net/cs89x0.c - 1.22 linux/drivers/net/ac3200.c - 1.17 linux/drivers/net/Makefile - 1.52 linux/drivers/net/Config.in - 1.56 linux/drivers/net/3c527.c - 1.18 linux/drivers/net/3c523.c - 1.16 linux/drivers/net/3c515.c - 1.22 linux/drivers/net/3c509.c - 1.27 linux/drivers/net/3c507.c - 1.21 linux/drivers/net/3c505.c - 1.23 linux/drivers/net/3c503.c - 1.20 linux/drivers/net/3c501.c - 1.16 linux/drivers/macintosh/nvram.c - 1.11 linux/drivers/isdn/isdn_net.c - 1.27 linux/drivers/isdn/isdn_common.c - 1.34 linux/drivers/isdn/isdn_audio.c - 1.11 linux/drivers/isdn/hisax/hisax.h - 1.26 linux/drivers/isdn/hisax/elsa.c - 1.16 linux/drivers/char/vc_screen.c - 1.13 linux/drivers/char/tpqic02.c - 1.18 linux/drivers/char/synclink.c - 1.21 linux/drivers/char/serial.c - 1.55 linux/drivers/char/nvram.c - 1.19 linux/drivers/char/mem.c - 1.43 linux/drivers/char/lp.c - 1.30 linux/drivers/char/joystick/Makefile - 1.9 linux/drivers/char/joystick/Config.in - 1.9 linux/drivers/char/ftape/lowlevel/fdc-io.c - 1.5 linux/drivers/char/esp.c - 1.16 linux/drivers/char/Makefile - 1.54 linux/drivers/char/Config.in - 1.56 linux/drivers/block/ps2esdi.c - 1.33 linux/drivers/block/nbd.c - 1.33 linux/drivers/Makefile - 1.28 linux/arch/sparc64/solaris/timod.c - 1.18 linux/arch/sparc64/solaris/socksys.c - 1.15 linux/arch/sparc64/solaris/socket.c - 1.8 linux/arch/sparc64/solaris/ioctl.c - 1.11 linux/arch/sparc64/solaris/fs.c - 1.16 linux/arch/sparc64/kernel/traps.c - 1.17 linux/arch/sparc64/kernel/systbls.S - 1.22 linux/arch/sparc64/kernel/sys_sunos32.c - 1.34 linux/arch/sparc64/kernel/sys_sparc32.c - 1.41 linux/arch/sparc64/kernel/smp.c - 1.37 linux/arch/sparc64/kernel/signal32.c - 1.19 linux/arch/sparc64/kernel/signal.c - 1.17 linux/arch/sparc64/kernel/rtrap.S - 1.13 linux/arch/sparc64/kernel/ptrace.c - 1.14 linux/arch/sparc64/kernel/process.c - 1.30 linux/arch/sparc64/kernel/entry.S - 1.19 linux/arch/sparc/kernel/systbls.S - 1.19 linux/arch/sparc/kernel/sys_sunos.c - 1.33 linux/arch/sparc/kernel/signal.c - 1.20 linux/arch/sparc/kernel/rtrap.S - 1.10 linux/arch/ppc/kernel/signal.c - 1.13 linux/arch/ppc/kernel/ppc_htab.c - 1.16 linux/arch/ppc/kernel/misc.S - 1.33 linux/arch/mips/kernel/sysirix.c - 1.17 linux/arch/mips/kernel/syscalls.h - 1.11 linux/arch/mips/kernel/signal.c - 1.14 linux/arch/m68k/vmlinux.lds - 1.12 linux/arch/m68k/kernel/signal.c - 1.14 linux/arch/m68k/kernel/entry.S - 1.15 linux/arch/i386/vmlinux.lds - 1.15 linux/arch/i386/lib/getuser.S - 1.3 linux/arch/i386/kernel/traps.c - 1.46 linux/arch/i386/kernel/signal.c - 1.22 linux/arch/i386/kernel/setup.c - 1.68 linux/arch/i386/kernel/ptrace.c - 1.20 linux/arch/i386/kernel/process.c - 1.43 linux/arch/i386/kernel/irq.c - 1.40 linux/arch/i386/kernel/init_task.c - 1.8 linux/arch/i386/kernel/head.S - 1.21 linux/arch/i386/kernel/entry.S - 1.46 linux/arch/i386/defconfig - 1.96 linux/arch/i386/boot/compressed/Makefile - 1.8 linux/arch/i386/boot/bootsect.S - 1.16 linux/arch/arm/kernel/signal.c - 1.18 linux/arch/arm/kernel/calls.S - 1.16 linux/arch/alpha/mm/fault.c - 1.15 linux/arch/alpha/kernel/signal.c - 1.12 linux/arch/alpha/kernel/setup.c - 1.27 linux/arch/alpha/kernel/entry.S - 1.24 linux/Rules.make - 1.14 linux/Makefile - 1.183 linux/MAINTAINERS - 1.94 linux/Documentation/oops-tracing.txt - 1.9 linux/Documentation/Changes - 1.45 linux/include/linux/efs_fs.h - 1.7 linux/fs/hpfs/super.c - 1.14 linux/fs/hpfs/buffer.c - 1.9 linux/fs/efs/super.c - 1.12 linux/drivers/usb/printer.c - 1.42 linux/drivers/usb/acm.c - 1.45 linux/drivers/block/blkpg.c - 1.16 linux/drivers/char/ppdev.c - 1.29 linux/drivers/block/smart1,2.h - 1.6 linux/drivers/parport/share.c - 1.19 linux/drivers/parport/parport_pc.c - 1.45 linux/drivers/parport/daisy.c - 1.7 linux/include/asm-i386/hw_irq.h - 1.23 linux/drivers/pnp/isapnp_proc.c - 1.15 linux/drivers/isdn/hisax/gazel.c - 1.11 linux/net/atm/proc.c - 1.14 linux/drivers/block/DAC960.h - 1.13 linux/arch/sh/vmlinux.lds.S - 1.14 linux/arch/sh/kernel/signal.c - 1.14 linux/arch/sh/kernel/entry.S - 1.22 linux/drivers/scsi/ips.c - 1.23 linux/include/asm-sh/unistd.h - 1.12 linux/include/asm-sh/siginfo.h - 1.5 linux/include/asm-i386/pci.h - 1.14 linux/drivers/pcmcia/cardbus.c - 1.19 linux/arch/m68k/vmlinux-sun3.lds - 1.9 linux/fs/udf/super.c - 1.25 linux/include/linux/spinlock.h - 1.12 linux/include/asm-ppc/pci.h - 1.15 linux/drivers/net/starfire.c - 1.23 linux/drivers/net/pcmcia/3c589_cs.c - 1.21 linux/arch/i386/kernel/smpboot.c - 1.32 linux/include/linux/pci_ids.h - 1.57 linux/drivers/scsi/sim710.c - 1.11 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.16 linux/mm/bootmem.c - 1.19 linux/fs/bfs/inode.c - 1.20 linux/include/linux/proc_fs_i.h - 1.3 linux/include/asm-i386/rwlock.h - 1.3 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.13 linux/drivers/char/agp/agpgart_fe.c - 1.16 linux/drivers/scsi/scsi_lib.c - 1.43 linux/drivers/char/agp/agpgart_be.c - 1.30 linux/drivers/char/agp/agp.h - 1.21 linux/drivers/usb/uhci-debug.h - 1.9 linux/drivers/usb/dabusb.c - 1.17 linux/drivers/sbus/char/jsflash.c - 1.14 linux/fs/openpromfs/inode.c - 1.16 linux/fs/cramfs/inode.c - 1.23 linux/drivers/usb/scanner.c - 1.29 linux/include/linux/input.h - 1.15 linux/drivers/usb/usbmouse.c - 1.16 linux/drivers/usb/usbkbd.c - 1.22 linux/drivers/usb/ov511.c - 1.31 linux/drivers/usb/devices.c - 1.15 linux/drivers/usb/devio.c - 1.26 linux/drivers/usb/drivers.c - 1.8 linux/drivers/usb/inode.c - 1.20 linux/drivers/ieee1394/pcilynx.c - 1.17 linux/drivers/scsi/3w-xxxx.c - 1.16 linux/arch/i386/kernel/pci-dma.c - 1.3 linux/Documentation/usb/ibmcam.txt - 1.5 linux/include/linux/pm.h - 1.9 linux/fs/autofs4/init.c - 1.5 linux/fs/autofs4/autofs_i.h - 1.7 linux/drivers/usb/usb-uhci.h - 1.11 linux/drivers/usb/usb-uhci.c - 1.38 linux/drivers/usb/usb-ohci.c - 1.35 linux/drivers/usb/ibmcam.h - 1.5 linux/drivers/usb/ibmcam.c - 1.16 linux/fs/autofs4/inode.c - 1.11 linux/drivers/usb/usb-uhci-debug.h - 1.7 linux/arch/ia64/kernel/entry.S - 1.19 linux/arch/ia64/ia32/sys_ia32.c - 1.19 linux/arch/ia64/tools/Makefile - 1.6 linux/arch/ia64/kernel/signal.c - 1.11 linux/arch/ia64/kernel/sys_ia64.c - 1.10 linux/drivers/scsi/qla1280.c - 1.14 linux/kernel/pm.c - 1.10 linux/include/asm-ia64/siginfo.h - 1.9 linux/include/asm-ia64/scatterlist.h - 1.6 linux/include/asm-ia64/unistd.h - 1.14 linux/drivers/net/8139too.c - 1.34 linux/fs/devfs/base.c - 1.31 linux/Documentation/networking/8139too.txt - 1.16 linux/drivers/net/tulip/tulip_core.c - 1.37 linux/drivers/net/tulip/tulip.h - 1.15 linux/drivers/net/tulip/timer.c - 1.11 linux/drivers/net/tulip/21142.c - 1.12 linux/drivers/char/nwflash.c - 1.10 linux/include/asm-mips64/siginfo.h - 1.5 linux/include/asm-mips64/unistd.h - 1.8 linux/include/asm-mips64/scatterlist.h - 1.3 linux/arch/mips64/kernel/scall_o32.S - 1.9 linux/arch/mips64/kernel/signal32.c - 1.9 linux/arch/mips64/kernel/signal.c - 1.8 linux/arch/mips64/kernel/linux32.c - 1.11 linux/arch/mips64/kernel/scall_64.S - 1.11 linux/drivers/usb/wacom.c - 1.16 linux/drivers/usb/pegasus.c - 1.26 linux/include/asm-sh/scatterlist.h - 1.4 linux/include/asm-sh/pci.h - 1.13 linux/include/linux/usb.h - 1.29 linux/drivers/parport/ChangeLog - 1.27 linux/drivers/ide/ide.c - 1.43 linux/drivers/ide/ide-proc.c - 1.10 linux/drivers/ide/ide-dma.c - 1.17 linux/drivers/ide/ide-disk.c - 1.23 linux/drivers/net/wan/comx.c - 1.14 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.20 linux/drivers/isdn/avmb1/capifs.c - 1.14 linux/drivers/usb/mdc800.c - 1.16 linux/fs/ramfs/inode.c - 1.16 linux/fs/nfs/nfs3proc.c - 1.8 linux/drivers/usb/serial/keyspan_pda.c - 1.21 linux/drivers/usb/serial/ftdi_sio.c - 1.30 linux/drivers/usb/serial/usbserial.c - 1.29 linux/drivers/usb/serial/whiteheat.c - 1.21 linux/drivers/usb/serial/visor.c - 1.29 linux/drivers/usb/serial/omninet.c - 1.20 linux/drivers/net/wan/lmc/lmc_main.c - 1.10 linux/include/linux/nfs_page.h - 1.7 linux/drivers/usb/serial/digi_acceleport.c - 1.22 linux/include/asm-s390/unistd.h - 1.8 linux/include/asm-s390/siginfo.h - 1.3 linux/arch/s390/kernel/entry.S - 1.16 linux/arch/s390/vmlinux.lds - 1.5 linux/arch/s390/kernel/signal.c - 1.8 linux/arch/i386/kernel/msr.c - 1.14 linux/arch/i386/kernel/cpuid.c - 1.7 linux/fs/xfs/linux/xfs_super.c - 1.161 linux/fs/xfs/linux/xfs_iops.c - 1.124 linux/kdb/kdbmain.c - 1.27 linux/drivers/char/joystick/turbografx.c - 1.3 linux/drivers/char/joystick/tmdc.c - 1.5 linux/drivers/char/joystick/spaceorb.c - 1.4 linux/drivers/char/joystick/spaceball.c - 1.6 linux/drivers/char/joystick/sidewinder.c - 1.7 linux/drivers/char/joystick/serport.c - 1.5 linux/drivers/char/joystick/serio.c - 1.4 linux/drivers/char/joystick/pcigame.c - 1.5 linux/drivers/char/joystick/ns558.c - 1.9 linux/drivers/char/joystick/magellan.c - 1.4 linux/drivers/char/joystick/lightning.c - 1.4 linux/drivers/char/joystick/interact.c - 1.4 linux/drivers/char/joystick/grip.c - 1.4 linux/drivers/char/joystick/gf2k.c - 1.4 linux/Documentation/filesystems/Locking - 1.5 linux/drivers/char/joystick/gameport.c - 1.6 linux/drivers/char/joystick/gamecon.c - 1.5 linux/drivers/char/joystick/db9.c - 1.4 linux/drivers/char/joystick/cobra.c - 1.5 linux/drivers/char/joystick/analog.c - 1.8 linux/drivers/char/joystick/amijoy.c - 1.5 linux/drivers/char/joystick/adi.c - 1.6 linux/drivers/char/joystick/a3d.c - 1.4 linux/drivers/char/joystick/warrior.c - 1.4 linux/drivers/usb/storage/usb.c - 1.17 linux/drivers/usb/storage/transport.c - 1.18 linux/drivers/usb/storage/scsiglue.c - 1.18 linux/drivers/usb/storage/protocol.c - 1.8 linux/drivers/usb/serial/keyspan.c - 1.20 linux/include/asm-i386/i387.h - 1.5 linux/drivers/usb/microtek.c - 1.16 linux/drivers/usb/bluetooth.c - 1.22 linux/fs/jffs/inode-v23.c - 1.18 linux/arch/i386/kernel/i387.c - 1.7 linux/drivers/mtd/mtdchar.c - 1.8 linux/include/linux/gameport.h - 1.5 linux/include/linux/serio.h - 1.4 linux/drivers/usb/storage/shuttle_usbat.c - 1.8 linux/drivers/usb/storage/sddr09.c - 1.14 linux/drivers/usb/storage/freecom.c - 1.10 linux/drivers/net/natsemi.c - 1.19 linux/drivers/media/video/cpia_usb.c - 1.9 linux/drivers/media/video/Config.in - 1.5 linux/drivers/input/mousedev.c - 1.9 linux/drivers/input/keybdev.c - 1.8 linux/drivers/input/joydev.c - 1.9 linux/drivers/input/input.c - 1.8 linux/drivers/input/evdev.c - 1.9 linux/drivers/input/Makefile - 1.3 linux/drivers/input/Config.in - 1.3 linux/drivers/char/joystick/iforce.c - 1.9 linux/drivers/net/hamachi.c - 1.13 linux/drivers/net/sundance.c - 1.14 linux/drivers/net/winbond-840.c - 1.15 linux/drivers/net/tulip/ChangeLog - 1.12 linux/drivers/usb/serial/belkin_sa.c - 1.16 linux/include/asm-i386/cpufeature.h - 1.3 linux/include/asm-i386/xor.h - 1.3 linux/include/asm-parisc/unistd.h - 1.2 linux/drivers/net/lasi_82596.c - 1.8 linux/drivers/usb/serial/mct_u232.c - 1.15 linux/drivers/usb/serial/empeg.c - 1.18 linux/arch/parisc/kernel/syscall.S - 1.2 linux/arch/parisc/kernel/signal.c - 1.2 linux/include/asm-parisc/scatterlist.h - 1.3 linux/include/asm-parisc/semaphore.h - 1.3 linux/include/asm-parisc/siginfo.h - 1.2 linux/arch/parisc/hpux/fs.c - 1.3 linux/include/asm-parisc/spinlock.h - 1.2 linux/mm/shmem.c - 1.28 linux/drivers/scsi/osst.c - 1.12 linux/arch/ia64/sn/fprom/Makefile - 1.3 linux/fs/reiserfs/stree.c - 1.18 linux/fs/reiserfs/super.c - 1.16 linux/fs/reiserfs/tail_conversion.c - 1.12 linux/fs/reiserfs/namei.c - 1.17 linux/fs/reiserfs/journal.c - 1.21 linux/fs/reiserfs/inode.c - 1.25 linux/fs/reiserfs/fix_node.c - 1.15 linux/fs/reiserfs/dir.c - 1.10 linux/include/linux/reiserfs_fs.h - 1.19 linux/include/linux/reiserfs_fs_sb.h - 1.9 linux/arch/s390x/kernel/signal32.c - 1.4 linux/arch/s390x/kernel/signal.c - 1.5 linux/include/asm-s390x/scatterlist.h - 1.3 linux/arch/s390x/kernel/linux32.c - 1.8 linux/include/asm-s390x/siginfo.h - 1.2 linux/arch/cris/cris.ld - 1.8 linux/arch/cris/kernel/entry.S - 1.12 linux/arch/cris/kernel/signal.c - 1.6 linux/arch/s390x/kernel/entry.S - 1.11 linux/include/asm-cris/unistd.h - 1.6 linux/include/asm-s390x/unistd.h - 1.5 linux/include/asm-cris/siginfo.h - 1.2 linux/include/asm-s390/scatterlist.h - 1.3 linux/drivers/net/pci-skeleton.c - 1.10 linux/arch/s390x/vmlinux.lds - 1.5 linux/drivers/usb/serial/io_edgeport.c - 1.19 linux/drivers/scsi/aic7xxx_old.c - 1.16 linux/drivers/char/joystick/stinger.c - 1.3 linux/drivers/char/joystick/cs461x.c - 1.4 linux/include/asm-i386/rwsem.h - 1.2 linux/arch/cris/drivers/usb-host.c - 1.12 linux/fs/freevxfs/vxfs_super.c - 1.7 linux/drivers/net/fealnx.c - 1.11 linux/drivers/net/irda/irda-usb.c - 1.13 linux/arch/cris/drivers/eeprom.c - 1.5 linux/drivers/usb/pwc-if.c - 1.11 linux/drivers/bluetooth/hci_usb.c - 1.6 linux/drivers/usb/catc.c - 1.8 linux/drivers/net/wireless/airo.c - 1.12 linux/drivers/usb/se401.c - 1.8 linux/drivers/usb/serial/cyberjack.c - 1.9 linux/drivers/usb/serial/pl2303.c - 1.10 linux/fs/sysv/super.c - 1.9 linux/drivers/net/au1000_eth.c - 1.5 linux/drivers/usb/usb-skeleton.c - 1.7 linux/drivers/net/dl2k.h - 1.6 linux/Documentation/networking/dl2k.txt - 1.5 linux/drivers/net/dl2k.c - 1.9 linux/drivers/usb/storage/isd200.c - 1.4 linux/drivers/usb/CDCEther.c - 1.7 linux/drivers/usb/kaweth.c - 1.11 linux/arch/s390x/vmlinux-shared.lds - 1.3 linux/arch/s390/vmlinux-shared.lds - 1.3 linux/drivers/usb/usbnet.c - 1.11 linux/drivers/usb/usbvideo.c - 1.6 linux/drivers/sound/nec_vrc5477.c - 1.4 linux/drivers/sound/ite8172.c - 1.5 linux/drivers/scsi/dpt_i2o.c - 1.10 linux/drivers/bluetooth/hci_vhci.c - 1.3 linux/drivers/isdn/hisax/st5481.h - 1.5 linux/drivers/isdn/hisax/st5481_b.c - 1.5 linux/drivers/isdn/hisax/st5481_d.c - 1.7 linux/drivers/isdn/hisax/st5481_usb.c - 1.8 linux/drivers/net/ns83820.c - 1.7 linux/drivers/usb/hid-core.c - 1.5 linux/drivers/char/joystick/emu10k1-gp.c - 1.3 linux/fs/jffs2/super.c - 1.6 linux/arch/i386/kernel/nmi.c - 1.4 linux/fs/smbfs/proto.h - 1.2 linux/fs/namespace.c - 1.13 linux/drivers/usb/hpusbscsi.c - 1.6 linux/drivers/usb/serial/ir-usb.c - 1.9 linux/drivers/message/i2o/i2o_scsi.c - 1.5 linux/drivers/message/i2o/i2o_lan.c - 1.3 linux/drivers/message/i2o/i2o_core.c - 1.5 linux/drivers/message/i2o/i2o_config.c - 1.4 linux/drivers/message/i2o/i2o_block.c - 1.9 linux/drivers/net/8139cp.c - 1.6 linux/fs/inflate_fs/infutil.h - 1.2 linux/fs/inflate_fs/zconf.h - 1.2 linux/net/8021q/vlanproc.c - 1.5 linux/fs/ext3/super.c - 1.10 linux/drivers/hotplug/pci_hotplug_core.c - 1.3 linux/include/linux/ext3_fs.h - 1.4 linux/fs/nfs/pagelist.c - 1.3 linux/fs/reiserfs/procfs.c - 1.4 linux/fs/sysv/ChangeLog - 1.6 linux/fs/driverfs/inode.c - 1.6 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.3 linux/fs/bio.c - 1.10 linux/include/linux/device.h - 1.5 linux/drivers/usb/hcd.c - 1.7 linux/drivers/usb/hcd/ehci-hcd.c - 1.5 linux/drivers/usb/serial/ipaq.c - 1.2 linux/drivers/usb/serial/kl5kusb105.c - 1.2 linux/drivers/usb/stv680.c - 1.4 linux/drivers/usb/vicam.c - 1.5 linux/arch/arm/mach-clps711x/dma.c - 1.2 linux/drivers/usb/auerswald.c - 1.4 linux/lib/crc32.c - 1.3 linux/include/linux/init_task.h - 1.5 linux/drivers/ide/ide-taskfile.c - 1.3 linux/fs/ext2/ext2.h - 1.2 linux/drivers/usb/hcd/ohci.h - 1.2 linux/drivers/usb/hcd/ohci-q.c - 1.2 linux/drivers/usb/hcd/ohci-mem.c - 1.2 linux/drivers/usb/hcd/ohci-hub.c - 1.2 linux/drivers/usb/hcd/ohci-hcd.c - 1.2 linux/drivers/usb/hcd/ohci-dbg.c - 1.2 linux/drivers/video/neofb.c - 1.2 linux/arch/i386/Config.help - 1.3 linux/init/Config.in - 1.2 linux/drivers/usb/Config.help - 1.2 linux/drivers/char/joystick/Config.help - 1.2 linux/drivers/ide/Config.help - 1.3 linux/drivers/input/Config.help - 1.2 linux/drivers/net/Config.help - 1.2 linux/drivers/net/mii.c - 1.2 linux/drivers/base/interface.c - 1.3 linux/drivers/base/fs.c - 1.2 linux/drivers/base/core.c - 1.3 linux/linux/zutil.h - 1.2 linux/linux/zconf.h - 1.2 linux/lib/zlib_inflate/infutil.h - 1.2 linux/lib/zlib_inflate/inflate_syms.c - 1.2 From owner-linux-xfs@oss.sgi.com Sat Feb 9 15:43:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19Nhcu26059 for linux-xfs-outgoing; Sat, 9 Feb 2002 15:43:38 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19NhWA26037 for ; Sat, 9 Feb 2002 15:43:32 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g19NgpB32725; Sat, 9 Feb 2002 17:42:51 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: rt_sigsuspend From: Austin Gonyou To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1013196636.28093.18.camel@UberGeek> References: <1013196636.28093.18.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 09 Feb 2002 17:42:51 -0600 Message-Id: <1013298171.32711.30.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Woops..That should be "I'd like to ask the SGI XFS team". :) Anyway, if anyoone has any info on Java apps with Linux > 2.4.10 having a problem stopping in rt_sigsuspend, please let me know. We're seeing this, at least it looks like it, but the only references I've seen are from 2.2.x days, and pre2.4.x. (2.3.xx). Thanks for any info if you've seen this. It will help greatly. On Fri, 2002-02-08 at 13:30, Austin Gonyou wrote: > There are some issues around rt_sigsuspend, which I'd like to as the SGI > XFS team if they have any insight into if this has been fixed. Ulrich > Drepper has had some info on this, but it was from more than 2 yr ago. I > was curious if there was more recent info on rt_sigsuspend breakage. > > Thanks for the time. > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Sat Feb 9 19:53:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1A3rLF05688 for linux-xfs-outgoing; Sat, 9 Feb 2002 19:53:21 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1A3rHA05664 for ; Sat, 9 Feb 2002 19:53:17 -0800 Received: from localhost.localdomain ([10.2.4.13]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 9 Feb 2002 19:53:11 -0800 Subject: Re: kernel panic (corruption of task struct) From: Thomas Duffy To: Linux Mailing List In-Reply-To: <3C657C70.9050300@sgi.com> References: <1013222059.2794.35.camel@tduffy-lnx.afara.com> <3C657C70.9050300@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 09 Feb 2002 19:52:50 -0800 Message-Id: <1013313171.26982.4.camel@localhost.localdomain> Mime-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2002 03:53:11.0891 (UTC) FILETIME=[75BBA230:01C1B1E6] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2002-02-09 at 11:45, Stephen Lord wrote: > Stack overflow looks likely here. I don't know of any in xfs, but xfs in > combination > with other things might cause problems. We had one case in LVM > snapshotting where > LVM was putting large chunks of stuff on the stack. That code should not > be in your > kernel though, unless you added it. This is a stock xfs kernel rpm 1.0.2 from sgi. No recompile, no addons -- we are not using lvm on this machine, anyways. Any suggestions on how to figure out what is going on here? Cause this is on a critical machine and having it go down every few days is not good... If it goes down again, is there anything I can do in kdb to help narrow down where this is happening? Thanks! -tduffy From owner-linux-xfs@oss.sgi.com Sun Feb 10 01:21:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1A9Lwm11874 for linux-xfs-outgoing; Sun, 10 Feb 2002 01:21:58 -0800 Received: from wh58-307.st.uni-magdeburg.de (wh58-307.st.Uni-Magdeburg.DE [141.44.198.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1A9LnA11852 for ; Sun, 10 Feb 2002 01:21:51 -0800 Received: (from elkner@localhost) by wh58-307.st.uni-magdeburg.de (8.11.6/8.11.6) id g1A9MqX14612 for linux-xfs@oss.sgi.com; Sun, 10 Feb 2002 10:22:52 +0100 From: elkner@linofee.org Message-Id: <200202100922.g1A9MqX14612@wh58-307.st.uni-magdeburg.de> Subject: configure bug ? To: linux-xfs@oss.sgi.com Date: Sun, 10 Feb 2002 10:22:52 +0100 (MET) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, just tried to build xfsprogs-1.3.17.src.tar.gz. For the "usual" user no problem, but if you want to make your own packages, which are not debian or redhat, you are out of luck, since your configure does not obey the --prefix=$proto option :( Since setting PREFIX and ROOT_PREFIX env variables did not work either, I need to replace PKG_.*_DIR values with sed, but IMHO this is quick and dirty as well. Furthermore I consider checking for ${prefix}/[share/]man/man1/man.1.gz to set HAVE_ZIPPED_MANPAGES is also very dirty because these directories or the man man page might not exist or not gzipped, but others. Thus an configure option e.g. --man={gz|cat|auto} would be nice, which might be set for compatibility reasons per default to "auto", where the traditional mechanismen might be used to determine the HAVE_ZIPPED_MANPAGES value. Another bug is related to static builds. With ./configure --prefix=$PROTO --enable-shared=no --enable-shared-uuid=no one is out of luck again, since on pass 1 it is compiled static, but than make builds the dynamic version and overwrites the static binary :((( So can you fix the: --prefix option gzipped man page stuff and building static progs please? Regards, jens. -- +---[ Jens Elkner ]--------------------------------------------------------+ | Walther-Rathenau-Str. 58 elkner@linofee.org | | 39104 Magdeburg GERMANY http://www.linofee.org/ | +--------------------------------------------------------------------------+ From owner-linux-xfs@oss.sgi.com Sun Feb 10 03:55:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ABtoT06490 for linux-xfs-outgoing; Sun, 10 Feb 2002 03:55:50 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ABth906468 for ; Sun, 10 Feb 2002 03:55:43 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id CAA03950 for ; Sun, 10 Feb 2002 02:55:41 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA21976; Sun, 10 Feb 2002 21:54:23 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA35192; Sun, 10 Feb 2002 21:54:22 +1100 (AEDT) Date: Sun, 10 Feb 2002 21:54:22 +1100 From: Nathan Scott To: elkner@linofee.org.com Cc: linux-xfs@oss.sgi.com Subject: Re: configure bug ? Message-ID: <20020210215422.A130088@wobbly.melbourne.sgi.com> References: <200202100922.g1A9MqX14612@wh58-307.st.uni-magdeburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202100922.g1A9MqX14612@wh58-307.st.uni-magdeburg.de>; from elkner@linofee.org on Sun, Feb 10, 2002 at 10:22:52AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 10, 2002 at 10:22:52AM +0100, elkner@linofee.org wrote: > Hi, hello, > just tried to build xfsprogs-1.3.17.src.tar.gz. For the "usual" user > no problem, but if you want to make your own packages, which are not > debian or redhat, you are out of luck, since your configure does > not obey the --prefix=$proto option :( yes, this is known - not very high on the priority list though. > Since setting PREFIX and ROOT_PREFIX env variables did not work either, this should work - what went wrong? > I need to replace PKG_.*_DIR values with sed, but IMHO this is quick and > dirty as well. yes, PREFIX/ROOT_PREFIX is the right way. > Furthermore I consider checking for ${prefix}/[share/]man/man1/man.1.gz > to set HAVE_ZIPPED_MANPAGES is also very dirty because these directories > or the man man page might not exist or not gzipped, but others. *shrug* - works for 99% of cases, if you want more please send a patch. > Thus an configure option e.g. --man={gz|cat|auto} would be nice, which > might be set for compatibility reasons per default to "auto", where the > traditional mechanismen might be used to determine the HAVE_ZIPPED_MANPAGES > value. yup, that would be a good solution if you/anyone wants to implement it. > Another bug is related to static builds. With > ./configure --prefix=$PROTO --enable-shared=no --enable-shared-uuid=no > one is out of luck again, since on pass 1 it is compiled static, but than > make builds the dynamic version and overwrites the static binary :((( > > So can you fix the: > --prefix option > gzipped man page stuff and > building static progs > please? soon as someone sends us a patch... these sorts of things just don't make it onto the radar anymore - what we have is plenty for most users, so we're unlikely to change it ourselves. soounds like you've done alot pf diagnosis and understand a bit about the build process - if you send a patch implementing these things, I would be happy to include it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 10 06:57:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AEvI813184 for linux-xfs-outgoing; Sun, 10 Feb 2002 06:57:18 -0800 Received: from trouble.picotech.net (trouble.picotech.net [216.17.224.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AEvA913159 for ; Sun, 10 Feb 2002 06:57:10 -0800 Received: (qmail 1969 invoked by uid 514); 10 Feb 2002 12:59:03 -0000 Received: from unknown (HELO jeffw) (192.168.100.2) by trouble.picotech.net with SMTP; 10 Feb 2002 12:59:03 -0000 Reply-To: From: "Jeffrey D. Means" To: Subject: Can anyone tell me where I set the CONFIG_PAGE_BUF selection?? Date: Sun, 10 Feb 2002 05:59:57 -0700 Organization: PicoTech Message-ID: <000501c1b232$da882930$0264a8c0@jeffw> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am following the checklist on the "Configuring and installing the XFS Linux Kernel" and when doing my make xconfig I can not find any reference to a CONFIG_PAGE_BUF anywhere I have gone looking through all the menus and have even gone to the trouble of doing a make config via the text prompts, however I still can't find any reference to it and my kernel will not compile. The compile dies in the XFS filesystem make directory. Any help would be appreaciated. BTW: I am using the 2.4.17-xfs CVS tree downloaded on 2/10/02 at aprox 2am Mountain Time if that makes any difference. Jeff Means CIO PicoTech Unix is userfriendly it is just selective of it's users [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Feb 10 07:43:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AFh8A13679 for linux-xfs-outgoing; Sun, 10 Feb 2002 07:43:08 -0800 Received: from mta01-srv.alltel.net (mta01.alltel.net [166.102.165.143]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AFh2913625 for ; Sun, 10 Feb 2002 07:43:02 -0800 Received: from asoh2pp13.alltel.net ([166.102.93.14]) by mta01-srv.alltel.net with ESMTP id <20020210144301.ZLNC3466.mta01-srv.alltel.net@asoh2pp13.alltel.net> for ; Sun, 10 Feb 2002 08:43:01 -0600 Subject: How to tell your Linux XFS Version on your box From: Roger To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-koY4wLSVaMctM0+nqhbr" X-Mailer: Evolution/0.99.0 (Preview Release) Message-Id: <1006379601.4180.5.camel@localhost2.localdomain> Mime-Version: 1.0 X-Mailer: Evolution/1.0.21mdk Date: 10 Feb 2002 09:42:26 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-koY4wLSVaMctM0+nqhbr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable How can one tell what version of XFS they're running on their box? shouldn't the xfs* tools also have versioning number in them (ie...bottom of man file or with a --version/-v option ?) eh, i even looked over a patch for the xfs fs applied to my distros kernel, and that doens't even show versioning numbers. Nor does, /usr/src/linux/Documentation/filesystems/xfs.txt contain versioning info. --=20 ----- Verify my pgp/gnupg signature on my HomePage: http://www.alltel.net/~rogerx/about/index.html My ICQ UIN# =3D 21252173 --=-koY4wLSVaMctM0+nqhbr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjv8Ij0ACgkQZA/JYxAFHWFkYgCfTU+Hl24cJJ/k2gk4qEEFJ+3V 1AIAoIJA1EOLJ/qYN1wdWZF0/mUaqkxp =9htJ -----END PGP SIGNATURE----- --=-koY4wLSVaMctM0+nqhbr-- From owner-linux-xfs@oss.sgi.com Sun Feb 10 07:43:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AFh4u13648 for linux-xfs-outgoing; Sun, 10 Feb 2002 07:43:04 -0800 Received: from mta01-srv.alltel.net (mta01.alltel.net [166.102.165.143]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AFgp913599 for ; Sun, 10 Feb 2002 07:42:51 -0800 Received: from asoh2pp13.alltel.net ([166.102.93.14]) by mta01-srv.alltel.net with ESMTP id <20020210144250.ZLMA3466.mta01-srv.alltel.net@asoh2pp13.alltel.net>; Sun, 10 Feb 2002 08:42:50 -0600 Subject: Re: data corruption/loss From: Roger To: Christian Zander Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011118193738.A17920@chronos> References: <20011118090353.A17758@chronos> <20011118095940.A6147@wotan.suse.de> <20011118193738.A17920@chronos> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/aYHipZ9KgnAwuYACDje" X-Mailer: Evolution/0.99.0 (Preview Release) Message-Id: <1006376438.4176.1.camel@localhost2.localdomain> Mime-Version: 1.0 X-Mailer: Evolution/1.0.21mdk Date: 10 Feb 2002 09:42:14 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-/aYHipZ9KgnAwuYACDje Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2001-11-18 at 13:37, Christian Zander wrote: >=20 > On Sun, Nov 18, 2001 at 09:59:40AM +0100, Andi Kleen wrote: > >=20 > > You're really asking a FAQ. Please check the FAQ. > >=20 >=20 > I did scan through it several times; I guess I wasn't looking for > the right question. My apologies for that, I will read through it > again as soon as oss.sgi.com comes back up. >=20 > > > > In short what you're seeing is that the files have their metadata > > (file size) but not their data flushed yet. The file has turned > > into an hole. One of the reasons XFS is so fast is that it delays > > data flushing until it has enough data to allocate a big chunk on > > disk. Because of that it can happen that the data has not made it > > to disk yet, but the file size has, turning the file into a hole > > (=3D zeroes). The journaling file system does only protect the > > metadata, not the data. > > >=20 > Ok, that makes sense. I'm not overly familiar with file system > concepts, but of what use is metadata if the corresponding data > never makes it to the disk? >=20 > >=20 > > Possibilities are to type sync manually, change your editor to use > > fsync/O_SYNC/O_DSYNC to force data to disk or mount the filesystem > > with one of the slower-but-somewhat safer sync/dsync etc. options. > >=20 >=20 > Changing all applications really isn't an option, but I will take a > look at the mount options. >=20 > > > > The other file systems have the same problem BTW, although it is > > less often seen in practice because they don't delay writes as > > aggressively as XFS. > >=20 >=20 > >From your explanation I can imagine that it happens on other file > systems as well. I've been relying on journaling file systems for > quite a while now, however, and have never experienced anything > alike with anything other than xfs. >=20 > Well, either way, I appreciate your quick response despite my > failing to 'read the fscking documentation' carefully enough. >=20 > --=20 > christian zander > phoenix@minion.de >=20 AH! i too am experiencing the same exact scenario! i've been browsing the FAQ on this including the mailling list archives, but am having a heck of a time. this really looks like something that needs to be address since i'm seeing this quite often now on my box. (i've been tinkering for the past week on test scenarios which are causing some crashes..devfs..etc). now, i'm loosing config/rc files left and right...over written by '@' characters etc. actually, it's chocking on me everywhere. if you find and hack that provides a solution, please advised. --=20 ----- Verify my pgp/gnupg signature on my HomePage: http://www.alltel.net/~rogerx/about/index.html My ICQ UIN# =3D 21252173 --=-/aYHipZ9KgnAwuYACDje Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjv8FdcACgkQZA/JYxAFHWHqFQCeIcAeNba3nCKDkD5MStiu9D8S hjwAn0vjuUAL8cyBrn+gQ20852x9hZWJ =korU -----END PGP SIGNATURE----- --=-/aYHipZ9KgnAwuYACDje-- From owner-linux-xfs@oss.sgi.com Sun Feb 10 07:43:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AFhC813684 for linux-xfs-outgoing; Sun, 10 Feb 2002 07:43:12 -0800 Received: from mta02-srv.alltel.net (mta02.alltel.net [166.102.165.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AFh6913655 for ; Sun, 10 Feb 2002 07:43:06 -0800 Received: from asoh2pp13.alltel.net ([166.102.93.14]) by mta02-srv.alltel.net with ESMTP id <20020210144305.YVQC25499.mta02-srv.alltel.net@asoh2pp13.alltel.net>; Sun, 10 Feb 2002 08:43:05 -0600 Subject: Re: How to tell your Linux XFS Version on your box From: Roger To: ian.nelson@echostar.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BFC16DE.A7010D3F@echostar.com> References: <1006379601.4180.5.camel@localhost2.localdomain> <3BFC16DE.A7010D3F@echostar.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AiKX/lmNvs7wxrmFJoJe" X-Mailer: Evolution/0.99.0 (Preview Release) Message-Id: <1006381710.4162.7.camel@localhost2.localdomain> Mime-Version: 1.0 X-Mailer: Evolution/1.0.21mdk Date: 10 Feb 2002 09:42:29 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-AiKX/lmNvs7wxrmFJoJe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable # cat /proc/fs/xfs/dmapi # SGI DMAPI (XDSM) API, Release 1.0 thanx. On Wed, 2001-11-21 at 16:04, Ian S. Nelson wrote: > Something could also be placed in /proc/fs >=20 >=20 >=20 > Roger wrote: >=20 > > How can one tell what version of XFS they're running on their box? > > > > shouldn't the xfs* tools also have versioning number in them > > (ie...bottom of man file or with a --version/-v option ?) > > > > eh, i even looked over a patch for the xfs fs applied to my distros > > kernel, and that doens't even show versioning numbers. > > > > Nor does, > > /usr/src/linux/Documentation/filesystems/xfs.txt > > contain versioning info. --=-AiKX/lmNvs7wxrmFJoJe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjv8KosACgkQZA/JYxAFHWHkIgCfcclNyx5TSNWOGIwm1JD1A3It QcoAnjvcx5WD5UySdbFqEMBwXAnbYRpq =uRFT -----END PGP SIGNATURE----- --=-AiKX/lmNvs7wxrmFJoJe-- From owner-linux-xfs@oss.sgi.com Sun Feb 10 08:08:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AG8Cb14264 for linux-xfs-outgoing; Sun, 10 Feb 2002 08:08:12 -0800 Received: from mta02-srv.alltel.net (mta02.alltel.net [166.102.165.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AG83914212 for ; Sun, 10 Feb 2002 08:08:04 -0800 Received: from asoh2pp13.alltel.net ([166.102.93.14]) by mta02-srv.alltel.net with ESMTP id <20020210150802.YZGT25499.mta02-srv.alltel.net@asoh2pp13.alltel.net> for ; Sun, 10 Feb 2002 09:08:02 -0600 Subject: Using Bonnie++ on XFS crashes fs/xfs driver? From: Roger To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oHzALpruOlA3/RUhbofg" X-Mailer: Evolution/0.99.0 (Preview Release) Message-Id: <1006634210.2199.5.camel@localhost2.localdomain> Mime-Version: 1.0 X-Mailer: Evolution/1.0.21mdk Date: 10 Feb 2002 10:07:27 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-oHzALpruOlA3/RUhbofg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable When i attempt to run Bonnie on my xfs filesystem, it crashes 3/4's way thru on writing the 100MB benchmarking The fs driver/process would stop at the "Writing intelligently..." process. At this point, trying to 'kill ' wouldn't work and niether would umounting the drive would work...resulting in an unclean reboot & me loosing more of my .configrc files :-( ... very bad. I'm also seeing similar activity when writing agressively to a XFS partition and then having another process also try writing at the same time. results a hang in the process (again) and unable to umount the drive. I believe not even the 'kernel hacking' keys work.=20 Here's the process i use on a system hang: alt+sysreq+s =3D sync all drives now! alt+sysreq+u =3D umount all mount points now! alt+sysreq+b =3D reboot system now! Bonnie++ =3D=3D Supposedly a better benchmarking utility then hdparm -tT http://sourceforge.net/projects/bonnie/ Although, I was able to successfully use bonnie on a ext3 partition tho on the same computer: $ bonnie -d /extra1/ File '/extra1//Bonnie.2698', size: 104857600 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU=20 /sec %CPU 100 6545 84.4 15639 33.9 7893 12.1 6915 81.0 15235 12.8 1351.8 5.7 [roger]$=20 --=-oHzALpruOlA3/RUhbofg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjwABOAACgkQZA/JYxAFHWG/bQCfZgcf3PQcB4QupBEBtvRv4IBQ okMAoJf4EVHtAPYf4W3L3gDiyuMelpMR =3Y7Q -----END PGP SIGNATURE----- --=-oHzALpruOlA3/RUhbofg-- From owner-linux-xfs@oss.sgi.com Sun Feb 10 08:08:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AG8HH14269 for linux-xfs-outgoing; Sun, 10 Feb 2002 08:08:17 -0800 Received: from mta02-srv.alltel.net (mta02.alltel.net [166.102.165.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AG8B914240 for ; Sun, 10 Feb 2002 08:08:11 -0800 Received: from asoh2pp13.alltel.net ([166.102.93.14]) by mta02-srv.alltel.net with ESMTP id <20020210150809.YZHD25499.mta02-srv.alltel.net@asoh2pp13.alltel.net> for ; Sun, 10 Feb 2002 09:08:09 -0600 Subject: Best Logfile size for XFS From: Roger To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4VpzvHRSSu/rap7XMdD2" X-Mailer: Evolution/0.99.0 (Preview Release) Message-Id: <1006732470.2870.0.camel@localhost2.localdomain> Mime-Version: 1.0 X-Mailer: Evolution/1.0.21mdk Date: 10 Feb 2002 10:07:34 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-4VpzvHRSSu/rap7XMdD2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ok. saw something in the archives about logfile size asked within the past 2 days but it really didn't give any clues to this question. As the FAQ states, specifing an alternate logfile size (and also other options) at the time of mkfs, can increase performance. here's a quick layout of my partitions on (using an add-on Promise Ultra100 ide controller card): Filesystem Size Used Avail Use% Mounted on /dev/hde1 576M 69M 507M 12% / /dev/hde5 4.3G 2.3G 2.0G 53% /home /dev/hde6 207M 280k 206M 1% /tmp /dev/hde7 3.0G 2.5G 571M 82% /usr /dev/hde8 787M 84M 704M 11% /var /dev/hdf5 6.2G 2.8G 3.4G 45% /usr/src/RPM /dev/hdg6 16G 14G 3.3G 80% /mnt/win_c2 /dev/hdg5 21G 33M 19G 1% /extra1 /dev/hdf6 3.4G 3.3G 165M 96% /mnt/win_d2 I'm mainly concerned about /dev/hdg5 (/extra1). I'm using it for video capturing and am curious as to optimizing it for write performance. Logfile size recommendations? other options? Since they SGI touches on this in the "howto make an xfs", i'm sure there will be plenty of others asking the same question i am...but with raid & larger hdd's. ;-) --=-4VpzvHRSSu/rap7XMdD2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjwBhLQACgkQZA/JYxAFHWEA2QCfUGgHYur36ORkxzz9aMcdbTpK 4NcAnidQCpKUbsWZsqg51oxIssH4mxs7 =6fh+ -----END PGP SIGNATURE----- --=-4VpzvHRSSu/rap7XMdD2-- From owner-linux-xfs@oss.sgi.com Sun Feb 10 08:29:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AGTX715498 for linux-xfs-outgoing; Sun, 10 Feb 2002 08:29:33 -0800 Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AGTS915476 for ; Sun, 10 Feb 2002 08:29:28 -0800 Message-Id: <200202101629.g1AGTS915476@oss.sgi.com> Received: from there ([144.135.24.81]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GRBPOX00.59W; Mon, 11 Feb 2002 01:29:21 +1000 Received: from CPE-144-137-128-87.qld.bigpond.net.au ([144.137.128.87]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0h 44/160646); 11 Feb 2002 01:29:21 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: , Subject: Re: Can anyone tell me where I set the CONFIG_PAGE_BUF selection?? Date: Mon, 11 Feb 2002 00:08:36 +1000 X-Mailer: KMail [version 1.3.1] References: <000501c1b232$da882930$0264a8c0@jeffw> In-Reply-To: <000501c1b232$da882930$0264a8c0@jeffw> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sounds like you are using an old .config file from a previous kernel? If this is the case you will have to do something like "make old_config." Reciently the page_buffer module has been rolled into the XFS module so there isn't a config option for it anymore. Hope this helps. On Sun, 10 Feb 2002 22:59, you wrote: > I am following the checklist on the "Configuring and installing the XFS > Linux Kernel" and when doing my make xconfig I can not find any > reference to a CONFIG_PAGE_BUF anywhere I have gone looking through all > the menus and have even gone to the trouble of doing a make config via > the text prompts, however I still can't find any reference to it and my > kernel will not compile. The compile dies in the XFS filesystem make > directory. Any help would be appreaciated. BTW: I am using the > 2.4.17-xfs CVS tree downloaded on 2/10/02 at aprox 2am Mountain Time if > that makes any difference. > > Jeff Means > CIO PicoTech > Unix is userfriendly it is just selective of it's users > > > > [[HTML alternate version deleted]] -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Sun Feb 10 08:52:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AGqEf15795 for linux-xfs-outgoing; Sun, 10 Feb 2002 08:52:14 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AGq7915771 for ; Sun, 10 Feb 2002 08:52:08 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA01425 for ; Sun, 10 Feb 2002 07:52:05 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA10613; Sun, 10 Feb 2002 07:51:36 -0800 (PST) Date: Sun, 10 Feb 2002 09:51:35 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Roger cc: Subject: Re: How to tell your Linux XFS Version on your box In-Reply-To: <1006379601.4180.5.camel@localhost2.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10 Feb 2002, Roger wrote: > How can one tell what version of XFS they're running on their box? XFS isn't versioned, per se, except for the full 1.0, 1.0.1, 1.0.2 etc. releases. Everything else is just a snapshot, identifiable by the date you checked it out, or more coarsely, the kernel version. The XFS on-disk format is not changing, so you won't have to worry about "incompatible versions." Whenever a syscall change happens (or something similar) we'll break cleanly on a kernel version. > shouldn't the xfs* tools also have versioning number in them > (ie...bottom of man file or with a --version/-v option ?) Yes, that would be nice. Can you send a patch? > eh, i even looked over a patch for the xfs fs applied to my distros > kernel, and that doens't even show versioning numbers. > > Nor does, > /usr/src/linux/Documentation/filesystems/xfs.txt > contain versioning info. Nope, it's not there. A fine-grained versioning scheme has not been implemented, and is not high on the priority list. -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 10 08:54:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AGsgp15952 for linux-xfs-outgoing; Sun, 10 Feb 2002 08:54:42 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AGsd915929 for ; Sun, 10 Feb 2002 08:54:39 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA01695 for ; Sun, 10 Feb 2002 07:54:38 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA32538; Sun, 10 Feb 2002 07:54:07 -0800 (PST) Date: Sun, 10 Feb 2002 09:54:07 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Roger cc: Subject: Re: Using Bonnie++ on XFS crashes fs/xfs driver? In-Reply-To: <1006634210.2199.5.camel@localhost2.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10 Feb 2002, Roger wrote: > When i attempt to run Bonnie on my xfs filesystem, it crashes 3/4's way > thru on writing the 100MB benchmarking Are you running a kernel from one of the XFS released versions, or a cvs checkout, or from a patch? There were earlier problems with bonnie++, but I was not aware of any currently. -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 10 09:19:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AHJGb19920 for linux-xfs-outgoing; Sun, 10 Feb 2002 09:19:16 -0800 Received: from lucy.physik.tu-cottbus.de (lucy.physik.TU-Cottbus.De [141.43.75.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AHJ8919895 for ; Sun, 10 Feb 2002 09:19:09 -0800 Received: (qmail 178369 invoked from network); 10 Feb 2002 16:19:01 -0000 Received: from strauss.physik.tu-cottbus.de (postfix@141.43.75.28) by lucy.physik.tu-cottbus.de with SMTP; 10 Feb 2002 16:19:01 -0000 Received: by strauss.physik.tu-cottbus.de (Postfix, from userid 7224) id 822CD14896; Sun, 10 Feb 2002 17:22:12 +0100 (CET) Date: Sun, 10 Feb 2002 17:22:12 +0100 To: linux-xfs@oss.sgi.com Subject: Re: Best Logfile size for XFS Message-ID: <20020210162212.GA14270@physik.tu-cottbus.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1006732470.2870.0.camel@localhost2.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1006732470.2870.0.camel@localhost2.localdomain> User-Agent: Mutt/1.3.25i From: george@physik.tu-cottbus.de (Ionut Georgescu) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Well, I don't think you should worry about performance in this case. There's only metadata going into the logfile and considering the number of files you're going to have on that partition (less then 20) you'll hardly have a write into the log. Please correct me if I'm wrong. On the other hand you could play with the realtime option, but I don't know if it's been implemented yet or not. Ionut On Sun, Feb 10, 2002 at 10:07:34AM -0500, Roger wrote: > ok. saw something in the archives about logfile size asked within the > past 2 days but it really didn't give any clues to this question. > > As the FAQ states, specifing an alternate logfile size (and also other > options) at the time of mkfs, can increase performance. > > here's a quick layout of my partitions on (using an add-on Promise > Ultra100 ide controller card): > > Filesystem Size Used Avail Use% Mounted on > /dev/hde1 576M 69M 507M 12% / > /dev/hde5 4.3G 2.3G 2.0G 53% /home > /dev/hde6 207M 280k 206M 1% /tmp > /dev/hde7 3.0G 2.5G 571M 82% /usr > /dev/hde8 787M 84M 704M 11% /var > /dev/hdf5 6.2G 2.8G 3.4G 45% /usr/src/RPM > /dev/hdg6 16G 14G 3.3G 80% /mnt/win_c2 > /dev/hdg5 21G 33M 19G 1% /extra1 > /dev/hdf6 3.4G 3.3G 165M 96% /mnt/win_d2 > > I'm mainly concerned about /dev/hdg5 (/extra1). I'm using it for video > capturing and am curious as to optimizing it for write performance. > > Logfile size recommendations? other options? > > Since they SGI touches on this in the "howto make an xfs", i'm sure > there will be plenty of others asking the same question i am...but with > raid & larger hdd's. ;-) -- *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * Registered Linux User #244479 * * "In Windows you can do everything Microsoft wants you to do; in Unix you * can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Sun Feb 10 10:12:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AIC5a20486 for linux-xfs-outgoing; Sun, 10 Feb 2002 10:12:05 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [195.124.129.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AIBo920462 for ; Sun, 10 Feb 2002 10:11:51 -0800 Received: from warp9.koschikode.com (pD9EB0DEB.dip.t-dialin.net [217.235.13.235]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id A613CF4AD; Sun, 10 Feb 2002 18:11:39 +0100 (CET) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id F0875B1; Sun, 10 Feb 2002 18:11:24 +0100 (CET) Message-ID: <3C66A9B9.20207@koschikode.com> Date: Sun, 10 Feb 2002 18:11:21 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Roger Cc: Christian Zander , linux-xfs@oss.sgi.com Subject: Re: data corruption/loss References: <20011118090353.A17758@chronos> <20011118095940.A6147@wotan.suse.de> <20011118193738.A17920@chronos> <1006376438.4176.1.camel@localhost2.localdomain> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Roger wrote: > AH! i too am experiencing the same exact scenario! > > i've been browsing the FAQ on this including the mailling list archives, > but am having a heck of a time. > > this really looks like something that needs to be address since i'm > seeing this quite often now on my box. (i've been tinkering for the past > week on test scenarios which are causing some crashes..devfs..etc). > > now, i'm loosing config/rc files left and right...over written by '@' > characters etc. actually, it's chocking on me everywhere. > > if you find and hack that provides a solution, please advised. Mount your partitions with -osync. That should do the trick I think. Juri From owner-linux-xfs@oss.sgi.com Sun Feb 10 10:26:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AIQk520721 for linux-xfs-outgoing; Sun, 10 Feb 2002 10:26:46 -0800 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AIQd920699 for ; Sun, 10 Feb 2002 10:26:40 -0800 Received: from user-2inia72.dialup.mindspring.com ([165.121.40.226] helo=waltsathlon.localhost.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16ZxkM-0002aD-00 for linux-xfs@oss.sgi.com; Sun, 10 Feb 2002 12:26:38 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id B09A8E00E15; Sun, 10 Feb 2002 09:25:51 -0800 (PST) Message-ID: <3C66AD1F.3020607@mindspring.com> Date: Sun, 10 Feb 2002 09:25:51 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: elkner@linofee.org Cc: linux-xfs@oss.sgi.com Subject: Re: configure bug ? References: <200202100922.g1A9MqX14612@wh58-307.st.uni-magdeburg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not sure if this helps you out, but if you set DIST_ROOT=/somedirectory/ and then export it prior to make install, it will prepend that dir to your install. Useful for installing the progs to a temp location for rescue disc builds etc... -Walt elkner@linofee.org wrote: > Hi, > > just tried to build xfsprogs-1.3.17.src.tar.gz. For the "usual" user > no problem, but if you want to make your own packages, which are not > debian or redhat, you are out of luck, since your configure does > not obey the --prefix=$proto option :( > > Since setting PREFIX and ROOT_PREFIX env variables did not work either, > I need to replace PKG_.*_DIR values with sed, but IMHO this is quick and > dirty as well. > > Furthermore I consider checking for ${prefix}/[share/]man/man1/man.1.gz > to set HAVE_ZIPPED_MANPAGES is also very dirty because these directories > or the man man page might not exist or not gzipped, but others. > > Thus an configure option e.g. --man={gz|cat|auto} would be nice, which > might be set for compatibility reasons per default to "auto", where the > traditional mechanismen might be used to determine the HAVE_ZIPPED_MANPAGES > value. > > Another bug is related to static builds. With > ./configure --prefix=$PROTO --enable-shared=no --enable-shared-uuid=no > one is out of luck again, since on pass 1 it is compiled static, but than > make builds the dynamic version and overwrites the static binary :((( > > So can you fix the: > --prefix option > gzipped man page stuff and > building static progs > please? > > > Regards, > jens. > From owner-linux-xfs@oss.sgi.com Sun Feb 10 13:18:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ALIS922304 for linux-xfs-outgoing; Sun, 10 Feb 2002 13:18:28 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ALIO922282 for ; Sun, 10 Feb 2002 13:18:25 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id MAA09097 for ; Sun, 10 Feb 2002 12:18:22 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA24028; Mon, 11 Feb 2002 07:17:06 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA35838; Mon, 11 Feb 2002 07:17:05 +1100 (AEDT) Date: Mon, 11 Feb 2002 07:17:05 +1100 From: Nathan Scott To: Roger Cc: linux-xfs@oss.sgi.com Subject: Re: How to tell your Linux XFS Version on your box Message-ID: <20020211071705.A110921@wobbly.melbourne.sgi.com> References: <1006379601.4180.5.camel@localhost2.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1006379601.4180.5.camel@localhost2.localdomain>; from roger@linuxfreemail.com on Sun, Feb 10, 2002 at 09:42:26AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Feb 10, 2002 at 09:42:26AM -0500, Roger wrote: > How can one tell what version of XFS they're running on their box? > > shouldn't the xfs* tools also have versioning number in them > (ie...bottom of man file or with a --version/-v option ?) > The tools do support -V, though this is the userspace package version, not the kernel version. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 10 14:40:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AMe7r23586 for linux-xfs-outgoing; Sun, 10 Feb 2002 14:40:07 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AMdv923561 for ; Sun, 10 Feb 2002 14:39:57 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-239.quicknet.nl [212.58.163.239]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1ALdslb024133; Sun, 10 Feb 2002 22:39:54 +0100 (CET) Message-Id: <4.3.2.7.2.20020210223228.02be0850@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Feb 2002 22:37:43 +0100 To: Roger , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Best Logfile size for XFS In-Reply-To: <1006732470.2870.0.camel@localhost2.localdomain> Mime-Version: 1.0 Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:07 10-2-2002 -0500, Roger wrote: >ef8b47d.jpg Best Logfile size for >XFS.ems<0880.0002>> >Content-Type: text/plain >Content-Transfer-Encoding: quoted-printable > > >*** PGP Signature Status: good >*** Signer: Roger (Invalid) >*** Signed: 26-11-2001 0:54:28 >*** Verified: 10-2-2002 22:31:49 >*** BEGIN PGP VERIFIED MESSAGE *** > >ok. saw something in the archives about logfile size asked within the >past 2 days but it really didn't give any clues to this question. > >As the FAQ states, specifing an alternate logfile size (and also other >options) at the time of mkfs, can increase performance. > >here's a quick layout of my partitions on (using an add-on Promise >Ultra100 ide controller card): > >Filesystem Size Used Avail Use% Mounted on >/dev/hde1 576M 69M 507M 12% / >/dev/hde5 4.3G 2.3G 2.0G 53% /home >/dev/hde6 207M 280k 206M 1% /tmp >/dev/hde7 3.0G 2.5G 571M 82% /usr >/dev/hde8 787M 84M 704M 11% /var >/dev/hdf5 6.2G 2.8G 3.4G 45% /usr/src/RPM >/dev/hdg6 16G 14G 3.3G 80% /mnt/win_c2 >/dev/hdg5 21G 33M 19G 1% /extra1 >/dev/hdf6 3.4G 3.3G 165M 96% /mnt/win_d2 > >I'm mainly concerned about /dev/hdg5 (/extra1). I'm using it for video >capturing and am curious as to optimizing it for write performance. > >Logfile size recommendations? other options? A large logfile size will not help that much. Having a larger log helps a lot when you touch a lot of smaller files many times. If you are writing large files the default log will suffice nicely which is 8MB large afaik. The largest you can go is 32768 == 32 MB. You can also mount with logbufs=4 or 8 which means that more updates are journaled but you lose more of them during a crash. This has the same effect as making the log bigger which means there can be more updates going on at one time. Cheers - -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBPGboJznWBc/r8P2XEQJ6SQCfaE7IINtxQ5aXMg/3ZvwqWZFuxBQAoNcV oN9arYaUALIAKDsxiUE/HRlg =BSpA -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Feb 10 15:45:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ANjPu24293 for linux-xfs-outgoing; Sun, 10 Feb 2002 15:45:25 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ANjI924271 for ; Sun, 10 Feb 2002 15:45:18 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1AMigL08276; Sun, 10 Feb 2002 16:44:42 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: rt_sigsuspend From: Austin Gonyou To: linux-xfs@oss.sgi.com In-Reply-To: <1013298171.32711.30.camel@UberGeek> References: <1013298171.32711.30.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 10 Feb 2002 16:44:41 -0600 Message-Id: <1013381081.16769.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Should I take the "stone silence" on this matter that there is a distinct problem and no-one wishes to speak of it, or rather, there is no problem so why am I bothering to ask? :) Please, if anyone has ANY information, this is very important. On Sat, 2002-02-09 at 17:42, Austin Gonyou wrote: > Woops..That should be "I'd like to ask the SGI XFS team". :) > > Anyway, if anyoone has any info on Java apps with Linux > 2.4.10 having > a problem stopping in rt_sigsuspend, please let me know. We're seeing > this, at least it looks like it, but the only references I've seen are > from 2.2.x days, and pre2.4.x. (2.3.xx). Thanks for any info if you've > seen this. It will help greatly. > > On Fri, 2002-02-08 at 13:30, Austin Gonyou wrote: > > There are some issues around rt_sigsuspend, which I'd like to as the > SGI > > XFS team if they have any insight into if this has been fixed. Ulrich > > Drepper has had some info on this, but it was from more than 2 yr ago. > I > > was curious if there was more recent info on rt_sigsuspend breakage. > > > > Thanks for the time. > > > > > > -- > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin@coremetrics.com > > > > "It is the part of a good shepherd to shear his flock, not to skin > it." > > Latin Proverb > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Sun Feb 10 16:18:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B0I8124779 for linux-xfs-outgoing; Sun, 10 Feb 2002 16:18:08 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B0I5924757 for ; Sun, 10 Feb 2002 16:18:05 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1B0I0xV008632 for ; Sun, 10 Feb 2002 16:18:00 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA15576; Sun, 10 Feb 2002 15:17:28 -0800 (PST) Date: Sun, 10 Feb 2002 17:17:27 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Austin Gonyou cc: Subject: Re: rt_sigsuspend In-Reply-To: <1013381081.16769.1.camel@UberGeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 10 Feb 2002, Austin Gonyou wrote: > Should I take the "stone silence" on this matter that there is a > distinct problem and no-one wishes to speak of it, or rather, there is > no problem so why am I bothering to ask? :) Please, if anyone has ANY > information, this is very important. The silence is probably due to the fact that the question doesn't sound like it has anything to do with XFS for Linux...? -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 10 18:20:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B2KYU25966 for linux-xfs-outgoing; Sun, 10 Feb 2002 18:20:34 -0800 Received: from hotmail.com (f222.pav1.hotmail.com [64.4.31.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B2KR925943 for ; Sun, 10 Feb 2002 18:20:27 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 10 Feb 2002 17:20:22 -0800 Received: from 138.80.69.107 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 11 Feb 2002 01:20:22 GMT X-Originating-IP: [138.80.69.107] From: "vovo99 vovo99" To: linux-xfs@oss.sgi.com Subject: RH7.2 and XFS 1.0.2a grpquota doesn't seem to work. Date: Mon, 11 Feb 2002 01:20:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Feb 2002 01:20:22.0300 (UTC) FILETIME=[46A4D5C0:01C1B29A] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have been attempting to test group quotas on an XFS file system. Individual user quotas seem to work OK, but I have a requirement to impose group quota checking (hardware was paid for by a number of groups). I have a couple of questions: I assume group quotas are enabled in the same manner user quotas are (using edquota) I assume group quotas are reported on in the same manner as user quotas (using repquota). The user quota function appears to work OK. This is a copy of my /etc/fstab. Note that in this example, I am only attempting to test group quotas: LABEL=/ / ext3 defaults 1 1 /dev/sda3 /xfs xfs defaults,grpquota 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/sda2 swap swap defaults 0 0 This is a dump of a quota that I have already enabled: [root@VM root]# edquota -g qtest Disk quotas for group qtest (gid 512): Filesystem blocks soft hard inodes soft hard /dev/sda3 0 25000 30000 0 0 0 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-linux-xfs@oss.sgi.com Sun Feb 10 18:25:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B2PCb26105 for linux-xfs-outgoing; Sun, 10 Feb 2002 18:25:12 -0800 Received: from ente.berdmann.de (frnk-d514e1c1.dsl.mediaWays.net [213.20.225.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B2P9926083 for ; Sun, 10 Feb 2002 18:25:10 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16a5DL-00060m-00; Mon, 11 Feb 2002 02:25:03 +0100 Message-ID: <3C671D6E.3CACDF2A@berdmann.de> Date: Mon, 11 Feb 2002 02:25:02 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: ivanr@sgi.com CC: Linux XFS Mailing List Subject: Re: xfsrestore dumps core on cumulative restore with -B (dirattr.c:945) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > I discovered a bug in xfsrestore 1.1.14 - it dumps core when the last > > level of a cumlative dump is restored using the option "-B" to set mode > > on . of the dumped filesystem. > > I couldn't reproduce the problem here, but judging by your core file, the > following patch should avoid the core dump. I shall have a chat to Tim > (the xfsrestore expert) next week, and see if we can get a better solution. Seems to help. xfsrestore doesn't dump core using your patch. From owner-linux-xfs@oss.sgi.com Sun Feb 10 18:31:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B2VUn26268 for linux-xfs-outgoing; Sun, 10 Feb 2002 18:31:30 -0800 Received: from mrhankey.homeip.net (adsl-64-164-173-115.dsl.lsan03.pacbell.net [64.164.173.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B2V9926244 for ; Sun, 10 Feb 2002 18:31:09 -0800 Received: by mrhankey.homeip.net (Postfix, from userid 501) id 4C3E1325AC5; Sun, 10 Feb 2002 17:31:04 -0800 (PST) Subject: null files and things disapear. From: Bryan B Whitehead To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-3IZMwenSe8+YXtZuR4s/" X-Mailer: Evolution/1.0.11mdk Date: 10 Feb 2002 17:31:04 -0800 Message-Id: <1013391064.2206.33.camel@mrhankey.homeip.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-3IZMwenSe8+YXtZuR4s/ Content-Type: text/plain Content-Transfer-Encoding: 7bit using XFS FS. NFS on XFS FS is heavily used. After reports of this happening from users on some systems I umounted the FS and ran xfs_check. got nothing. but when I ran xfs_repair I had a whole string of things "fixed". I attached the output. This has happened on about 7 different machines. Each are Dell Precision workstations with a min of 512MB ram with some at 2GB. All are Dual CPU rannging from 800mhz Pentium III to 2.2Ghz P4(Xeon)'s. The kernel running is standard mandrake 8.1 kernel. looking through the /var/log/messages the only little chue I can find is this: Feb 10 15:57:55 micro kernel: Start mounting filesystem: sd(8,17) Feb 10 15:57:55 micro kernel: Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) Feb 10 15:57:55 micro kernel: Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) Feb 10 15:57:55 micro kernel: XFS: Filesystem has duplicate UUID - can't mount there is 5 different xfs FS's on the machine. all the FS's were mounted even though the error message: "Filesystem has duplicate UUID - can't mount". It's also anoying it doesn't tell me what device it's talking about. after the xfs_check I get this message: Feb 10 17:26:25 micro kernel: Start mounting filesystem: sd(8,17) Feb 10 17:26:25 micro kernel: Ending clean XFS mount for filesystem: sd(8,17) Is this a know problem that is resolved in a newer version of XFS FS? or is this something new? Any help is good. :) -- Bryan Whitehead SysAdmin - JPL - Interferometry Systems and Technology Phone: 818 354 2903 driver@jpl.nasa.gov --=-3IZMwenSe8+YXtZuR4s/ Content-Disposition: attachment; filename=xfs.txt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad agbno 1481003842 in agfl, agno 0 bad agbno 4480119 in agfl, agno 0 bad agbno 1481003842 in agfl, agno 1 bad agbno 4480119 in agfl, agno 1 bad agbno 1481003842 in agfl, agno 2 bad agbno 4480119 in agfl, agno 2 bad agbno 1481003842 in agfl, agno 3 bad agbno 4480119 in agfl, agno 3 bad agbno 1481003842 in agfl, agno 4 bad agbno 4480119 in agfl, agno 4 bad agbno 1481003842 in agfl, agno 5 bad agbno 4480119 in agfl, agno 5 bad agbno 1481003842 in agfl, agno 6 bad agbno 4480119 in agfl, agno 6 bad agbno 1481003842 in agfl, agno 7 bad agbno 4480119 in agfl, agno 7 bad agbno 1481003842 in agfl, agno 8 bad agbno 4480119 in agfl, agno 8 bad agbno 1481003842 in agfl, agno 9 bad agbno 4480119 in agfl, agno 9 bad agbno 1481003842 in agfl, agno 10 bad agbno 4480119 in agfl, agno 10 bad agbno 1481003842 in agfl, agno 11 bad agbno 4480119 in agfl, agno 11 bad agbno 1481003842 in agfl, agno 12 bad agbno 4480119 in agfl, agno 12 bad agbno 1481003842 in agfl, agno 13 bad agbno 4480119 in agfl, agno 13 bad agbno 1481003842 in agfl, agno 14 bad agbno 4480119 in agfl, agno 14 bad agbno 1481003842 in agfl, agno 15 bad agbno 4480119 in agfl, agno 15 bad agbno 1481003842 in agfl, agno 16 bad agbno 4480119 in agfl, agno 16 bad agbno 1481003842 in agfl, agno 17 bad agbno 4480119 in agfl, agno 17 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno =3D 0 data fork in ino 168 claims free block 4096 - agno =3D 1 data fork in ino 4194479 claims free block 266240 - agno =3D 2 data fork in ino 8435607 claims free block 528384 - agno =3D 3 data fork in ino 12596401 claims free block 790528 - agno =3D 4 data fork in ino 16842038 claims free block 1052672 - agno =3D 5 data fork in ino 20972877 claims free block 1314816 - agno =3D 6 data fork in ino 25165983 claims free block 1576960 - agno =3D 7 data fork in ino 29360294 claims free block 1839104 - agno =3D 8 data fork in ino 33585970 claims free block 2101248 - agno =3D 9 data fork in ino 37780298 claims free block 2363392 - agno =3D 10 data fork in ino 41983581 claims free block 2625536 - agno =3D 11 data fork in ino 46195164 claims free block 2887680 - agno =3D 12 data fork in ino 50375684 claims free block 3149824 - agno =3D 13 data fork in ino 54526093 claims free block 3411968 - agno =3D 14 data fork in ino 58720391 claims free block 3674112 - agno =3D 15 data fork in ino 62914733 claims free block 3936256 - agno =3D 16 data fork in ino 67109053 claims free block 4198400 - agno =3D 17 data fork in ino 71305186 claims free block 4460544 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno =3D 0 - agno =3D 1 - agno =3D 2 - agno =3D 3 - agno =3D 4 - agno =3D 5 - agno =3D 6 - agno =3D 7 - agno =3D 8 - agno =3D 9 - agno =3D 10 - agno =3D 11 - agno =3D 12 - agno =3D 13 - agno =3D 14 - agno =3D 15 - agno =3D 16 - agno =3D 17 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ...=20 - traversal finished ...=20 - traversing all unattached subtrees ...=20 - traversals finished ...=20 - moving disconnected inodes to lost+found ...=20 Phase 7 - verify and correct link counts... done --=-3IZMwenSe8+YXtZuR4s/-- From owner-linux-xfs@oss.sgi.com Sun Feb 10 18:34:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B2YDg26427 for linux-xfs-outgoing; Sun, 10 Feb 2002 18:34:13 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B2Y9926405 for ; Sun, 10 Feb 2002 18:34:09 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA27340 for ; Sun, 10 Feb 2002 17:29:39 -0800 (PST) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25547; Mon, 11 Feb 2002 12:32:47 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA94795; Mon, 11 Feb 2002 12:32:46 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 11 Feb 2002 12:32:46 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: "Bernhard R. Erdmann" cc: Linux XFS Mailing List Subject: Re: xfsrestore dumps core on cumulative restore with -B (dirattr.c:945) In-Reply-To: <3C671D6E.3CACDF2A@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 11 Feb 2002, Bernhard R. Erdmann wrote: > > > I discovered a bug in xfsrestore 1.1.14 - it dumps core when the last > > > level of a cumlative dump is restored using the option "-B" to set mode > > > on . of the dumped filesystem. > > > > I couldn't reproduce the problem here, but judging by your core file, the > > following patch should avoid the core dump. I shall have a chat to Tim > > (the xfsrestore expert) next week, and see if we can get a better solution. > > Seems to help. xfsrestore doesn't dump core using your patch. Good. We're still going to take a look and see why it was core dumping, but I'll check in the patch anyway. So in all other respects, is -B working now as you'd expect it to? Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Feb 10 18:39:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B2d1n26572 for linux-xfs-outgoing; Sun, 10 Feb 2002 18:39:01 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B2ct926550 for ; Sun, 10 Feb 2002 18:38:55 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA04185 for ; Sun, 10 Feb 2002 17:40:08 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25556; Mon, 11 Feb 2002 12:37:37 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA11473; Mon, 11 Feb 2002 12:37:36 +1100 (AEDT) Date: Mon, 11 Feb 2002 12:37:36 +1100 From: Nathan Scott To: vovo99 vovo99 Cc: linux-xfs@oss.sgi.com Subject: Re: RH7.2 and XFS 1.0.2a grpquota doesn't seem to work. Message-ID: <20020211123736.F135802@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vovo99@hotmail.com on Mon, Feb 11, 2002 at 01:20:22AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 11, 2002 at 01:20:22AM +0000, vovo99 vovo99 wrote: > Hi, > > I have been attempting to test group quotas on an XFS file system. > Individual user quotas seem to work OK, but I have a requirement to impose > group quota checking (hardware was paid for by a number of groups). > > I have a couple of questions: > I assume group quotas are enabled in the same manner user quotas are (using > edquota) yes, with -g option (whereas user quota is the default / -u). > I assume group quotas are reported on in the same manner as user quotas > (using repquota). yes, also with -g option (user quota also as above). > The user quota function appears to work OK. > > > This is a copy of my /etc/fstab. Note that in this example, I am only > attempting to test group quotas: > > LABEL=/ / ext3 defaults 1 1 > /dev/sda3 /xfs xfs defaults,grpquota > 1 2 > none /dev/pts devpts gid=5,mode=620 0 0 > none /proc proc defaults 0 0 > none /dev/shm tmpfs defaults 0 0 > /dev/sda2 swap swap defaults 0 0 > > > This is a dump of a quota that I have already enabled: > > [root@VM root]# edquota -g qtest > Disk quotas for group qtest (gid 512): > Filesystem blocks soft hard inodes > soft hard > /dev/sda3 0 25000 30000 0 > 0 0 OK, so what's the problem? Looks like its working... group qtest has some limits set - ah, I can guess - try using "-v" to repquota (by default, repquota wont report users/groups that are not using any space/inodes). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 10 20:42:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B4gm127869 for linux-xfs-outgoing; Sun, 10 Feb 2002 20:42:48 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B4gi927847 for ; Sun, 10 Feb 2002 20:42:44 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1B3gctm025741 for ; Sun, 10 Feb 2002 19:42:38 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA64977 for ; Sun, 10 Feb 2002 21:41:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA67242 for ; Sun, 10 Feb 2002 21:41:23 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1B3fNW11211; Sun, 10 Feb 2002 21:41:23 -0600 Message-Id: <200202110341.g1B3fNW11211@stout.americas.sgi.com> Date: Sun, 10 Feb 2002 21:41:23 -0600 From: Eric Sandeen Subject: TAKE - tweak pagebuf_delalloc_convert Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At the bottom of pagebuf_delalloc_convert there's a test to make sure we really get something out of bmap, sort of a safety valve so that if we were asking for direct allocation, but got back a delayed allocation, we try again. We were testing "flags == PBF_DIRECT" when it should be "flags & PBF_DIRECT" since PBF_WRITE would also be set. If we hit this, it probably means something else has not gone as expected, but it's a safety valve that was "stuck" until this change. Date: Sun Feb 10 19:34:28 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111476a linux/fs/xfs/pagebuf/page_buf_io.c - 1.7 - fix test at bottom of pagebuf_delalloc_convert From owner-linux-xfs@oss.sgi.com Sun Feb 10 22:32:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B6WIT28814 for linux-xfs-outgoing; Sun, 10 Feb 2002 22:32:18 -0800 Received: from tomts17-srv.bellnexxia.net (tomts17.bellnexxia.net [209.226.175.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B6Vx928786 for ; Sun, 10 Feb 2002 22:31:59 -0800 Received: from cr53174a ([64.230.168.40]) by tomts17-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020211053157.JBYA10641.tomts17-srv.bellnexxia.net@cr53174a> for ; Mon, 11 Feb 2002 00:31:57 -0500 Message-ID: <00ac01c1b2b3$341b9ec0$e374fea9@cr53174a> From: "airsearch" To: Subject: asp,erp,oracle,siebel,sap customer lists Date: Sun, 10 Feb 2002 23:16:50 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk About Us This email is to introduce Repharm; a knowledge management company that provides installed customer lists for companies such as Oracle, PeopleSoft, Siebel, etc. Listed below are just a few of the customer lists we have. I have attached a sample of our Siebel installed customer database to show you the fields we include and just some of the contacts available for these companies. Some of the fields we include in our databases are: Company, Street, City, State/Province, ZipCode/Postal Code, Country, Telephone, Url, Sales/Revenue, Total Employees, SIC Code, Primary Industry and Parent Company. Contacts/Titles include: Chief Executive Officer, Chief Financial Officer, Chief Information Officer, Vice President Sales/Marketing, Vice President Human Resources, etc. We also provide Director/Manager level titles as well. We have obtained these lists through ongoing direct mail, fax and telemarketing campaigns, internet research, etc. Dianne Edwards Director, Business Development Repharm Tel: 905-721-8456 Fax: 905-721-1471 Email: repharm1@aol.com These are just a few of the lists we offer: ERP (Enterprise Resource Planning): Baan Epicor JD Edwards Lawson Made2Manage Mapics Marcam Oracle Peoplesoft SAP SSA CRM (Customer Relationship Management): Clarify E.piphany HNC Onyx Pivotal Siebel Vantive Xchange E-business Applications Ariba BMC BroadVision Commerce One Webtrends Middleware/Connectivity/App Servers/ Web Servers: Bea Systems Iona Unisys Operating Systems/Hardware/Software: COMPAQ HP 3000 HP 9000 HP-UX IBM AS/400 IBM OS/390 Lotus Notes Microsoft Sun Microsystems DATABASE: DB2 FileMaker Informix Oracle SQL Sybase SUPPLY CHAIN: Agile i2 Technologies Manugistics QAD Webplan COMMUNICATIONS: ASPs CLECS ISPs E-COMMERCE: Dot Com Directory Consultant Directory Software Directory EXECUTIVE DIRECTORIES: CEO Directory CFO Directory CIO Directory Engineering Human Resources Purchasing Sales/Marketing INDUSTRY SPECIFIC LISTS: Agriculture, Forestry and Fishing Communications Construction Finance, Insurance and Real Estate Manufacturing Mining Public Administration Retail Trade Services Transportation Utilities Wholesale Trade FRONT OFFICE SERVICES: We offer the following Front Office Services: Fax Campaigns Telemarketing Direct Mail Customer Satisfaction Surveys [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Feb 11 00:05:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1B854e29666 for linux-xfs-outgoing; Mon, 11 Feb 2002 00:05:04 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1B84p929642 for ; Mon, 11 Feb 2002 00:04:51 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA10363; Mon, 11 Feb 2002 08:04:17 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA10157; Mon, 11 Feb 2002 08:04:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 1030157306; Mon, 11 Feb 2002 08:04:02 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 9063325835; Mon, 11 Feb 2002 08:04:01 +0100 (CET) Message-ID: <3C676CE1.A00077FF@ch.sauter-bc.com> Date: Mon, 11 Feb 2002 08:04:01 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Bryan B Whitehead Cc: linux-xfs@oss.sgi.com Subject: Re: null files and things disapear. References: <1013391064.2206.33.camel@mrhankey.homeip.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I got data corruption when I used similar configuration some time ago. An easy way was using rpm -Va to check system files and it told me that lot's of files have changed. I did not see this kind of error with the RH 7.2 installer and 2.4.9-* kernel. -Simon Bryan B Whitehead schrieb: > > using XFS FS. > > NFS on XFS FS is heavily used. > > After reports of this happening from users on some systems I umounted > the FS and ran xfs_check. got nothing. but when I ran xfs_repair I had a > whole string of things "fixed". > > I attached the output. > > This has happened on about 7 different machines. Each are Dell Precision > workstations with a min of 512MB ram with some at 2GB. All are Dual CPU > rannging from 800mhz Pentium III to 2.2Ghz P4(Xeon)'s. > > The kernel running is standard mandrake 8.1 kernel. > > looking through the /var/log/messages the only little chue I can find is > this: > Feb 10 15:57:55 micro kernel: Start mounting filesystem: sd(8,17) > Feb 10 15:57:55 micro kernel: Starting XFS recovery on filesystem: > sd(8,17) (dev: 8/17) > Feb 10 15:57:55 micro kernel: Ending XFS recovery on filesystem: > sd(8,17) (dev: 8/17) > Feb 10 15:57:55 micro kernel: XFS: Filesystem has duplicate UUID - can't > mount > > there is 5 different xfs FS's on the machine. all the FS's were mounted > even though the error message: "Filesystem has duplicate UUID - can't > mount". It's also anoying it doesn't tell me what device it's talking > about. > > after the xfs_check I get this message: > Feb 10 17:26:25 micro kernel: Start mounting filesystem: sd(8,17) > Feb 10 17:26:25 micro kernel: Ending clean XFS mount for filesystem: > sd(8,17) > > Is this a know problem that is resolved in a newer version of XFS FS? or > is this something new? > > Any help is good. :) > > -- > Bryan Whitehead > SysAdmin - JPL - Interferometry Systems and Technology > Phone: 818 354 2903 > driver@jpl.nasa.gov > > ------------------------------------------------------------------------ > Name: xfs.txt > xfs.txt Type: Plain Text (text/plain) > Encoding: quoted-printable From owner-linux-xfs@oss.sgi.com Mon Feb 11 03:45:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BBjvo01424 for linux-xfs-outgoing; Mon, 11 Feb 2002 03:45:57 -0800 Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BBjl901401 for ; Mon, 11 Feb 2002 03:45:48 -0800 Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11]) by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id LAA21854; Mon, 11 Feb 2002 11:45:40 +0100 Received: from eigner.com (crusher.ep-ka.de [194.120.231.18]) by ep-ag.com (8.9.3/8.9.3) with ESMTP id LAA26141; Mon, 11 Feb 2002 11:45:40 +0100 (MET) Message-ID: <3C67A0D3.9060803@eigner.com> Date: Mon, 11 Feb 2002 11:45:39 +0100 From: Klaus Strebel Organization: EIGNER User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en, de MIME-Version: 1.0 To: "Stephenson, Dale" CC: "'linux-xfs@oss.sgi.com'" , "'linux-lvm@sistina.com'" Subject: Re: Oops unmounting snapshot of xfs filesystem References: <2D0AFEFEE711D611923E009027D39F2B02F08F@cdserv.meridian-data.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephenson, Dale wrote: > I have been running into an oops when umounting the snapshot of an xfs > filesystem, or following the umount. For instance, a umount followed by an > lvremove will oops in the lvremove, while a mount/umount/mount/umount > sequence will oops on the second or third umount. > > What does seem consistent is the error message logged on each umount. Here > are the messages from a mount/umount sequence: > > <4> Feb 7 11:20:00 kernel: Mounting filesystem "lvm(58,1)" in no-recovery > mode. Filesystem will be inconsistent. > <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write for readonly LV > /dev/volgr0/lvol1 > <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write for readonly LV > /dev/volgr0/lvol1 > <4> Feb 7 11:20:02 kernel: I/O error in filesystem ("lvm(58,1)") meta-data > dev 0x3a01 block 0xa00020 > <4> Feb 7 11:20:02 kernel: ("xlog_iodone") error 5 buf count 1024 > <4> Feb 7 11:20:02 kernel: xfs_force_shutdown(lvm(58,1),0x2) called from > line 939 of file xfs_log.c. Return address = 0xc01b3cbc > <4> Feb 7 11:20:02 kernel: Log I/O Error Detected. Shutting down > filesystem: lvm(58,1) > <4> Feb 7 11:20:02 kernel: Please umount the filesystem, and rectify the > problem(s) > > I've attached the oops (run through ksymoops) from this particular umount. > The snapshot is mounted ro,nouuid,norecovery. The source of the snapshot > contains an unmounted xfs filesystem, which was unmounted at the time of > snapshot creation. There has been no intentional I/O activity to the > snapshot, either. > > It looks to me like xfs is trying to flush something to disk on the umount, > even though the filesystem is read only and no recovery. I would not have > expected this. Is it correct behavior? > > I made the snapshot writeable, but kept the mount options the same. I was > able to mount/umount many times without oops, I/O errors, or > xfs_force_shutdown. > > I did notice similar behavior when a full snapshot returns an I/O error -- > xfs_force_shutdown, with an oops following soon thereafter. > > System details: > Celeron with 512 MB of RAM and WD 45GB harddrives. > 128 MB swap, one vg consisting of a one-drive RAID 0. > Kernel 2.4.16 with 12/14/01 xfs CVS. > LVM CVS of 1/21/02 (functionally identical to 1.0.2, I believe). > LVM's linux-2.4.11-VFS-lock.patch. > xfs_fs_freeze() patch posted by Eric Sandeen. > Anselm Kruis' writable snapshot patch. Had the same, disappeared when compiled the kernel with gcc-2.91.66 ! Seems to be a compiler issue. Ciao Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@eigner.com EIGNER - Precision Lifecycle Management - From owner-linux-xfs@oss.sgi.com Mon Feb 11 04:01:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BC14701787 for linux-xfs-outgoing; Mon, 11 Feb 2002 04:01:04 -0800 Received: from a.mx.spoiled.org (babel.spoiled.org [217.13.197.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BC0w901760 for ; Mon, 11 Feb 2002 04:00:59 -0800 Received: by a.mx.spoiled.org (Postfix, from userid 8) id 7186711961; Mon, 11 Feb 2002 12:00:56 +0100 (CET) From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: repairing / Date: Mon, 11 Feb 2002 11:59:50 +0100 Organization: spoiled dot org Lines: 28 Distribution: local Message-ID: References: <1013195057.544.4.camel@granite> <4.3.2.7.2.20020208201315.02c59de0@pop.xs4all.nl> Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.14-xfs (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > At 13:04 8-2-2002 -0600, Hollis Blanchard wrote: >>Per the thread at >>http://marc.theaimsgroup.com/?l=linux-xfs&m=100754969025805&w=2 , >>*please* add a note to the XFS FAQ. It took me a while to discover that >>what I need to do is simply not possible without an alternate root >>device. I think that's very important to point out. > Makes sense. I will mention something like this and the GRUB boot support. maybe adding a link to my little miniroot system at http://people.spoiled.org/tgr/unix/miniroot/ would be good - it helped me already a few times for repairing or moving xfs root filesystems, is easy to setup, adapt and use (i even made one for the serial console) and maybe worth a look as somekind of online-rescue disk ... only requirement: /boot should be on an extra fs (best would be ext2 which should be no problem because a /boot of say 64 or 128mb is checked very fast and it might even be mounted ro) t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Mon Feb 11 05:31:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BDVti05765 for linux-xfs-outgoing; Mon, 11 Feb 2002 05:31:55 -0800 Received: from mail.gmx.net (sproxy.gmx.de [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BDVW905741 for ; Mon, 11 Feb 2002 05:31:32 -0800 Received: (qmail 12078 invoked by uid 0); 11 Feb 2002 12:31:23 -0000 Received: from pec-89-32.tnt6.b2.uunet.de (HELO 127.0.0.1) (149.225.89.32) by mail.gmx.net (mp020-rz3) with SMTP; 11 Feb 2002 12:31:23 -0000 Date: Mon, 11 Feb 2002 13:31:06 +0100 From: Andreas Piesk X-Mailer: The Bat! (v1.53d) Personal Reply-To: Andreas Piesk Organization: private X-Priority: 3 (Normal) Message-ID: <6053616045.20020211133106@gmx.net> To: xfs ML Subject: PATCH proposal: attr MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------58CD2317857846" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ------------58CD2317857846 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hiho, this is a patch for attr. detail: - provides the ability to hande more than one file like chacl - changes the error messages to look like the ones from chacl i introduced a new command line parameter "-c". if set, attr continues with the next file if an error occured. it's disabled by default. ciao -ap -- Andreas Piesk a.piesk@gmx.net PGP-Fingerprint: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 ------------58CD2317857846 Content-Type: application/octet-stream; name="attr-1.1.4-multifile.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attr-1.1.4-multifile.patch" ZGlmZiAtUHVyIGF0dHItMS4xLjQvYXR0ci9hdHRyLmMgYXR0ci0xLjEuNC5t b2QvYXR0ci9hdHRyLmMKLS0tIGF0dHItMS4xLjQvYXR0ci9hdHRyLmMJV2Vk IEphbiAxNiAxNzo1MzoxMSAyMDAyCisrKyBhdHRyLTEuMS40Lm1vZC9hdHRy L2F0dHIuYwlNb24gRmViIDExIDEyOjQ1OjI2IDIwMDIKQEAgLTY5LDcgKzY5 LDcgQEAKIHsKIAljaGFyICphdHRybmFtZSwgKmF0dHJ2YWx1ZSwgKmZpbGVu YW1lLCAqYnVmZmVyOwogCWludCBhdHRybGVuZ3RoOwotCWludCBvcGZsYWcs IGNoLCBlcnJvciwgZm9sbG93LCB2ZXJib3NlLCByb290ZmxhZywgaTsKKwlp bnQgb3BmbGFnLCBjaCwgZXJyb3IsIGZvbGxvdywgdmVyYm9zZSwgcm9vdGZs YWcsIGksIGVycm9yY29udDsKIAlhdHRybGlzdF90ICphbGlzdDsKIAlhdHRy bGlzdF9lbnRfdCAqYWVwOwogCWF0dHJsaXN0X2N1cnNvcl90IGN1cnNvcjsK QEAgLTgwLDkgKzgwLDkgQEAKIAkgKiBQaWNrIHVwIGFuZCB2YWxpZGF0ZSB0 aGUgYXJndW1lbnRzLgogCSAqLwogCXZlcmJvc2UgPSAxOwotCWZvbGxvdyA9 IG9wZmxhZyA9IHJvb3RmbGFnID0gMDsKKwlmb2xsb3cgPSBvcGZsYWcgPSBy b290ZmxhZyA9IGVycm9yY29udCA9IDA7CiAJYXR0cm5hbWUgPSBhdHRydmFs dWUgPSBOVUxMOwotCXdoaWxlICgoY2ggPSBnZXRvcHQoYXJnYywgYXJndiwg InM6VjpnOnI6bHFMUiIpKSAhPSBFT0YpIHsKKwl3aGlsZSAoKGNoID0gZ2V0 b3B0KGFyZ2MsIGFyZ3YsICJzOlY6ZzpyOmxxTFJjIikpICE9IEVPRikgewog CQlzd2l0Y2ggKGNoKSB7CiAJCWNhc2UgJ3MnOgogCQkJaWYgKChvcGZsYWcg IT0gMCkgJiYgKG9wZmxhZyAhPSBTRVRPUCkpIHsKQEAgLTEzNywxMzIgKzEz NywxNDQgQEAKIAkJY2FzZSAncSc6CiAJCQl2ZXJib3NlID0gMDsKIAkJCWJy ZWFrOworCQljYXNlICdjJzoKKwkJCWVycm9yY29udCA9IDE7CisJCQlicmVh azsKIAkJZGVmYXVsdDoKIAkJCWZwcmludGYoc3RkZXJyLCAiVW5yZWNvZ25p emVkIG9wdGlvbjogJWNcbiIsIChjaGFyKWNoKTsKIAkJCXVzYWdlKCk7CiAJ CQlicmVhazsKIAkJfQogCX0KLQlpZiAob3B0aW5kICE9IGFyZ2MtMSkgewor CWlmIChvcHRpbmQgPT0gYXJnYykgewogCQlmcHJpbnRmKHN0ZGVyciwgIkEg ZmlsZW5hbWUgdG8gb3BlcmF0ZSBvbiBpcyByZXF1aXJlZFxuIik7CiAJCXVz YWdlKCk7CiAJfQotCWZpbGVuYW1lID0gYXJndltvcHRpbmRdOwogCi0JLyoK LQkgKiBCcmVhayBvdXQgaW50byBvcHRpb24tc3BlY2lmaWMgcHJvY2Vzc2lu Zy4KLQkgKi8KLQlzd2l0Y2ggKG9wZmxhZykgewotCWNhc2UgU0VUT1A6Ci0J CWlmIChhdHRydmFsdWUgPT0gTlVMTCkgeworCWZvciggOyBvcHRpbmQgPCBh cmdjOyBvcHRpbmQrKyApIHsKKworCQlmaWxlbmFtZSA9IGFyZ3Zbb3B0aW5k XTsKKworCQkvKgorCQkgKiBCcmVhayBvdXQgaW50byBvcHRpb24tc3BlY2lm aWMgcHJvY2Vzc2luZy4KKwkJICovCisJCXN3aXRjaCAob3BmbGFnKSB7CisJ CWNhc2UgU0VUT1A6CisJCQlpZiAoYXR0cnZhbHVlID09IE5VTEwpIHsKKwkJ CQlhdHRydmFsdWUgPSBtYWxsb2MoQVRUUl9NQVhfVkFMVUVMRU4pOworCQkJ CWlmIChhdHRydmFsdWUgPT0gTlVMTCkgeworCQkJCQlwZXJyb3IoIm1hbGxv YyIpOworCQkJCQkvKiBlcnJvciBpcyBjcml0aWNhbCAsIG5vIGNvbnRpbnVl ICovCisJCQkJCWV4aXQoMSk7CisJCQkJfQorCQkJCWF0dHJsZW5ndGggPQor CQkJCQlmcmVhZChhdHRydmFsdWUsIDEsIEFUVFJfTUFYX1ZBTFVFTEVOLCBz dGRpbik7CisJCQl9IGVsc2UgeworCQkJCWF0dHJsZW5ndGggPSBzdHJsZW4o YXR0cnZhbHVlKTsKKwkJCX0KKwkJCWVycm9yID0gYXR0cl9zZXQoZmlsZW5h bWUsIGF0dHJuYW1lLCBhdHRydmFsdWUsCisJCQkJCQkgICBhdHRybGVuZ3Ro LAorCQkJCQkJICAgKCFmb2xsb3cgPyBBVFRSX0RPTlRGT0xMT1cgOiAwKSB8 CisJCQkJCQkgICAocm9vdGZsYWcgPyBBVFRSX1JPT1QgOiAwKSk7CisJCQlp ZiAoZXJyb3IpIHsKKwkJCQlmcHJpbnRmKHN0ZGVyciwgIiVzOiBDb3VsZCBu b3Qgc2V0IFwiJXNcIiBmb3IgJXM6ICVzXG4iLAorCQkJCQlwcm9nbmFtZSwg YXR0cm5hbWUsIGZpbGVuYW1lLCBzdHJlcnJvcihlcnJubykpOworCQkJCWlm KCBlcnJvcmNvbnQgKQorCQkJCQljb250aW51ZTsKKwkJCQlleGl0KDEpOwor CQkJfQorCQkJaWYgKHZlcmJvc2UpIHsKKwkJCQlwcmludGYoIkF0dHJpYnV0 ZSBcIiVzXCIgc2V0IHRvIGEgJWQgYnl0ZSB2YWx1ZSAiCisJCQkJICAgICAg ICJmb3IgJXM6XG4iLAorCQkJICAgICAgIAkJYXR0cm5hbWUsIGF0dHJsZW5n dGgsIGZpbGVuYW1lKTsKKwkJCQlmd3JpdGUoYXR0cnZhbHVlLCAxLCBhdHRy bGVuZ3RoLCBzdGRvdXQpOworCQkJCXByaW50ZigiXG4iKTsKKwkJCX0KKwkJ CWJyZWFrOworCisJCWNhc2UgR0VUT1A6CiAJCQlhdHRydmFsdWUgPSBtYWxs b2MoQVRUUl9NQVhfVkFMVUVMRU4pOwogCQkJaWYgKGF0dHJ2YWx1ZSA9PSBO VUxMKSB7CiAJCQkJcGVycm9yKCJtYWxsb2MiKTsKKwkJCQkvKiBlcnJvciBp cyBjcml0aWNhbCwgbm8gY29udGludWUgKi8KIAkJCQlleGl0KDEpOwogCQkJ fQotCQkJYXR0cmxlbmd0aCA9Ci0JCQkJZnJlYWQoYXR0cnZhbHVlLCAxLCBB VFRSX01BWF9WQUxVRUxFTiwgc3RkaW4pOwotCQl9IGVsc2UgewotCQkJYXR0 cmxlbmd0aCA9IHN0cmxlbihhdHRydmFsdWUpOwotCQl9Ci0JCWVycm9yID0g YXR0cl9zZXQoZmlsZW5hbWUsIGF0dHJuYW1lLCBhdHRydmFsdWUsCi0JCQkJ CSAgIGF0dHJsZW5ndGgsCi0JCQkJCSAgICghZm9sbG93ID8gQVRUUl9ET05U Rk9MTE9XIDogMCkgfAotCQkJCQkgICAocm9vdGZsYWcgPyBBVFRSX1JPT1Qg OiAwKSk7Ci0JCWlmIChlcnJvcikgewotCQkJcGVycm9yKCJhdHRyX3NldCIp OwotCQkJZnByaW50ZihzdGRlcnIsICJDb3VsZCBub3Qgc2V0IFwiJXNcIiBm b3IgJXNcbiIsCi0JCQkJCWF0dHJuYW1lLCBmaWxlbmFtZSk7Ci0JCQlleGl0 KDEpOwotCQl9Ci0JCWlmICh2ZXJib3NlKSB7Ci0JCQlwcmludGYoIkF0dHJp YnV0ZSBcIiVzXCIgc2V0IHRvIGEgJWQgYnl0ZSB2YWx1ZSAiCi0JCQkgICAg ICAgImZvciAlczpcbiIsCi0JCQkgICAgICAgYXR0cm5hbWUsIGF0dHJsZW5n dGgsIGZpbGVuYW1lKTsKKwkJCWF0dHJsZW5ndGggPSBBVFRSX01BWF9WQUxV RUxFTjsKKwkJCWVycm9yID0gYXR0cl9nZXQoZmlsZW5hbWUsIGF0dHJuYW1l LCBhdHRydmFsdWUsCisJCQkJCQkgICAmYXR0cmxlbmd0aCwKKwkJCQkJCSAg ICghZm9sbG93ID8gQVRUUl9ET05URk9MTE9XIDogMCkgfAorCQkJCQkJICAg KHJvb3RmbGFnID8gQVRUUl9ST09UIDogMCkpOworCQkJaWYgKGVycm9yKSB7 CisJCQkJZnByaW50ZihzdGRlcnIsICIlczogQ291bGQgbm90IGdldCBcIiVz XCIgZm9yICVzOiAlc1xuIiwKKwkJCQkJCXByb2duYW1lLCBhdHRybmFtZSwg ZmlsZW5hbWUsIHN0cmVycm9yKGVycm5vKSk7CisJCQkJaWYoIGVycm9yY29u dCApCisJCQkJCWNvbnRpbnVlOworCQkJCWV4aXQoMSk7CisJCQl9CisJCQlp ZiAodmVyYm9zZSkgeworCQkJCXByaW50ZigiQXR0cmlidXRlIFwiJXNcIiBo YWQgYSAlZCBieXRlIHZhbHVlIGZvciAlczpcbiIsCisJCQkJCWF0dHJuYW1l LCBhdHRybGVuZ3RoLCBmaWxlbmFtZSk7CisJCQl9CiAJCQlmd3JpdGUoYXR0 cnZhbHVlLCAxLCBhdHRybGVuZ3RoLCBzdGRvdXQpOwogCQkJcHJpbnRmKCJc biIpOwotCQl9Ci0JCWJyZWFrOwotCi0JY2FzZSBHRVRPUDoKLQkJYXR0cnZh bHVlID0gbWFsbG9jKEFUVFJfTUFYX1ZBTFVFTEVOKTsKLQkJaWYgKGF0dHJ2 YWx1ZSA9PSBOVUxMKSB7Ci0JCQlwZXJyb3IoIm1hbGxvYyIpOwotCQkJZXhp dCgxKTsKLQkJfQotCQlhdHRybGVuZ3RoID0gQVRUUl9NQVhfVkFMVUVMRU47 Ci0JCWVycm9yID0gYXR0cl9nZXQoZmlsZW5hbWUsIGF0dHJuYW1lLCBhdHRy dmFsdWUsCi0JCQkJCSAgICZhdHRybGVuZ3RoLAotCQkJCQkgICAoIWZvbGxv dyA/IEFUVFJfRE9OVEZPTExPVyA6IDApIHwKLQkJCQkJICAgKHJvb3RmbGFn ID8gQVRUUl9ST09UIDogMCkpOwotCQlpZiAoZXJyb3IpIHsKLQkJCXBlcnJv cigiYXR0cl9nZXQiKTsKLQkJCWZwcmludGYoc3RkZXJyLCAiQ291bGQgbm90 IGdldCBcIiVzXCIgZm9yICVzXG4iLAotCQkJCQlhdHRybmFtZSwgZmlsZW5h bWUpOwotCQkJZXhpdCgxKTsKLQkJfQotCQlpZiAodmVyYm9zZSkgewotCQkJ cHJpbnRmKCJBdHRyaWJ1dGUgXCIlc1wiIGhhZCBhICVkIGJ5dGUgdmFsdWUg Zm9yICVzOlxuIiwKLQkJCQlhdHRybmFtZSwgYXR0cmxlbmd0aCwgZmlsZW5h bWUpOwotCQl9Ci0JCWZ3cml0ZShhdHRydmFsdWUsIDEsIGF0dHJsZW5ndGgs IHN0ZG91dCk7Ci0JCWlmICh2ZXJib3NlKSB7Ci0JCQlwcmludGYoIlxuIik7 Ci0JCX0KLQkJYnJlYWs7Ci0KLQljYXNlIFJFTU9WRU9QOgotCQllcnJvciA9 IGF0dHJfcmVtb3ZlKGZpbGVuYW1lLCBhdHRybmFtZSwKLQkJCQkJICAgICAg KCFmb2xsb3cgPyBBVFRSX0RPTlRGT0xMT1cgOiAwKSB8Ci0JCQkJCSAgICAg IChyb290ZmxhZyA/IEFUVFJfUk9PVCA6IDApKTsKLQkJaWYgKGVycm9yKSB7 Ci0JCQlwZXJyb3IoImF0dHJfcmVtb3ZlIik7Ci0JCQlmcHJpbnRmKHN0ZGVy ciwgIkNvdWxkIG5vdCByZW1vdmUgXCIlc1wiIGZvciAlc1xuIiwKLQkJCQkJ YXR0cm5hbWUsIGZpbGVuYW1lKTsKLQkJCWV4aXQoMSk7Ci0JCX0KLQkJYnJl YWs7Ci0KLQljYXNlIExJU1RPUDoKLQkJaWYgKChidWZmZXIgPSBtYWxsb2Mo QVRUUl9NQVhfVkFMVUVMRU4pKSA9PSBOVUxMKSB7Ci0JCQlwZXJyb3IoIm1h bGxvYyIpOwotCQkJZXhpdCgxKTsKLQkJfQotCi0JCW1lbXNldCgoY2hhciAq KSZjdXJzb3IsIDAsIHNpemVvZihjdXJzb3IpKTsKKwkJCWJyZWFrOwogCi0J CWRvIHsKLQkJCWVycm9yID0gYXR0cl9saXN0KGZpbGVuYW1lLCBidWZmZXIs IEFUVFJfTUFYX1ZBTFVFTEVOLAotCQkJCQkgICAgKCFmb2xsb3cgPyBBVFRS X0RPTlRGT0xMT1cgOiAwKSB8Ci0JCQkJCSAgICAocm9vdGZsYWcgPyBBVFRS X1JPT1QgOiAwKSwKLQkJCQkJICAgICZjdXJzb3IpOworCQljYXNlIFJFTU9W RU9QOgorCQkJZXJyb3IgPSBhdHRyX3JlbW92ZShmaWxlbmFtZSwgYXR0cm5h bWUsCisJCQkJCQkgICAgICAoIWZvbGxvdyA/IEFUVFJfRE9OVEZPTExPVyA6 IDApIHwKKwkJCQkJCSAgICAgIChyb290ZmxhZyA/IEFUVFJfUk9PVCA6IDAp KTsKIAkJCWlmIChlcnJvcikgewotCQkJCXBlcnJvcigiYXR0cl9saXN0Iik7 Ci0JCQkJZnByaW50ZihzdGRlcnIsICJDb3VsZCBub3QgbGlzdCBhdHRyaWJ1 dGVzIGZvciAlc1xuIiwKLQkJCQkJCWZpbGVuYW1lKTsKKwkJCQlmcHJpbnRm KHN0ZGVyciwgIiVzOiBDb3VsZCBub3QgcmVtb3ZlIFwiJXNcIiBmb3IgJXM6 ICVzXG4iLAorCQkJCQkJcHJvZ25hbWUsIGF0dHJuYW1lLCBmaWxlbmFtZSwg c3RyZXJyb3IoZXJybm8pKTsKKwkJCQlpZiggZXJyb3Jjb250ICkKKwkJCQkJ Y29udGludWU7CiAJCQkJZXhpdCgxKTsKIAkJCX0KKwkJCWJyZWFrOwogCi0J CQlhbGlzdCA9IChhdHRybGlzdF90ICopYnVmZmVyOwotCQkJZm9yIChpID0g MDsgaSA8IGFsaXN0LT5hbF9jb3VudDsgaSsrKSB7Ci0JCQkJYWVwID0gKGF0 dHJsaXN0X2VudF90ICopJmJ1ZmZlclsgYWxpc3QtPmFsX29mZnNldFtpXSBd OwotCQkJCWlmICh2ZXJib3NlKSB7Ci0JCQkJCXByaW50ZigiQXR0cmlidXRl IFwiJXNcIiBoYXMgYSAlZCBieXRlIHZhbHVlIGZvciAlc1xuIiwKLQkJCQkJ CQkgICAgYWVwLT5hX25hbWUsCi0JCQkJCQkJICAgIGFlcC0+YV92YWx1ZWxl biwKLQkJCQkJCQkgICAgZmlsZW5hbWUpOwotCQkJCX0gZWxzZSB7IAotCQkJ CQlwcmludGYoIiVzXG4iLCBhZXAtPmFfbmFtZSk7Ci0JCQkJfQorCQljYXNl IExJU1RPUDoKKwkJCWlmICgoYnVmZmVyID0gbWFsbG9jKEFUVFJfTUFYX1ZB TFVFTEVOKSkgPT0gTlVMTCkgeworCQkJCXBlcnJvcigibWFsbG9jIik7CisJ CQkJLyogZXJyb3IgaXMgY3JpdGljYWwsIG5vIGNvbnRpbnVlICovCisJCQkJ ZXhpdCgxKTsKIAkJCX0KLQkJfSB3aGlsZSAoYWxpc3QtPmFsX21vcmUpOwot CQlicmVhazsKIAotCWRlZmF1bHQ6Ci0JCWZwcmludGYoc3RkZXJyLAotCQkJ IkF0IGxlYXN0IG9uZSBvZiAtcywgLWcsIC1yLCBvciAtbCBpcyByZXF1aXJl ZFxuIik7Ci0JCXVzYWdlKCk7Ci0JCWJyZWFrOworCQkJbWVtc2V0KChjaGFy ICopJmN1cnNvciwgMCwgc2l6ZW9mKGN1cnNvcikpOworCisJCQlkbyB7CisJ CQkJZXJyb3IgPSBhdHRyX2xpc3QoZmlsZW5hbWUsIGJ1ZmZlciwgQVRUUl9N QVhfVkFMVUVMRU4sCisJCQkJCQkgICAgKCFmb2xsb3cgPyBBVFRSX0RPTlRG T0xMT1cgOiAwKSB8CisJCQkJCQkgICAgKHJvb3RmbGFnID8gQVRUUl9ST09U IDogMCksCisJCQkJCQkgICAgJmN1cnNvcik7CisJCQkJaWYgKGVycm9yKSB7 CisJCQkJCWZwcmludGYoc3RkZXJyLCAiJXM6IENvdWxkIG5vdCBsaXN0IGF0 dHJpYnV0ZXMgZm9yICVzOiAlc1xuIiwKKwkJCQkJCQlwcm9nbmFtZSwgZmls ZW5hbWUsIHN0cmVycm9yKGVycm5vKSk7CisJCQkJCWlmKCBlcnJvcmNvbnQg KQorCQkJCQkJY29udGludWU7CisJCQkJCWV4aXQoMSk7CisJCQkJfQorCisJ CQkJYWxpc3QgPSAoYXR0cmxpc3RfdCAqKWJ1ZmZlcjsKKwkJCQlmb3IgKGkg PSAwOyBpIDwgYWxpc3QtPmFsX2NvdW50OyBpKyspIHsKKwkJCQkJYWVwID0g KGF0dHJsaXN0X2VudF90ICopJmJ1ZmZlclsgYWxpc3QtPmFsX29mZnNldFtp XSBdOworCQkJCQlpZiAodmVyYm9zZSkgeworCQkJCQkJcHJpbnRmKCJBdHRy aWJ1dGUgXCIlc1wiIGhhcyBhICVkIGJ5dGUgdmFsdWUgZm9yICVzXG4iLAor CQkJCQkJCQkgICAgYWVwLT5hX25hbWUsCisJCQkJCQkJCSAgICBhZXAtPmFf dmFsdWVsZW4sCisJCQkJCQkJCSAgICBmaWxlbmFtZSk7CisJCQkJCX0gZWxz ZSB7IAorCQkJCQkJcHJpbnRmKCIlc1xuIiwgYWVwLT5hX25hbWUpOworCQkJ CQl9CisJCQkJfQorCQkJfSB3aGlsZSAoKGFsaXN0LT5hbF9tb3JlKSAmJiAh ZXJyb3IpOworCQkJYnJlYWs7CisKKwkJZGVmYXVsdDoKKwkJCWZwcmludGYo c3RkZXJyLAorCQkJCSJBdCBsZWFzdCBvbmUgb2YgLXMsIC1nLCAtciwgb3Ig LWwgaXMgcmVxdWlyZWRcbiIpOworCQkJdXNhZ2UoKTsKKwkJCWJyZWFrOwor CQl9CiAJfQogCiAJcmV0dXJuKDApOwo= ------------58CD2317857846-- From owner-linux-xfs@oss.sgi.com Mon Feb 11 05:41:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BDfvd06060 for linux-xfs-outgoing; Mon, 11 Feb 2002 05:41:57 -0800 Received: from trouble.picotech.net (trouble.picotech.net [216.17.224.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BDfs906036 for ; Mon, 11 Feb 2002 05:41:54 -0800 Received: (qmail 1992 invoked by uid 514); 11 Feb 2002 12:44:03 -0000 Received: from unknown (HELO jeffw) (192.168.100.2) by trouble.picotech.net with SMTP; 11 Feb 2002 12:44:03 -0000 Reply-To: From: "Jeffrey D. Means" To: "'Linux-xfs'" Subject: Question about the ISO image on the FTP site Date: Mon, 11 Feb 2002 05:44:41 -0700 Organization: PicoTech Message-ID: <000801c1b2f9$e3651d20$0264a8c0@jeffw> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was wondering if that image is for booting the computer or just installing XFS?? I need a boot disk that will boot my kernel but if there is a way to do this with a cd I would like that even better. Jeff Means CIO PicoTech Unix is userfriendly it is just selective of it's users [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Feb 11 06:21:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BEL7F08905 for linux-xfs-outgoing; Mon, 11 Feb 2002 06:21:07 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BEKS908878 for ; Mon, 11 Feb 2002 06:20:29 -0800 Received: by monkeyiq.dnsalias.org id g1BDM0Z16215 ; Mon, 11 Feb 2002 23:22:00 +1000 Date: Mon, 11 Feb 2002 23:22:00 +1000 Message-Id: <200202111322.g1BDM0Z16215@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com cc: monkeyiq@users.sourceforge.net Subject: xfs_bmap & XML patch From: monkeyiq MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-=-= Hi, With this little change one can use $ ./xfs_bmap -x ~/tmp/holes So they can use XSLT to provide a Gtk+/HTML extent viewer quite simply. I'll probably play with some stuff for a nice extent viewer interface too soon. I was trying to abstract out the code doing i = ioctl(fd, XFS_IOC_GETBMAPX, map); but ran into the old problem of no exceptions in C. I have worked around such problems in the past though it makes the code more complex than a dump msg and exit() solution. I'll think more about a getExtents() function in the next days and see if I can find an elegant solution to it. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=xfsprogs-xml.patch Content-Description: xml out for xfs_bmap ? config.status ? .census ? configure ? autom4te.cache ? config.log ? bmap/.libs ? bmap/xfs_bmap ? db/.libs ? db/xfs_db ? doc/CHANGES.gz ? freeze/.libs ? freeze/xfs_freeze ? fsck/.libs ? fsck/fsck.xfs ? growfs/.libs ? growfs/xfs_growfs ? imap/.libs ? imap/xfs_imap ? include/builddefs ? include/platform_defs.h ? libdisk/.libs ? libdisk/md.lo ? libdisk/fstype.lo ? libdisk/lvm.lo ? libdisk/mountinfo.lo ? libdisk/xvm.lo ? libdisk/drivers.lo ? libdisk/libdisk.la ? libdisk/pttype.lo ? libhandle/libhandle.la ? libhandle/.libs ? libhandle/jdm.lo ? libhandle/handle.lo ? libxfs/trans.lo ? libxfs/logitem.lo ? libxfs/.libs ? libxfs/rdwr.lo ? libxfs/xfs_dir2_node.lo ? libxfs/xfs_dir_leaf.lo ? libxfs/xfs_rtalloc.lo ? libxfs/libxfs.la ? libxfs/xfs_bmap_btree.lo ? libxfs/xfs_alloc_btree.lo ? libxfs/xfs_mount.lo ? libxfs/xfs_ialloc.lo ? libxfs/xfs_ialloc_btree.lo ? libxfs/xfs_btree.lo ? libxfs/xfs_da_btree.lo ? libxfs/xfs_bmap.lo ? libxfs/xfs_dir2_data.lo ? libxfs/xfs_attr_leaf.lo ? libxfs/xfs_alloc.lo ? libxfs/xfs_bit.lo ? libxfs/xfs_dir.lo ? libxfs/xfs_inode.lo ? libxfs/xfs_dir2_leaf.lo ? libxfs/xfs_dir2.lo ? libxfs/util.lo ? libxfs/xfs_dir2_block.lo ? libxfs/xfs_trans.lo ? libxfs/xfs_rtbit.lo ? libxfs/init.lo ? libxfs/xfs_dir2_sf.lo ? libxlog/.libs ? libxlog/xfs_log_recover.lo ? libxlog/util.lo ? libxlog/libxlog.la ? logprint/.libs ? logprint/xfs_logprint ? mkfile/.libs ? mkfile/xfs_mkfile ? mkfs/.libs ? mkfs/fstyp ? mkfs/maxtrres.h ? mkfs/maxtrres ? mkfs/mkfs.xfs ? repair/.libs ? repair/xfs_repair ? rtcp/.libs ? rtcp/xfs_rtcp Index: configure.in =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/configure.in,v retrieving revision 1.12 diff -u -3 -p -r1.12 configure.in --- configure.in 2001/09/19 05:03:59 1.12 +++ configure.in 2002/02/11 14:13:04 @@ -232,6 +232,15 @@ dnl doc directory pkg_doc_dir=${prefix}/share/doc/${pkg_name} AC_SUBST(pkg_doc_dir) +dnl see if some XML options are desired. +AC_ARG_WITH(xmloutput, + [ --with-xmloutput Enable XML output options], + [ + xmloutput_build=" -DENABLE_XML " + AC_SUBST(xmloutput_build) + echo enabled xml output + ]) + dnl dnl output files Index: bmap/xfs_bmap.c =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/bmap/xfs_bmap.c,v retrieving revision 1.5 diff -u -3 -p -r1.5 xfs_bmap.c --- bmap/xfs_bmap.c 2002/01/11 04:01:45 1.5 +++ bmap/xfs_bmap.c 2002/02/11 14:13:04 @@ -43,6 +43,7 @@ int aflag = 0; /* Attribute fork. */ int lflag = 0; /* list number of blocks with each extent */ int nflag = 0; /* number of extents specified */ int vflag = 0; /* Verbose output */ +int xmlflag = 0; /* output in XML */ int bmv_iflags = 0; /* Input flags for XFS_IOC_GETBMAPX */ char *progname; @@ -50,15 +51,69 @@ int dofile(char *); __off64_t file_size(int fd, char * fname); int numlen(__off64_t); +static void +perform_xml_output( struct getbmapx* map, __off64_t bbperag ) +{ +#ifdef ENABLE_XML + int i=0; + + printf("\n"); + printf("\n"); + + for (i = 0; i < map->bmv_entries; i++) + { + if (map[i + 1].bmv_block == -1) + { + printf(" \n"); + printf("\n"); + } + else + { + + int agno = map[i + 1].bmv_block / bbperag; + int agoff = map[i + 1].bmv_block - (agno * bbperag); + + printf(" \n"); + printf("\n"); + } + } + + printf("\n"); +#endif +} + int main(int argc, char **argv) { char *fname; int i = 0; int option; - +#ifdef ENABLE_XML + const char* getopt_options = "adln:pxvV"; +#else + const char* getopt_options = "adln:pvV"; +#endif + progname = basename(argv[0]); - while ((option = getopt(argc, argv, "adln:pvV")) != EOF) { + while ((option = getopt(argc, argv, getopt_options)) != EOF) + { switch (option) { case 'a': bmv_iflags |= BMV_IF_ATTRFORK; @@ -84,10 +139,19 @@ main(int argc, char **argv) case 'V': printf("%s version %s\n", progname, VERSION); break; +#ifdef ENABLE_XML + case 'x': + xmlflag++; + break; +#endif + default: - fprintf(stderr, "Usage: %s [-adlpV] [-n nx] file...\n", - progname); - exit(1); +#ifdef ENABLE_XML + fprintf(stderr, "Usage: %s [-adlpxV] [-n nx] file...\n", progname); +#else + fprintf(stderr, "Usage: %s [-adlpV] [-n nx] file...\n", progname); +#endif + exit(1); } } if (aflag) @@ -130,7 +194,12 @@ dofile(char *fname) int map_size; int loop = 0; xfs_fsop_geom_t fsgeo; - + /* extra info for xml or verbose output */ + int agno=0; + __off64_t agoff=0, bbperag=0; + int foff_w=0, boff_w=0, aoff_w=0, tot_w=0, agno_w=0; + char rbuf[32], bbuf[32], abuf[32]; + fd = open(fname, O_RDONLY); if (fd < 0) { fprintf(stderr, "%s: cannot open \"%s\": %s\n", @@ -146,7 +215,7 @@ dofile(char *fname) return 1; } - if (vflag) { + if (vflag || xmlflag) { if (ioctl(fd, XFS_IOC_FSGEOMETRY, &fsgeo) < 0) { fprintf(stderr, "%s: can't get geometry [\"%s\"]: %s\n", progname, fname, strerror(errno)); @@ -287,7 +356,29 @@ dofile(char *fname) } } close(fd); - printf("%s:\n", fname); + + /* Get some more info for verbose output */ + if( vflag || xmlflag ) + { +#define MINRANGE_WIDTH 16 +#define MINAG_WIDTH 2 +#define MINTOT_WIDTH 5 +#define max(a,b) (a > b ? a : b) + + foff_w = boff_w = aoff_w = MINRANGE_WIDTH; + tot_w = MINTOT_WIDTH; + bbperag = (__off64_t)fsgeo.agblocks * + (__off64_t)fsgeo.blocksize / BBSIZE; + } + + + if( xmlflag ) + { + perform_xml_output( map, bbperag ); + exit(0); + } + + printf("%s:\n", fname); if (!vflag) { for (i = 0; i < map->bmv_entries; i++) { printf("\t%d: [%lld..%lld]: ", i, @@ -314,19 +405,6 @@ dofile(char *fname) * extent: [startoffset..endoffset]: startblock..endblock \ * ag# (agoffset..agendoffset) totalbbs */ -#define MINRANGE_WIDTH 16 -#define MINAG_WIDTH 2 -#define MINTOT_WIDTH 5 -#define max(a,b) (a > b ? a : b) - int agno; - __off64_t agoff, bbperag; - int foff_w, boff_w, aoff_w, tot_w, agno_w; - char rbuf[32], bbuf[32], abuf[32]; - - foff_w = boff_w = aoff_w = MINRANGE_WIDTH; - tot_w = MINTOT_WIDTH; - bbperag = (__off64_t)fsgeo.agblocks * - (__off64_t)fsgeo.blocksize / BBSIZE; /* * Go through the extents and figure out the width Index: include/builddefs.in =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/include/builddefs.in,v retrieving revision 1.18 diff -u -3 -p -r1.18 builddefs.in --- include/builddefs.in 2001/10/17 11:00:32 1.18 +++ include/builddefs.in 2002/02/11 14:13:04 @@ -91,7 +91,8 @@ BUILDRULES = $(TOPDIR)/include/buildrule CFLAGS += -O1 $(OPTIMIZER) $(DEBUG) -funsigned-char -Wall $(LCFLAGS) \ -I$(TOPDIR)/include '-DVERSION="$(PKG_VERSION)"' -D_GNU_SOURCE \ - -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 + -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 \ + @xmloutput_build@ LDFLAGS = $(LLDFLAGS) LDLIBS = $(LLDLIBS) $(MALLOCLIB) --=-=-= -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ --=-=-=-- From owner-linux-xfs@oss.sgi.com Mon Feb 11 07:22:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BFMJN10689 for linux-xfs-outgoing; Mon, 11 Feb 2002 07:22:19 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BFMC910667 for ; Mon, 11 Feb 2002 07:22:12 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1BFM7xV024951 for ; Mon, 11 Feb 2002 07:22:07 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA66452; Mon, 11 Feb 2002 08:20:51 -0600 (CST) Received: from sgi.com (VVClf3j9gmVoVdIoFpncbECw/9c0/eVR@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA09332; Mon, 11 Feb 2002 08:20:50 -0600 (CST) Message-ID: <3C67D368.2090209@sgi.com> Date: Mon, 11 Feb 2002 08:21:28 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Roger CC: linux-xfs@oss.sgi.com Subject: Re: Best Logfile size for XFS References: <1006732470.2870.0.camel@localhost2.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Roger wrote: >ok. saw something in the archives about logfile size asked within the >past 2 days but it really didn't give any clues to this question. > >As the FAQ states, specifing an alternate logfile size (and also other >options) at the time of mkfs, can increase performance. > >here's a quick layout of my partitions on (using an add-on Promise >Ultra100 ide controller card): > >Filesystem Size Used Avail Use% Mounted on >/dev/hde1 576M 69M 507M 12% / >/dev/hde5 4.3G 2.3G 2.0G 53% /home >/dev/hde6 207M 280k 206M 1% /tmp >/dev/hde7 3.0G 2.5G 571M 82% /usr >/dev/hde8 787M 84M 704M 11% /var >/dev/hdf5 6.2G 2.8G 3.4G 45% /usr/src/RPM >/dev/hdg6 16G 14G 3.3G 80% /mnt/win_c2 >/dev/hdg5 21G 33M 19G 1% /extra1 >/dev/hdf6 3.4G 3.3G 165M 96% /mnt/win_d2 > >I'm mainly concerned about /dev/hdg5 (/extra1). I'm using it for video >capturing and am curious as to optimizing it for write performance. > >Logfile size recommendations? other options? > >Since they SGI touches on this in the "howto make an xfs", i'm sure >there will be plenty of others asking the same question i am...but with >raid & larger hdd's. ;-) > There is no hard and fast rule for this, a larger log is only really useful if you are doing metadata intensive operations over extended periods of time and we have found that more iclogs are just as useful (the logbugs=8 mount option). I cannot remember right now, but mkfs may automatically make the log bigger on large devices, of course large may be past the 2 Tbyte limit on linux. For write performance a larger log will not help, more iclogs might, but not by much. The other thing to consider with larger logs is that recovery after a crash can take longer. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 11 07:36:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BFaX511059 for linux-xfs-outgoing; Mon, 11 Feb 2002 07:36:33 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BFYH911010 for ; Mon, 11 Feb 2002 07:34:18 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA1690533 for ; Mon, 11 Feb 2002 15:33:58 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA72673; Mon, 11 Feb 2002 06:32:50 -0800 (PST) Date: Mon, 11 Feb 2002 08:32:50 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Jeffrey D. Means" cc: "'Linux-xfs'" Subject: Re: Question about the ISO image on the FTP site In-Reply-To: <000801c1b2f9$e3651d20$0264a8c0@jeffw> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's primarily designed to install xfs, but to do that, you boot from it. It can also act as a rescue cd by typing "linux rescue" at the boot prompt when it first comes up. -Eric On Mon, 11 Feb 2002, Jeffrey D. Means wrote: > I was wondering if that image is for booting the computer or just > installing XFS?? I need a boot disk that will boot my kernel but if > there is a way to do this with a cd I would like that even better. > From owner-linux-xfs@oss.sgi.com Mon Feb 11 07:48:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BFm3611261 for linux-xfs-outgoing; Mon, 11 Feb 2002 07:48:03 -0800 Received: from smile.asf.ro ([213.154.137.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BFlv911237 for ; Mon, 11 Feb 2002 07:47:59 -0800 Received: from asf.ro (vali.localnet [192.168.16.63]) by smile.asf.ro (8.11.0/8.11.0) with ESMTP id g1BEepG01753 for ; Mon, 11 Feb 2002 16:40:52 +0200 Message-ID: <3C67D96D.1030301@asf.ro> Date: Mon, 11 Feb 2002 16:47:09 +0200 From: Vali Dragnuta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and > 2gb files Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there an issue regarding files bigger than 2gb on XFS ? I'm running kernel 2.4.17 and XFS and on two different machines I get filesystem corruption as soon as I create a file larger than 2 GB This happens both on mandrake 8.0 and RH7.2 From owner-linux-xfs@oss.sgi.com Mon Feb 11 08:00:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BG0u311724 for linux-xfs-outgoing; Mon, 11 Feb 2002 08:00:56 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BG0o911691 for ; Mon, 11 Feb 2002 08:00:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08349 for ; Mon, 11 Feb 2002 07:02:04 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA66235; Mon, 11 Feb 2002 08:59:34 -0600 (CST) Received: from sgi.com (HIaNnWZyi67Am9utjRuiROYbQvi77Der@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA33601; Mon, 11 Feb 2002 08:59:34 -0600 (CST) Message-ID: <3C67DC7C.4010107@sgi.com> Date: Mon, 11 Feb 2002 09:00:12 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Vali Dragnuta CC: linux-xfs@oss.sgi.com Subject: Re: XFS and > 2gb files References: <3C67D96D.1030301@asf.ro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vali Dragnuta wrote: > > > Is there an issue regarding files bigger than 2gb on XFS ? > > > I'm running kernel 2.4.17 and XFS and on two different machines I > get filesystem corruption as soon as I > create a file larger than 2 GB > This happens both on mandrake 8.0 and RH7.2 > Where and when did you get your kernel source from? Steve From owner-linux-xfs@oss.sgi.com Mon Feb 11 08:23:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BGN6s12658 for linux-xfs-outgoing; Mon, 11 Feb 2002 08:23:06 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BGN2912636 for ; Mon, 11 Feb 2002 08:23:03 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16aIDU-0006V3-00 for ; Mon, 11 Feb 2002 16:18:04 +0100 Date: Mon, 11 Feb 2002 16:18:04 +0100 To: linux-xfs@oss.sgi.com Subject: Re: XFS and > 2gb files Message-ID: <20020211151804.GG994@muaddib.localnet> References: <3C67D96D.1030301@asf.ro> <3C67DC7C.4010107@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C67DC7C.4010107@sgi.com> User-Agent: Mutt/1.3.27i From: Ingo Juergensmann Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 11, 2002 at 09:00:12AM -0600, Stephen Lord wrote: > > Is there an issue regarding files bigger than 2gb on XFS ? > >I'm running kernel 2.4.17 and XFS and on two different machines I > >get filesystem corruption as soon as I > >create a file larger than 2 GB > >This happens both on mandrake 8.0 and RH7.2 > Where and when did you get your kernel source from? No problems here with >2 GB files with 2.4.17-xfs last weekend, neither on my gateway nor on my laptop, when copying a 3.4 GB file in order to migrate to external log, which failed for another reason. But no problem with >2 GB files, though... -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Mon Feb 11 09:52:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BHqOq14420 for linux-xfs-outgoing; Mon, 11 Feb 2002 09:52:24 -0800 Received: from studserv.uni-leipzig.de (studserv.uni-leipzig.de [139.18.1.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BHqI914395 for ; Mon, 11 Feb 2002 09:52:18 -0800 Received: from alex (port-213-20-128-54.reverse.qdsl-home.de [213.20.128.54]) by studserv.uni-leipzig.de (8.9.3/8.9.3) with ESMTP id RAA18028 for ; Mon, 11 Feb 2002 17:52:15 +0100 From: "mai99bxd" To: Subject: best kernel version to use with XFS+LVM+MD Date: Mon, 11 Feb 2002 17:52:12 +0100 Message-ID: <002201c1b31c$75c02f30$0b00a8c0@alex> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I'm going to plan a fileserver with 2 45Gb IDE disks in soft RAID1 and 4 100GB IDE disks in soft RAID5. I would take the RAID1 for system and the RAID5 for storage. The 300GB RADI5 space should be divided by LVM into some XFS filesystems. I also use NFS and Samba over the XFS. Which kernel version seems to be stable in realation with XFS, LVM and MD? Some 2.4.x kernels had problems in the past. thank ALEX http://alexk.homeip.net [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Feb 11 09:53:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BHriO15251 for linux-xfs-outgoing; Mon, 11 Feb 2002 09:53:44 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BHrc915217 for ; Mon, 11 Feb 2002 09:53:38 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1BHrYxV001057 for ; Mon, 11 Feb 2002 09:53:34 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA69707; Mon, 11 Feb 2002 10:52:18 -0600 (CST) Received: from sgi.com (npC+bGslyDx+5ql0udoyMpSuuPPvAYX0@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA44429; Mon, 11 Feb 2002 10:52:17 -0600 (CST) Message-ID: <3C67F6E7.8000908@sgi.com> Date: Mon, 11 Feb 2002 10:52:55 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Duffy CC: Linux Mailing List Subject: Re: kernel panic (corruption of task struct) References: <1013222059.2794.35.camel@tduffy-lnx.afara.com> <3C657C70.9050300@sgi.com> <1013313171.26982.4.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Duffy wrote: >On Sat, 2002-02-09 at 11:45, Stephen Lord wrote: > >>Stack overflow looks likely here. I don't know of any in xfs, but xfs in >>combination >>with other things might cause problems. We had one case in LVM >>snapshotting where >>LVM was putting large chunks of stuff on the stack. That code should not >>be in your >>kernel though, unless you added it. >> > >This is a stock xfs kernel rpm 1.0.2 from sgi. No recompile, no addons >-- we are not using lvm on this machine, anyways. Any suggestions on >how to figure out what is going on here? Cause this is on a critical >machine and having it go down every few days is not good... > >If it goes down again, is there anything I can do in kdb to help narrow >down where this is happening? > >Thanks! > >-tduffy > Should this actually be stack overflow, the tricky part is that the crash usually happens long after the overflow - when the corrupted task struct is accessed. The one of these we found in LVM took a long time to locate. All I can suggest right now is updating your kernel. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 11 11:01:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BJ1SQ08243 for linux-xfs-outgoing; Mon, 11 Feb 2002 11:01:28 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BJ0g908146 for ; Mon, 11 Feb 2002 11:00:42 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1782379 for ; Mon, 11 Feb 2002 19:00:39 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA70725 for ; Mon, 11 Feb 2002 11:59:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA41579 for ; Mon, 11 Feb 2002 11:59:23 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1BHwY113556; Mon, 11 Feb 2002 11:58:34 -0600 Message-Id: <200202111758.g1BHwY113556@jen.americas.sgi.com> Date: Mon, 11 Feb 2002 11:58:34 -0600 Subject: TAKE - merge up to 2.5.4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Makes kernel preemptable Date: Mon Feb 11 09:34:00 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:111492a linux/include/linux/err.h - 1.1 linux/Documentation/preempt-locking.txt - 1.1 linux/include/asm-sparc64/thread_info.h - 1.1 linux/net/sunrpc/svcauth.c - 1.4 linux/net/socket.c - 1.31 linux/mm/slab.c - 1.31 linux/mm/mremap.c - 1.27 linux/mm/mprotect.c - 1.22 linux/mm/filemap.c - 1.109 linux/kernel/time.c - 1.8 linux/kernel/sys.c - 1.27 linux/kernel/signal.c - 1.26 linux/kernel/sched.c - 1.58 linux/kernel/module.c - 1.26 linux/kernel/ksyms.c - 1.133 linux/kernel/fork.c - 1.48 linux/kernel/exit.c - 1.40 linux/include/net/sock.h - 1.28 linux/include/net/scm.h - 1.4 linux/include/net/neighbour.h - 1.8 linux/include/linux/vmalloc.h - 1.15 linux/include/linux/timex.h - 1.5 linux/include/linux/time.h - 1.6 linux/include/linux/swap.h - 1.53 linux/include/linux/sunrpc/xdr.h - 1.7 linux/include/linux/sunrpc/svc.h - 1.5 linux/include/linux/sound.h - 1.4 linux/include/linux/smp_lock.h - 1.5 linux/include/linux/smp.h - 1.10 linux/include/linux/smb_fs_i.h - 1.8 linux/include/linux/smb.h - 1.6 linux/include/linux/slab.h - 1.22 linux/include/linux/skbuff.h - 1.23 linux/include/linux/sched.h - 1.61 linux/include/linux/quotaops.h - 1.13 linux/include/linux/msdos_fs_i.h - 1.6 linux/include/linux/mm.h - 1.78 linux/include/linux/lp.h - 1.8 linux/include/linux/iso_fs_i.h - 1.5 linux/include/linux/inet.h - 1.4 linux/include/linux/in.h - 1.5 linux/include/linux/fs.h - 1.149 linux/include/linux/file.h - 1.14 linux/include/linux/capability.h - 1.11 linux/include/linux/ax25.h - 1.4 linux/include/linux/affs_fs_i.h - 1.6 linux/include/asm-sparc64/unistd.h - 1.17 linux/include/asm-sparc64/uaccess.h - 1.7 linux/include/asm-sparc64/ttable.h - 1.9 linux/include/asm-sparc64/system.h - 1.16 linux/include/asm-sparc64/spinlock.h - 1.11 linux/include/asm-sparc64/softirq.h - 1.10 linux/include/asm-sparc64/smplock.h - 1.6 linux/include/asm-sparc64/smp.h - 1.13 linux/include/asm-sparc64/ptrace.h - 1.3 linux/include/asm-sparc64/processor.h - 1.23 linux/include/asm-sparc64/pgtable.h - 1.30 linux/include/asm-sparc64/page.h - 1.13 linux/include/asm-sparc64/mmu_context.h - 1.16 linux/include/asm-sparc64/hardirq.h - 1.14 linux/include/asm-sparc64/fpumacro.h - 1.3 linux/include/asm-sparc64/elf.h - 1.12 linux/include/asm-sparc64/delay.h - 1.8 linux/include/asm-sparc64/current.h - 1.3 linux/include/asm-sparc64/checksum.h - 1.8 linux/include/asm-sparc64/a.out.h - 1.5 linux/include/asm-sparc/unistd.h - 1.15 linux/include/asm-sparc/siginfo.h - 1.9 linux/include/asm-sparc/checksum.h - 1.6 linux/include/asm-i386/uaccess.h - 1.15 linux/include/asm-i386/spinlock.h - 1.23 linux/include/asm-i386/softirq.h - 1.15 linux/include/asm-i386/smplock.h - 1.13 linux/include/asm-i386/processor.h - 1.32 linux/include/asm-i386/hardirq.h - 1.17 linux/fs/umsdos/rdir.c - 1.15 linux/fs/umsdos/namei.c - 1.13 linux/fs/umsdos/ioctl.c - 1.9 linux/fs/umsdos/inode.c - 1.23 linux/fs/umsdos/emd.c - 1.10 linux/fs/umsdos/dir.c - 1.19 linux/fs/ufs/truncate.c - 1.15 linux/fs/ufs/super.c - 1.26 linux/fs/ufs/namei.c - 1.13 linux/fs/ufs/inode.c - 1.21 linux/fs/ufs/ialloc.c - 1.13 linux/fs/ufs/file.c - 1.11 linux/fs/ufs/dir.c - 1.15 linux/fs/ufs/cylinder.c - 1.6 linux/fs/ufs/balloc.c - 1.13 linux/fs/stat.c - 1.23 linux/fs/smbfs/sock.c - 1.11 linux/fs/smbfs/ioctl.c - 1.9 linux/fs/smbfs/inode.c - 1.29 linux/fs/smbfs/file.c - 1.26 linux/fs/smbfs/dir.c - 1.17 linux/fs/smbfs/cache.c - 1.13 linux/fs/select.c - 1.19 linux/fs/readdir.c - 1.12 linux/fs/qnx4/namei.c - 1.12 linux/fs/qnx4/fsync.c - 1.9 linux/fs/qnx4/file.c - 1.10 linux/fs/qnx4/bitmap.c - 1.11 linux/fs/proc/root.c - 1.26 linux/fs/proc/proc_tty.c - 1.7 linux/fs/proc/proc_devtree.c - 1.8 linux/fs/proc/kmsg.c - 1.8 linux/fs/proc/inode.c - 1.18 linux/fs/proc/generic.c - 1.26 linux/fs/proc/base.c - 1.33 linux/fs/proc/array.c - 1.37 linux/fs/pipe.c - 1.26 linux/fs/nfsd/vfs.c - 1.44 linux/fs/nfsd/stats.c - 1.8 linux/fs/nfsd/nfsxdr.c - 1.14 linux/fs/nfsd/nfssvc.c - 1.18 linux/fs/nfsd/nfsproc.c - 1.21 linux/fs/nfsd/nfsfh.c - 1.34 linux/fs/nfsd/nfsctl.c - 1.25 linux/fs/nfsd/nfscache.c - 1.9 linux/fs/nfsd/nfs3xdr.c - 1.24 linux/fs/nfsd/nfs3proc.c - 1.11 linux/fs/nfsd/export.c - 1.25 linux/fs/nfs/symlink.c - 1.15 linux/fs/nfs/read.c - 1.30 linux/fs/nfs/proc.c - 1.12 linux/fs/nfs/nfsroot.c - 1.12 linux/fs/nfs/nfs3xdr.c - 1.8 linux/fs/nfs/nfs2xdr.c - 1.11 linux/fs/nfs/inode.c - 1.38 linux/fs/nfs/file.c - 1.29 linux/fs/nfs/dir.c - 1.33 linux/fs/ncpfs/symlink.c - 1.14 linux/fs/ncpfs/sock.c - 1.11 linux/fs/ncpfs/mmap.c - 1.16 linux/fs/ncpfs/ioctl.c - 1.16 linux/fs/ncpfs/inode.c - 1.26 linux/fs/ncpfs/file.c - 1.19 linux/fs/ncpfs/dir.c - 1.26 linux/fs/msdos/namei.c - 1.25 linux/fs/locks.c - 1.22 linux/fs/lockd/svcsubs.c - 1.9 linux/fs/lockd/svcshare.c - 1.5 linux/fs/lockd/svcproc.c - 1.9 linux/fs/lockd/svclock.c - 1.14 linux/fs/lockd/lockd_syms.c - 1.6 linux/fs/lockd/clntlock.c - 1.11 linux/fs/isofs/rock.c - 1.19 linux/fs/isofs/namei.c - 1.9 linux/fs/isofs/inode.c - 1.33 linux/fs/isofs/dir.c - 1.13 linux/fs/ioctl.c - 1.12 linux/fs/filesystems.c - 1.19 linux/fs/file_table.c - 1.18 linux/fs/fifo.c - 1.15 linux/fs/fat/inode.c - 1.36 linux/fs/fat/file.c - 1.19 linux/fs/fat/dir.c - 1.17 linux/fs/ext2/ioctl.c - 1.10 linux/fs/ext2/inode.c - 1.41 linux/fs/ext2/file.c - 1.19 linux/fs/ext2/balloc.c - 1.17 linux/fs/exec.c - 1.52 linux/fs/dquot.c - 1.48 linux/fs/devices.c - 1.19 linux/fs/coda/upcall.c - 1.16 linux/fs/coda/sysctl.c - 1.15 linux/fs/coda/symlink.c - 1.13 linux/fs/coda/psdev.c - 1.21 linux/fs/coda/pioctl.c - 1.13 linux/fs/coda/file.c - 1.18 linux/fs/coda/dir.c - 1.21 linux/fs/coda/coda_linux.c - 1.8 linux/fs/coda/cache.c - 1.11 linux/fs/buffer.c - 1.110 linux/fs/binfmt_script.c - 1.13 linux/fs/binfmt_elf.c - 1.38 linux/fs/binfmt_aout.c - 1.25 linux/fs/bad_inode.c - 1.10 linux/fs/autofs/waitq.c - 1.5 linux/fs/autofs/root.c - 1.16 linux/fs/autofs/autofs_i.h - 1.10 linux/fs/attr.c - 1.13 linux/fs/affs/super.c - 1.20 linux/fs/affs/namei.c - 1.15 linux/fs/affs/inode.c - 1.17 linux/fs/affs/file.c - 1.24 linux/fs/affs/bitmap.c - 1.8 linux/fs/affs/amigaffs.c - 1.11 linux/fs/adfs/super.c - 1.18 linux/fs/adfs/inode.c - 1.22 linux/fs/adfs/file.c - 1.12 linux/fs/adfs/dir.c - 1.15 linux/drivers/zorro/proc.c - 1.13 linux/drivers/usb/usb.c - 1.68 linux/drivers/sound/opl3sa2.c - 1.14 linux/drivers/scsi/aha1542.c - 1.23 linux/drivers/sbus/char/sunmouse.c - 1.14 linux/drivers/sbus/char/sunkbd.c - 1.19 linux/drivers/net/eepro100.c - 1.38 linux/drivers/net/bsd_comp.c - 1.9 linux/drivers/isdn/hisax/elsa.c - 1.17 linux/drivers/isdn/Makefile - 1.10 linux/drivers/char/random.c - 1.25 linux/arch/sparc64/solaris/timod.c - 1.19 linux/arch/sparc64/solaris/socksys.c - 1.16 linux/arch/sparc64/solaris/socket.c - 1.9 linux/arch/sparc64/solaris/misc.c - 1.22 linux/arch/sparc64/solaris/ioctl.c - 1.12 linux/arch/sparc64/solaris/fs.c - 1.17 linux/arch/sparc64/solaris/entry64.S - 1.4 linux/arch/sparc64/mm/ultra.S - 1.25 linux/arch/sparc64/mm/init.c - 1.39 linux/arch/sparc64/mm/fault.c - 1.20 linux/arch/sparc64/math-emu/math.c - 1.7 linux/arch/sparc64/lib/checksum.S - 1.5 linux/arch/sparc64/lib/blockops.S - 1.16 linux/arch/sparc64/lib/VISsave.S - 1.5 linux/arch/sparc64/lib/VIScsum.S - 1.5 linux/arch/sparc64/lib/VIScopy.S - 1.8 linux/arch/sparc64/kernel/winfixup.S - 1.5 linux/arch/sparc64/kernel/unaligned.c - 1.8 linux/arch/sparc64/kernel/ttable.S - 1.13 linux/arch/sparc64/kernel/traps.c - 1.18 linux/arch/sparc64/kernel/trampoline.S - 1.10 linux/arch/sparc64/kernel/systbls.S - 1.23 linux/arch/sparc64/kernel/sys_sunos32.c - 1.35 linux/arch/sparc64/kernel/sys_sparc32.c - 1.42 linux/arch/sparc64/kernel/sys_sparc.c - 1.23 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.39 linux/arch/sparc64/kernel/smp.c - 1.38 linux/arch/sparc64/kernel/signal32.c - 1.20 linux/arch/sparc64/kernel/signal.c - 1.18 linux/arch/sparc64/kernel/setup.c - 1.26 linux/arch/sparc64/kernel/rtrap.S - 1.14 linux/arch/sparc64/kernel/ptrace.c - 1.15 linux/arch/sparc64/kernel/process.c - 1.31 linux/arch/sparc64/kernel/itlb_base.S - 1.7 linux/arch/sparc64/kernel/init_task.c - 1.8 linux/arch/sparc64/kernel/head.S - 1.15 linux/arch/sparc64/kernel/etrap.S - 1.7 linux/arch/sparc64/kernel/entry.S - 1.20 linux/arch/sparc64/kernel/check_asm.sh - 1.7 linux/arch/sparc64/kernel/binfmt_elf32.c - 1.7 linux/arch/sparc64/kernel/binfmt_aout32.c - 1.17 linux/arch/sparc64/kernel/Makefile - 1.21 linux/arch/sparc64/defconfig - 1.60 linux/arch/sparc64/config.in - 1.51 linux/arch/sparc64/Makefile - 1.16 linux/arch/sparc/kernel/systbls.S - 1.20 linux/arch/sparc/kernel/sys_sunos.c - 1.34 linux/arch/sparc/kernel/signal.c - 1.21 linux/arch/i386/kernel/traps.c - 1.47 linux/arch/i386/kernel/smp.c - 1.41 linux/arch/i386/kernel/process.c - 1.44 linux/arch/i386/kernel/init_task.c - 1.9 linux/arch/i386/kernel/entry.S - 1.47 linux/arch/i386/defconfig - 1.97 linux/arch/i386/config.in - 1.72 linux/arch/alpha/defconfig - 1.22 linux/Makefile - 1.184 linux/MAINTAINERS - 1.95 linux/CREDITS - 1.72 linux/include/linux/efs_fs.h - 1.8 linux/fs/hpfs/inode.c - 1.16 linux/fs/hpfs/hpfs_fn.h - 1.16 linux/fs/hpfs/file.c - 1.18 linux/fs/hpfs/dir.c - 1.11 linux/fs/efs/inode.c - 1.10 linux/drivers/usb/acm.c - 1.46 linux/fs/file.c - 1.9 linux/drivers/char/sx.c - 1.23 linux/drivers/char/generic_serial.c - 1.13 linux/include/asm-i386/hw_irq.h - 1.24 linux/drivers/isdn/hisax/gazel.c - 1.12 linux/arch/i386/kernel/semaphore.c - 1.18 linux/arch/sparc64/kernel/pci_psycho.c - 1.26 linux/arch/sparc64/kernel/pci_common.c - 1.16 linux/drivers/pcmcia/cardbus.c - 1.20 linux/fs/udf/symlink.c - 1.14 linux/include/linux/spinlock.h - 1.13 linux/include/linux/highmem.h - 1.18 linux/include/asm-i386/highmem.h - 1.9 linux/include/linux/bfs_fs_i.h - 1.5 linux/fs/proc/proc_misc.c - 1.31 linux/fs/bfs/dir.c - 1.17 linux/include/asm-i386/pgalloc.h - 1.15 linux/include/asm-sparc64/sfp-machine.h - 1.3 linux/drivers/net/aironet4500_proc.c - 1.10 linux/drivers/char/agp/agpgart_be.c - 1.31 linux/include/asm-sparc64/pgalloc.h - 1.17 linux/drivers/usb/scanner.c - 1.30 linux/drivers/telephony/phonedev.c - 1.9 linux/drivers/usb/devio.c - 1.27 linux/drivers/usb/inode.c - 1.21 linux/include/asm-i386/io_apic.h - 1.6 linux/fs/autofs4/autofs_i.h - 1.8 linux/fs/autofs4/waitq.c - 1.6 linux/fs/autofs4/root.c - 1.12 linux/drivers/usb/usb-uhci.c - 1.39 linux/drivers/usb/usb-ohci.c - 1.36 linux/fs/adfs/dir_f.c - 1.6 linux/fs/adfs/dir_fplus.c - 1.5 linux/fs/devfs/base.c - 1.32 linux/fs/lockd/svc4proc.c - 1.5 linux/include/linux/brlock.h - 1.6 linux/drivers/usb/pegasus.c - 1.27 linux/drivers/char/sh-sci.c - 1.18 linux/include/linux/generic_serial.h - 1.4 linux/fs/nfs/flushd.c - 1.11 linux/drivers/usb/mdc800.c - 1.17 linux/include/linux/fs_struct.h - 1.6 linux/drivers/char/rio/rio_linux.c - 1.13 linux/arch/i386/kernel/msr.c - 1.15 linux/arch/i386/kernel/cpuid.c - 1.8 linux/include/asm-i386/i387.h - 1.6 linux/fs/jffs/inode-v23.c - 1.19 linux/fs/jffs/intrep.c - 1.10 linux/arch/i386/kernel/i387.c - 1.8 linux/arch/sparc64/lib/dec_and_lock.S - 1.4 linux/drivers/sound/ymfpci.c - 1.20 linux/include/linux/shmem_fs.h - 1.6 linux/fs/reiserfs/stree.c - 1.19 linux/fs/reiserfs/super.c - 1.17 linux/fs/reiserfs/tail_conversion.c - 1.13 linux/fs/reiserfs/prints.c - 1.11 linux/fs/reiserfs/objectid.c - 1.9 linux/fs/reiserfs/namei.c - 1.18 linux/fs/reiserfs/lbalance.c - 1.7 linux/fs/reiserfs/journal.c - 1.22 linux/fs/reiserfs/item_ops.c - 1.5 linux/fs/reiserfs/ioctl.c - 1.6 linux/fs/reiserfs/inode.c - 1.26 linux/fs/reiserfs/ibalance.c - 1.7 linux/fs/reiserfs/fix_node.c - 1.16 linux/fs/reiserfs/file.c - 1.8 linux/fs/reiserfs/do_balan.c - 1.9 linux/fs/reiserfs/buffer2.c - 1.10 linux/fs/reiserfs/bitmap.c - 1.13 linux/drivers/sound/cs4281/cs4281m.c - 1.10 linux/fs/freevxfs/vxfs_lookup.c - 1.4 linux/drivers/video/aty/mach64_accel.c - 1.3 linux/drivers/usb/kaweth.c - 1.12 linux/drivers/char/serial_tx3912.c - 1.5 linux/drivers/scsi/53c700.c - 1.6 linux/drivers/scsi/53c700.h - 1.4 linux/drivers/scsi/53c700.scr - 1.3 linux/drivers/scsi/NCR_D700.c - 1.2 linux/drivers/scsi/lasi700.c - 1.3 linux/drivers/usb/hid-core.c - 1.6 linux/fs/jffs2/background.c - 1.6 linux/fs/jffs2/dir.c - 1.5 linux/fs/jffs2/gc.c - 1.5 linux/fs/jffs/jffs_proc.c - 1.2 linux/fs/isofs/compress.c - 1.4 linux/fs/jbd/journal.c - 1.6 linux/fs/ext3/file.c - 1.3 linux/fs/ext3/fsync.c - 1.3 linux/fs/ext3/ialloc.c - 1.8 linux/fs/ext3/inode.c - 1.6 linux/fs/ext3/ioctl.c - 1.3 linux/fs/ext3/namei.c - 1.3 linux/fs/ext3/super.c - 1.11 linux/fs/intermezzo/file.c - 1.3 linux/fs/intermezzo/journal_ext2.c - 1.3 linux/fs/intermezzo/journal_ext3.c - 1.4 linux/fs/intermezzo/journal_obdfs.c - 1.4 linux/fs/intermezzo/journal_reiserfs.c - 1.4 linux/fs/intermezzo/journal_xfs.c - 1.5 linux/fs/intermezzo/methods.c - 1.4 linux/fs/intermezzo/presto.c - 1.5 linux/fs/intermezzo/psdev.c - 1.5 linux/fs/intermezzo/super.c - 1.3 linux/fs/intermezzo/sysctl.c - 1.4 linux/fs/intermezzo/upcall.c - 1.3 linux/fs/jbd/recovery.c - 1.4 linux/fs/jbd/revoke.c - 1.5 linux/fs/jbd/transaction.c - 1.5 linux/fs/reiserfs/procfs.c - 1.5 linux/fs/ext3/balloc.c - 1.3 linux/fs/jbd/commit.c - 1.4 linux/fs/intermezzo/cache.c - 1.3 linux/fs/jbd/checkpoint.c - 1.2 linux/fs/intermezzo/dir.c - 1.3 linux/fs/intermezzo/dcache.c - 1.4 linux/fs/driverfs/inode.c - 1.7 linux/drivers/usb/hcd/ehci-mem.c - 1.2 linux/include/linux/namespace.h - 1.2 linux/drivers/usb/hcd.c - 1.8 linux/drivers/usb/hcd/ehci-hub.c - 1.3 linux/drivers/usb/hcd/ehci-q.c - 1.5 linux/drivers/usb/hcd/ehci-sched.c - 1.4 linux/drivers/usb/auerswald.c - 1.5 linux/drivers/usb/hcd/ohci-q.c - 1.3 linux/drivers/usb/hcd/ohci-hcd.c - 1.3 linux/arch/alpha/Config.help - 1.3 linux/arch/arm/Config.help - 1.3 linux/arch/cris/Config.help - 1.3 linux/arch/i386/Config.help - 1.4 linux/arch/ia64/Config.help - 1.3 linux/arch/mips/Config.help - 1.2 linux/arch/mips64/Config.help - 1.2 linux/arch/ppc/Config.help - 1.3 linux/arch/sparc/Config.help - 1.2 linux/arch/sparc64/Config.help - 1.2 linux/drivers/base/interface.c - 1.4 linux/drivers/base/fs.c - 1.3 linux/drivers/base/core.c - 1.4 linux/drivers/pnp/pnpbios_core.c - 1.2 linux/include/asm-i386/thread_info.h - 1.2 From owner-linux-xfs@oss.sgi.com Mon Feb 11 11:25:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BJP7P08546 for linux-xfs-outgoing; Mon, 11 Feb 2002 11:25:07 -0800 Received: from vortex.xnote.com ([65.105.237.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BJP4908524 for ; Mon, 11 Feb 2002 11:25:04 -0800 Received: from xnote.com ([166.70.98.117]) by vortex.xnote.com (8.11.0/8.8.7) with ESMTP id g1BIP4M11684 for ; Mon, 11 Feb 2002 11:25:04 -0700 Message-ID: <3C680C6D.9070708@xnote.com> Date: Mon, 11 Feb 2002 11:24:45 -0700 From: Vernon McPherron User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.8) Gecko/20020208 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Current status of 2.5.x Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I haven't been following the 2.5.x branch lately. Does the XFS CVS branch support LVM and MD, or does it still need work? I understood that early 2.5 trees the vfs was quite different from the 2.4 vfs. I guess this should really go to the Kernel mailing list, just curious to know of those using the 2.5 cvs tree are using LVM & MD. Thanks. -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Mon Feb 11 11:34:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BJY0u09234 for linux-xfs-outgoing; Mon, 11 Feb 2002 11:34:00 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BJXu909212 for ; Mon, 11 Feb 2002 11:33:56 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA07193 for ; Mon, 11 Feb 2002 10:35:10 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA36032; Mon, 11 Feb 2002 12:32:40 -0600 (CST) Received: from sgi.com (MhdrH62JBuJr02jWtu1KHlxB9iTYPw5L@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA36581; Mon, 11 Feb 2002 12:32:40 -0600 (CST) Message-ID: <3C680E6C.9040002@sgi.com> Date: Mon, 11 Feb 2002 12:33:16 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Vernon McPherron CC: linux-xfs@oss.sgi.com Subject: Re: Current status of 2.5.x References: <3C680C6D.9070708@xnote.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vernon McPherron wrote: > I haven't been following the 2.5.x branch lately. Does the XFS CVS > branch support LVM and MD, or does it still need work? I understood > that early 2.5 trees the vfs was quite different from the 2.4 vfs. > > I guess this should really go to the Kernel mailing list, just curious > to know of those using the 2.5 cvs tree are using LVM & MD. > > Thanks. > > -=/Vernon McPherron/=- So far as I know, md in 2.5 should be working, lvm is totally broken, and no one is attempting to fix it. Sistina shows no sign of working on it, they released a rewrite of lvm in 2.4 instead. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 11 11:49:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BJnnK09681 for linux-xfs-outgoing; Mon, 11 Feb 2002 11:49:49 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BJnj909659 for ; Mon, 11 Feb 2002 11:49:45 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1BJnexV007531 for ; Mon, 11 Feb 2002 11:49:41 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA71267 for ; Mon, 11 Feb 2002 12:48:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA80572 for ; Mon, 11 Feb 2002 12:48:24 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1BIlZo13970; Mon, 11 Feb 2002 12:47:35 -0600 Message-Id: <200202111847.g1BIlZo13970@jen.americas.sgi.com> Date: Mon, 11 Feb 2002 12:47:35 -0600 Subject: TAKE - deal with stale pagebufs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There was never any code in pagebuf to deal with finding a stale buffer in cache - finding one could lead to returning a null pointer to the caller. In theory this should not happen - but a bug elsewhere exposed the problem for me, possibly other people who have seen crashes where a null pointer was dereferenced were victims of the same thing Date: Mon Feb 11 10:42:29 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.back The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111500a linux/fs/xfs/xfs_buf.h - 1.80 - use PBF_STALE to stale a buffer linux/fs/xfs/pagebuf/page_buf_locking.c - 1.3 - Deal with finding stale buffers in the cache linux/fs/xfs/pagebuf/page_buf.c - 1.6 - fix pagebuf tracing linux/fs/xfs/pagebuf/page_buf.h - 1.3 - Define PBF_STALE From owner-linux-xfs@oss.sgi.com Mon Feb 11 12:26:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BKQfu10568 for linux-xfs-outgoing; Mon, 11 Feb 2002 12:26:41 -0800 Received: from ente.berdmann.de (frnk-d514e1c1.dsl.mediaWays.net [213.20.225.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BKQb910546 for ; Mon, 11 Feb 2002 12:26:37 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aM5v-0000zL-00; Mon, 11 Feb 2002 20:26:31 +0100 Message-ID: <3C681AE7.3759DF54@berdmann.de> Date: Mon, 11 Feb 2002 20:26:31 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: mai99bxd CC: linux-xfs@oss.sgi.com Subject: Re: best kernel version to use with XFS+LVM+MD References: <002201c1b31c$75c02f30$0b00a8c0@alex> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I'm going to plan a fileserver with 2 45Gb IDE disks in soft RAID1 and 4 > 100GB IDE disks in soft RAID5. I would take the RAID1 for system and the > RAID5 for storage. The 300GB RADI5 space should be divided by LVM into > some XFS filesystems. I also use NFS and Samba over the XFS. > > Which kernel version seems to be stable in realation with XFS, LVM and > MD? I'm using here 2.4.14, LVM (1.0.1rc4), MD and XFS. 4*17 GB in RAID5. No problems yet. Just one: since I tried to build a second raid array (2*1 GB RAID1 for XFS log volumes) and use it for a second volume group, lvcreate doesn't let me specify /dev/md0 as the physical volume for new LVs. Nevertheless, it is possible to create the new LV on a different PV in the same VG outside the RAID and pvmove it afterwards onto the RAID. # /sbin/lvcreate -L 1G -n junk vg2 /dev/md0 lvcreate -- couldn't read physical volume "/dev/md0" From owner-linux-xfs@oss.sgi.com Mon Feb 11 12:41:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BKfoN11035 for linux-xfs-outgoing; Mon, 11 Feb 2002 12:41:50 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BKfk911013 for ; Mon, 11 Feb 2002 12:41:46 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 LAA01930 for ; Mon, 11 Feb 2002 11:37:19 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA71172; Mon, 11 Feb 2002 13:40:27 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA18561; Mon, 11 Feb 2002 13:40:26 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id NAA76596; Mon, 11 Feb 2002 13:40:26 -0600 (CST) Message-Id: <200202111940.NAA76596@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI remove event Date: Mon, 11 Feb 2002 13:40:26 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" >When receiving a 'remove' event using the DMAPI the mode is always returned >as 0 (actually it's the ne_mode field of the dm_namesp_event_t extracted >from the event). This makes it impossible to determine if the event refers >to a file, directory, symlink, etc. > >I don't know if this is a problem with other types of DMAPI events as well, >but it is serious. Serious? I'm not sure you've ever come up with a minor problem for me :) >Is this an easy fix? I see that the mode comes in the POSTREMOVE event, and that we'll have to rearrange some code to get it into the REMOVE event. I'll play with it a bit. Dean From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:00:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BL00011881 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:00:00 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BKxm911859 for ; Mon, 11 Feb 2002 12:59:49 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1BJv0g08547; Mon, 11 Feb 2002 13:57:00 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Current status of 2.5.x From: Austin Gonyou To: Stephen Lord Cc: Vernon McPherron , linux-xfs@oss.sgi.com In-Reply-To: <3C680E6C.9040002@sgi.com> References: <3C680E6C.9040002@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Feb 2002 13:56:59 -0600 Message-Id: <1013457419.7922.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Also it must be shown that lvm in 2.5 will be worked on, but there was word from sistna when the released lvm2, that a port would happen at a later time. I think it's best to ask directly on that list. Probably even Heinz himself. On Mon, 2002-02-11 at 12:33, Stephen Lord wrote: > Vernon McPherron wrote: > > > I haven't been following the 2.5.x branch lately. Does the XFS CVS > > branch support LVM and MD, or does it still need work? I understood > > that early 2.5 trees the vfs was quite different from the 2.4 vfs. > > > > I guess this should really go to the Kernel mailing list, just curious > > > to know of those using the 2.5 cvs tree are using LVM & MD. > > > > Thanks. > > > > -=/Vernon McPherron/=- > > So far as I know, md in 2.5 should be working, lvm is totally broken, > and no one is attempting > to fix it. Sistina shows no sign of working on it, they released a > rewrite of lvm in 2.4 instead. > > Steve > > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:16:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLGXq13065 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:16:33 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLGQ913040 for ; Mon, 11 Feb 2002 13:16:26 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1BKFmN15243; Mon, 11 Feb 2002 14:15:48 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: best kernel version to use with XFS+LVM+MD From: Austin Gonyou To: "Bernhard R. Erdmann" Cc: mai99bxd , linux-xfs@oss.sgi.com In-Reply-To: <3C681AE7.3759DF54@berdmann.de> References: <3C681AE7.3759DF54@berdmann.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Feb 2002 14:15:48 -0600 Message-Id: <1013458548.7922.12.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is something that was seen on the LVM list as well. I don't remember what the fix was, if there was one, but a pvmove was working there as well. On Mon, 2002-02-11 at 13:26, Bernhard R. Erdmann wrote: > > I'm going to plan a fileserver with 2 45Gb IDE disks in soft RAID1 and > 4 > > 100GB IDE disks in soft RAID5. I would take the RAID1 for system and > the > > RAID5 for storage. The 300GB RADI5 space should be divided by LVM into > > some XFS filesystems. I also use NFS and Samba over the XFS. > > > > Which kernel version seems to be stable in realation with XFS, LVM and > > MD? > > I'm using here 2.4.14, LVM (1.0.1rc4), MD and XFS. 4*17 GB in RAID5. No > problems yet. > > Just one: since I tried to build a second raid array (2*1 GB RAID1 for > XFS log volumes) and use it for a second volume group, lvcreate doesn't > let me specify /dev/md0 as the physical volume for new LVs. > Nevertheless, it is possible to create the new LV on a different PV in > the same VG outside the RAID and pvmove it afterwards onto the RAID. > > # /sbin/lvcreate -L 1G -n junk vg2 /dev/md0 > lvcreate -- couldn't read physical volume "/dev/md0" -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:16:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLGoO13180 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:16:50 -0800 Received: from net.rongage.org (root@lns-saginaw.net [63.83.235.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLGl913133 for ; Mon, 11 Feb 2002 13:16:47 -0800 Received: from localhost (nobody@localhost [127.0.0.1]) by net.rongage.org (8.10.2/8.10.2) with ESMTP id g1BKGiN11438 for ; Mon, 11 Feb 2002 15:16:44 -0500 Received: from 64.113.37.141 ( [64.113.37.141]) as user ron@net.rongage.org by webmail.rongage.org with HTTP; Mon, 11 Feb 2002 15:16:44 -0500 Message-ID: <1013458604.3c6826acb7db7@webmail.rongage.org> Date: Mon, 11 Feb 2002 15:16:44 -0500 From: Ron Gage To: linux-xfs@oss.sgi.com Subject: Hello MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 64.113.37.141 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi folks: Just signed up for the mailing list. I hope to be of some assistance for the effort here. I have XFS running under Slackware 8.0, kernel 2.4.16 on one of my spare machines at home. The main storage on this computer is a Software Raid-5 volume consiting of 6 x 21gig SCSI-Wide disks powered by an older Adaptec 3940(?) Wide SCSI controller. If there is anything I can do to help out the project (testing, limited coding, documentation), please let me know. -- Ron Gage - Owner, Linux Network Services - Saginaw, Michigan - 989-274-8088 Your one-stop source for Reliable, Secure and Affordable Networking Solutions ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:26:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLQds15000 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:26:39 -0800 Received: from ente.berdmann.de (frnk-d514e1ae.dsl.mediaWays.net [213.20.225.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLQW914978 for ; Mon, 11 Feb 2002 13:26:33 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aN1r-0001dW-00; Mon, 11 Feb 2002 21:26:23 +0100 Message-ID: <3C6828EE.6F3F825D@berdmann.de> Date: Mon, 11 Feb 2002 21:26:22 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: "Jeffrey D. Means" , "'Linux-xfs'" Subject: Re: Question about the ISO image on the FTP site References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > It's primarily designed to install xfs, but to do that, you boot from it. > It can also act as a rescue cd by typing "linux rescue" at the boot prompt > when it first comes up. Unfortunately it misses the st driver, so you can't access a directly connected SCSI tape drive. From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:36:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLa6Q15353 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:36:06 -0800 Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLZu915330 for ; Mon, 11 Feb 2002 13:35:56 -0800 Received: from burns.home.kernel.dk ([192.168.0.2] ident=mail) by virtualhost.dk with esmtp (Exim 3.34 #1) id 16aN5z-0006St-00; Mon, 11 Feb 2002 21:30:39 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.33 #1) id 16aN5u-0001e0-00; Mon, 11 Feb 2002 21:30:34 +0100 Date: Mon, 11 Feb 2002 21:30:34 +0100 From: Jens Axboe To: Stephen Lord Cc: Vernon McPherron , linux-xfs@oss.sgi.com Subject: Re: Current status of 2.5.x Message-ID: <20020211213034.P729@suse.de> References: <3C680C6D.9070708@xnote.com> <3C680E6C.9040002@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C680E6C.9040002@sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 11 2002, Stephen Lord wrote: > Vernon McPherron wrote: > > >I haven't been following the 2.5.x branch lately. Does the XFS CVS > >branch support LVM and MD, or does it still need work? I understood > >that early 2.5 trees the vfs was quite different from the 2.4 vfs. > > > >I guess this should really go to the Kernel mailing list, just curious > >to know of those using the 2.5 cvs tree are using LVM & MD. > > > >Thanks. > > > >-=/Vernon McPherron/=- > > So far as I know, md in 2.5 should be working, lvm is totally broken, raid0 and raid1 works perfectly, raid5 does not. raid1 over raid0 has resync problems unless you change the resync bio size, but apart from that it should be perfect. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:41:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLfQU15578 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:41:26 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLfJ915556 for ; Mon, 11 Feb 2002 13:41:20 -0800 Received: (qmail 1911 invoked from network); 11 Feb 2002 20:42:27 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 11 Feb 2002 20:42:27 -0000 Subject: OT: SGI's CVS commitlog/TAKE script? From: Shawn Starr To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Feb 2002 15:43:52 -0500 Message-Id: <1013460260.19744.178.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was wondering how you keep track of TAKES in CVS. Any possibility of seeing the script source? Shawn. From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:48:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLm3Y15746 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:48:03 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLlx915723 for ; Mon, 11 Feb 2002 13:47:59 -0800 Received: (qmail 1948 invoked from network); 11 Feb 2002 20:49:11 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 11 Feb 2002 20:49:11 -0000 Subject: XFS + rmap12e + 2.4.18-pre9 From: Shawn Starr To: xfs In-Reply-To: <200202111847.g1BIlZo13970@jen.americas.sgi.com> References: <200202111847.g1BIlZo13970@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Feb 2002 15:50:37 -0500 Message-Id: <1013460664.19791.186.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am happy to say, that I've managed to get rmap12e working correctly with XFS-CVS head. Some minor modifications to mm/vmscan.c and fs/buffer.c but, I've not seen corruption yet. 504 root 15 0 1024 1000 360 R 94.0 1.6 756:00 blowup-xfs (fsx-linux.c) I will be trying some of the test XFS programs in the tree as well today. Shawn. From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:49:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLn1515870 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:49:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLmu915848 for ; Mon, 11 Feb 2002 13:48:57 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1759083 for ; Mon, 11 Feb 2002 21:48:53 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA72576; Mon, 11 Feb 2002 14:47:36 -0600 (CST) Received: from sgi.com (CI8D3IOj9cHsYluI/uHqRKb7qUsvQG6x@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA50917; Mon, 11 Feb 2002 14:47:36 -0600 (CST) Message-ID: <3C682E0C.3030601@sgi.com> Date: Mon, 11 Feb 2002 14:48:12 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Shawn Starr CC: xfs Subject: Re: OT: SGI's CVS commitlog/TAKE script? References: <1013460260.19744.178.camel@unaropia> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Shawn Starr wrote: >I was wondering how you keep track of TAKES in CVS. Any possibility of >seeing the script source? > >Shawn. > > You really do not want to know what is going on ;-) The TAKE messages come from SGI's internal source code control system - which is based on rcs, but with a lot of other features. Every hour a cron job takes the current version of this rcs tree, prunes out the pre open source parts of the rcs history, and rsyncs it out to oss as a cvs repository. So we are not using cvs internally at all. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:50:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLoUK16002 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:50:30 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLoQ915980 for ; Mon, 11 Feb 2002 13:50:26 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1809337 for ; Mon, 11 Feb 2002 21:50:23 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA72952; Mon, 11 Feb 2002 14:49:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA32063; Mon, 11 Feb 2002 14:49:08 -0600 (CST) Subject: Re: OT: SGI's CVS commitlog/TAKE script? From: Eric Sandeen To: Shawn Starr Cc: xfs In-Reply-To: <1013460260.19744.178.camel@unaropia> References: <1013460260.19744.178.camel@unaropia> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Feb 2002 14:49:08 -0600 Message-Id: <1013460548.12855.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's more than that; internally we use a different source code control tool, and the resulting RCS repository just gets pushed out to the CVS repository each hour. So, there's a lot more than "a script." -Eric On Mon, 2002-02-11 at 14:43, Shawn Starr wrote: > I was wondering how you keep track of TAKES in CVS. Any possibility of > seeing the script source? > > Shawn. > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:57:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLvNU16190 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:57:23 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLvI916167 for ; Mon, 11 Feb 2002 13:57:18 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1BKt5916152; Mon, 11 Feb 2002 14:55:05 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Current status of 2.5.x From: Austin Gonyou To: Jens Axboe Cc: Stephen Lord , Vernon McPherron , linux-xfs@oss.sgi.com In-Reply-To: <20020211213034.P729@suse.de> References: <20020211213034.P729@suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Feb 2002 14:55:05 -0600 Message-Id: <1013460905.15451.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ahh...that explains what I saw on the LVM list then. Thanks! On Mon, 2002-02-11 at 14:30, Jens Axboe wrote: > On Mon, Feb 11 2002, Stephen Lord wrote: > > Vernon McPherron wrote: > > > > >I haven't been following the 2.5.x branch lately. Does the XFS CVS > > >branch support LVM and MD, or does it still need work? I understood > > >that early 2.5 trees the vfs was quite different from the 2.4 vfs. > > > > > >I guess this should really go to the Kernel mailing list, just > curious > > >to know of those using the 2.5 cvs tree are using LVM & MD. > > > > > >Thanks. > > > > > >-=/Vernon McPherron/=- > > > > So far as I know, md in 2.5 should be working, lvm is totally broken, > > raid0 and raid1 works perfectly, raid5 does not. raid1 over raid0 has > resync problems unless you change the resync bio size, but apart from > that it should be perfect. > > -- > Jens Axboe -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Feb 11 13:59:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLx4H16319 for linux-xfs-outgoing; Mon, 11 Feb 2002 13:59:04 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLx0916297 for ; Mon, 11 Feb 2002 13:59:00 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1BKtGS16163; Mon, 11 Feb 2002 14:55:16 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS + rmap12e + 2.4.18-pre9 From: Austin Gonyou To: Shawn Starr Cc: xfs In-Reply-To: <1013460664.19791.186.camel@unaropia> References: <1013460664.19791.186.camel@unaropia> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Feb 2002 14:55:16 -0600 Message-Id: <1013460916.15452.4.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Posting a patch for that anywhere? On Mon, 2002-02-11 at 14:50, Shawn Starr wrote: > I am happy to say, that I've managed to get rmap12e working correctly > with XFS-CVS head. > > Some minor modifications to mm/vmscan.c and fs/buffer.c but, I've not > seen corruption yet. > > 504 root 15 0 1024 1000 360 R 94.0 1.6 756:00 blowup-xfs > (fsx-linux.c) > > I will be trying some of the test XFS programs in the tree as well > today. > > Shawn. > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Feb 11 14:01:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BM1Pk16528 for linux-xfs-outgoing; Mon, 11 Feb 2002 14:01:25 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BM1I916506 for ; Mon, 11 Feb 2002 14:01:19 -0800 Received: (qmail 2031 invoked from network); 11 Feb 2002 21:02:30 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 11 Feb 2002 21:02:30 -0000 Subject: Re: XFS + rmap12e + 2.4.18-pre9 From: Shawn Starr To: Austin Gonyou Cc: xfs In-Reply-To: <1013460916.15452.4.camel@UberGeek> References: <1013460664.19791.186.camel@unaropia> <1013460916.15452.4.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Feb 2002 16:03:56 -0500 Message-Id: <1013461463.19744.189.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One is coming, I'm at work right now so I'll generate one shortly :-) On Mon, 2002-02-11 at 15:55, Austin Gonyou wrote: > Posting a patch for that anywhere? > > On Mon, 2002-02-11 at 14:50, Shawn Starr wrote: > > I am happy to say, that I've managed to get rmap12e working correctly > > with XFS-CVS head. > > > > Some minor modifications to mm/vmscan.c and fs/buffer.c but, I've not > > seen corruption yet. > > > > 504 root 15 0 1024 1000 360 R 94.0 1.6 756:00 blowup-xfs > > (fsx-linux.c) > > > > I will be trying some of the test XFS programs in the tree as well > > today. > > > > Shawn. > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb > From owner-linux-xfs@oss.sgi.com Mon Feb 11 14:02:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BM20v16656 for linux-xfs-outgoing; Mon, 11 Feb 2002 14:02:00 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BM1t916633 for ; Mon, 11 Feb 2002 14:01:55 -0800 Received: (qmail 2036 invoked from network); 11 Feb 2002 21:03:06 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 11 Feb 2002 21:03:06 -0000 Subject: Re: XFS + rmap12e + 2.4.18-pre9 From: Shawn Starr To: Austin Gonyou Cc: xfs In-Reply-To: <1013460916.15452.4.camel@UberGeek> References: <1013460664.19791.186.camel@unaropia> <1013460916.15452.4.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Feb 2002 16:04:32 -0500 Message-Id: <1013461499.19792.191.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You can find my xfs related patches at http://xfs.sh0n.net I need to add some new ones today :) Shawn. On Mon, 2002-02-11 at 15:55, Austin Gonyou wrote: > Posting a patch for that anywhere? > > On Mon, 2002-02-11 at 14:50, Shawn Starr wrote: > > I am happy to say, that I've managed to get rmap12e working correctly > > with XFS-CVS head. > > > > Some minor modifications to mm/vmscan.c and fs/buffer.c but, I've not > > seen corruption yet. > > > > 504 root 15 0 1024 1000 360 R 94.0 1.6 756:00 blowup-xfs > > (fsx-linux.c) > > > > I will be trying some of the test XFS programs in the tree as well > > today. > > > > Shawn. > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb > From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:02:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BN2qC17676 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:02:52 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BN2k917654 for ; Mon, 11 Feb 2002 15:02:46 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-239.quicknet.nl [212.58.163.239]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1BM2iGX017632; Mon, 11 Feb 2002 23:02:44 +0100 (CET) Message-Id: <4.3.2.7.2.20020211224914.03741290@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Feb 2002 23:00:41 +0100 To: "mai99bxd" , From: Seth Mos Subject: Re: best kernel version to use with XFS+LVM+MD In-Reply-To: <002201c1b31c$75c02f30$0b00a8c0@alex> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:52 11-2-2002 +0100, mai99bxd wrote: >Hi all, > >I'm going to plan a fileserver with 2 45Gb IDE disks in soft RAID1 and 4 >100GB IDE disks in soft RAID5. I would take the RAID1 for system and the >RAID5 for storage. The 300GB RADI5 space should be divided by LVM into >some XFS filesystems. I also use NFS and Samba over the XFS. Make sure that you make the log of the raid5 volume external and preferably on the raid1 device (make a 50MB partition for this). This will result in a normal performance level of the raid5 volume. >Which kernel version seems to be stable in realation with XFS, LVM and >MD? I am using the 1.0.2 with decent success. I have a occasional hang during mount on one box with a squid cache which havn't tracked down yet. No LVM or MD involved. I do have a box with a md raid5 which seems to do fine which is made of 3 40GB IDE disks. >Some 2.4.x kernels had problems in the past. The releases based on the Red Hat kernels (the XFS 1.0 1.0.1 and 1.0.2) releases do well. They are well tested. The XFS 1.0.2 release is the latest and there is a contributed Red Hat errata kernel for 1.0.2 in the contrib directory of the ftp site. ftp://oss.sgi.com/projects/xfs/ Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:10:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNAYT17948 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:10:34 -0800 Received: from ente.berdmann.de (frnk-d514e1ae.dsl.mediaWays.net [213.20.225.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNAU917926 for ; Mon, 11 Feb 2002 15:10:30 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aOeT-0002g2-00; Mon, 11 Feb 2002 23:10:21 +0100 Message-ID: <3C68414D.D92A6E64@berdmann.de> Date: Mon, 11 Feb 2002 23:10:21 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: ivanr@sgi.com CC: Linux XFS Mailing List Subject: Re: xfsrestore dumps core on cumulative restore with -B (dirattr.c:945) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Good. We're still going to take a look and see why it was core dumping, > but I'll check in the patch anyway. > > So in all other respects, is -B working now as you'd expect it to? I'm not very sure about the results. Using the patched tree.c xfsrestore runs well on that particular test case restoring the level 3 dump. Using -B, the permissions aren't restored on ., but I'm not very sure if the permissions I'd expect were there at backup time. Some other cumulative dumps can be restored without problems using the unpatched version of tree.c. I'll check if xfsrestore's interactive mode can tell me something about the mode . was backed up. From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:16:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNGa818199 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:16:36 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNGU918176 for ; Mon, 11 Feb 2002 15:16:31 -0800 Received: (qmail 2341 invoked from network); 11 Feb 2002 22:17:41 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 11 Feb 2002 22:17:41 -0000 Subject: Re: XFS + rmap12e + 2.4.18-pre9 From: Shawn Starr To: xfs In-Reply-To: <1013460916.15452.4.camel@UberGeek> References: <1013460664.19791.186.camel@unaropia> <1013460916.15452.4.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Feb 2002 17:19:07 -0500 Message-Id: <1013465975.19790.197.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk you can get the latest patch now. linux-2.4.18-pre8-xfs-shawn4 contains rmap12e + 2.4.18-pre7-ac3. Shawn. On Mon, 2002-02-11 at 15:55, Austin Gonyou wrote: > Posting a patch for that anywhere? > > On Mon, 2002-02-11 at 14:50, Shawn Starr wrote: > > I am happy to say, that I've managed to get rmap12e working correctly > > with XFS-CVS head. > > > > Some minor modifications to mm/vmscan.c and fs/buffer.c but, I've not > > seen corruption yet. > > > > 504 root 15 0 1024 1000 360 R 94.0 1.6 756:00 blowup-xfs > > (fsx-linux.c) > > > > I will be trying some of the test XFS programs in the tree as well > > today. > > > > Shawn. > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb > > From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:16:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNGu818328 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:16:56 -0800 Received: from ente.berdmann.de (frnk-d514e1ae.dsl.mediaWays.net [213.20.225.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNGr918303 for ; Mon, 11 Feb 2002 15:16:53 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aOke-0002iJ-00; Mon, 11 Feb 2002 23:16:44 +0100 Message-ID: <3C6842CB.9890CB2B@berdmann.de> Date: Mon, 11 Feb 2002 23:16:43 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Seth Mos CC: mai99bxd , linux-xfs@oss.sgi.com Subject: Re: best kernel version to use with XFS+LVM+MD References: <4.3.2.7.2.20020211224914.03741290@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The releases based on the Red Hat kernels (the XFS 1.0 1.0.1 and 1.0.2) > releases do well. They are well tested. The XFS 1.0.2 release is the latest > and there is a contributed Red Hat errata kernel for 1.0.2 in the contrib > directory of the ftp site. ftp://oss.sgi.com/projects/xfs/ These contributed kernels are just RedHat + XFS. No LVM. I should have known this before I upgraded our department server heavily using LVM and rebooted at 9:15h am. :-( From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:19:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNJJZ18467 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:19:19 -0800 Received: from studserv.uni-leipzig.de (studserv.uni-leipzig.de [139.18.1.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNJE918444 for ; Mon, 11 Feb 2002 15:19:14 -0800 Received: from alex (port-213-20-128-54.reverse.qdsl-home.de [213.20.128.54]) by studserv.uni-leipzig.de (8.9.3/8.9.3) with ESMTP id XAA33010; Mon, 11 Feb 2002 23:19:12 +0100 From: "mai99bxd" To: "'Seth Mos'" Cc: Subject: AW: best kernel version to use with XFS+LVM+MD Date: Mon, 11 Feb 2002 23:19:01 +0100 Message-ID: <002801c1b34a$2225f7f0$0b00a8c0@alex> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <4.3.2.7.2.20020211224914.03741290@pop.xs4all.nl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth, >Make sure that you make the log of the raid5 volume external and >preferably >on the raid1 device (make a 50MB partition for this). This will result in a >normal performance level of the raid5 volume. Thank you. I read this in the mailing list. On witch fakt depends the size of 50MB? Is it rigth that one logfile can be max 32MB? Can I put more than one log in the same partition? I want use more than one XFS filesystem on the RAID5. >The releases based on the Red Hat kernels (the XFS 1.0 1.0.1 and 1.0.2) >releases do well. They are well tested. The XFS 1.0.2 release is the latest >and there is a contributed Red Hat errata kernel for 1.0.2 in the contrib >directory of the ftp site. ftp://oss.sgi.com/projects/xfs/ I use SuSE 7.1 with several updates and almost self compiled standard kernel's from original source (www.kernel.org). The Question is: can I use the last (2.4.17) or are there known problems with this version? I ask this, because ReiserFS for example had sometimes lists with known bugs on some kernels. Bye ALEX http://alexk.homeip.net From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:19:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNJPP18557 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:19:25 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNJK918481 for ; Mon, 11 Feb 2002 15:19:20 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-239.quicknet.nl [212.58.163.239]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1BMJDM4036873; Mon, 11 Feb 2002 23:19:14 +0100 (CET) Message-Id: <4.3.2.7.2.20020211231536.037a0ab0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Feb 2002 23:17:11 +0100 To: "Bernhard R. Erdmann" From: Seth Mos Subject: Re: Question about the ISO image on the FTP site Cc: "Jeffrey D. Means" , "'Linux-xfs'" In-Reply-To: <3C6828EE.6F3F825D@berdmann.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:26 11-2-2002 +0100, Bernhard R. Erdmann wrote: > > It's primarily designed to install xfs, but to do that, you boot from it. > > It can also act as a rescue cd by typing "linux rescue" at the boot prompt > > when it first comes up. > >Unfortunately it misses the st driver, so you can't access a directly >connected SCSI tape drive. Use the Linuxcare Bootable Toolbox instead. It's a 50 MB download and gets you just about everything you want. Try it. http://lbt.linuxcare.com/ And we have Martin K Petersen to thank for this one :-) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:22:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNM5X18789 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:22:05 -0800 Received: from studserv.uni-leipzig.de (studserv.uni-leipzig.de [139.18.1.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNM2918767 for ; Mon, 11 Feb 2002 15:22:02 -0800 Received: from alex (port-213-20-128-54.reverse.qdsl-home.de [213.20.128.54]) by studserv.uni-leipzig.de (8.9.3/8.9.3) with ESMTP id XAA38992; Mon, 11 Feb 2002 23:22:00 +0100 From: "mai99bxd" To: Cc: Subject: AW: best kernel version to use with XFS+LVM+MD Date: Mon, 11 Feb 2002 23:21:49 +0100 Message-ID: <002901c1b34a$867ceb50$0b00a8c0@alex> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3C6842CB.9890CB2B@berdmann.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >These contributed kernels are just RedHat + XFS. No LVM. I should have >known this before I upgraded our department server heavily using LVM and >rebooted at 9:15h am. :-( You had the old kernel in lilo? ;-) Bye ALEX http://alexk.homeip.net From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:29:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNTVx19104 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:29:31 -0800 Received: from ente.berdmann.de (frnk-d514e1ae.dsl.mediaWays.net [213.20.225.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNTR919082 for ; Mon, 11 Feb 2002 15:29:27 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aOwo-0002pJ-00; Mon, 11 Feb 2002 23:29:18 +0100 Message-ID: <3C6845BD.C4DD497D@berdmann.de> Date: Mon, 11 Feb 2002 23:29:17 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: mai99bxd CC: linux-xfs@oss.sgi.com Subject: Re: AW: best kernel version to use with XFS+LVM+MD References: <002901c1b34a$867ceb50$0b00a8c0@alex> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >These contributed kernels are just RedHat + XFS. No LVM. I should have > >known this before I upgraded our department server heavily using LVM > and > >rebooted at 9:15h am. :-( > > You had the old kernel in lilo? ;-) Not the old one of XFS 1.0.2 for RH7.1 from oss.sgi.com, but a very old kernel compiled by myself. ;-) Rebooted to single user mode using that very old kernel. All filesystems online. Set up network with ifconfig. Ping fileserver. Listen on a TCP port with netcat's output redirected to a file in /tmp. Tar the original RPMs on the fileserver and pipe with netcat to the crying box. Untar this file in /tmp. rpm -Uhv --nodeps --oldpackage *rpm. 20 min later. ;-) From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:37:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNbEP19391 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:37:14 -0800 Received: from studserv.uni-leipzig.de (studserv.uni-leipzig.de [139.18.1.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNb9919369 for ; Mon, 11 Feb 2002 15:37:09 -0800 Received: from alex (port-213-20-128-54.reverse.qdsl-home.de [213.20.128.54]) by studserv.uni-leipzig.de (8.9.3/8.9.3) with ESMTP id XAA32458; Mon, 11 Feb 2002 23:37:06 +0100 From: "mai99bxd" To: Cc: Subject: AW: AW: best kernel version to use with XFS+LVM+MD Date: Mon, 11 Feb 2002 23:36:55 +0100 Message-ID: <002a01c1b34c$a2895480$0b00a8c0@alex> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3C6845BD.C4DD497D@berdmann.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >Not the old one of XFS 1.0.2 for RH7.1 from oss.sgi.com, but a very old >kernel compiled by myself. ;-) >Rebooted to single user mode using that very old kernel. All filesystems >online. Set up network with ifconfig. Ping fileserver. Listen on a TCP >port with netcat's output redirected to a file in /tmp. Tar the original >RPMs on the fileserver and pipe with netcat to the crying box. Untar >this file in /tmp. rpm -Uhv --nodeps --oldpackage *rpm. 20 min later. >;-) Uhh - that sounds like me when I must use vi in single user mode, because mc isn't work. If I compile and boot up a new kernel (and I never use RPM kernels), I let stay the current in the lilo. So nothing happens if I compile some trash. Bye ALEX http://alexk.homeip.net From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:41:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNfVO19570 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:41:31 -0800 Received: from ente.berdmann.de (frnk-d514e1ae.dsl.mediaWays.net [213.20.225.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNfR919548 for ; Mon, 11 Feb 2002 15:41:28 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aP8Q-0002vE-00; Mon, 11 Feb 2002 23:41:18 +0100 Message-ID: <3C68488E.2DB897EB@berdmann.de> Date: Mon, 11 Feb 2002 23:41:18 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: mai99bxd CC: linux-xfs@oss.sgi.com Subject: Re: AW: AW: best kernel version to use with XFS+LVM+MD References: <002a01c1b34c$a2895480$0b00a8c0@alex> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Uhh - that sounds like me when I must use vi in single user mode, > because mc isn't work. Too many libraries linked against in the /usr filesystem to throw mc into /bin: $ ldd /usr/bin/mc libgpm.so.1 => /usr/lib/libgpm.so.1 (0x4001c000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40022000) libext2fs.so.2 => /lib/libext2fs.so.2 (0x40045000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x40059000) libc.so.6 => /lib/libc.so.6 (0x4005d000) libncurses.so.4 => /usr/lib/libncurses.so.4 (0x40152000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) That's exactly the reason you must know vi's basic commands for. From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:48:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNmdD19807 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:48:39 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNmY919776 for ; Mon, 11 Feb 2002 15:48:34 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id OAA07298 for ; Mon, 11 Feb 2002 14:49:47 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02891 for ; Tue, 12 Feb 2002 09:47:09 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA11856 for linux-xfs@oss.sgi.com; Tue, 12 Feb 2002 09:47:09 +1100 (AEDT) Date: Tue, 12 Feb 2002 09:47:08 +1100 From: Nathan Scott To: Andreas Piesk Subject: Re: PATCH proposal: attr Message-ID: <20020212094708.A138465@wobbly.melbourne.sgi.com> References: <6053616045.20020211133106@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6053616045.20020211133106@gmx.net>; from a.piesk@gmx.net on Mon, Feb 11, 2002 at 01:31:06PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 11, 2002 at 01:31:06PM +0100, Andreas Piesk wrote: > hiho, > > this is a patch for attr. > > detail: > - provides the ability to hande more than one file like chacl > - changes the error messages to look like the ones from chacl > > i introduced a new command line parameter "-c". if set, attr > continues with the next file if an error occured. it's disabled > by default. > There is a new command on its way which should do these things. Please wait a bit, then lets reevaluate whether this change is still useful once you've had a look at the new tools. ETA for new EA tools is with the 2.4.18 merge, once that is out. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:50:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNoMU19936 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:50:22 -0800 Received: from ente.berdmann.de (frnk-d514e1ae.dsl.mediaWays.net [213.20.225.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNoI919912 for ; Mon, 11 Feb 2002 15:50:18 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aPH2-00032b-00; Mon, 11 Feb 2002 23:50:12 +0100 Message-ID: <3C684AA4.E794A84F@berdmann.de> Date: Mon, 11 Feb 2002 23:50:12 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Seth Mos CC: "Jeffrey D. Means" , "'Linux-xfs'" Subject: Re: Question about the ISO image on the FTP site References: <4.3.2.7.2.20020211231536.037a0ab0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Use the Linuxcare Bootable Toolbox instead. It's a 50 MB download and gets > you just about everything you want. Try it. I'm afraid it can't boot just using a diskette and to grab the rest via network. I'd like to set up a rescue system using PXE. If something goes wrong, you just press "N" to boot from network and get into a full-blown linux. The next step would be to switch all NIC's default setting to boot via PXE. So sorry for the windoze lusers... ;-) From owner-linux-xfs@oss.sgi.com Mon Feb 11 15:53:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNrSt20119 for linux-xfs-outgoing; Mon, 11 Feb 2002 15:53:28 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNrK920097 for ; Mon, 11 Feb 2002 15:53:21 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id XAA1862146 for ; Mon, 11 Feb 2002 23:53:17 +0100 (CET) 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 JAA02915; Tue, 12 Feb 2002 09:51:59 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA36879; Tue, 12 Feb 2002 09:51:58 +1100 (AEDT) Date: Tue, 12 Feb 2002 09:51:58 +1100 From: Nathan Scott To: monkeyiq Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_bmap & XML patch Message-ID: <20020212095158.B138465@wobbly.melbourne.sgi.com> References: <200202111322.g1BDM0Z16215@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202111322.g1BDM0Z16215@monkeyiq.dnsalias.org>; from monkeyiq@users.sourceforge.net on Mon, Feb 11, 2002 at 11:22:00PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Feb 11, 2002 at 11:22:00PM +1000, monkeyiq wrote: > Hi, > With this little change one can use > $ ./xfs_bmap -x ~/tmp/holes > > > > > > > > Now that I've seen the code, it seems this could be done with a 4/5 line perl/awk script which parses `xfs_bmap -vv /tmp/foo` rather than modifying the existing program at all. Thoughts? xfs_bmap output is quite regular, so it shouldn't be too hard.. And when someone wants a output or some other trendy output format, only the script would need changes. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 11 16:05:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1C05nc20560 for linux-xfs-outgoing; Mon, 11 Feb 2002 16:05:49 -0800 Received: from ente.berdmann.de (frnk-d514e1ae.dsl.mediaWays.net [213.20.225.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1C05k920537 for ; Mon, 11 Feb 2002 16:05:46 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16aPW0-0003Dq-00; Tue, 12 Feb 2002 00:05:40 +0100 Message-ID: <3C684E44.31F9249@berdmann.de> Date: Tue, 12 Feb 2002 00:05:40 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: mai99bxd CC: "'Seth Mos'" , linux-xfs@oss.sgi.com Subject: Re: AW: best kernel version to use with XFS+LVM+MD References: <002801c1b34a$2225f7f0$0b00a8c0@alex> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Thank you. I read this in the mailing list. On witch fakt depends the > size of 50MB? Is it rigth that one logfile can be max 32MB? Can I put > more than one log in the same partition? I want use more than one XFS > filesystem on the RAID5. I don't know of a 32 MB border for the external log volume. You can put just one log volume into a single partition. That's what LVM is good for. Make a physical volume on your RAID1 volume and you can put all your logical volumes for the log volumes onto that PV. From owner-linux-xfs@oss.sgi.com Mon Feb 11 16:30:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1C0UAX20972 for linux-xfs-outgoing; Mon, 11 Feb 2002 16:30:10 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1C0U0920938 for ; Mon, 11 Feb 2002 16:30:01 -0800 Received: by monkeyiq.dnsalias.org id g1BNVRp17359 ; Tue, 12 Feb 2002 09:31:27 +1000 Date: Tue, 12 Feb 2002 09:31:27 +1000 Message-Id: <200202112331.g1BNVRp17359@monkeyiq.dnsalias.org> To: Nathan Scott Cc: monkeyiq , linux-xfs@oss.sgi.com Subject: Re: xfs_bmap & XML patch From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott writes: > hi, > > On Mon, Feb 11, 2002 at 11:22:00PM +1000, monkeyiq wrote: > > Hi, > > With this little change one can use > > $ ./xfs_bmap -x ~/tmp/holes > > > > > > > > > > > > > > > > > > Now that I've seen the code, it seems this could be done with > a 4/5 line perl/awk script which parses `xfs_bmap -vv /tmp/foo` > rather than modifying the existing program at all. Thoughts? > xfs_bmap output is quite regular, so it shouldn't be too hard.. Well, the main reason I was adding this was to avoid parsing output to get output, though that is very possible. I dont see that the script would be that much simpler than the xml output function by the time one takes into account script readability and special cases like holes in files. Also because the XML output is not ment for direct tty output one can add in any other extent related info that can be found, including for example if an extent is preallocation related which is not in -v at this point. Also if there is other stuff that goes into bmv_oflags in the future then that can become a new attribute in the XML. > > And when someone wants a output or some > other trendy output format, only the script would need changes. I am no expert on what XML 2.0 will offer, but one could also use XSLT to make it from the 1.0 document though I don't see a version 2.0 sweeping the land. In the end, I don't mind much either way. I'm not out to ruffle people up about putting XML everywhere. If folks don't think that having a XML output option is correct or desirable in xfs_bmap then maybe it should go someplace else. > > thanks. > > -- > Nathan > -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Feb 11 16:35:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1C0ZEW21144 for linux-xfs-outgoing; Mon, 11 Feb 2002 16:35:14 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1C0ZA921122 for ; Mon, 11 Feb 2002 16:35:10 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 PAA06025 for ; Mon, 11 Feb 2002 15:30:43 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA74742 for ; Mon, 11 Feb 2002 17:33:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA56147 for ; Mon, 11 Feb 2002 17:33:53 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1BNXr322222; Mon, 11 Feb 2002 17:33:53 -0600 Message-Id: <200202112333.g1BNXr322222@stout.americas.sgi.com> Date: Mon, 11 Feb 2002 17:33:53 -0600 From: Eric Sandeen Subject: TAKE - Report fsname on UUID mount failure Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This was suggested on the list, seems like a good idea to me. Now, if you try to mount a filesystem w/ a duplicate (or nil) UUID, you'll get XFS: Filesystem loop(7,1) has duplicate UUID - can't mount instead of the slightly less helpful XFS: Filesystem has duplicate UUID - can't mount Date: Mon Feb 11 15:31:49 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-nonsynchxact2 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111527a linux/fs/xfs/xfs_mount.c - 1.268 - Report filesystem name on UUID failure From owner-linux-xfs@oss.sgi.com Mon Feb 11 17:06:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1C16dh21774 for linux-xfs-outgoing; Mon, 11 Feb 2002 17:06:39 -0800 Received: from viruswall.behr.de ([194.99.122.195]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1C16W921752 for ; Mon, 11 Feb 2002 17:06:33 -0800 Received: from 172.27.16.1 by viruswall.behr.de (InterScan E-Mail VirusWall NT); Tue, 12 Feb 2002 01:11:00 +0100 Received: from stdohu01.st.behr.de (stdohu01.st.behr.de [172.27.15.11]) by mh1.st.behr.de (8.9.3/8.9.3) with ESMTP id XAA00812 for ; Mon, 11 Feb 2002 23:42:32 +0100 Subject: Andreas Reschke/Behr/Behrgroup ist zur Zeit nicht erreichbar. From: "Andreas Reschke" To: "Andreas Piesk Message-ID: Date: Tue, 12 Feb 2002 01:01:00 +0100 X-MIMETrack: Serialize by Router on stdohu01/Server/Behrgroup(Release 5.0.3 (Intl)|21 March 2000) at 02/12/2002 01:01:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1C16Y921753 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sehr geehrte Dame, sehr geehrter Herr, vielen Dank für Ihre Nachricht. Leider bin ich im Zeitraum vom 11.02.2002 bis 15.02.2002 nicht im Büro. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. From owner-linux-xfs@oss.sgi.com Mon Feb 11 17:22:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1C1M0F22056 for linux-xfs-outgoing; Mon, 11 Feb 2002 17:22:00 -0800 Received: from studserv.uni-leipzig.de (studserv.uni-leipzig.de [139.18.1.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1C1Lp922026 for ; Mon, 11 Feb 2002 17:21:51 -0800 Received: from alex (port-213-20-128-54.reverse.qdsl-home.de [213.20.128.54]) by studserv.uni-leipzig.de (8.9.3/8.9.3) with ESMTP id BAA33384; Tue, 12 Feb 2002 01:21:49 +0100 From: "mai99bxd" To: Cc: Subject: AW: AW: best kernel version to use with XFS+LVM+MD Date: Tue, 12 Feb 2002 01:21:39 +0100 Message-ID: <002b01c1b35b$43562740$0b00a8c0@alex> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3C684E44.31F9249@berdmann.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi >I don't know of a 32 MB border for the external log volume. You can put >just one log volume into a single partition. That's what LVM is good >for. Make a physical volume on your RAID1 volume and you can put all >your logical volumes for the log volumes onto that PV. That's right. I have no experiences in LVM. Seems this a good design? My current config: 45GB IDE hda1 ( 16MB) -> /boot (ext2) hda2 ( 5GB) -> RAID1 part of LVM sysVG (current empty space) hda3 ( 8GB) -> RAID1 part of / (reiserFS) hda4 ( 32GB) -> RAID1 part of /home (reiserFS) 45GB IDE hdc1 ( 16MB) -> /boot2 (ext2) hdc2 ( 5GB) -> RAID1 part of LVM sysVG (current empty space) hdc3 ( 8GB) -> RAID1 part of / (reiserFS) hdc4 ( 32GB) -> RAID1 part of /home (reiserFS) 2GB SCSI sda1 ( 2GB) -> swap My planed RAID5: 100GB IDE hde1 (100GB) -> RAID5 part of LVM storageVG 100GB IDE hdg1 (100GB) -> RAID5 part of LVM storageVG 100GB IDE hdi1 (100GB) -> RAID5 part of LVM storageVG 100GB IDE hdk1 (100GB) -> RAID5 part of LVM storageVG All RAID's are software (MD). Hardware is simple PC style. AMD K7 650MHz 768MB PC100 Gigabyte AMD 751 Chipset onboard IDE UDMA66 (hda, hdc) 2x Promise Ultra 100 (hde, hdg, hdi, hdk) Adaptec 2940 with disk, streamer, 2x CDROM 2x 3com 100 MBit/s NIC I don't want change my current /boot, /, /home system. My storage space (video, audio, install files) is on a single 100GB with single filesystem (ReiserFS) now. This storage should migrate to the RAID5. I will put several LV's like /storageVG/video /storageVG/mp3 /storageVG/source /storageVG/share on the RAID5. Most LV's should run with XFS. The XFS log's go in LV's on the sysVG. The rest of the 5GB sysVG is for backup und playing :-) The server is a dedicated file/database server which provide files for SMB, NFS(webserver) Clients and do some DB stuff for webservers. My intentions are in this order: redundancy of data, stable and secure system, good design, performance, coast minimization. A make regular backups of /home and important peaces (small enough) of data. But I can't backup the 300GB of volume data. I have a UPS but no redundant power supply now. Thank you for read my long posting. I hope you can make some annotations to my design. ALEX http://alexk.homeip.net From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:14:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFE3I02786 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:14:03 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFDr902760 for ; Tue, 12 Feb 2002 07:13:53 -0800 Received: (qmail 4281 invoked from network); 12 Feb 2002 14:15:05 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 12 Feb 2002 14:15:05 -0000 Subject: Re: 2.4.18-pre9-xfs-shawn4 - hpfs bug From: Shawn Starr To: Dag Bakke Cc: Linux , xfs In-Reply-To: <20020212140036.A223@dagb> References: <20020212140036.A223@dagb> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 12 Feb 2002 09:16:10 -0500 Message-Id: <1013523397.263.6.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some others have reported problems with superblock reading on boot. There may be some code that has changed superblock reading but this might be different. Shawn. On Tue, 2002-02-12 at 08:00, Dag Bakke wrote: > Hi. > > Compiling in support for hpfs in 2.4.18-pre9-xfs-shawn4 causes panic on > boot. > (I do have a some devicedriver patches added to your patch, but nothing related to > core, vfs or hpfs.) > > Thanks, > > Dag B > > > root@dagb:~# ksymoops -L -m /boot/System.map -K <~dagb/kernelcrash.txt > ksymoops 2.4.3 on i686 2.4.18-pre9-xfs-shawn4. Options used > -V (default) > -K (specified) > -L (specified) > -o /lib/modules/2.4.18-pre9-xfs-shawn4/ (default) > -m /boot/System.map (specified) > > No modules in ksyms, skipping objects > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010286 > Warning (Oops_read): Code line not seen, dumping what data is available > > >>EIP; c0136d10 <===== > > Stack: 00000302 00000000 00000000 c13a91c0 00002240 c0134eb7 00000302 00000000 > 00000000 cffe7ed8 cfe6a000 cfe6a044 c01350aa 00000302 00000000 00000000 > cffe7ed8 cfe6a000 c13a91c0 c019e96c 00000302 00000000 00000000 00000000 > Call Trace: [] [] [] [] [] [] [] [] [] > Code: 0f 0b b9 ff ff ff ff 89 fa b6 00 90 8d 74 26 06 8b 44 24 20 > > Trace; c0134eb6 > Trace; c01350aa > Trace; c019e96e > Trace; c01a7a8c > Trace; c01378a8 > Trace; c0137c26 > Trace; c010503a > Trace; c010504c > Trace; c01054e8 > Code; c0136d10 > 00000000 <_EIP>: > Code; c0136d10 > 0: 0f 0b ud2a > Code; c0136d12 > 2: b9 ff ff ff ff mov $0xffffffff,%ecx > Code; c0136d16 > 7: 89 fa mov %edi,%edx > Code; c0136d18 > 9: b6 00 mov $0x0,%dh > Code; c0136d1a > b: 90 nop > Code; c0136d1c > c: 8d 74 26 06 lea 0x6(%esi,1),%esi > Code; c0136d20 > 10: 8b 44 24 20 mov 0x20(%esp,1),%eax > > > 1 warning issued. Results may not be reliable. > From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:11:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFBo202528 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:11:50 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFBY902506 for ; Tue, 12 Feb 2002 07:11:35 -0800 Received: (qmail 4272 invoked from network); 12 Feb 2002 14:12:45 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 12 Feb 2002 14:12:45 -0000 Subject: Re: 2.4.18-pre9-xfs-shawn4 - kmem_cache_alloc oops From: Shawn Starr To: Dag Bakke Cc: Linux , xfs In-Reply-To: <20020212141007.B223@dagb> References: <20020212141007.B223@dagb> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 12 Feb 2002 09:13:49 -0500 Message-Id: <1013523257.262.3.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Interesting, I have CONFIG_PNPBIOS on. What other filesystems do you have or is it just XFS only? Shawn. On Tue, 2002-02-12 at 08:10, Dag Bakke wrote: > After ditching hpfs support, I got the kernel to boot. I do get one > ooops during boot, though. > I'll try ditching CONFIG_PNPBIOS and see if that makes a difference. > > Thanks, > > Dag B > > > > root@dagb:/usr/src/kernelpatches# ksymoops < ~dagb/kerneloops2.txt > ksymoops 2.4.3 on i686 2.4.18-pre9-xfs-shawn4. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.18-pre9-xfs-shawn4/ (default) > -m /usr/src/linux/System.map (default) > > Warning: You did not tell me where to find symbol information. I will > assume that the log matches the kernel and modules that are running > right now and I'll use the default options above for symbol resolution. > If the current kernel and/or modules do not match the log, you can get > more accurate output by telling me the kernel version and where to find > map, modules, ksyms etc. ksymoops -h explains the options. > > Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c02fb0c0, System.map says c0150450. Ignoring ksyms_base entry > Unable to handle kernel NULL pointer dereference at virtual address 0000002c > c012a994 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010046 > eax: 00000000 ebx: 00000008 ecx: c1374000 edx: 00000000 > esi: 00000000 edi: c0444880 ebp: 000001f0 esp: c1375f90 > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid: 2, stackpage=c1375000) > Stack: 00000000 00000000 c0444880 c1375fd4 c011d6f8 00000000 000001f0 c1374000 > 00000000 00000000 c011f6c3 00000000 00010f00 cffe7fb8 c0114982 00000000 > 00000000 0008e000 c02d67b1 00010f00 cffe7fb8 00000000 0008e000 c01054df > Call Trace: [] [] [] [] [] > [] > Code: f6 46 2c 01 74 02 0f 0b 9c 5f fa 8b 4e 08 39 d9 75 22 8b 4e > > >>EIP; c012a994 <===== > Trace; c011d6f8 > Trace; c011f6c2 > Trace; c0114982 > Trace; c02d67b0 > Trace; c01054de > Trace; c01054e8 > Code; c012a994 > 00000000 <_EIP>: > Code; c012a994 <===== > 0: f6 46 2c 01 testb $0x1,0x2c(%esi) <===== > Code; c012a998 > 4: 74 02 je 8 <_EIP+0x8> c012a99c > Code; c012a99a > 6: 0f 0b ud2a > Code; c012a99c > 8: 9c pushf > Code; c012a99c > 9: 5f pop %edi > Code; c012a99e > a: fa cli > Code; c012a99e > b: 8b 4e 08 mov 0x8(%esi),%ecx > Code; c012a9a2 > e: 39 d9 cmp %ebx,%ecx > Code; c012a9a4 > 10: 75 22 jne 34 <_EIP+0x34> c012a9c8 > Code; c012a9a6 > 12: 8b 4e 00 mov 0x0(%esi),%ecx > > > 2 warnings issued. Results may not be reliable. > From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:16:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFGsk03930 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:16:54 -0800 Received: from cala ([62.98.122.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFGn903908 for ; Tue, 12 Feb 2002 07:16:50 -0800 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by cala with esmtp (Exim 3.33 #1 (Debian)) id 16ac7Y-000737-00 for ; Tue, 12 Feb 2002 13:33:16 +0100 Subject: I need a patch to make XFS work with debian apt From: Mario Giammarco To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Feb 2002 13:33:15 +0100 Message-Id: <1013517196.3453.4.camel@cala> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have kernel 2.4.17 and I patched it with 2.4.17 xfs patch that I have found in SGI web site. But I use also debian and apt suite has some problems and gives me segmentation faults. Reading past mails I have seen there is a "bug" in xfs code. So I ask: where can I find a patch that makes apt work again? Thank you very much for your help! -- Mario Giammarco From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:18:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFIDJ05807 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:18:13 -0800 Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFI1905776 for ; Tue, 12 Feb 2002 07:18:02 -0800 Received: from localhost (pozsy@localhost) by balu.sch.bme.hu (8.9.3+Sun/8.9.2) with ESMTP id PAA16619; Tue, 12 Feb 2002 15:17:40 +0100 (MET) Date: Tue, 12 Feb 2002 15:17:39 +0100 (MET) From: Pozsar Balazs X-Sender: To: Shawn Starr cc: Dag Bakke , Linux , xfs Subject: Re: 2.4.18-pre9-xfs-shawn4 - hpfs bug In-Reply-To: <1013523397.263.6.camel@unaropia> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I also get an oops with 2.4.18-pre9-ac1, pnpbios compiled in, but no xfs. So I think this is a pnpbios problem. On 12 Feb 2002, Shawn Starr wrote: > Some others have reported problems with superblock reading on boot. > There may be some code that has changed superblock reading but this > might be different. > > Shawn. > > > On Tue, 2002-02-12 at 08:00, Dag Bakke wrote: > > Hi. > > > > Compiling in support for hpfs in 2.4.18-pre9-xfs-shawn4 causes panic on > > boot. > > (I do have a some devicedriver patches added to your patch, but nothing related to > > core, vfs or hpfs.) > > > > Thanks, > > > > Dag B > > > > > > root@dagb:~# ksymoops -L -m /boot/System.map -K <~dagb/kernelcrash.txt > > ksymoops 2.4.3 on i686 2.4.18-pre9-xfs-shawn4. Options used > > -V (default) > > -K (specified) > > -L (specified) > > -o /lib/modules/2.4.18-pre9-xfs-shawn4/ (default) > > -m /boot/System.map (specified) > > > > No modules in ksyms, skipping objects > > invalid operand: 0000 > > CPU: 0 > > EIP: 0010:[] Not tainted > > Using defaults from ksymoops -t elf32-i386 -a i386 > > EFLAGS: 00010286 > > Warning (Oops_read): Code line not seen, dumping what data is available > > > > >>EIP; c0136d10 <===== > > > > Stack: 00000302 00000000 00000000 c13a91c0 00002240 c0134eb7 00000302 00000000 > > 00000000 cffe7ed8 cfe6a000 cfe6a044 c01350aa 00000302 00000000 00000000 > > cffe7ed8 cfe6a000 c13a91c0 c019e96c 00000302 00000000 00000000 00000000 > > Call Trace: [] [] [] [] [] [] [] [] [] > > Code: 0f 0b b9 ff ff ff ff 89 fa b6 00 90 8d 74 26 06 8b 44 24 20 > > > > Trace; c0134eb6 > > Trace; c01350aa > > Trace; c019e96e > > Trace; c01a7a8c > > Trace; c01378a8 > > Trace; c0137c26 > > Trace; c010503a > > Trace; c010504c > > Trace; c01054e8 > > Code; c0136d10 > > 00000000 <_EIP>: > > Code; c0136d10 > > 0: 0f 0b ud2a > > Code; c0136d12 > > 2: b9 ff ff ff ff mov $0xffffffff,%ecx > > Code; c0136d16 > > 7: 89 fa mov %edi,%edx > > Code; c0136d18 > > 9: b6 00 mov $0x0,%dh > > Code; c0136d1a > > b: 90 nop > > Code; c0136d1c > > c: 8d 74 26 06 lea 0x6(%esi,1),%esi > > Code; c0136d20 > > 10: 8b 44 24 20 mov 0x20(%esp,1),%eax > > > > > > 1 warning issued. Results may not be reliable. > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Balazs Pozsar From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:42:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFgKO06306 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:42:20 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFgG906284 for ; Tue, 12 Feb 2002 07:42:16 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA1864167 for ; Tue, 12 Feb 2002 15:42:13 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA89529; Tue, 12 Feb 2002 06:41:41 -0800 (PST) Date: Tue, 12 Feb 2002 08:41:41 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Mario Giammarco cc: Subject: Re: I need a patch to make XFS work with debian apt In-Reply-To: <1013517196.3453.4.camel@cala> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Mario - I have never heard of XFS causing problems with apt. Can you run your apt command through strace to see On 12 Feb 2002, Mario Giammarco wrote: > Hello, > I have kernel 2.4.17 and I patched it with 2.4.17 xfs patch that I have > found in SGI web site. > But I use also debian and apt suite has some problems and gives me > segmentation faults. > Reading past mails I have seen there is a "bug" in xfs code. So I ask: > where can I find a patch that makes apt work again? > > Thank you very much for your help! > From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:45:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFjFq06469 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:45:15 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFjC906447 for ; Tue, 12 Feb 2002 07:45:12 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA1874541 for ; Tue, 12 Feb 2002 15:45:03 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA77100; Tue, 12 Feb 2002 06:44:33 -0800 (PST) Date: Tue, 12 Feb 2002 08:44:32 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Mario Giammarco cc: Subject: Re: I need a patch to make XFS work with debian apt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Feb 2002, Eric Sandeen wrote: > Hi Mario - > > I have never heard of XFS causing problems with apt. Can you run your apt > command through strace to see Whoops.. :) ... to see why it's failing? Are you certain that it's only failing with the XFS kernel? -Eric From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:51:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFp5306661 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:51:05 -0800 Received: from fruit.eu.org (qmailr@34dyn21.com21.casema.net [212.64.15.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFp1906639 for ; Tue, 12 Feb 2002 07:51:01 -0800 Received: (qmail 86656 invoked by uid 500); 12 Feb 2002 14:50:57 -0000 Date: Tue, 12 Feb 2002 15:50:57 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: I need a patch to make XFS work with debian apt Message-ID: <20020212155057.Q22191@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sandeen@sgi.com on Tue, Feb 12, 2002 at 08:44:32AM -0600 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 2002-02-12 08:44:32-0600, Eric Sandeen wrote: > On Tue, 12 Feb 2002, Eric Sandeen wrote: > > > Hi Mario - > > > > I have never heard of XFS causing problems with apt. Can you run your apt > > command through strace to see > > Whoops.. :) > > ... to see why it's failing? Are you certain that it's only failing with > the XFS kernel? Apt uses db files and there was a problem with mmap() some time ago which affected these files. Lucky for Mario these files are merely caches of other files. Perhaps you should back them up first to be sure, but: rm /var/cache/apt/*pkgcache.bin should do it. -- Wessel Dankers Dew on the telephone lines. From owner-linux-xfs@oss.sgi.com Tue Feb 12 07:51:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CFpKT06784 for linux-xfs-outgoing; Tue, 12 Feb 2002 07:51:20 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CFpG906758 for ; Tue, 12 Feb 2002 07:51:16 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 GAA19739 for ; Tue, 12 Feb 2002 06:46:47 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA79607; Tue, 12 Feb 2002 08:49:58 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA32778; Tue, 12 Feb 2002 08:49:58 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1CEn0g19717; Tue, 12 Feb 2002 08:49:00 -0600 Subject: Re: I need a patch to make XFS work with debian apt From: Steve Lord To: Eric Sandeen Cc: Mario Giammarco , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Feb 2002 08:49:00 -0600 Message-Id: <1013525340.19605.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-12 at 08:44, Eric Sandeen wrote: > On Tue, 12 Feb 2002, Eric Sandeen wrote: > > > Hi Mario - > > > > I have never heard of XFS causing problems with apt. Can you run your apt > > command through strace to see > > Whoops.. :) > > ... to see why it's failing? Are you certain that it's only failing with > the XFS kernel? > > -Eric Eric, the mmap failure which showed up in bitkeeper also generated some comments from debian folks. I don't think that fix is anywhere but cvs. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 12 08:05:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CG5fV08926 for linux-xfs-outgoing; Tue, 12 Feb 2002 08:05:41 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CG5c908899 for ; Tue, 12 Feb 2002 08:05:38 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) 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 HAA03101 for ; Tue, 12 Feb 2002 07:05:32 -0800 (PST) mail_from (alan@lxorguk.ukuu.org.uk) Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16aecO-00025H-00; Tue, 12 Feb 2002 15:13:16 +0000 Subject: Re: 2.4.18-pre9-xfs-shawn4 - hpfs bug To: pozsy@sch.bme.hu (Pozsar Balazs) Date: Tue, 12 Feb 2002 15:13:16 +0000 (GMT) Cc: spstarr@sh0n.net (Shawn Starr), dag@bakke.com (Dag Bakke), linux-kernel@vger.kernel.org (Linux), linux-xfs@oss.sgi.com (xfs) In-Reply-To: from "Pozsar Balazs" at Feb 12, 2002 03:17:39 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I also get an oops with 2.4.18-pre9-ac1, pnpbios compiled in, but no xfs. > So I think this is a pnpbios problem. At the moment there are a couple of pnpbios related problems that need fixing. One of them is -ac kernel triggered due to the way the pnpbios docking thread is created, the other is the inability of some bios vendors to read documentation and may be harder to cure For the moment assume its the docking thread. I'll fix that soonish From owner-linux-xfs@oss.sgi.com Tue Feb 12 08:05:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CG5eK08921 for linux-xfs-outgoing; Tue, 12 Feb 2002 08:05:40 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CG5X908876 for ; Tue, 12 Feb 2002 08:05:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02604 for ; Tue, 12 Feb 2002 07:06:48 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA79594; Tue, 12 Feb 2002 09:04:17 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA21147; Tue, 12 Feb 2002 09:04:16 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1CF3IE19812; Tue, 12 Feb 2002 09:03:18 -0600 Subject: Re: I need a patch to make XFS work with debian apt From: Steve Lord To: Steve Lord Cc: Eric Sandeen , Mario Giammarco , linux-xfs@oss.sgi.com In-Reply-To: <1013525340.19605.0.camel@jen.americas.sgi.com> References: <1013525340.19605.0.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Feb 2002 09:03:18 -0600 Message-Id: <1013526198.19775.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-12 at 08:49, Steve Lord wrote: > On Tue, 2002-02-12 at 08:44, Eric Sandeen wrote: > > On Tue, 12 Feb 2002, Eric Sandeen wrote: > > > > > Hi Mario - > > > > > > I have never heard of XFS causing problems with apt. Can you run your apt > > > command through strace to see > > > > Whoops.. :) > > > > ... to see why it's failing? Are you certain that it's only failing with > > the XFS kernel? > > > > -Eric > > Eric, the mmap failure which showed up in bitkeeper also generated > some comments from debian folks. I don't think that fix is anywhere > but cvs. > Just following up, this is the mod information, you need these revisions of these files from cvs: > Date: Wed Jan 30 12:55:07 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:110651a > linux/fs/buffer.c - 1.100 > - Fix up return values used in xfs writepage call, plus a couple > of other tweaks. > > linux/fs/xfs/linux/xfs_iops.c - 1.120 > - Fix up return values used in xfs writepage > > linux/fs/xfs/pagebuf/page_buf_io.c - 1.5 > - No longer return a count of pages written in the write full page > path, > and ensure that we write out pages passed into writepage from the > mmap path. There is a patch against 2.4.17 which was made on Feb 10th: ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4.17-xfs-2002-02-10.cvs-patch.bz2 Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 12 13:15:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CLFct25071 for linux-xfs-outgoing; Tue, 12 Feb 2002 13:15:38 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CLFZ925049 for ; Tue, 12 Feb 2002 13:15:35 -0800 Received: from nowaydude.rearden.com ([64.160.169.126] helo=zip.com.au) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16ajKf-0003x5-00; Tue, 12 Feb 2002 20:15:18 +0000 Message-ID: <3C6977A3.1F509184@zip.com.au> Date: Tue, 12 Feb 2002 12:14:27 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-pre9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Shawn Starr CC: Dag Bakke , Linux , xfs Subject: Re: 2.4.18-pre9-xfs-shawn4 - kmem_cache_alloc oops References: <20020212141007.B223@dagb>, <20020212141007.B223@dagb> <1013523257.262.3.camel@unaropia> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Shawn Starr wrote: > > Interesting, I have CONFIG_PNPBIOS on. > What other filesystems do you have or is it just XFS only? > Known bug in -ac kernels. It's due to initialisation-order disagreement between Alan and I. It looks like Alan has fixed it in 2.4.18-pre9-ac2. For earlier -ac's, disable the pnpbios driver in config. - From owner-linux-xfs@oss.sgi.com Tue Feb 12 13:22:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CLMsp25234 for linux-xfs-outgoing; Tue, 12 Feb 2002 13:22:54 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CLMp925212 for ; Tue, 12 Feb 2002 13:22:51 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA04365 for ; Tue, 12 Feb 2002 12:24:06 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA45663 for ; Tue, 12 Feb 2002 14:21:34 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA32373 for ; Tue, 12 Feb 2002 14:21:34 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1CKKYc31035; Tue, 12 Feb 2002 14:20:34 -0600 Message-Id: <200202122020.g1CKKYc31035@jen.americas.sgi.com> Date: Tue, 12 Feb 2002 14:20:34 -0600 Subject: TAKE - minor code cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk use defined constants for iclog counts Date: Tue Feb 12 12:20:29 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111602a linux/fs/xfs/xfs_vfsops.c - 1.334 linux/fs/xfs/linux/xfs_super.c - 1.155 From owner-linux-xfs@oss.sgi.com Tue Feb 12 13:56:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CLuum25748 for linux-xfs-outgoing; Tue, 12 Feb 2002 13:56:56 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CLuq925726 for ; Tue, 12 Feb 2002 13:56:52 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1CLulxV004525 for ; Tue, 12 Feb 2002 13:56:47 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA84259 for ; Tue, 12 Feb 2002 14:55:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA86770 for ; Tue, 12 Feb 2002 14:55:31 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1CKtVb29136; Tue, 12 Feb 2002 14:55:31 -0600 Message-Id: <200202122055.g1CKtVb29136@stout.americas.sgi.com> Date: Tue, 12 Feb 2002 14:55:31 -0600 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:110771a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Actually only a small part of this mod applies to Linux... Date: Tue Feb 12 12:54:33 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111610a linux/fs/xfs/xfs_dmapi.c - 1.47 - Merge irix6.5f:irix:110771a Update xfs_dm_get_bulkattr_rvp() to detect a buffer that is too big for xfs_bulkstat&friends to handle. From owner-linux-xfs@oss.sgi.com Tue Feb 12 13:59:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CLxUh25891 for linux-xfs-outgoing; Tue, 12 Feb 2002 13:59:30 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CLxR925869 for ; Tue, 12 Feb 2002 13:59:27 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1CLxMxV004698 for ; Tue, 12 Feb 2002 13:59:23 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA84162 for ; Tue, 12 Feb 2002 14:58:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA22443 for ; Tue, 12 Feb 2002 14:58:06 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1CKw6l29534; Tue, 12 Feb 2002 14:58:06 -0600 Message-Id: <200202122058.g1CKw6l29534@stout.americas.sgi.com> Date: Tue, 12 Feb 2002 14:58:06 -0600 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:110411a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Feb 12 12:57:22 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111611a linux/fs/xfs/xfs_log_recover.c - 1.218 - Merge irix6.5f:irix:110411a No need to look at UUID and DEV cases in the inode recovery case statement, they are already handled. This was breaking debug kernel.s From owner-linux-xfs@oss.sgi.com Wed Feb 13 05:21:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DDLHY09821 for linux-xfs-outgoing; Wed, 13 Feb 2002 05:21:17 -0800 Received: from eowyn.vianetworks.nl (eowyn.iae.nl [212.61.25.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DDLA909795 for ; Wed, 13 Feb 2002 05:21:11 -0800 Received: from fikkie.vesc.nl (asadm01d425.dialin.vianetworks.nl [195.38.255.171]) by eowyn.vianetworks.nl (Postfix) with ESMTP id 5147D20F17 for ; Wed, 13 Feb 2002 13:20:56 +0100 (CET) Received: (from wwwrun@localhost) by fikkie.vesc.nl (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id NAA26371; Wed, 13 Feb 2002 13:13:55 +0100 Date: Wed, 13 Feb 2002 13:13:55 +0100 Message-Id: <200202131213.NAA26371@fikkie.vesc.nl> From: "E. Abbink" To: linux-xfs@oss.sgi.com Reply-To: e.abbink@chello.nl Subject: xfsdump aborts after assertion failure X-Mailer: NeoMail 1.25 X-IPAddress: 192.0.0.12 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, i have a problem dumping my xfs filesystem. setup: 2.4.17 stock kernel patched with latest(1.0.2) xfs and various (suse) patches. xfsdump & xfsprogs are downloaded latest versions as well. xfs filesystem mounted in root reiser filesystem. xfs filesystem is a LVM on MD raid1. backup device is a tandberg slr24 on a adaptec 78xx. when i try to backup a test directory on the xfs filesystem with the following command: xfsdump -o -m -b 1024 -f /dev/st0 -s backup_test /fsdata i get the following assertion: .. xfsdump: dumping ino map xfsdump: drive_minrmt.c:1862: do_get_write_buf: Assertion 'contextp->dc_nextp < contextp->dc_recendp' failed. Aborted Note that the Aborted line does not _immediately_ follow the assertion line, some time passes. If anyone could shed any light on this that would be very helpful as i'm kinda stumped atm. Esger -- NeoMail - Webmail that doesn't suck... as much. http://neomail.sourceforge.net From owner-linux-xfs@oss.sgi.com Wed Feb 13 08:26:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DGQPR20754 for linux-xfs-outgoing; Wed, 13 Feb 2002 08:26:25 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DGQK920731 for ; Wed, 13 Feb 2002 08:26:20 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1DFQEtm020810 for ; Wed, 13 Feb 2002 07:26:14 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA91584 for ; Wed, 13 Feb 2002 09:24:59 -0600 (CST) Received: from lord.americas.sgi.com (lord.americas.sgi.com [128.162.187.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA24341 for ; Wed, 13 Feb 2002 09:24:59 -0600 (CST) From: Steve Lord Received: by lord.americas.sgi.com (8.11.2/SGI-client-1.7) id g1DFOn502317; Wed, 13 Feb 2002 09:24:49 -0600 Message-Id: <200202131524.g1DFOn502317@lord.americas.sgi.com> Date: Wed, 13 Feb 2002 09:24:49 -0600 Subject: TAKE - speed up acl enabled kernel Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This reduced the performance drop introduced when you turn on the posix acl code. In the case where the code is turned on, but no acls are present then the speed difference is now very small. Date: Wed Feb 13 07:23:28 PST 2002 Workarea: lord.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:111679a linux/fs/xfs/xfs_attr_fetch.c - 1.9 linux/fs/xfs/xfs_attr.c - 1.86 - Optimize the case where there are no extended attributes linux/fs/xfs/xfs_dinode.h - 1.58 - Remove endian conversion from some macros which are always used on local byte order structures. From owner-linux-xfs@oss.sgi.com Wed Feb 13 10:22:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DIMn827509 for linux-xfs-outgoing; Wed, 13 Feb 2002 10:22:49 -0800 Received: from ws0021 (development.webstream.net [63.77.144.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DIMi927487 for ; Wed, 13 Feb 2002 10:22:44 -0800 Date: Wed, 13 Feb 2002 10:22:44 -0800 Message-Id: <200202131822.g1DIMi927487@oss.sgi.com> To: linux-xfs@oss.sgi.com From: josh.winters@webstream.net Subject: We would like to get some information on your company Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, We would like to get some info or a media kit on your company in an effort to explore the ways that we might be able to work together. We have been developing and hosting web sites since 1997. We offer low-cost design, programming, hosting and traffic generation. We support Linux, WinNT and AS400. We also offer webcasting, video conferenceing, on-line training and other streaming media applications designed to save you money and enhance your on-line image. Our channel marketing program allows you to become a reseller of our services and create a revenue share for yourself. Please forward this to the proper party, or respond to the address below. You can also visit our web site at http://webstream.net for more information on our services. If by e-mail: josh.winters@webstream.net If by mail: WebStream Internet Solutions Outsourcing/Purchasing 2200 W.Commercial Blvd. Suite 204 Ft. Lauderdale, FL 33309 USA Thank you very much. Sincerely, Josh Winters josh.winters@webstream.net http://webstream.net Design * Programming * Hosting * WebCasting * Since 1997 From owner-linux-xfs@oss.sgi.com Wed Feb 13 12:13:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DKDkx01943 for linux-xfs-outgoing; Wed, 13 Feb 2002 12:13:46 -0800 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DKDZ901918 for ; Wed, 13 Feb 2002 12:13:36 -0800 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA04594 for ; Wed, 13 Feb 2002 14:13:28 -0500 Subject: Re: We would like to get some information on your company From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <200202131822.g1DIMi927487@oss.sgi.com> References: <200202131822.g1DIMi927487@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 14:13:21 -0500 Message-Id: <1013627602.6288.34.camel@two.nks.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-13 at 13:22, josh.winters@webstream.net wrote: > Hello, > > We would like to get some info or a media kit on your company in an effort to explore the ways that we might be able to work together. We have been developing and hosting web sites since 1997. We offer low-cost design, programming, hosting and traffic generation. We support Linux, WinNT and AS400. > > We also offer webcasting, video conferenceing, on-line training and other streaming media applications designed to save you money and enhance your on-line image. [snip] Um, yeah... I'm sure a company like SGI is in need of expertise in web development. I'm sure they need someone who understands WinNT, Linux and AS/400 (but not IRIX obviously...). And I bet they're really having a hard time coming to grips with things like webcasting and video conferencing. This is about the funniest by being most misappropriate SPAM I've ever seen. :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed Feb 13 12:22:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DKM0502307 for linux-xfs-outgoing; Wed, 13 Feb 2002 12:22:00 -0800 Received: from PCS001C.pcs-telcom.com ([207.247.149.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DKLr902284 for ; Wed, 13 Feb 2002 12:21:54 -0800 Received: by pcs001c.pcs-telcom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 11:13:25 -0800 Message-ID: From: Ted Hazlewood To: "'linux-xfs@oss.sgi.com'" Subject: Help Date: Wed, 13 Feb 2002 11:13:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm running RedHat 7.2 build from your RedHat 7.2 ISO XFS ver 1.02 with Samba 2.2.3a and Winbind This comes with Kernel 2.4.9 My other machine (Machine2) is RedHat 7.2 ext3 with Kernel 2.4.17 with POSIX ACL Samba 2.2.3a and Winbind What I was doing with Machine2 was using Winbind from Samba to use a Windows NT PDC to get usernames and group names from. With this config I could add and remove multiple users and groups using my Windows Explorer and make multiple ACE changes. This was great but we like the performance of XFS. The POSIX ACL site doesn't have patches to work with XFS. The site is http://acl.bestbits.at/ They are on version 0.7.27 The only version of POSIX ACL I can find that your XFS ver 1.02 has is an RPM ver acl-1.1.3-0. I don't see any correlation of version numbers except the kernel they are configured for. With your version of POSIX ACL I am not able to make any changes from a Windows Explorer. I have spoken to the SAMBA Team and they first thought they had a bug in the new 2.2.3a. But I can get it to work with ext3 so now I think that the problem is the version of POSIX ACL you have included in ver 1.02. What I would like to try is either installing RedHat 7.2 with XFS ver 1.02 without POSIX ACL and then recompile with Kernel 2.4.17 and ACL POSIX 0.7.27. If this is possible. Or if there already is a fix for my problem that you may know about. Either way I need assistance from the awesome creators of XFS. Is there source of XFS ver 1.02 without ACL or do you know of a way to update XFS ver 1.02 to the ACL POSIX 0.7.27 and later kernel if needed. Any help would be appreciated. Ted Hazlewood Senior Systems Administrator Public Communications Services (310) 954-3024 Phone (310) 954-2139 Fax ted.hazlewood@teampcs.com From owner-linux-xfs@oss.sgi.com Wed Feb 13 12:51:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DKp6s02948 for linux-xfs-outgoing; Wed, 13 Feb 2002 12:51:06 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DKou902922 for ; Wed, 13 Feb 2002 12:50:56 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1DJoB431568; Wed, 13 Feb 2002 13:50:11 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Help From: Austin Gonyou To: Ted Hazlewood Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 13:50:11 -0600 Message-Id: <1013629811.31543.10.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd recommend using the POSIX ACLs that come with a xfs kernel, then go get the helper programs from CVS for that patch version. (acl, etc is in there) On Wed, 2002-02-13 at 13:13, Ted Hazlewood wrote: > I'm running RedHat 7.2 build from your RedHat 7.2 ISO XFS ver 1.02 with > Samba 2.2.3a and Winbind > > This comes with Kernel 2.4.9 > > My other machine (Machine2) is RedHat 7.2 ext3 with Kernel 2.4.17 with > POSIX ACL Samba 2.2.3a and Winbind > > What I was doing with Machine2 was using Winbind from Samba to use a > Windows > NT PDC to get usernames and group names from. > With this config I could add and remove multiple users and groups using > my > Windows Explorer and make multiple ACE changes. > This was great but we like the performance of XFS. > > The POSIX ACL site doesn't have patches to work with XFS. The site is > http://acl.bestbits.at/ They are on version 0.7.27 > The only version of POSIX ACL I can find that your XFS ver 1.02 has is > an > RPM ver acl-1.1.3-0. I don't see any correlation of version numbers > except > the kernel they are configured for. > > > With your version of POSIX ACL I am not able to make any changes from a > Windows Explorer. I have spoken to the SAMBA Team and they first > thought > they had a bug in the new 2.2.3a. But I can get it to work with ext3 so > now > I think that the problem is the version of POSIX ACL you have included > in > ver 1.02. > > What I would like to try is either installing RedHat 7.2 with XFS ver > 1.02 > without POSIX ACL and then recompile with Kernel 2.4.17 and ACL POSIX > 0.7.27. If this is possible. > Or if there already is a fix for my problem that you may know about. > > Either way I need assistance from the awesome creators of XFS. > > Is there source of XFS ver 1.02 without ACL or do you know of a way to > update XFS ver 1.02 to the ACL POSIX 0.7.27 and later kernel if needed. > > Any help would be appreciated. > > > Ted Hazlewood > Senior Systems Administrator > Public Communications Services > (310) 954-3024 Phone > (310) 954-2139 Fax > ted.hazlewood@teampcs.com > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Wed Feb 13 12:56:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DKuF603169 for linux-xfs-outgoing; Wed, 13 Feb 2002 12:56:15 -0800 Received: from chimta02 (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DKu5903127 for ; Wed, 13 Feb 2002 12:56:05 -0800 Received: from jtsdell (66-2-81-28.customer.algx.net [66.2.81.28]) by chimmx02.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GRH004BNM1GDR@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Wed, 13 Feb 2002 13:56:05 -0600 (CST) Date: Wed, 13 Feb 2002 14:54:42 -0500 (EST) From: jtrostel@snapserver.com Subject: Re: Help In-reply-to: <1013629811.31543.10.camel@UberGeek> To: "linux-xfs@oss.sgi.com" Cc: Ted Hazlewood Reply-to: jtrostel@snapserver.com Message-id: Organization: Quantum Corp. / NASD MIME-version: 1.0 X-Mailer: XFMail 1.5.2 on Linux Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I agree with Austin.. I use the current CVS of the XFS kernel and ACLs with the HEAD branch of Samba without trouble. It adds in multiple users and groups from the AD domain no problem. On 13-Feb-2002 Austin Gonyou wrote: > I'd recommend using the POSIX ACLs that come with a xfs kernel, then go > get the helper programs from CVS for that patch version. (acl, etc is in > there) > > On Wed, 2002-02-13 at 13:13, Ted Hazlewood wrote: >> I'm running RedHat 7.2 build from your RedHat 7.2 ISO XFS ver 1.02 with >> Samba 2.2.3a and Winbind >> >> This comes with Kernel 2.4.9 >> >> My other machine (Machine2) is RedHat 7.2 ext3 with Kernel 2.4.17 with >> POSIX ACL Samba 2.2.3a and Winbind >> >> What I was doing with Machine2 was using Winbind from Samba to use a >> Windows >> NT PDC to get usernames and group names from. >> With this config I could add and remove multiple users and groups using >> my >> Windows Explorer and make multiple ACE changes. >> This was great but we like the performance of XFS. >> >> The POSIX ACL site doesn't have patches to work with XFS. The site is >> http://acl.bestbits.at/ They are on version 0.7.27 >> The only version of POSIX ACL I can find that your XFS ver 1.02 has is >> an >> RPM ver acl-1.1.3-0. I don't see any correlation of version numbers >> except >> the kernel they are configured for. >> >> >> With your version of POSIX ACL I am not able to make any changes from a >> Windows Explorer. I have spoken to the SAMBA Team and they first >> thought >> they had a bug in the new 2.2.3a. But I can get it to work with ext3 so >> now >> I think that the problem is the version of POSIX ACL you have included >> in >> ver 1.02. >> >> What I would like to try is either installing RedHat 7.2 with XFS ver >> 1.02 >> without POSIX ACL and then recompile with Kernel 2.4.17 and ACL POSIX >> 0.7.27. If this is possible. >> Or if there already is a fix for my problem that you may know about. >> >> Either way I need assistance from the awesome creators of XFS. >> >> Is there source of XFS ver 1.02 without ACL or do you know of a way to >> update XFS ver 1.02 to the ACL POSIX 0.7.27 and later kernel if needed. >> >> Any help would be appreciated. >> >> >> Ted Hazlewood >> Senior Systems Administrator >> Public Communications Services >> (310) 954-3024 Phone >> (310) 954-2139 Fax >> ted.hazlewood@teampcs.com >> > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Wed Feb 13 12:58:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DKwkU03331 for linux-xfs-outgoing; Wed, 13 Feb 2002 12:58:46 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DKwf903301 for ; Wed, 13 Feb 2002 12:58:41 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id LAA08638 for ; Wed, 13 Feb 2002 11:59:57 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA18806; Thu, 14 Feb 2002 06:57:23 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id GAA18145; Thu, 14 Feb 2002 06:57:22 +1100 (AEDT) Date: Thu, 14 Feb 2002 06:57:21 +1100 From: Nathan Scott To: Ted Hazlewood Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Help Message-ID: <20020214065721.A143574@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ted.hazlewood@teampcs.com on Wed, Feb 13, 2002 at 11:13:20AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 13, 2002 at 11:13:20AM -0800, Ted Hazlewood wrote: > The POSIX ACL site doesn't have patches to work with XFS. The site is > http://acl.bestbits.at/ They are on version 0.7.27 > > The only version of POSIX ACL I can find that your XFS ver 1.02 has is an > RPM ver acl-1.1.3-0. I don't see any correlation of version numbers except > the kernel they are configured for. There is no correlation at this stage. There are currently two different sets of ACL userspace - you must have one or the other and not both, which means only one of XFS and ext2 (or ext3) can be using ACLs at any one time. We expect to remedy this long-standing problem soon (2.4.18 + new ACL userspace), but until then you're stuck with the status quo, unfortunately. > With your version of POSIX ACL I am not able to make any changes from a > Windows Explorer. I have spoken to the SAMBA Team and they first thought > they had a bug in the new 2.2.3a. But I can get it to work with ext3 so now > I think that the problem is the version of POSIX ACL you have included in > ver 1.02. > > What I would like to try is either installing RedHat 7.2 with XFS ver 1.02 > without POSIX ACL and then recompile with Kernel 2.4.17 and ACL POSIX > 0.7.27. If this is possible. No, that's not currently possible due to the userspace/syscall differences. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 13 13:05:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DL5Ip03617 for linux-xfs-outgoing; Wed, 13 Feb 2002 13:05:18 -0800 Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DL54903595 for ; Wed, 13 Feb 2002 13:05:04 -0800 Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel13.hp.com (Postfix) with ESMTP id 90C2340050F for ; Wed, 13 Feb 2002 12:04:59 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 782AABD for ; Wed, 13 Feb 2002 12:04:54 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id <1KHMWYWD>; Wed, 13 Feb 2002 12:04:54 -0800 Message-ID: From: "DICKENS,CARY (HP-Loveland,ex2)" To: "Xfs Mailing List (E-mail)" Subject: trouble implementing default quotas Date: Wed, 13 Feb 2002 12:04:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm implementing a default quota scheme on xfs and have something weird going on that I don't understand. I am using a recent cvs snapshot and linux 2.4.17. I want to use root to store the default user and group quota and only enforce the default quota if a user doesn't have an explicit quota set. When I apply this patch, I lock up when a user, with or without a quota, tries to write to the disk. When I copy some files to the filesystem with my altered xfs, it appears to lock up returning from the xfs_create call in xfs_vnodeops.c. It leaves this function via std_return with error 0, but the console never returns a prompt. Without my patch, all appears ok, so I know I'm doing something screwy. I just don't know what. Any help would be appreciated. If this is a duplicate post, I'm sorry. I sent one Tuesday night and never saw it hit the list, so I'm trying again. Cary diff -Nur linux.orig/fs/xfs/xfs_trans_dquot.c linux/fs/xfs/xfs_trans_dquot.c --- linux.orig/fs/xfs/xfs_trans_dquot.c Thu Feb 7 13:02:57 2002 +++ linux/fs/xfs/xfs_trans_dquot.c Fri Feb 8 11:20:09 2002 @@ -573,6 +573,7 @@ xfs_trans_dqresv( xfs_trans_t *tp, xfs_dquot_t *dqp, + xfs_dquot_t *defaultqp, long nblks, long ninos, uint flags) @@ -588,14 +589,22 @@ } ASSERT(XFS_DQ_IS_LOCKED(dqp)); if (flags & XFS_TRANS_DQ_RES_BLKS) { - hardlimit = INT_GET(dqp->q_core.d_blk_hardlimit, ARCH_CONVERT); - softlimit = INT_GET(dqp->q_core.d_blk_softlimit, ARCH_CONVERT); + if ((hardlimit = INT_GET(dqp->q_core.d_blk_hardlimit, ARCH_CONVERT)) == 0) { + hardlimit = INT_GET(defaultqp->q_core.d_blk_hardlimit, ARCH_CONVERT); + } + if ((softlimit = INT_GET(dqp->q_core.d_blk_softlimit, ARCH_CONVERT)) == 0) { + softlimit = INT_GET(defaultqp->q_core.d_blk_hardlimit, ARCH_CONVERT); + } btimer = INT_GET(dqp->q_core.d_btimer, ARCH_CONVERT); resbcountp = &dqp->q_res_bcount; } else { ASSERT(flags & XFS_TRANS_DQ_RES_RTBLKS); - hardlimit = INT_GET(dqp->q_core.d_rtb_hardlimit, ARCH_CONVERT); - softlimit = INT_GET(dqp->q_core.d_rtb_softlimit, ARCH_CONVERT); + if ((hardlimit = INT_GET(dqp->q_core.d_rtb_hardlimit, ARCH_CONVERT)) == 0) { + hardlimit = INT_GET(defaultqp->q_core.d_rtb_hardlimit, ARCH_CONVERT); + } + if ((softlimit = INT_GET(dqp->q_core.d_rtb_softlimit, ARCH_CONVERT)) == 0) { + softlimit = INT_GET(defaultqp->q_core.d_rtb_hardlimit, ARCH_CONVERT); + } btimer = INT_GET(dqp->q_core.d_rtbtimer, ARCH_CONVERT); resbcountp = &dqp->q_res_rtbcount; } @@ -711,6 +720,9 @@ * XFS_TRANS_DQ_RES_RTBLKS reserves realtime disk blocks * dquots are unlocked on return, if they were not locked by caller. */ + + + int xfs_trans_reserve_quota_bydquots( xfs_trans_t *tp, @@ -721,6 +733,8 @@ uint flags) { int resvd; + int error; + xfs_dquot_t *defaultqp; if (tp && tp->t_dqinfo == NULL) xfs_trans_alloc_dqinfo(tp); @@ -729,18 +743,20 @@ resvd = 0; if (udqp) { - if (xfs_trans_dqresv(tp, udqp, nblks, ninos, flags)) + error = xfs_qm_dqget(udqp->q_mount, NULL, 0, XFS_DQ_USER, 0, &defaultqp); + if (xfs_trans_dqresv(tp, udqp, defaultqp, nblks, ninos, flags)) return (EDQUOT); resvd = 1; } if (gdqp) { - if (xfs_trans_dqresv(tp, gdqp, nblks, ninos, flags)) { + error = xfs_qm_dqget(udqp->q_mount, NULL, 0, XFS_DQ_GROUP, 0, &defaultqp); + if (xfs_trans_dqresv(tp, gdqp, defaultqp, nblks, ninos, flags)) { /* * can't do it, so backout previous reservation */ if (resvd) { - xfs_trans_dqresv(tp, udqp, -nblks, -ninos, + xfs_trans_dqresv(tp, udqp, defaultqp, -nblks, -ninos, flags); } return (EDQUOT); From owner-linux-xfs@oss.sgi.com Wed Feb 13 13:33:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DLXbo04092 for linux-xfs-outgoing; Wed, 13 Feb 2002 13:33:37 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DLXS904070 for ; Wed, 13 Feb 2002 13:33:29 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA01260 for ; Wed, 13 Feb 2002 12:33:24 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA95439; Wed, 13 Feb 2002 14:32:05 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA49210; Wed, 13 Feb 2002 14:32:04 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1DKUs415919; Wed, 13 Feb 2002 14:30:54 -0600 Subject: Re: trouble implementing default quotas From: Steve Lord To: "DICKENS,CARY ""(HP-Loveland,ex2)" Cc: Xfs "Mailing List (E-mail)" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 14:30:54 -0600 Message-Id: <1013632254.10461.60.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-13 at 14:04, DICKENS,CARY (HP-Loveland,ex2) wrote: > I'm implementing a default quota scheme on xfs and have something weird > going on that I don't understand. I am using a recent cvs snapshot and > linux 2.4.17. > > I want to use root to store the default user and group quota and only > enforce the default quota if a user doesn't have an explicit quota set. > When I apply this patch, I lock up when a user, with or without a quota, > tries to write to the disk. When I copy some files to the filesystem with > my altered xfs, it appears to lock up returning from the xfs_create call in > xfs_vnodeops.c. It leaves this function via std_return with error 0, but > the console never returns a prompt. > > Without my patch, all appears ok, so I know I'm doing something screwy. I > just don't know what. > > Any help would be appreciated. > > If this is a duplicate post, I'm sorry. I sent one Tuesday night and never > saw it hit the list, so I'm trying again. > > Cary So explain how this is supposed to work. Each user has a quota structure, an xfs_dquot_t which is looked up via xfs_qm_dqget. This is the in memory representation of a user's quota. If quotas are not defined for a specific user then there is no structure, and nothing happens with quotas. So you are trying to implement default quotas for accounts the administrator did not configure one for. Where does the quota space used get recorded, do all user's without a specific quota get to share one pool of quota space? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Feb 13 14:36:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DMaXr06279 for linux-xfs-outgoing; Wed, 13 Feb 2002 14:36:33 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DMaS906256 for ; Wed, 13 Feb 2002 14:36:28 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 NAA17307 for ; Wed, 13 Feb 2002 13:32:03 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA96079 for ; Wed, 13 Feb 2002 15:35:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA89495 for ; Wed, 13 Feb 2002 15:35:10 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1DLXxp16092; Wed, 13 Feb 2002 15:33:59 -0600 Message-Id: <200202132133.g1DLXxp16092@jen.americas.sgi.com> Date: Wed, 13 Feb 2002 15:33:59 -0600 Subject: TAKE - shrink the xfs inode To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This gets us more xfs inodes in a page, and streamlines the locking code a little bit. Date: Wed Feb 13 13:33:50 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.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:111724a linux/fs/xfs/xfsidbg.c - 1.171 - Make pagebuf trace dumping work again, and remove a field which nolonger exists from the xfs inode dump. linux/fs/xfs/xfs_iget.c - 1.151 - remove a layer of call stack from the xfs_ilock code, drop a flag which was never used, and remove the recording of the lock holder. linux/fs/xfs/xfs_inode.h - 1.154 - Remove some fields from the xfs inode, we now get 9 per page on ia32 rather than 8 per page. Saves quite a chunk of memory when you have lots of inodes linux/fs/xfs/linux/xfs_linux.h - 1.60 - Use the barrier() macro linux/fs/xfs_support/mrlock.c - 1.5 - remove the owner word, we never looked at it and it shrinks the xfs inode nicely. linux/include/linux/xfs_support/mrlock.h - 1.2 - remove owner field from mrlock. From owner-linux-xfs@oss.sgi.com Wed Feb 13 14:50:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DMorw06554 for linux-xfs-outgoing; Wed, 13 Feb 2002 14:50:53 -0800 Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DMon906532 for ; Wed, 13 Feb 2002 14:50:49 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id 0833FC0036C; Wed, 13 Feb 2002 13:11:26 -0800 (PST) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 007F4E000AB; Wed, 13 Feb 2002 13:11:26 -0800 (PST) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id <1FZ2YXL4>; Wed, 13 Feb 2002 13:11:25 -0800 Message-ID: From: "DICKENS,CARY (HP-Loveland,ex2)" To: "'Steve Lord'" Cc: "Xfs \"Mailing List (E-mail)" Subject: RE: trouble implementing default quotas Date: Wed, 13 Feb 2002 13:11:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > So explain how this is supposed to work. Each user has a > quota structure, > an xfs_dquot_t which is looked up via xfs_qm_dqget. This is the in > memory representation of a user's quota. If quotas are not defined for > a specific user then there is no structure, and nothing happens with > quotas. So you are trying to implement default quotas for accounts > the administrator did not configure one for. Where does the > quota space > used get recorded, do all user's without a specific quota get to share > one pool of quota space? > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > My idea was to enforce limits that were defined in the root quota regardless of whether there was a specifically defined quota or not. I thought when accounting was active, and a user wrote to that filesystem, the file was accounted for (xfs_dquot_t created). If enforcement was active, then the system checked for the limits and if they were > 0, then they were enforced. Is an xfs_dquot_t only created when limits are set? Cary From owner-linux-xfs@oss.sgi.com Wed Feb 13 15:06:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DN6vw07030 for linux-xfs-outgoing; Wed, 13 Feb 2002 15:06:57 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DN6n907008 for ; Wed, 13 Feb 2002 15:06:49 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1DM5oV31836; Wed, 13 Feb 2002 16:05:50 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Help From: Austin Gonyou To: Nathan Scott Cc: Ted Hazlewood , "'linux-xfs@oss.sgi.com'" In-Reply-To: <20020214065721.A143574@wobbly.melbourne.sgi.com> References: <20020214065721.A143574@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 16:05:49 -0600 Message-Id: <1013637950.31285.12.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Wow..I had no idea it was such a problem. Thanks for letting us know. On Wed, 2002-02-13 at 13:57, Nathan Scott wrote: > On Wed, Feb 13, 2002 at 11:13:20AM -0800, Ted Hazlewood wrote: > > The POSIX ACL site doesn't have patches to work with XFS. The site is > > http://acl.bestbits.at/ They are on version 0.7.27 > > > > The only version of POSIX ACL I can find that your XFS ver 1.02 has is > an > > RPM ver acl-1.1.3-0. I don't see any correlation of version numbers > except > > the kernel they are configured for. > > There is no correlation at this stage. There are currently two > different sets of ACL userspace - you must have one or the other > and not both, which means only one of XFS and ext2 (or ext3) can > be using ACLs at any one time. > > We expect to remedy this long-standing problem soon (2.4.18 + new > ACL userspace), but until then you're stuck with the status quo, > unfortunately. > > > With your version of POSIX ACL I am not able to make any changes from > a > > Windows Explorer. I have spoken to the SAMBA Team and they first > thought > > they had a bug in the new 2.2.3a. But I can get it to work with ext3 > so now > > I think that the problem is the version of POSIX ACL you have included > in > > ver 1.02. > > > > What I would like to try is either installing RedHat 7.2 with XFS ver > 1.02 > > without POSIX ACL and then recompile with Kernel 2.4.17 and ACL POSIX > > 0.7.27. If this is possible. > > No, that's not currently possible due to the userspace/syscall > differences. > > cheers. > > -- > Nathan -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Wed Feb 13 15:18:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DNIu807386 for linux-xfs-outgoing; Wed, 13 Feb 2002 15:18:56 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DNIr907363 for ; Wed, 13 Feb 2002 15:18:53 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA112824 for ; Wed, 13 Feb 2002 17:15:41 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1DMIpV75408 for ; Wed, 13 Feb 2002 15:18:51 -0700 Subject: DMAPI rights To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Wed, 13 Feb 2002 16:18:50 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/13/2002 03:18:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, Since XFS DMAPI doesn't implement rights, rights obviously can't be attached to tokens. Does this mean that every call requiring a certain level of 'rights' must be called using DM_NO_TOKEN? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Wed Feb 13 16:12:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E0CA108824 for linux-xfs-outgoing; Wed, 13 Feb 2002 16:12:10 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E0C6908802 for ; Wed, 13 Feb 2002 16:12:06 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1DNC0tm013561 for ; Wed, 13 Feb 2002 15:12:00 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA96350; Wed, 13 Feb 2002 17:10:44 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA41283; Wed, 13 Feb 2002 17:10:44 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id RAA08338; Wed, 13 Feb 2002 17:10:43 -0600 (CST) Message-Id: <200202132310.RAA08338@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI rights Date: Wed, 13 Feb 2002 17:10:43 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" >Dean, > >Since XFS DMAPI doesn't implement rights, rights obviously can't be >attached to tokens. Does this mean that every call requiring a certain >level of 'rights' must be called using DM_NO_TOKEN? No, we do attach rights to tokens. It's just that XFS itself knows nothing about the rights and once you step out of the DMAPI code and into the XFS code your rights won't be honored. A dm_request_right/dm_release_right will do a hold/rele on the vnode, at least. Other than that, the rights stuff is a no-op. There's a write-up on rights in fs/xfs_dmapi/dmapi_event.c, though I don't know how much of that reflects the current code. Dean From owner-linux-xfs@oss.sgi.com Wed Feb 13 16:21:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E0Lg009169 for linux-xfs-outgoing; Wed, 13 Feb 2002 16:21:42 -0800 Received: from lucy.physik.tu-cottbus.de (lucy.physik.TU-Cottbus.De [141.43.75.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E0Lc909146 for ; Wed, 13 Feb 2002 16:21:39 -0800 Received: (qmail 226020 invoked from network); 13 Feb 2002 23:21:37 -0000 Received: from mozart.physik.tu-cottbus.de (postfix@141.43.75.26) by lucy.physik.tu-cottbus.de with SMTP; 13 Feb 2002 23:21:37 -0000 Received: by mozart.physik.tu-cottbus.de (Postfix, from userid 7224) id 2898D3754; Thu, 14 Feb 2002 00:21:37 +0100 (CET) Date: Thu, 14 Feb 2002 00:21:37 +0100 To: linux-xfs@oss.sgi.com Subject: kdb: task_has_cpu not found Message-ID: <20020213232136.GA31067@physik.tu-cottbus.de> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i From: george@physik.tu-cottbus.de (Ionut Georgescu) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, i was trying to compile a 2.4.17 kernel with the cvs patch from 20020210. However, linking the kernel fails because task_has_cpu, which is called in kdbmain.c, is not defined. Indeed, grep -r task_has_cpu * in the linux tree showed only one occurence: the one in kdbmain. Am I missing something here ? Ionut -- *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * Registered Linux User #244479 * * "In Windows you can do everything Microsoft wants you to do; in Unix you * can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Wed Feb 13 16:29:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E0TvC09741 for linux-xfs-outgoing; Wed, 13 Feb 2002 16:29:57 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E0Tq909718 for ; Wed, 13 Feb 2002 16:29:52 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1957164 for ; Thu, 14 Feb 2002 00:29:49 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA97248; Wed, 13 Feb 2002 17:28:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA92041; Wed, 13 Feb 2002 17:28:32 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1DNRLg22171; Wed, 13 Feb 2002 17:27:21 -0600 Subject: Re: kdb: task_has_cpu not found From: Steve Lord To: Ionut Georgescu Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020213232136.GA31067@physik.tu-cottbus.de> References: <20020213232136.GA31067@physik.tu-cottbus.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 17:27:21 -0600 Message-Id: <1013642841.16011.15.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-13 at 17:21, Ionut Georgescu wrote: > Hi, > > i was trying to compile a 2.4.17 kernel with the cvs patch from > 20020210. However, linking the kernel fails because task_has_cpu, which > is called in kdbmain.c, is not defined. Indeed, grep -r task_has_cpu * > in the linux tree showed only one occurence: the one in kdbmain. Am I > missing something here ? In 2.4.17: Line 555 of include/linux/sched.h #define task_has_cpu(tsk) ((tsk)->cpus_runnable != ~0UL) Check your sources... Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Feb 13 16:33:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E0XOQ10031 for linux-xfs-outgoing; Wed, 13 Feb 2002 16:33:24 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E0XJ910009 for ; Wed, 13 Feb 2002 16:33:20 -0800 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Feb 2002 15:33:10 -0800 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Feb 2002 15:33:10 -0800 Subject: Re: kdb: task_has_cpu not found From: Thomas Duffy To: Ionut Georgescu Cc: Linux XFS Mailing List In-Reply-To: <20020213232136.GA31067@physik.tu-cottbus.de> References: <20020213232136.GA31067@physik.tu-cottbus.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2.99 Preview Release Date: 13 Feb 2002 15:33:05 -0800 Message-Id: <1013643185.5390.1.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2002 23:33:10.0529 (UTC) FILETIME=[CC3FB710:01C1B4E6] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-13 at 15:21, Ionut Georgescu wrote: > Hi, > > i was trying to compile a 2.4.17 kernel with the cvs patch from > 20020210. However, linking the kernel fails because task_has_cpu, which > is called in kdbmain.c, is not defined. Indeed, grep -r task_has_cpu * > in the linux tree showed only one occurence: the one in kdbmain. Am I > missing something here ? did you apply ingo's o1 sched patch as well? this will get rid of this function. -tduffy From owner-linux-xfs@oss.sgi.com Wed Feb 13 16:44:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E0iY010306 for linux-xfs-outgoing; Wed, 13 Feb 2002 16:44:34 -0800 Received: from lucy.physik.tu-cottbus.de (lucy.physik.TU-Cottbus.De [141.43.75.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E0iS910284 for ; Wed, 13 Feb 2002 16:44:28 -0800 Received: (qmail 225694 invoked from network); 13 Feb 2002 23:44:20 -0000 Received: from mozart.physik.tu-cottbus.de (postfix@141.43.75.26) by lucy.physik.tu-cottbus.de with SMTP; 13 Feb 2002 23:44:20 -0000 Received: by mozart.physik.tu-cottbus.de (Postfix, from userid 7224) id 8C6A43754; Thu, 14 Feb 2002 00:44:20 +0100 (CET) Date: Thu, 14 Feb 2002 00:44:20 +0100 To: Linux XFS Mailing List Subject: Re: kdb: task_has_cpu not found Message-ID: <20020213234420.GA31093@physik.tu-cottbus.de> Mail-Followup-To: Linux XFS Mailing List References: <20020213232136.GA31067@physik.tu-cottbus.de> <1013643185.5390.1.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1013643185.5390.1.camel@tduffy-lnx.afara.com> User-Agent: Mutt/1.3.27i From: george@physik.tu-cottbus.de (Ionut Georgescu) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes ... it was somewhere there on the list :)) It seemed that the original files had all gone into *.orig's after applying the patch ... Therefore my grep -r theory. Is there a way to solve this ? I have turned kdb off meanwhile and I'm prepairing to reboot. On Wed, Feb 13, 2002 at 03:33:05PM -0800, Thomas Duffy wrote: > On Wed, 2002-02-13 at 15:21, Ionut Georgescu wrote: > > Hi, > > > > i was trying to compile a 2.4.17 kernel with the cvs patch from > > 20020210. However, linking the kernel fails because task_has_cpu, which > > is called in kdbmain.c, is not defined. Indeed, grep -r task_has_cpu * > > in the linux tree showed only one occurence: the one in kdbmain. Am I > > missing something here ? > > did you apply ingo's o1 sched patch as well? this will get rid of this > function. > > -tduffy > -- *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * Registered Linux User #244479 * * "In Windows you can do everything Microsoft wants you to do; in Unix you * can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Wed Feb 13 16:48:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E0mba10506 for linux-xfs-outgoing; Wed, 13 Feb 2002 16:48:37 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E0mV910484 for ; Wed, 13 Feb 2002 16:48:31 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1919301 for ; Thu, 14 Feb 2002 00:48:28 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA97331; Wed, 13 Feb 2002 17:47:11 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA69869; Wed, 13 Feb 2002 17:47:11 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1DNk0o22209; Wed, 13 Feb 2002 17:46:00 -0600 Subject: Re: kdb: task_has_cpu not found From: Steve Lord To: Ionut Georgescu Cc: Linux XFS Mailing List In-Reply-To: <20020213234420.GA31093@physik.tu-cottbus.de> References: <20020213232136.GA31067@physik.tu-cottbus.de> <1013643185.5390.1.camel@tduffy-lnx.afara.com> <20020213234420.GA31093@physik.tu-cottbus.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 17:46:00 -0600 Message-Id: <1013643960.16007.20.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-13 at 17:44, Ionut Georgescu wrote: > > Yes ... it was somewhere there on the list :)) It seemed that the > original files had all gone into *.orig's after applying the patch ... > Therefore my grep -r theory. > > Is there a way to solve this ? I have turned kdb off meanwhile and I'm > prepairing to reboot. >From the 2.5 tree: int kdb_ps(int argc, const char **argv, const char **envp, struct pt_regs *regs) { struct task_struct *p; kdb_printf("%-*s Pid Parent [*] cpu State %-*s Command\n", (int)(2*sizeof(void *))+2, "Task Addr", (int)(2*sizeof(void *))+2, "Thread"); for_each_task(p) { kdb_printf("0x%p %08d %08d %1.1d %3.3d %s 0x%p%c%s\n", (void *)p, p->pid, p->p_pptr->pid, p->state == TASK_RUNNING, p->thread_info->cpu, (p->state == 0)?"run ":(p->state>0)?"stop":"unrn", (void *)(&p->thread), (p == current) ? '*': ' ', p->comm); } return 0; } I think this should work - since this is where the scheduler went in first. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Feb 13 16:56:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E0uqC10827 for linux-xfs-outgoing; Wed, 13 Feb 2002 16:56:52 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E0uh910802 for ; Wed, 13 Feb 2002 16:56:44 -0800 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Feb 2002 15:56:35 -0800 Received: from tduffy-lnx.afara.com ([10.2.4.191]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Feb 2002 15:56:35 -0800 Subject: Re: kdb: task_has_cpu not found From: Thomas Duffy To: Ionut Georgescu Cc: Linux XFS Mailing List In-Reply-To: <20020213234420.GA31093@physik.tu-cottbus.de> References: <20020213232136.GA31067@physik.tu-cottbus.de> <1013643185.5390.1.camel@tduffy-lnx.afara.com> <20020213234420.GA31093@physik.tu-cottbus.de> Content-Type: multipart/mixed; boundary="=-Ux5pFzFF7LsDszn5mw+Y" X-Mailer: Evolution/1.0.2.99 Preview Release Date: 13 Feb 2002 15:56:30 -0800 Message-Id: <1013644590.5390.17.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2002 23:56:35.0623 (UTC) FILETIME=[11C00B70:01C1B4EA] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Ux5pFzFF7LsDszn5mw+Y Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2002-02-13 at 15:44, Ionut Georgescu wrote: > > Yes ... it was somewhere there on the list :)) It seemed that the > original files had all gone into *.orig's after applying the patch ... > Therefore my grep -r theory. > > Is there a way to solve this ? I have turned kdb off meanwhile and I'm > prepairing to reboot. here is a small patch to fix this, turns out the only usage of this is the ps printk in kdb... -tduffy --=-Ux5pFzFF7LsDszn5mw+Y Content-Disposition: attachment; filename=o1-sched-kdb.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 --- ../../linux-2.4.17+kdb-v2.1-2/kdb/kdbmain.c Fri Feb 1 13:46:20 2002 +++ kdbmain.c Wed Feb 13 15:53:01 2002 @@ -2344,7 +2344,7 @@ for_each_task(p) { kdb_printf("0x%p %08d %08d %1.1d %3.3d %s 0x%p%c%s\n", (void *)p, p->pid, p->p_pptr->pid, - task_has_cpu(p), p->processor, + (p->state =3D=3D TASK_RUNNING), p->cpu, (p->state =3D=3D 0)?"run ":(p->state>0)?"stop":"unrn", (void *)(&p->thread), (p =3D=3D current) ? '*': ' ', --=-Ux5pFzFF7LsDszn5mw+Y-- From owner-linux-xfs@oss.sgi.com Wed Feb 13 19:28:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E3SVu13653 for linux-xfs-outgoing; Wed, 13 Feb 2002 19:28:31 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E3SO913558 for ; Wed, 13 Feb 2002 19:28:25 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 7F09C835FF5; Wed, 13 Feb 2002 21:29:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 666402800458; Wed, 13 Feb 2002 21:29:01 -0500 (EST) Date: Wed, 13 Feb 2002 21:29:01 -0500 (EST) From: Mike Burger To: e.abbink@chello.nl Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump aborts after assertion failure In-Reply-To: <200202131213.NAA26371@fikkie.vesc.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Esger. I just went through the same thing. Is the tape drive a QIC drive (TR-something)? If so, try using the -q parameter, instead of the -b (-q is/was previously undocumented), and see how you make out. On Wed, 13 Feb 2002, E. Abbink wrote: > Hi, > > i have a problem dumping my xfs filesystem. > > setup: > 2.4.17 stock kernel patched with latest(1.0.2) xfs and various (suse) > patches. > xfsdump & xfsprogs are downloaded latest versions as well. > xfs filesystem mounted in root reiser filesystem. xfs filesystem is a > LVM on MD raid1. > backup device is a tandberg slr24 on a adaptec 78xx. > > when i try to backup a test directory on the xfs filesystem with the > following command: > > xfsdump -o -m -b 1024 -f /dev/st0 -s backup_test /fsdata > > i get the following assertion: > > .. > xfsdump: dumping ino map > xfsdump: drive_minrmt.c:1862: do_get_write_buf: Assertion > 'contextp->dc_nextp < contextp->dc_recendp' failed. > Aborted > > Note that the Aborted line does not _immediately_ follow the assertion > line, some time passes. > > If anyone could shed any light on this that would be very helpful as i'm > kinda stumped atm. > > Esger > > From owner-linux-xfs@oss.sgi.com Thu Feb 14 03:41:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EBfO008850 for linux-xfs-outgoing; Thu, 14 Feb 2002 03:41:24 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EBfA908827 for ; Thu, 14 Feb 2002 03:41:10 -0800 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g1EAf8H06278; Thu, 14 Feb 2002 10:41:08 GMT Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g1EAesg11879; Thu, 14 Feb 2002 10:40:54 GMT Message-ID: <3C6B9436.A6F50C8@soton.ac.uk> Date: Thu, 14 Feb 2002 10:40:54 +0000 From: "Ian D. Hardy" Organization: University of Southampton 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, oz@soton.ac.uk Subject: Re: Oopses in kfree References: <3C5E8CFA.CACF28C3@soton.ac.uk> <1013126082.21881.65.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve+ I enabled the 'CONFIG_DEBUG_SLAB' option in the kernel (taking a recent CVS of the 2.4.17 XFS from 12th Feb) and have had the following Oops (which I hope means more to you than to me!). Feb 14 00:41:31 blue00 kernel: kfree: bad ptr f8f3d000h. Feb 14 00:41:31 blue00 kernel: invalid operand: 0000 Feb 14 00:41:32 blue00 kernel: CPU: 1 Feb 14 00:41:32 blue00 kernel: EIP: 0010:[kmem_cache_free+54/128] Not tainted Feb 14 00:41:32 blue00 kernel: EFLAGS: 00010086 Feb 14 00:41:32 blue00 kernel: eax: 0000001d ebx: 00e3cf40 ecx: 0000002e edx: 00000000 Feb 14 00:41:32 blue00 kernel: esi: d42520e4 edi: f8f3d000 ebp: 00000000 esp: f7ee1e30 Feb 14 00:41:32 blue00 kernel: ds: 0018 es: 0018 ss: 0018 Feb 14 00:41:32 blue00 kernel: Process kswapd (pid: 5, stackpage=f7ee1000) Feb 14 00:41:32 blue00 kernel: Stack: c02b3322 f8f3d000 d4252130 d42520e4 00000000 00000000 00000286 c74bfecc Feb 14 00:41:32 blue00 kernel: c01f6f86 f8f3d000 c01cabfe f8f3d000 00014460 d42520e4 d42520e4 00000000 Feb 14 00:41:32 blue00 kernel: c01cac6f d42520e4 00000000 d42520e4 c01c78ae d42520e4 00000001 c01e649a Feb 14 00:41:32 blue00 kernel: Call Trace: [change_termios+118/400] [xlog_recover_do_efi_trans+158/192] [xlog_recover_do_efd_trans+79/256] [xlog_regrant_write_log_space+94/784] [linvfs_follow_link+10/240] Feb 14 00:41:32 blue00 kernel: Code: 0f 0b 83 c4 08 8b 15 8c 85 3f c0 8b 2c 1a 89 7c 24 14 b8 00 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: 83 c4 08 add $0x8,%esp Code; 00000004 Before first symbol 5: 8b 15 8c 85 3f c0 mov 0xc03f858c,%edx Code; 0000000a Before first symbol b: 8b 2c 1a mov (%edx,%ebx,1),%ebp Code; 0000000e Before first symbol e: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; 00000012 Before first symbol 12: b8 00 00 00 00 mov $0x0,%eax Ian Steve Lord wrote: > > On Mon, 2002-02-04 at 07:30, Ian D. Hardy wrote: > > Hi, > > > > Anyone any ideas on the following Oops (processed with ksymoops 2.4.3). It is > > from a NFS server (Dual 1Ghz Supermicro LE, 1Gbyte RAM, 40Gbyte Maxtor IDE > > system disk, Zero-D/GForce RI Fibrechannel to IDE hardware RAID-5 500Gbyte > > disk unit). It is running the Linux 2.4.17-xfs kernel taken as a CVS image > > on 27th January. The main area of disk it is serving is on the HW RAID unit, > > which is the only XFS filesystem on the system. The system had been up > > for just over 3 days when it crashed. > > > > I reported a very similar failure a few weeks ago, at that time running a > > 2.4.9 based kernel, Steve Lord suggested that we tried the latest CVS image > > as this had fixed some memory alloacation problems. > > > > The machine is essentially an NFS fileserver to a computational cluster. Though > > of possible interest is the 'save' process that was running on one of the > > processes, this is the Legato Networker backup client process (which was > > performing a full backup of the XFS filesystem at the time). I don't think > > this is significant as I was seeing these crashes (at ~4 to 12 day intervals) > > with the 2.4.9 kernel not dependant upon a 'save' session running. > > > > > > You have not been forgotten, just trying to do too many things at once > around here right now. But both of you ended up with an oops in kfree, > would it be possible to turn on CONFIG_DEBUG_SLAB. > This will turn on a number of memory checking features and might make > things fall over at a different - and more inciteful point. > > In Chip's case I suspect the config flag does not exist, so hand edit > mm/slab.c and turn on the DEBUG options in there. > > On a side note, today I experienced an oops due to what appeared to be > a failure to allocate a buffer - we had been assuming these were caused > by being out of memory, but in my case I had plenty of available memory, > it turns out to be a bug in the pagebuf code when we reallocate metadata > space. I am thrashing the fix on some test boxes now, but it is possible > that those really were not out of memory cases people were seeing, but > due to this bug. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Computing Services Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Thu Feb 14 08:09:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EG9X414785 for linux-xfs-outgoing; Thu, 14 Feb 2002 08:09:33 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EG9N914761 for ; Thu, 14 Feb 2002 08:09:24 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA92210; Thu, 14 Feb 2002 10:06:09 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1EF9I5128304; Thu, 14 Feb 2002 08:09:19 -0700 Subject: Re: DMAPI rights To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Thu, 14 Feb 2002 09:09:16 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/14/2002 08:09:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are you saying that rights do exist and are checked at the DMAPI level? If so, does this mean that a DMAPI program could use rights to synchronize between DMAPI calls but must use some other mechanism to coordinate with non-DMAPI clients of the filesystem? Let me clarify a bit. Let's say that I have two DMAPI programs that want to modify the DM attributes of the same file using the dm_set_dmattr() call. If they both call dm_request_right() to get a DM_RIGHT_EXCL right to the file, one will get the right while the other will block. When the initial program finally calls dm_release_right() the second program will get the DM_RIGHT_EXCL and continue. Is that correct? By the way, I did read the comments on rights in the dmapi_event.c, and it was more informative about what should be done in the future than what currently exists in the code. Thanks for the reference though. -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI rights 02/13/2002 05:10 PM >From: "James A Goodwin" >Dean, > >Since XFS DMAPI doesn't implement rights, rights obviously can't be >attached to tokens. Does this mean that every call requiring a certain >level of 'rights' must be called using DM_NO_TOKEN? No, we do attach rights to tokens. It's just that XFS itself knows nothing about the rights and once you step out of the DMAPI code and into the XFS code your rights won't be honored. A dm_request_right/dm_release_right will do a hold/rele on the vnode, at least. Other than that, the rights stuff is a no-op. There's a write-up on rights in fs/xfs_dmapi/dmapi_event.c, though I don't know how much of that reflects the current code. Dean From owner-linux-xfs@oss.sgi.com Thu Feb 14 09:04:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EH4Nn20216 for linux-xfs-outgoing; Thu, 14 Feb 2002 09:04:23 -0800 Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EH4J920193 for ; Thu, 14 Feb 2002 09:04:19 -0800 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 14 Feb 2002 09:03:18 -0700 Message-ID: <3C6BDFC6.14BE4651@echostar.com> Date: Thu, 14 Feb 2002 09:03:18 -0700 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS List Subject: Mounting an xfs partition twice? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk While looking into an apparent filesystem corruption issue, I noticed that a script that we run mounts an already mounted filesystem in a different location. Mount allows it. Is this a feature? or is this a _bad_ thing? The corruption I am seeing is not on the partition that is mounted twice. In the corrupted directory, I see several files listed twice, and a simple "ls -l" gives me several "No such file or directory" errors on other files that were previously in the directory. Any help and/or advice would be appreciated. Thanks, Jim Buzbee Echostar Technologies From owner-linux-xfs@oss.sgi.com Thu Feb 14 09:14:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EHEEs24685 for linux-xfs-outgoing; Thu, 14 Feb 2002 09:14:14 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EHE8924663 for ; Thu, 14 Feb 2002 09:14:09 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1EGE3tm011117 for ; Thu, 14 Feb 2002 08:14:03 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA03368; Thu, 14 Feb 2002 10:12:44 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA15952; Thu, 14 Feb 2002 10:12:42 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1EGBIJ24415; Thu, 14 Feb 2002 10:11:18 -0600 Subject: Re: Mounting an xfs partition twice? From: Steve Lord To: Jim Buzbee Cc: XFS List In-Reply-To: <3C6BDFC6.14BE4651@echostar.com> References: <3C6BDFC6.14BE4651@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 10:11:18 -0600 Message-Id: <1013703078.16007.92.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-14 at 10:03, Jim Buzbee wrote: > > While looking into an apparent filesystem corruption issue, I noticed > that a script that we run mounts an already mounted filesystem in a > different location. Mount allows it. Is this a feature? or is this a > _bad_ thing? The corruption I am seeing is not on the partition that is > mounted twice. > > In the corrupted directory, I see several files listed twice, and a > simple "ls -l" gives me several "No such file or directory" errors on > other files that were previously in the directory. > > Any help and/or advice would be appreciated. Mounting a filesystem in two different places (or the same place twice) is a linux vfs thing. The idea is so make setting up chrooted environments simpler. All it means is there are multiple paths into the filesystem, the filesystem itself is really only present once. As for the corruption thing, run xfs_repair -n on the filesystem and xfs_check and send us the output. Also some information about software and hardware versions, and what you are doing to get the corruption. Steve > > Thanks, > > Jim Buzbee > Echostar Technologies -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 14 09:14:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EHEVY24746 for linux-xfs-outgoing; Thu, 14 Feb 2002 09:14:31 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EHER924724 for ; Thu, 14 Feb 2002 09:14:27 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1EGEMtm011156 for ; Thu, 14 Feb 2002 08:14:22 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA03228; Thu, 14 Feb 2002 10:13:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA06539; Thu, 14 Feb 2002 10:13:06 -0600 (CST) Subject: Re: Mounting an xfs partition twice? From: Eric Sandeen To: Jim Buzbee Cc: XFS List In-Reply-To: <3C6BDFC6.14BE4651@echostar.com> References: <3C6BDFC6.14BE4651@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 10:13:06 -0600 Message-Id: <1013703186.17196.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-14 at 10:03, Jim Buzbee wrote: > > While looking into an apparent filesystem corruption issue, I noticed > that a script that we run mounts an already mounted filesystem in a > different location. Mount allows it. Is this a feature? or is this a > _bad_ thing? The corruption I am seeing is not on the partition that is > mounted twice. http://www.tux.org/lkml/#s14-6 1. I've mounted a filesystem in two different places and it worked. Why? * (AV, paraphrased by William Stearns)Because you've asked the kernel to do that. Yes, it works. No, it's not a bug. To unmount it from either mountpoint, simply run umount . Repeat for each mountpoint on which you do not wish the filesystem mounted. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 14 09:16:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EHGhc24962 for linux-xfs-outgoing; Thu, 14 Feb 2002 09:16:43 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EHGe924940 for ; Thu, 14 Feb 2002 09:16:40 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1EGGYtm011267 for ; Thu, 14 Feb 2002 08:16:34 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA03246; Thu, 14 Feb 2002 10:15:19 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA89684; Thu, 14 Feb 2002 10:15:18 -0600 (CST) Subject: Re: Mounting an xfs partition twice? From: Eric Sandeen To: Jim Buzbee Cc: XFS List In-Reply-To: <3C6BDFC6.14BE4651@echostar.com> References: <3C6BDFC6.14BE4651@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 10:15:18 -0600 Message-Id: <1013703319.17209.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-14 at 10:03, Jim Buzbee wrote: > In the corrupted directory, I see several files listed twice, and a > simple "ls -l" gives me several "No such file or directory" errors on > other files that were previously in the directory. Oh, and for this problem... what flavor of kernel/xfs are you running? xfs_repair -n on the filesystem in question might tell us some interesting things as well, but it will be hard to know how the filesystem got into this state. What sorts of interesting things are you doing with it? :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 14 09:39:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EHdb327013 for linux-xfs-outgoing; Thu, 14 Feb 2002 09:39:37 -0800 Received: from mail.tvol.net ([66.150.46.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EHdA926991 for ; Thu, 14 Feb 2002 09:39:10 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NJA2Q6K; Thu, 14 Feb 2002 11:36:52 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g1EGd4615195; Thu, 14 Feb 2002 11:39:04 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3C6BE828.70F37D8@wgate.com> Date: Thu, 14 Feb 2002 11:39:04 -0500 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Linux XFS List Subject: [PATCH] Core dump file control Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have, for a long time, wished that Linux had a way to specify where core dumps are stored and what the name of the core dump is. Now that I have been building large linux clusters with many diskless nodes, this need has become even more important. The reason I am sending this here is that we actually use the XFS 2.4 tree for a lot of our work. I am also submitting a patch (almost exactly the same) to the main Linux tree but I thought that those who use large systems (which usually involves something like XFS) would also be interested. What I did with this patch is provide a new sysctl that lets you control the name of the core file. The this name is actually a format string such that certain values from the process can be included. The sysctl is kernel.core_name_format and is a string up to 63 characters (plus 1 for the null) The following format options are available in that string: %P The Process ID (current->pid) %U The UID of the process (current->uid) %N The command name of the process (current->comm) %H The nodename of the system (system_utsname.nodename) %% A "%" For example, in my clusters, I have an NFS R/W mount at /coredumps that all nodes have access to. The format string I use is: sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core" This then causes core dumps to be of the format: /coredumps/whale.sinz.org-badprogram-13917.core Only behavior of appending the PID to the "core" name is still supported with the added logic of only doing so if the PID is not already part of the name format. The default name format is still just "core" to match old behavior. NOTE - I was tempted to change the default format to be something like "%N.core" which would at least identify the program that caused the core file. However, I can do that as part of my init process so it is not a issue here. The attached cvs diff is from the 2.4 tree. Index: include/linux/sysctl.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/include/linux/sysctl.h,v retrieving revision 1.45 diff -u -4 -w -w -r1.45 sysctl.h --- include/linux/sysctl.h 2002/01/11 23:31:51 1.45 +++ include/linux/sysctl.h 2002/02/14 17:30:57 @@ -126,8 +126,9 @@ KERN_CADPID=54, /* int: PID of the process to notify on CAD */ #ifdef CONFIG_KDB KERN_KDB=55, /* int: kdb on/off */ #endif /* CONFIG_KDB */ + KERN_CORE_NAME_FORMAT=56, /* string: core file name format string */ }; /* CTL_VM names: */ Index: kernel/sysctl.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/kernel/sysctl.c,v retrieving revision 1.47 diff -u -4 -w -w -r1.47 sysctl.c --- kernel/sysctl.c 2002/01/04 03:48:48 1.47 +++ kernel/sysctl.c 2002/02/14 17:30:59 @@ -51,8 +51,9 @@ extern atomic_t nr_queued_signals; extern int max_queued_signals; extern int sysrq_enabled; extern int core_uses_pid; +extern char core_name_format []; extern int cad_pid; /* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */ static int maxolduid = 65535; @@ -173,8 +174,10 @@ {KERN_PANIC, "panic", &panic_timeout, sizeof(int), 0644, NULL, &proc_dointvec}, {KERN_CORE_USES_PID, "core_uses_pid", &core_uses_pid, sizeof(int), 0644, NULL, &proc_dointvec}, + {KERN_CORE_NAME_FORMAT, "core_name_format", core_name_format, 64, + 0644, NULL, &proc_doutsstring, &sysctl_string}, {KERN_TAINTED, "tainted", &tainted, sizeof(int), 0644, NULL, &proc_dointvec}, {KERN_CAP_BSET, "cap-bound", &cap_bset, sizeof(kernel_cap_t), 0600, NULL, &proc_dointvec_bset}, Index: fs/exec.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/exec.c,v retrieving revision 1.50 diff -u -4 -w -w -r1.50 exec.c --- fs/exec.c 2001/12/23 05:47:19 1.50 +++ fs/exec.c 2002/02/14 17:30:52 @@ -34,8 +34,9 @@ #include #include #include #include +#include #define __NO_VERSION__ #include #include @@ -46,8 +47,9 @@ #include #endif int core_uses_pid; +char core_name_format[64] = {"core"}; static struct linux_binfmt *formats; static rwlock_t binfmt_lock = RW_LOCK_UNLOCKED; @@ -932,15 +934,23 @@ if (old && old->module) __MOD_DEC_USE_COUNT(old->module); } +#define MAX_CORE_NAME (160) int do_coredump(long signr, struct pt_regs * regs) { struct linux_binfmt * binfmt; - char corename[6+sizeof(current->comm)+10]; + + /* The 11 extra are for the support of the old "uses PID option" + and such that the PID option does not need some fancy size trick */ + char corename[MAX_CORE_NAME+1+11]; struct file * file; struct inode * inode; int retval = 0; + int fmt_i; + int name_n; + int addPID; + char *cname; lock_kernel(); binfmt = current->binfmt; if (!binfmt || !binfmt->core_dump) @@ -949,13 +959,93 @@ goto fail; current->mm->dumpable = 0; if (current->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump) goto fail; + + /* Set this to true if we are going to add the PID. If the PID + already is added in the format we will end up clearing this. + The purpose is to provide for the old behavior of adding the + PID to the core file name but to not add it if it already + was included via the file name format pattern. */ + addPID = (core_uses_pid || atomic_read(¤t->mm->mm_users) != 1); + + /* Build the core file name as needed from the format string */ + for (fmt_i=0, name_n=0; + name_n < MAX_CORE_NAME && core_name_format[fmt_i]; + fmt_i++) + { + switch (core_name_format[fmt_i]) + { + case '%': /* A format character */ + fmt_i++; + switch (core_name_format[fmt_i]) + { + case '%': /* The way we get this character */ + corename[name_n++] = '%'; + break; + + case 'N': /* Process name */ + cname=current->comm; + + /* Only copy as much as will fit within the MAX_CORE_NAME */ + while (*cname && (name_n < MAX_CORE_NAME)) + { + if (*cname != '/') + corename[name_n++] = *cname; + cname++; + } + break; + + case 'H': /* Host name */ + cname=system_utsname.nodename; + + /* Only copy as much as will fit within the MAX_CORE_NAME */ + while (*cname && (name_n < MAX_CORE_NAME)) + { + if (*cname != '/') + corename[name_n++] = *cname; + cname++; + } + break; + + case 'P': /* Process PID */ + /* Since we are adding it here, don't append at end */ + addPID=0; + + /* We don't need to pre-check that the number fits since we + added a padding of 11 characters to the end of the string + buffer just so that we don't need to do an extra check */ + name_n += sprintf(&corename[name_n],"%d",current->pid); + break; + + case 'U': /* UID of the process */ + /* We don't need to pre-check that the number fits since we + added a padding of 11 characters to the end of the string + buffer just so that we don't need to do an extra check */ + name_n += sprintf(&corename[name_n],"%d",current->uid); + break; + } + break; + + default: /* Anything else just pass along */ + corename[name_n++] = core_name_format[fmt_i]; + } + } + + /* If we still want to append the PID and there is room, do so */ + /* This is mainly for compatibility */ + if (addPID && (name_n < MAX_CORE_NAME)) + { + name_n += sprintf(&corename[name_n],".%d",current->pid); + } + + /* And null terminate the string */ + corename[name_n]='\0'; + + /* Check that we actually got a name */ + if (name_n < 1) + goto fail; - memcpy(corename,"core.", 5); - corename[4] = '\0'; - if (core_uses_pid || atomic_read(¤t->mm->mm_users) != 1) - sprintf(&corename[4], ".%d", current->pid); file = filp_open(corename, O_CREAT | 2 | O_NOFOLLOW, 0600); if (IS_ERR(file)) goto fail; inode = file->f_dentry->d_inode; -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Thu Feb 14 09:55:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EHtmt27421 for linux-xfs-outgoing; Thu, 14 Feb 2002 09:55:48 -0800 Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EHtb927398 for ; Thu, 14 Feb 2002 09:55:37 -0800 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 14 Feb 2002 09:54:17 -0700 Message-ID: <3C6BEBC4.18AA60E9@echostar.com> Date: Thu, 14 Feb 2002 09:54:28 -0700 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen , Steve Lord CC: XFS List Subject: Re: Mounting an xfs partition twice? References: <3C6BDFC6.14BE4651@echostar.com> <1013703319.17209.3.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > On Thu, 2002-02-14 at 10:03, Jim Buzbee wrote: > > > In the corrupted directory, I see several files listed twice, and a > > simple "ls -l" gives me several "No such file or directory" errors on > > other files that were previously in the directory. > > Oh, and for this problem... what flavor of kernel/xfs are you running? OK, X86, IDE - 2.4.8 Kernel with a number of modifications, compiler : egcs 1.1.2 - The xfs patch we applied to the kernel is : patch-2.4.8-xfs-2001-08-13.bz2 We are pretty much frozen on this kernel right now because of the difficulty of moving forward our 2.4.8 modifications. > xfs_repair -n on the filesystem in question might tell us some > interesting things as well, Here's the 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... - 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 ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. > but it will be hard to know how the > filesystem got into this state. What sorts of interesting things are > you doing with it? :) This condition is unfortunately repeatable (we trashed a number of our set top boxes...). For us it occurs during the automated installation of several compressed tar files - Nothing extraordinary other than the filesystem is quite busy (we are simultaneously recording and playing MPEG 2 video from our satellites) - This problem just started occuring - The only change was a new build of the kernel so that is my current suspicion... Jim Buzbee, Echostar Technologies > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 14 10:09:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EI9OA28635 for linux-xfs-outgoing; Thu, 14 Feb 2002 10:09:24 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EI9I928610 for ; Thu, 14 Feb 2002 10:09:18 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA05328 for ; Thu, 14 Feb 2002 09:10:35 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA01612; Thu, 14 Feb 2002 11:08:01 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA90171; Thu, 14 Feb 2002 11:08:01 -0600 (CST) Subject: Re: Mounting an xfs partition twice? From: Eric Sandeen To: Jim Buzbee Cc: Steve Lord , XFS List In-Reply-To: <3C6BEBC4.18AA60E9@echostar.com> References: <3C6BDFC6.14BE4651@echostar.com> <1013703319.17209.3.camel@stout.americas.sgi.com> <3C6BEBC4.18AA60E9@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 11:08:01 -0600 Message-Id: <1013706481.17209.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-14 at 10:54, Jim Buzbee wrote: > OK, X86, IDE - 2.4.8 Kernel with a number of modifications, compiler : > egcs 1.1.2 - The xfs patch we applied to the kernel is : > > patch-2.4.8-xfs-2001-08-13.bz2 > > We are pretty much frozen on this kernel right now because of the > difficulty of moving forward our 2.4.8 modifications. > > > xfs_repair -n on the filesystem in question might tell us some > > interesting things as well, > > What sorts of interesting things are > > you doing with it? :) > > This condition is unfortunately repeatable (we trashed a number of our > set top boxes...). For us it occurs during the automated installation > of several compressed tar files - Nothing extraordinary other than the > filesystem is quite busy (we are simultaneously recording and playing > MPEG 2 video from our satellites) - This problem just started occuring - > The only change was a new build of the kernel so that is my current > suspicion... Well, repeatable is good. Just send me one of the set-top boxes, and ... ;-) So you're recording, playing, and installing tar files at the same time? Which files get mixed up, the mpegs, or the files from the tar? Does it fail if you only install, and don't record/play? If you can duplicate this without the need for a satellite, perhaps we can duplicate it here as well. Although, if it "just started occuring" - sounds like it might be some change you made... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 14 10:23:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EIN7k29068 for linux-xfs-outgoing; Thu, 14 Feb 2002 10:23:07 -0800 Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EIMw929046 for ; Thu, 14 Feb 2002 10:22:59 -0800 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 14 Feb 2002 10:21:39 -0700 Message-ID: <3C6BF22E.91E6AE60@echostar.com> Date: Thu, 14 Feb 2002 10:21:50 -0700 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Steve Lord , XFS List Subject: Re: Mounting an xfs partition twice? References: <3C6BDFC6.14BE4651@echostar.com> <1013703319.17209.3.camel@stout.americas.sgi.com> <3C6BEBC4.18AA60E9@echostar.com> <1013706481.17209.10.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote : ... > > Well, repeatable is good. Just send me one of the set-top boxes, and > ... ;-) Just wait until we hit the market, then call your local Dish Network dealer :-) > > So you're recording, playing, and installing tar files at the same > time? Yeah, and we could be doing this with dual streams - I hope we're not pushing too hard... > Which files get mixed up, the mpegs, or the files from the tar? The files from the tar - The mpeg data looks good. > Does it fail if you only install, and don't record/play? I'll try. Although at this point the directory structure is probably already corrupted, here's a partial strace of a simple "rm" that is failing. lstat64("DishLinux.tar.bz2.old", {st_mode=S_IFREG|0664, st_size=10698129, ...}) = 0 access("DishLinux.tar.bz2.old", W_OK) = 0 unlink("DishLinux.tar.bz2.old") = -1 ENOENT (No such file or directory) > > If you can duplicate this without the need for a satellite, perhaps we > can duplicate it here as well. > > Although, if it "just started occuring" - sounds like it might be some > change you made... I'm going to move back to a previous build of the kernel to see if the problem goes away. Jim Buzbee, Echostar Technologies > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 14 13:31:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ELV1N00757 for linux-xfs-outgoing; Thu, 14 Feb 2002 13:31:01 -0800 Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ELUn900726 for ; Thu, 14 Feb 2002 13:30:50 -0800 Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel11.hp.com (Postfix) with ESMTP id 6049860021B for ; Thu, 14 Feb 2002 12:30:42 -0800 (PST) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 54E01166 for ; Thu, 14 Feb 2002 12:30:42 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id <17M59BVY>; Thu, 14 Feb 2002 12:30:42 -0800 Message-ID: From: "DICKENS,CARY (HP-Loveland,ex2)" To: "Xfs \"Mailing List (E-mail)" Subject: RE: trouble implementing default quotas Date: Thu, 14 Feb 2002 12:30:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Steve Lord wrote: > > So explain how this is supposed to work. Let me see if I can better explain what I'm trying to do. This way, if I have a glaring misconception, some one can point it out. I'll trace what I want to do through the xfs_create path. Background: - xfs filesystem with user and qroup quotas enabled. Both accounting and enforcement are enabled. - Default quotas set in root user quota for a particular filesystem. - user1 copies a file from their local drive to the shared drive that has the quotas on it. What happens regarding quotas: (the way I read it starting at xfs_create) - xfs_create is called. - if quotas are on the mountpoint then call xfs_qm_vop_dqalloc. (xfs_vnodeops.c:2197) - attach the dquots (user and group) the the inode and allocate dquots if necessary. (xfs_qm.c:2532) - call xfs_qm_dqget without the inode in order to get the uid dquot. Allocate if necessary. (xfs_qm.c:2553) - repeat for the group quota. (xfs_qm.c:2583) - return the user and group quotas. - call xfs_trans_reserve_quota which is typedefed to xfs_trans_reserve_quota_bydquots in xfs_quota.h:307. (xfs_vnodeops.c:2278) - call xfs_trans_dqresv and verify that we can reserve the number of blocks or inodes that we need to without exceeding quota. It is at this point that I would like to use user1's hardlimit as the hardlimit if they have a limit and root's hardlimit if user1's hardlimit is 0. I don't want to change how the accounting takes place, I just want access to an alternate set of enforcement criteria. - If we can't reserve the number of blocks needed for the write because hardlimit has been exceeded, return EDQUOT. If we can, go ahead and do your mojo. > Each user has a quota structure, > an xfs_dquot_t which is looked up via xfs_qm_dqget. This is the in > memory representation of a user's quota. If quotas are not defined for > a specific user then there is no structure, and nothing happens with > quotas. So you are trying to implement default quotas for accounts > the administrator did not configure one for. Where does the > quota space > used get recorded, do all user's without a specific quota get to share > one pool of quota space? I was under the assumption that a dquot is allocated to disk if one isn't found for that user. That appears to be what is happening when xfs_qm_dqget is called. It eventually calls xfs_qm_idtodq which allocates a dquot and then reads it. I don't understand why a dquot wouldn't exist just because there isn't a [hard,soft,inode]limit set for a particular uid when they own files on filesystem. Cary From owner-linux-xfs@oss.sgi.com Thu Feb 14 13:37:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ELbim00947 for linux-xfs-outgoing; Thu, 14 Feb 2002 13:37:44 -0800 Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ELbU900921 for ; Thu, 14 Feb 2002 13:37:30 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id B69E2A00348 for ; Wed, 13 Feb 2002 00:24:45 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id B08374000A6 for ; Wed, 13 Feb 2002 00:24:45 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id <1D2TJ3RV>; Wed, 13 Feb 2002 00:24:45 -0500 Message-ID: From: "DICKENS,CARY (HP-Loveland,ex2)" To: "'linux-xfs@oss.sgi.com'" Subject: trouble implementing default quotas Date: Wed, 13 Feb 2002 00:24:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Folks, I'm implementing a default quota scheme on xfs and have something weird going on that I don't understand. I am using a recent cvs snapshot and linux 2.4.17. I want to use root to store the default user and group quota and only enforce the default quota if a user doesn't have an explicit quota set. When I apply this patch, I lock up when a user, with or without a quota, tries to write to the disk. When I copy some files to the filesystem with my altered xfs, it appears to lock up returning from the xfs_create call in xfs_vnodeops.c. It leaves this function via std_return with error 0, but the console never returns a prompt. Without my patch, all appears ok, so I know I'm doing something screwy, I just don't know what. Any help would be appreciated. Cary diff -Nur linux.orig/fs/xfs/xfs_trans_dquot.c linux/fs/xfs/xfs_trans_dquot.c --- linux.orig/fs/xfs/xfs_trans_dquot.c Thu Feb 7 13:02:57 2002 +++ linux/fs/xfs/xfs_trans_dquot.c Fri Feb 8 11:20:09 2002 @@ -573,6 +573,7 @@ xfs_trans_dqresv( xfs_trans_t *tp, xfs_dquot_t *dqp, + xfs_dquot_t *defaultqp, long nblks, long ninos, uint flags) @@ -588,14 +589,22 @@ } ASSERT(XFS_DQ_IS_LOCKED(dqp)); if (flags & XFS_TRANS_DQ_RES_BLKS) { - hardlimit = INT_GET(dqp->q_core.d_blk_hardlimit, ARCH_CONVERT); - softlimit = INT_GET(dqp->q_core.d_blk_softlimit, ARCH_CONVERT); + if ((hardlimit = INT_GET(dqp->q_core.d_blk_hardlimit, ARCH_CONVERT)) == 0) { + hardlimit = INT_GET(defaultqp->q_core.d_blk_hardlimit, ARCH_CONVERT); + } + if ((softlimit = INT_GET(dqp->q_core.d_blk_softlimit, ARCH_CONVERT)) == 0) { + softlimit = INT_GET(defaultqp->q_core.d_blk_hardlimit, ARCH_CONVERT); + } btimer = INT_GET(dqp->q_core.d_btimer, ARCH_CONVERT); resbcountp = &dqp->q_res_bcount; } else { ASSERT(flags & XFS_TRANS_DQ_RES_RTBLKS); - hardlimit = INT_GET(dqp->q_core.d_rtb_hardlimit, ARCH_CONVERT); - softlimit = INT_GET(dqp->q_core.d_rtb_softlimit, ARCH_CONVERT); + if ((hardlimit = INT_GET(dqp->q_core.d_rtb_hardlimit, ARCH_CONVERT)) == 0) { + hardlimit = INT_GET(defaultqp->q_core.d_rtb_hardlimit, ARCH_CONVERT); + } + if ((softlimit = INT_GET(dqp->q_core.d_rtb_softlimit, ARCH_CONVERT)) == 0) { + softlimit = INT_GET(defaultqp->q_core.d_rtb_hardlimit, ARCH_CONVERT); + } btimer = INT_GET(dqp->q_core.d_rtbtimer, ARCH_CONVERT); resbcountp = &dqp->q_res_rtbcount; } @@ -711,6 +720,9 @@ * XFS_TRANS_DQ_RES_RTBLKS reserves realtime disk blocks * dquots are unlocked on return, if they were not locked by caller. */ + + + int xfs_trans_reserve_quota_bydquots( xfs_trans_t *tp, @@ -721,6 +733,8 @@ uint flags) { int resvd; + int error; + xfs_dquot_t *defaultqp; if (tp && tp->t_dqinfo == NULL) xfs_trans_alloc_dqinfo(tp); @@ -729,18 +743,20 @@ resvd = 0; if (udqp) { - if (xfs_trans_dqresv(tp, udqp, nblks, ninos, flags)) + error = xfs_qm_dqget(udqp->q_mount, NULL, 0, XFS_DQ_USER, 0, &defaultqp); + if (xfs_trans_dqresv(tp, udqp, defaultqp, nblks, ninos, flags)) return (EDQUOT); resvd = 1; } if (gdqp) { - if (xfs_trans_dqresv(tp, gdqp, nblks, ninos, flags)) { + error = xfs_qm_dqget(udqp->q_mount, NULL, 0, XFS_DQ_GROUP, 0, &defaultqp); + if (xfs_trans_dqresv(tp, gdqp, defaultqp, nblks, ninos, flags)) { /* * can't do it, so backout previous reservation */ if (resvd) { - xfs_trans_dqresv(tp, udqp, -nblks, -ninos, + xfs_trans_dqresv(tp, udqp, defaultqp, -nblks, -ninos, flags); } return (EDQUOT); From owner-linux-xfs@oss.sgi.com Thu Feb 14 16:29:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F0Tgl03149 for linux-xfs-outgoing; Thu, 14 Feb 2002 16:29:42 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F0QM903067 for ; Thu, 14 Feb 2002 16:26:22 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA07086 for ; Thu, 14 Feb 2002 15:26:17 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA07871 for ; Thu, 14 Feb 2002 17:25:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA12742 for ; Thu, 14 Feb 2002 17:25:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1ENNfa00934; Thu, 14 Feb 2002 17:23:41 -0600 Message-Id: <200202142323.g1ENNfa00934@jen.americas.sgi.com> Date: Thu, 14 Feb 2002 17:23:41 -0600 Subject: TAKE - merge up to 2.5.5-pre1 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Take the left sound driver out, put the right sound driver in and shake it all about. Date: Thu Feb 14 15:10:05 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:111852a linux/sound/synth/util_mem.c - 1.1 linux/sound/synth/emux/soundfont.c - 1.1 linux/Documentation/filesystems/directory-locking - 1.1 linux/Documentation/filesystems/porting - 1.1 linux/sound/synth/emux/emux_voice.h - 1.1 linux/Documentation/x86_64/mm.txt - 1.1 linux/sound/synth/emux/emux_synth.c - 1.1 linux/sound/synth/emux/emux_seq.c - 1.1 linux/sound/synth/emux/emux_proc.c - 1.1 linux/sound/synth/emux/emux_oss.c - 1.1 linux/sound/synth/emux/emux_nrpn.c - 1.1 linux/sound/synth/emux/emux_effect.c - 1.1 linux/sound/synth/emux/emux.c - 1.1 linux/sound/synth/emux/Makefile - 1.1 linux/sound/synth/Makefile - 1.1 linux/arch/alpha/kernel/init_task.c - 1.1 linux/sound/sound_firmware.c - 1.1 linux/sound/sound_core.c - 1.1 linux/sound/ppc/tumbler.c - 1.1 linux/sound/ppc/powermac.c - 1.1 linux/sound/ppc/pmac.h - 1.1 linux/sound/ppc/pmac.c - 1.1 linux/sound/ppc/keywest.c - 1.1 linux/sound/ppc/daca.c - 1.1 linux/sound/ppc/burgundy.h - 1.1 linux/sound/ppc/burgundy.c - 1.1 linux/sound/ppc/awacs.h - 1.1 linux/sound/ppc/awacs.c - 1.1 linux/sound/ppc/Makefile - 1.1 linux/sound/ppc/Config.in - 1.1 linux/sound/pci/ymfpci/ymfpci_main.c - 1.1 linux/sound/pci/ymfpci/ymfpci_image.h - 1.1 linux/sound/pci/ymfpci/ymfpci.c - 1.1 linux/sound/pci/ymfpci/Makefile - 1.1 linux/sound/pci/via8233.c - 1.1 linux/sound/pci/via686.c - 1.1 linux/sound/pci/trident/trident_synth.c - 1.1 linux/sound/pci/trident/trident_memory.c - 1.1 linux/sound/pci/trident/trident_main.c - 1.1 linux/sound/pci/trident/trident.c - 1.1 linux/sound/pci/trident/Makefile - 1.1 linux/sound/pci/sonicvibes.c - 1.1 linux/sound/pci/rme9652/rme9652_mem.c - 1.1 linux/sound/pci/rme9652/rme9652.c - 1.1 linux/sound/pci/rme9652/Makefile - 1.1 linux/sound/pci/rme96.c - 1.1 linux/sound/pci/nm256/nm256_coef.c - 1.1 linux/sound/pci/nm256/nm256.c - 1.1 linux/sound/pci/nm256/Makefile - 1.1 linux/sound/pci/maestro3.c - 1.1 linux/sound/pci/korg1212/korg1212.c - 1.1 linux/sound/pci/korg1212/korg1212-firmware.h - 1.1 linux/sound/pci/korg1212/Makefile - 1.1 linux/sound/pci/intel8x0.c - 1.1 linux/sound/pci/ice1712.c - 1.1 linux/arch/ppc/4xx_io/Config.in - 1.1 linux/arch/ppc/4xx_io/Makefile - 1.1 linux/arch/ppc/4xx_io/serial_sicc.c - 1.1 linux/arch/ppc/4xx_io/stb_kb.c - 1.1 linux/sound/pci/fm801.c - 1.1 linux/sound/pci/es1968.c - 1.1 linux/sound/pci/es1938.c - 1.1 linux/sound/pci/ens1371.c - 1.1 linux/sound/pci/ens1370.c - 1.1 linux/sound/pci/emu10k1/voice.c - 1.1 linux/arch/ppc/8xx_io/cs4218.h - 1.1 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.1 linux/sound/pci/emu10k1/memory.c - 1.1 linux/sound/pci/emu10k1/irq.c - 1.1 linux/sound/pci/emu10k1/io.c - 1.1 linux/sound/pci/emu10k1/emuproc.c - 1.1 linux/sound/pci/emu10k1/emupcm.c - 1.1 linux/sound/pci/emu10k1/emumpu401.c - 1.1 linux/sound/pci/emu10k1/emumixer.c - 1.1 linux/sound/pci/emu10k1/emufx.c - 1.1 linux/sound/pci/emu10k1/emu10k1_synth_local.h - 1.1 linux/sound/pci/emu10k1/emu10k1_synth.c - 1.1 linux/sound/pci/emu10k1/emu10k1_patch.c - 1.1 linux/sound/pci/emu10k1/emu10k1_main.c - 1.1 linux/sound/pci/emu10k1/emu10k1_callback.c - 1.1 linux/arch/ppc/boot/common/dummy.c - 1.1 linux/sound/pci/emu10k1/emu10k1.c - 1.1 linux/sound/pci/emu10k1/Makefile - 1.1 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.1 linux/sound/pci/cs46xx/cs46xx_image.h - 1.1 linux/arch/ppc/boot/common/relocate.S - 1.1 linux/arch/ppc/boot/common/util.S - 1.1 linux/sound/pci/cs46xx/cs46xx.c - 1.1 linux/arch/ppc/boot/ld.script - 1.1 linux/sound/pci/cs46xx/Makefile - 1.1 linux/sound/pci/cs4281.c - 1.1 linux/sound/pci/cmipci.c - 1.1 linux/sound/pci/als4000.c - 1.1 linux/sound/pci/ali5451/ali5451.c - 1.1 linux/sound/pci/ali5451/Makefile - 1.1 linux/sound/pci/ac97/ak4531_codec.c - 1.1 linux/sound/pci/ac97/ac97_codec.c - 1.1 linux/sound/pci/ac97/Makefile - 1.1 linux/sound/pci/Makefile - 1.1 linux/sound/pci/Config.in - 1.1 linux/sound/oss/yss225.h - 1.1 linux/sound/oss/yss225.c - 1.1 linux/sound/oss/ymfpci_image.h - 1.1 linux/sound/oss/ymfpci.h - 1.1 linux/sound/oss/ymfpci.c - 1.1 linux/sound/oss/wf_midi.c - 1.1 linux/sound/oss/wavfront.c - 1.1 linux/sound/oss/waveartist.h - 1.1 linux/sound/oss/waveartist.c - 1.1 linux/sound/oss/vwsnd.c - 1.1 linux/sound/oss/vidc_fill.S - 1.1 linux/sound/oss/vidc.h - 1.1 linux/arch/ppc/boot/simple/Makefile - 1.1 linux/arch/ppc/boot/simple/chrpmap.S - 1.1 linux/arch/ppc/boot/simple/direct.S - 1.1 linux/arch/ppc/boot/simple/embed_config.c - 1.1 linux/arch/ppc/boot/simple/gt64260_tty.c - 1.1 linux/arch/ppc/boot/simple/head.S - 1.1 linux/arch/ppc/boot/simple/iic.c - 1.1 linux/arch/ppc/boot/simple/legacy.S - 1.1 linux/arch/ppc/boot/simple/m8260_tty.c - 1.1 linux/arch/ppc/boot/simple/m8xx_tty.c - 1.1 linux/arch/ppc/boot/simple/misc-embedded.c - 1.1 linux/arch/ppc/boot/simple/misc-ev64260.S - 1.1 linux/arch/ppc/boot/simple/misc-spruce.c - 1.1 linux/arch/ppc/boot/simple/pci.c - 1.1 linux/arch/ppc/boot/simple/qspan_pci.c - 1.1 linux/arch/ppc/boot/simple/rw4/ppc_40x.h - 1.1 linux/arch/ppc/boot/simple/rw4/rw4_init.S - 1.1 linux/arch/ppc/boot/simple/rw4/rw4_init_brd.S - 1.1 linux/arch/ppc/boot/simple/rw4/stb.h - 1.1 linux/sound/oss/vidc.c - 1.1 linux/sound/oss/via82cxxx_audio.c - 1.1 linux/sound/oss/v_midi.h - 1.1 linux/sound/oss/v_midi.c - 1.1 linux/sound/oss/ulaw.h - 1.1 linux/sound/oss/uart6850.c - 1.1 linux/sound/oss/uart401.c - 1.1 linux/arch/ppc/boot/utils/addRamDisk.c - 1.1 linux/arch/ppc/boot/utils/addSystemMap.c - 1.1 linux/arch/ppc/boot/utils/mkbugboot.c - 1.1 linux/sound/oss/tuning.h - 1.1 linux/arch/ppc/boot/utils/mkimage.wrapper - 1.1 linux/sound/oss/trix.c - 1.1 linux/sound/oss/trident.h - 1.1 linux/arch/ppc/boot/utils/mktree.c - 1.1 linux/sound/oss/trident.c - 1.1 linux/sound/oss/sys_timer.c - 1.1 linux/sound/oss/sscape.c - 1.1 linux/sound/oss/soundvers.h - 1.1 linux/sound/oss/soundcard.c - 1.1 linux/sound/oss/sound_timer.c - 1.1 linux/arch/ppc/configs/FADS_defconfig - 1.1 linux/sound/oss/sound_syms.c - 1.1 linux/sound/oss/sound_firmware.h - 1.1 linux/sound/oss/sound_config.h - 1.1 linux/sound/oss/sound_calls.h - 1.1 linux/arch/ppc/configs/TQM8260_defconfig - 1.1 linux/sound/oss/sonicvibes.c - 1.1 linux/sound/oss/skeleton.c - 1.1 linux/arch/ppc/configs/adir_defconfig - 1.1 linux/sound/oss/sgalaxy.c - 1.1 linux/arch/ppc/configs/ash_defconfig - 1.1 linux/sound/oss/sequencer_syms.c - 1.1 linux/arch/ppc/configs/ceder_defconfig - 1.1 linux/sound/oss/sequencer.c - 1.1 linux/arch/ppc/configs/cpci405_defconfig - 1.1 linux/arch/ppc/configs/ep405_defconfig - 1.1 linux/sound/oss/sb_mixer.h - 1.1 linux/arch/ppc/configs/ev64260_defconfig - 1.1 linux/sound/oss/sb_mixer.c - 1.1 linux/arch/ppc/configs/iSeries_defconfig - 1.1 linux/sound/oss/sb_midi.c - 1.1 linux/arch/ppc/configs/k2_defconfig - 1.1 linux/arch/ppc/configs/lopec_defconfig - 1.1 linux/sound/oss/sb_ess.h - 1.1 linux/arch/ppc/configs/mcpn765_defconfig - 1.1 linux/arch/ppc/configs/menf1_defconfig - 1.1 linux/arch/ppc/configs/mvme5100_defconfig - 1.1 linux/sound/oss/sb_ess.c - 1.1 linux/arch/ppc/configs/pcore_defconfig - 1.1 linux/sound/oss/sb_common.c - 1.1 linux/sound/oss/sb_card.c - 1.1 linux/arch/ppc/configs/pplus_defconfig - 1.1 linux/arch/ppc/configs/prpmc750_defconfig - 1.1 linux/arch/ppc/configs/prpmc800_defconfig - 1.1 linux/arch/ppc/configs/redwood5_defconfig - 1.1 linux/arch/ppc/configs/redwood_defconfig - 1.1 linux/sound/oss/sb_audio.c - 1.1 linux/sound/oss/sb.h - 1.1 linux/arch/ppc/configs/sandpoint_defconfig - 1.1 linux/arch/ppc/configs/spruce_defconfig - 1.1 linux/sound/oss/rme96xx.h - 1.1 linux/arch/ppc/configs/zx4500_defconfig - 1.1 linux/sound/oss/rme96xx.c - 1.1 linux/arch/ppc/iSeries/HvCall.c - 1.1 linux/arch/ppc/iSeries/HvLpConfig.c - 1.1 linux/arch/ppc/iSeries/HvLpEvent.c - 1.1 linux/arch/ppc/iSeries/ItLpQueue.c - 1.1 linux/arch/ppc/iSeries/LparData.c - 1.1 linux/arch/ppc/iSeries/Makefile - 1.1 linux/arch/ppc/iSeries/XmPciLpEvent.c - 1.1 linux/arch/ppc/iSeries/createReleaseData - 1.1 linux/arch/ppc/iSeries/iSeries_FlightRecorder.c - 1.1 linux/arch/ppc/iSeries/iSeries_IoMmTable.c - 1.1 linux/arch/ppc/iSeries/iSeries_IoMmTable.h - 1.1 linux/arch/ppc/iSeries/iSeries_VpdInfo.c - 1.1 linux/arch/ppc/iSeries/iSeries_fixup.c - 1.1 linux/arch/ppc/iSeries/iSeries_irq.c - 1.1 linux/arch/ppc/iSeries/iSeries_ksyms.c - 1.1 linux/arch/ppc/iSeries/iSeries_pci.c - 1.1 linux/arch/ppc/iSeries/iSeries_pci.h - 1.1 linux/arch/ppc/iSeries/iSeries_pci_proc.c - 1.1 linux/arch/ppc/iSeries/iSeries_proc.c - 1.1 linux/arch/ppc/iSeries/iSeries_reset_device.c - 1.1 linux/arch/ppc/iSeries/mf.c - 1.1 linux/arch/ppc/iSeries/mf_proc.c - 1.1 linux/arch/ppc/iSeries/pmc_proc.c - 1.1 linux/arch/ppc/iSeries/rtc.c - 1.1 linux/sound/oss/pss.c - 1.1 linux/sound/oss/pas2_pcm.c - 1.1 linux/sound/oss/pas2_mixer.c - 1.1 linux/sound/oss/pas2_midi.c - 1.1 linux/sound/oss/pas2_card.c - 1.1 linux/sound/oss/pas2.h - 1.1 linux/sound/oss/os.h - 1.1 linux/sound/oss/opl3sa2.c - 1.1 linux/sound/oss/opl3sa.c - 1.1 linux/sound/oss/opl3_hw.h - 1.1 linux/sound/oss/opl3.h - 1.1 linux/sound/oss/opl3.c - 1.1 linux/sound/oss/nm256_coeff.h - 1.1 linux/sound/oss/nm256_audio.c - 1.1 linux/sound/oss/nm256.h - 1.1 linux/sound/oss/nec_vrc5477.c - 1.1 linux/sound/oss/msnd_pinnacle.h - 1.1 linux/sound/oss/msnd_pinnacle.c - 1.1 linux/sound/oss/msnd_classic.h - 1.1 linux/sound/oss/msnd_classic.c - 1.1 linux/sound/oss/msnd.h - 1.1 linux/arch/ppc/kernel/gt64260_common.c - 1.1 linux/arch/ppc/kernel/gt64260_pic.c - 1.1 linux/arch/ppc/kernel/harrier.c - 1.1 linux/sound/oss/msnd.c - 1.1 linux/sound/oss/mpu401.h - 1.1 linux/sound/oss/mpu401.c - 1.1 linux/sound/oss/midibuf.c - 1.1 linux/sound/oss/midi_synth.h - 1.1 linux/arch/ppc/kernel/iSeries_asm.h - 1.1 linux/arch/ppc/kernel/iSeries_head.S - 1.1 linux/arch/ppc/kernel/iSeries_misc.S - 1.1 linux/sound/oss/midi_synth.c - 1.1 linux/sound/oss/midi_syms.c - 1.1 linux/sound/oss/midi_ctrl.h - 1.1 linux/sound/oss/maui.c - 1.1 linux/sound/oss/maestro_tables.h - 1.1 linux/sound/oss/maestro3.h - 1.1 linux/sound/oss/maestro3.c - 1.1 linux/sound/oss/maestro.h - 1.1 linux/sound/oss/maestro.c - 1.1 linux/arch/ppc/kernel/mpc10x_common.c - 1.1 linux/sound/oss/mad16.c - 1.1 linux/sound/oss/iwmem.h - 1.1 linux/sound/oss/ite8172.c - 1.1 linux/sound/oss/ics2101.c - 1.1 linux/sound/oss/i810_audio.c - 1.1 linux/sound/oss/hex2hex.c - 1.1 linux/sound/oss/gus_wave.c - 1.1 linux/sound/oss/gus_vol.c - 1.1 linux/arch/ppc/kernel/pci_auto.c - 1.1 linux/sound/oss/gus_midi.c - 1.1 linux/sound/oss/gus_linearvol.h - 1.1 linux/sound/oss/gus_hw.h - 1.1 linux/sound/oss/gus_card.c - 1.1 linux/sound/oss/gus.h - 1.1 linux/sound/oss/esssolo1.c - 1.1 linux/sound/oss/es1371.c - 1.1 linux/sound/oss/es1370.c - 1.1 linux/sound/oss/emu10k1/voicemgr.h - 1.1 linux/arch/ppc/kernel/ppc405_dma.c - 1.1 linux/arch/ppc/kernel/ppc405_pci.c - 1.1 linux/arch/ppc/kernel/ppc4xx_kgdb.c - 1.1 linux/sound/oss/emu10k1/voicemgr.c - 1.1 linux/sound/oss/emu10k1/timer.h - 1.1 linux/arch/ppc/kernel/ppc4xx_pm.c - 1.1 linux/arch/ppc/kernel/ppc4xx_serial.c - 1.1 linux/arch/ppc/kernel/ppc4xx_setup.c - 1.1 linux/sound/oss/emu10k1/timer.c - 1.1 linux/sound/oss/emu10k1/recmgr.h - 1.1 linux/sound/oss/emu10k1/recmgr.c - 1.1 linux/sound/oss/emu10k1/passthrough.h - 1.1 linux/sound/oss/emu10k1/passthrough.c - 1.1 linux/sound/oss/emu10k1/mixer.c - 1.1 linux/sound/oss/emu10k1/midi.h - 1.1 linux/arch/ppc/kernel/pplus_common.c - 1.1 linux/sound/oss/emu10k1/midi.c - 1.1 linux/sound/oss/emu10k1/main.c - 1.1 linux/sound/oss/emu10k1/irqmgr.h - 1.1 linux/sound/oss/emu10k1/irqmgr.c - 1.1 linux/sound/oss/emu10k1/icardwav.h - 1.1 linux/sound/oss/emu10k1/icardmid.h - 1.1 linux/sound/oss/emu10k1/hwaccess.h - 1.1 linux/arch/ppc/kernel/prom_init.c - 1.1 linux/sound/oss/emu10k1/hwaccess.c - 1.1 linux/sound/oss/emu10k1/emuadxmg.c - 1.1 linux/sound/oss/emu10k1/efxmgr.h - 1.1 linux/sound/oss/emu10k1/efxmgr.c - 1.1 linux/sound/oss/emu10k1/ecard.h - 1.1 linux/sound/oss/emu10k1/ecard.c - 1.1 linux/sound/oss/emu10k1/cardwo.h - 1.1 linux/sound/oss/emu10k1/cardwo.c - 1.1 linux/sound/oss/emu10k1/cardwi.h - 1.1 linux/sound/oss/emu10k1/cardwi.c - 1.1 linux/arch/ppc/kernel/todc_time.c - 1.1 linux/sound/oss/emu10k1/cardmo.h - 1.1 linux/sound/oss/emu10k1/cardmo.c - 1.1 linux/sound/oss/emu10k1/cardmi.h - 1.1 linux/sound/oss/emu10k1/cardmi.c - 1.1 linux/sound/oss/emu10k1/audio.h - 1.1 linux/sound/oss/emu10k1/audio.c - 1.1 linux/sound/oss/emu10k1/Makefile - 1.1 linux/sound/oss/emu10k1/8010.h - 1.1 linux/sound/oss/dmasound/dmasound_q40.c - 1.1 linux/sound/oss/dmasound/dmasound_paula.c - 1.1 linux/sound/oss/dmasound/dmasound_core.c - 1.1 linux/sound/oss/dmasound/dmasound_awacs.c - 1.1 linux/sound/oss/dmasound/dmasound_atari.c - 1.1 linux/sound/oss/dmasound/dmasound.h - 1.1 linux/sound/oss/dmasound/awacs_defs.h - 1.1 linux/arch/ppc/mm/iSeries_hashtable.c - 1.1 linux/arch/ppc/mm/iSeries_mmu.c - 1.1 linux/sound/oss/dmasound/Makefile - 1.1 linux/sound/oss/dmasound/Config.in - 1.1 linux/sound/oss/dmasound/Config.help - 1.1 linux/sound/oss/dmabuf.c - 1.1 linux/sound/oss/dm.h - 1.1 linux/arch/ppc/platforms/Makefile - 1.1 linux/arch/ppc/platforms/adir.h - 1.1 linux/arch/ppc/platforms/adir_pci.c - 1.1 linux/arch/ppc/platforms/adir_pic.c - 1.1 linux/arch/ppc/platforms/adir_setup.c - 1.1 linux/arch/ppc/platforms/apus_pci.c - 1.1 linux/arch/ppc/platforms/apus_pci.h - 1.1 linux/arch/ppc/platforms/apus_setup.c - 1.1 linux/arch/ppc/platforms/ash.c - 1.1 linux/arch/ppc/platforms/ash.h - 1.1 linux/arch/ppc/platforms/bseip.h - 1.1 linux/arch/ppc/platforms/ccm.h - 1.1 linux/arch/ppc/platforms/ceder.c - 1.1 linux/arch/ppc/platforms/ceder.h - 1.1 linux/arch/ppc/platforms/chrp_pci.c - 1.1 linux/arch/ppc/platforms/chrp_setup.c - 1.1 linux/arch/ppc/platforms/chrp_smp.c - 1.1 linux/arch/ppc/platforms/chrp_time.c - 1.1 linux/arch/ppc/platforms/cpc700.h - 1.1 linux/arch/ppc/platforms/cpc700_pic.c - 1.1 linux/arch/ppc/platforms/cpc710.h - 1.1 linux/arch/ppc/platforms/cpci405.c - 1.1 linux/arch/ppc/platforms/cpci405.h - 1.1 linux/arch/ppc/platforms/ep405.c - 1.1 linux/arch/ppc/platforms/ep405.h - 1.1 linux/arch/ppc/platforms/error_log.c - 1.1 linux/arch/ppc/platforms/error_log.h - 1.1 linux/arch/ppc/platforms/est8260.h - 1.1 linux/arch/ppc/platforms/ev64260.h - 1.1 linux/arch/ppc/platforms/ev64260_setup.c - 1.1 linux/arch/ppc/platforms/fads.h - 1.1 linux/arch/ppc/platforms/gemini.h - 1.1 linux/arch/ppc/platforms/gemini_pci.c - 1.1 linux/arch/ppc/platforms/gemini_prom.S - 1.1 linux/arch/ppc/platforms/gemini_serial.h - 1.1 linux/arch/ppc/platforms/gemini_setup.c - 1.1 linux/arch/ppc/platforms/hermes.h - 1.1 linux/arch/ppc/platforms/iSeries_dma.c - 1.1 linux/arch/ppc/platforms/iSeries_pic.c - 1.1 linux/arch/ppc/platforms/iSeries_setup.c - 1.1 linux/arch/ppc/platforms/iSeries_setup.h - 1.1 linux/arch/ppc/platforms/iSeries_smp.c - 1.1 linux/arch/ppc/platforms/iSeries_time.c - 1.1 linux/arch/ppc/platforms/ibm405.h - 1.1 linux/arch/ppc/platforms/ibm405gp.c - 1.1 linux/arch/ppc/platforms/ibm405gp.h - 1.1 linux/arch/ppc/platforms/ibm_ocp.h - 1.1 linux/arch/ppc/platforms/ibmnp405h.c - 1.1 linux/arch/ppc/platforms/ibmnp405h.h - 1.1 linux/arch/ppc/platforms/ibmnp405l.c - 1.1 linux/arch/ppc/platforms/ibmnp405l.h - 1.1 linux/arch/ppc/platforms/ibmstb3.c - 1.1 linux/arch/ppc/platforms/ibmstb3.h - 1.1 linux/arch/ppc/platforms/ibmstb4.c - 1.1 linux/arch/ppc/platforms/ibmstb4.h - 1.1 linux/arch/ppc/platforms/ip860.h - 1.1 linux/arch/ppc/platforms/ivms8.h - 1.1 linux/arch/ppc/platforms/k2.h - 1.1 linux/arch/ppc/platforms/k2_pci.c - 1.1 linux/arch/ppc/platforms/k2_setup.c - 1.1 linux/arch/ppc/platforms/lantec.h - 1.1 linux/arch/ppc/platforms/lopec_pci.c - 1.1 linux/arch/ppc/platforms/lopec_serial.h - 1.1 linux/arch/ppc/platforms/lopec_setup.c - 1.1 linux/arch/ppc/platforms/lwmon.h - 1.1 linux/arch/ppc/platforms/mbx.h - 1.1 linux/arch/ppc/platforms/mcpn765.h - 1.1 linux/arch/ppc/platforms/mcpn765_pci.c - 1.1 linux/arch/ppc/platforms/mcpn765_serial.h - 1.1 linux/arch/ppc/platforms/mcpn765_setup.c - 1.1 linux/arch/ppc/platforms/menf1.h - 1.1 linux/arch/ppc/platforms/menf1_pci.c - 1.1 linux/arch/ppc/platforms/menf1_setup.c - 1.1 linux/arch/ppc/platforms/mvme5100.h - 1.1 linux/arch/ppc/platforms/mvme5100_pci.c - 1.1 linux/arch/ppc/platforms/mvme5100_serial.h - 1.1 linux/arch/ppc/platforms/mvme5100_setup.c - 1.1 linux/arch/ppc/platforms/oak.h - 1.1 linux/arch/ppc/platforms/oak_setup.c - 1.1 linux/arch/ppc/platforms/oak_setup.h - 1.1 linux/arch/ppc/platforms/pcore.h - 1.1 linux/arch/ppc/platforms/pcore_pci.c - 1.1 linux/arch/ppc/platforms/pcore_setup.c - 1.1 linux/arch/ppc/platforms/pcu_e.h - 1.1 linux/arch/ppc/platforms/pmac_backlight.c - 1.1 linux/arch/ppc/platforms/pmac_feature.c - 1.1 linux/arch/ppc/platforms/pmac_nvram.c - 1.1 linux/arch/ppc/platforms/pmac_pci.c - 1.1 linux/arch/ppc/platforms/pmac_pic.c - 1.1 linux/arch/ppc/platforms/pmac_pic.h - 1.1 linux/arch/ppc/platforms/pmac_setup.c - 1.1 linux/arch/ppc/platforms/pmac_smp.c - 1.1 linux/arch/ppc/platforms/pmac_time.c - 1.1 linux/arch/ppc/platforms/powerpmc250.c - 1.1 linux/arch/ppc/platforms/powerpmc250.h - 1.1 linux/arch/ppc/platforms/powerpmc250_serial.h - 1.1 linux/arch/ppc/platforms/pplus_pci.c - 1.1 linux/arch/ppc/platforms/pplus_setup.c - 1.1 linux/arch/ppc/platforms/prep_nvram.c - 1.1 linux/arch/ppc/platforms/prep_pci.c - 1.1 linux/arch/ppc/platforms/prep_setup.c - 1.1 linux/arch/ppc/platforms/prep_time.c - 1.1 linux/arch/ppc/platforms/proc_rtas.c - 1.1 linux/arch/ppc/platforms/prpmc750.h - 1.1 linux/arch/ppc/platforms/prpmc750_pci.c - 1.1 linux/arch/ppc/platforms/prpmc750_serial.h - 1.1 linux/arch/ppc/platforms/prpmc750_setup.c - 1.1 linux/arch/ppc/platforms/prpmc800.h - 1.1 linux/arch/ppc/platforms/prpmc800_pci.c - 1.1 linux/arch/ppc/platforms/prpmc800_serial.h - 1.1 linux/arch/ppc/platforms/prpmc800_setup.c - 1.1 linux/arch/ppc/platforms/redwood.c - 1.1 linux/arch/ppc/platforms/redwood.h - 1.1 linux/arch/ppc/platforms/redwood5.c - 1.1 linux/arch/ppc/platforms/redwood5.h - 1.1 linux/arch/ppc/platforms/residual.c - 1.1 linux/arch/ppc/platforms/rpxclassic.h - 1.1 linux/arch/ppc/platforms/rpxhiox.h - 1.1 linux/arch/ppc/platforms/rpxlite.h - 1.1 linux/arch/ppc/platforms/rpxsuper.h - 1.1 linux/arch/ppc/platforms/sandpoint.h - 1.1 linux/arch/ppc/platforms/sandpoint_pci.c - 1.1 linux/arch/ppc/platforms/sandpoint_serial.h - 1.1 linux/arch/ppc/platforms/sandpoint_setup.c - 1.1 linux/arch/ppc/platforms/sbs8260.h - 1.1 linux/arch/ppc/platforms/sleep.S - 1.1 linux/arch/ppc/platforms/spd8xx.h - 1.1 linux/arch/ppc/platforms/spruce.h - 1.1 linux/arch/ppc/platforms/spruce_pci.c - 1.1 linux/arch/ppc/platforms/spruce_serial.h - 1.1 linux/arch/ppc/platforms/spruce_setup.c - 1.1 linux/arch/ppc/platforms/tqm8260.h - 1.1 linux/arch/ppc/platforms/tqm8xx.h - 1.1 linux/arch/ppc/platforms/walnut.c - 1.1 linux/arch/ppc/platforms/walnut.h - 1.1 linux/arch/ppc/platforms/zx4500.h - 1.1 linux/arch/ppc/platforms/zx4500_pci.c - 1.1 linux/arch/ppc/platforms/zx4500_serial.h - 1.1 linux/arch/ppc/platforms/zx4500_setup.c - 1.1 linux/sound/oss/dev_table.h - 1.1 linux/sound/oss/dev_table.c - 1.1 linux/sound/oss/cs46xxpm.h - 1.1 linux/sound/oss/cs46xxpm-24.h - 1.1 linux/sound/oss/cs46xx_wrapper-24.h - 1.1 linux/sound/oss/cs46xx.c - 1.1 linux/sound/oss/cs461x_image.h - 1.1 linux/sound/oss/cs461x.h - 1.1 linux/sound/oss/cs4281/cs4281pm.h - 1.1 linux/sound/oss/cs4281/cs4281pm-24.c - 1.1 linux/sound/oss/cs4281/cs4281m.c - 1.1 linux/sound/oss/cs4281/cs4281_wrapper-24.c - 1.1 linux/sound/oss/cs4281/cs4281_hwdefs.h - 1.1 linux/sound/oss/cs4281/Makefile - 1.1 linux/sound/oss/cs4232.h - 1.1 linux/sound/oss/cs4232.c - 1.1 linux/sound/oss/coproc.h - 1.1 linux/sound/oss/cmpci.c - 1.1 linux/sound/oss/btaudio.c - 1.1 linux/arch/x86_64/Config.help - 1.1 linux/arch/x86_64/Makefile - 1.1 linux/arch/x86_64/boot/Makefile - 1.1 linux/arch/x86_64/boot/bootsect.S - 1.1 linux/arch/x86_64/boot/compressed/Makefile - 1.1 linux/arch/x86_64/boot/compressed/head.S - 1.1 linux/arch/x86_64/boot/compressed/misc.c - 1.1 linux/arch/x86_64/boot/compressed/miscsetup.h - 1.1 linux/arch/x86_64/boot/install.sh - 1.1 linux/arch/x86_64/boot/setup.S - 1.1 linux/arch/x86_64/boot/tools/build.c - 1.1 linux/arch/x86_64/boot/video.S - 1.1 linux/arch/x86_64/config.in - 1.1 linux/arch/x86_64/defconfig - 1.1 linux/arch/x86_64/ia32/Makefile - 1.1 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.1 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.1 linux/arch/x86_64/ia32/ia32_signal.c - 1.1 linux/arch/x86_64/ia32/ia32entry.S - 1.1 linux/arch/x86_64/ia32/ptrace32.c - 1.1 linux/arch/x86_64/ia32/socket32.c - 1.1 linux/arch/x86_64/ia32/sys_ia32.c - 1.1 linux/arch/x86_64/kernel/Makefile - 1.1 linux/arch/x86_64/kernel/apic.c - 1.1 linux/arch/x86_64/kernel/bluesmoke.c - 1.1 linux/arch/x86_64/kernel/cpuid.c - 1.1 linux/arch/x86_64/kernel/early_printk.c - 1.1 linux/arch/x86_64/kernel/entry.S - 1.1 linux/arch/x86_64/kernel/head.S - 1.1 linux/arch/x86_64/kernel/head64.c - 1.1 linux/arch/x86_64/kernel/i387.c - 1.1 linux/arch/x86_64/kernel/i8259.c - 1.1 linux/arch/x86_64/kernel/init_task.c - 1.1 linux/arch/x86_64/kernel/io_apic.c - 1.1 linux/arch/x86_64/kernel/ioport.c - 1.1 linux/arch/x86_64/kernel/irq.c - 1.1 linux/arch/x86_64/kernel/ldt.c - 1.1 linux/arch/x86_64/kernel/mpparse.c - 1.1 linux/arch/x86_64/kernel/msr.c - 1.1 linux/arch/x86_64/kernel/mtrr.c - 1.1 linux/arch/x86_64/kernel/nmi.c - 1.1 linux/arch/x86_64/kernel/pci-dma.c - 1.1 linux/arch/x86_64/kernel/pci-irq.c - 1.1 linux/arch/x86_64/kernel/pci-pc.c - 1.1 linux/arch/x86_64/kernel/pci-x86_64.c - 1.1 linux/arch/x86_64/kernel/pci-x86_64.h - 1.1 linux/arch/x86_64/kernel/process.c - 1.1 linux/arch/x86_64/kernel/ptrace.c - 1.1 linux/arch/x86_64/kernel/semaphore.c - 1.1 linux/arch/x86_64/kernel/setup.c - 1.1 linux/arch/x86_64/kernel/setup64.c - 1.1 linux/arch/x86_64/kernel/signal.c - 1.1 linux/arch/x86_64/kernel/smp.c - 1.1 linux/arch/x86_64/kernel/smpboot.c - 1.1 linux/arch/x86_64/kernel/sys_x86_64.c - 1.1 linux/arch/x86_64/kernel/syscall.c - 1.1 linux/arch/x86_64/kernel/time.c - 1.1 linux/arch/x86_64/kernel/trampoline.S - 1.1 linux/arch/x86_64/kernel/traps.c - 1.1 linux/arch/x86_64/kernel/vsyscall.c - 1.1 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.1 linux/arch/x86_64/lib/Makefile - 1.1 linux/arch/x86_64/lib/checksum_copy.S - 1.1 linux/arch/x86_64/lib/dec_and_lock.c - 1.1 linux/arch/x86_64/lib/delay.c - 1.1 linux/arch/x86_64/lib/generic-checksum.c - 1.1 linux/arch/x86_64/lib/getuser.S - 1.1 linux/arch/x86_64/lib/iodebug.c - 1.1 linux/arch/x86_64/lib/mmx.c - 1.1 linux/arch/x86_64/lib/old-checksum.c - 1.1 linux/arch/x86_64/lib/putuser.S - 1.1 linux/arch/x86_64/lib/rwsem_thunk.S - 1.1 linux/arch/x86_64/lib/usercopy.c - 1.1 linux/arch/x86_64/mm/Makefile - 1.1 linux/arch/x86_64/mm/extable.c - 1.1 linux/arch/x86_64/mm/fault.c - 1.1 linux/arch/x86_64/mm/init.c - 1.1 linux/arch/x86_64/mm/ioremap.c - 1.1 linux/arch/x86_64/tools/Makefile - 1.1 linux/arch/x86_64/tools/offset.c - 1.1 linux/arch/x86_64/tools/offset.sed - 1.1 linux/arch/x86_64/vmlinux.lds - 1.1 linux/sound/oss/bin2hex.c - 1.1 linux/sound/oss/awe_wave.h - 1.1 linux/sound/oss/awe_wave.c - 1.1 linux/sound/oss/awe_hw.h - 1.1 linux/sound/oss/audio_syms.c - 1.1 linux/sound/oss/audio.c - 1.1 linux/sound/oss/aedsp16.c - 1.1 linux/sound/oss/adlib_card.c - 1.1 linux/sound/oss/ad1848_mixer.h - 1.1 linux/sound/oss/ad1848.h - 1.1 linux/sound/oss/ad1848.c - 1.1 linux/sound/oss/ad1816.c - 1.1 linux/sound/oss/aci.h - 1.1 linux/sound/oss/aci.c - 1.1 linux/sound/oss/ac97_codec.c - 1.1 linux/sound/oss/ac97.h - 1.1 linux/sound/oss/ac97.c - 1.1 linux/sound/oss/README.FIRST - 1.1 linux/sound/oss/Makefile - 1.1 linux/sound/oss/Hwmcode.h - 1.1 linux/sound/oss/Config.in - 1.1 linux/sound/oss/Config.help - 1.1 linux/sound/oss/COPYING - 1.1 linux/sound/oss/CHANGELOG - 1.1 linux/sound/oss/724hwmcode.h - 1.1 linux/sound/last.c - 1.1 linux/sound/isa/wavefront/wavefront_synth.c - 1.1 linux/sound/isa/wavefront/wavefront_midi.c - 1.1 linux/sound/isa/wavefront/wavefront_fx.c - 1.1 linux/sound/isa/wavefront/wavefront.c - 1.1 linux/sound/isa/wavefront/Makefile - 1.1 linux/sound/isa/sgalaxy.c - 1.1 linux/sound/isa/sb/sbawe.c - 1.1 linux/sound/isa/sb/sb_mixer.c - 1.1 linux/sound/isa/sb/sb_common.c - 1.1 linux/sound/isa/sb/sb8_midi.c - 1.1 linux/sound/isa/sb/sb8_main.c - 1.1 linux/sound/isa/sb/sb8.c - 1.1 linux/sound/isa/sb/sb16_main.c - 1.1 linux/sound/isa/sb/sb16_csp_codecs.h - 1.1 linux/sound/isa/sb/sb16_csp.c - 1.1 linux/sound/isa/sb/sb16.c - 1.1 linux/sound/isa/sb/es968.c - 1.1 linux/sound/isa/sb/emu8000_synth.c - 1.1 linux/sound/isa/sb/emu8000_patch.c - 1.1 linux/sound/isa/sb/emu8000_local.h - 1.1 linux/sound/isa/sb/emu8000_callback.c - 1.1 linux/sound/isa/sb/emu8000.c - 1.1 linux/sound/isa/sb/Makefile - 1.1 linux/sound/isa/opti9xx/opti93x.c - 1.1 linux/sound/isa/opti9xx/opti92x-cs4231.c - 1.1 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.1 linux/sound/isa/opti9xx/Makefile - 1.1 linux/sound/isa/opl3sa2.c - 1.1 linux/sound/isa/gus/interwave.c - 1.1 linux/sound/isa/gus/interwave-stb.c - 1.1 linux/sound/isa/gus/gusmax.c - 1.1 linux/sound/isa/gus/gusextreme.c - 1.1 linux/sound/isa/gus/gusclassic.c - 1.1 linux/sound/isa/gus/gus_volume.c - 1.1 linux/sound/isa/gus/gus_uart.c - 1.1 linux/sound/isa/gus/gus_timer.c - 1.1 linux/sound/isa/gus/gus_tables.h - 1.1 linux/sound/isa/gus/gus_synth.c - 1.1 linux/sound/isa/gus/gus_simple.c - 1.1 linux/sound/isa/gus/gus_sample.c - 1.1 linux/sound/isa/gus/gus_reset.c - 1.1 linux/sound/isa/gus/gus_pcm.c - 1.1 linux/sound/isa/gus/gus_mixer.c - 1.1 linux/sound/isa/gus/gus_mem_proc.c - 1.1 linux/sound/isa/gus/gus_mem.c - 1.1 linux/sound/isa/gus/gus_main.c - 1.1 linux/sound/isa/gus/gus_lfo.c - 1.1 linux/sound/isa/gus/gus_irq.c - 1.1 linux/sound/isa/gus/gus_io.c - 1.1 linux/sound/isa/gus/gus_instr.c - 1.1 linux/sound/isa/gus/gus_dram.c - 1.1 linux/sound/isa/gus/gus_dma.c - 1.1 linux/sound/isa/gus/Makefile - 1.1 linux/sound/isa/es18xx.c - 1.1 linux/sound/isa/es1688/es1688_lib.c - 1.1 linux/sound/isa/es1688/es1688.c - 1.1 linux/sound/isa/es1688/Makefile - 1.1 linux/sound/isa/dt0197h.c - 1.1 linux/sound/isa/cs423x/cs4236_lib.c - 1.1 linux/sound/isa/cs423x/cs4236.c - 1.1 linux/sound/isa/cs423x/cs4232.c - 1.1 linux/sound/isa/cs423x/cs4231_lib.c - 1.1 linux/sound/isa/cs423x/cs4231.c - 1.1 linux/sound/isa/cs423x/Makefile - 1.1 linux/sound/isa/cmi8330.c - 1.1 linux/sound/isa/azt2320.c - 1.1 linux/sound/isa/als100.c - 1.1 linux/sound/isa/ad1848/ad1848_lib.c - 1.1 linux/sound/isa/ad1848/ad1848.c - 1.1 linux/sound/isa/ad1848/Makefile - 1.1 linux/sound/isa/ad1816a/ad1816a_lib.c - 1.1 linux/sound/isa/ad1816a/ad1816a.c - 1.1 linux/sound/isa/ad1816a/Makefile - 1.1 linux/sound/isa/Makefile - 1.1 linux/sound/isa/Config.in - 1.1 linux/sound/i2c/tea6330t.c - 1.1 linux/sound/i2c/i2c.c - 1.1 linux/sound/i2c/cs8427.c - 1.1 linux/sound/i2c/Makefile - 1.1 linux/sound/drivers/virmidi.c - 1.1 linux/sound/drivers/serial-u16550.c - 1.1 linux/sound/drivers/opl3/opl3_voice.h - 1.1 linux/sound/drivers/opl3/opl3_synth.c - 1.1 linux/sound/drivers/opl3/opl3_seq.c - 1.1 linux/sound/drivers/opl3/opl3_oss.c - 1.1 linux/sound/drivers/opl3/opl3_midi.c - 1.1 linux/sound/drivers/opl3/opl3_lib.c - 1.1 linux/sound/drivers/opl3/opl3_drums.c - 1.1 linux/sound/drivers/opl3/Makefile - 1.1 linux/sound/drivers/mtpav.c - 1.1 linux/sound/drivers/mpu401/mpu401_uart.c - 1.1 linux/sound/drivers/mpu401/mpu401.c - 1.1 linux/sound/drivers/mpu401/Makefile - 1.1 linux/sound/drivers/dummy.c - 1.1 linux/sound/drivers/Makefile - 1.1 linux/sound/drivers/Config.in - 1.1 linux/sound/core/wrappers.c - 1.1 linux/sound/core/timer.c - 1.1 linux/sound/core/sound_oss.c - 1.1 linux/sound/core/sound.c - 1.1 linux/sound/core/seq/seq_virmidi.c - 1.1 linux/sound/core/seq/seq_timer.h - 1.1 linux/sound/core/seq/seq_timer.c - 1.1 linux/sound/core/seq/seq_system.h - 1.1 linux/sound/core/seq/seq_system.c - 1.1 linux/sound/core/seq/seq_sync.h - 1.1 linux/sound/core/seq/seq_sync.c - 1.1 linux/sound/core/seq/seq_queue.h - 1.1 linux/sound/core/seq/seq_queue.c - 1.1 linux/sound/core/seq/seq_prioq.h - 1.1 linux/sound/core/seq/seq_prioq.c - 1.1 linux/sound/core/seq/seq_ports.h - 1.1 linux/sound/core/seq/seq_ports.c - 1.1 linux/sound/core/seq/seq_mtc.c - 1.1 linux/sound/core/seq/seq_midi_event.c - 1.1 linux/sound/core/seq/seq_midi_emul.c - 1.1 linux/sound/core/seq/seq_midi_clock.c - 1.1 linux/sound/core/seq/seq_midi.c - 1.1 linux/sound/core/seq/seq_memory.h - 1.1 linux/sound/core/seq/seq_memory.c - 1.1 linux/sound/core/seq/seq_lock.h - 1.1 linux/sound/core/seq/seq_lock.c - 1.1 linux/sound/core/seq/seq_instr.c - 1.1 linux/sound/core/seq/seq_info.h - 1.1 linux/sound/core/seq/seq_info.c - 1.1 linux/sound/core/seq/seq_fifo.h - 1.1 linux/sound/core/seq/seq_fifo.c - 1.1 linux/sound/core/seq/seq_dummy.c - 1.1 linux/sound/core/seq/seq_dtl.c - 1.1 linux/sound/core/seq/seq_device.c - 1.1 linux/sound/core/seq/seq_clientmgr.h - 1.1 linux/sound/core/seq/seq_clientmgr.c - 1.1 linux/sound/core/seq/seq.c - 1.1 linux/sound/core/seq/oss/seq_oss_writeq.h - 1.1 linux/sound/core/seq/oss/seq_oss_writeq.c - 1.1 linux/sound/core/seq/oss/seq_oss_timer.h - 1.1 linux/sound/core/seq/oss/seq_oss_timer.c - 1.1 linux/sound/core/seq/oss/seq_oss_synth.h - 1.1 linux/sound/core/seq/oss/seq_oss_synth.c - 1.1 linux/sound/core/seq/oss/seq_oss_rw.c - 1.1 linux/sound/core/seq/oss/seq_oss_readq.h - 1.1 linux/sound/core/seq/oss/seq_oss_readq.c - 1.1 linux/sound/core/seq/oss/seq_oss_misc.c - 1.1 linux/sound/core/seq/oss/seq_oss_midi.h - 1.1 linux/sound/core/seq/oss/seq_oss_midi.c - 1.1 linux/sound/core/seq/oss/seq_oss_ioctl.c - 1.1 linux/sound/core/seq/oss/seq_oss_init.c - 1.1 linux/sound/core/seq/oss/seq_oss_event.h - 1.1 linux/sound/core/seq/oss/seq_oss_event.c - 1.1 linux/sound/core/seq/oss/seq_oss_device.h - 1.1 linux/sound/core/seq/oss/seq_oss.c - 1.1 linux/sound/core/seq/oss/Makefile - 1.1 linux/sound/core/seq/instr/ainstr_simple.c - 1.1 linux/sound/core/seq/instr/ainstr_iw.c - 1.1 linux/sound/core/seq/instr/ainstr_gf1.c - 1.1 linux/sound/core/seq/instr/ainstr_fm.c - 1.1 linux/sound/core/seq/instr/Makefile - 1.1 linux/sound/core/seq/Makefile - 1.1 linux/sound/core/rtctimer.c - 1.1 linux/sound/core/rawmidi.c - 1.1 linux/sound/core/pcm_timer.c - 1.1 linux/sound/core/pcm_native.c - 1.1 linux/sound/core/pcm_misc.c - 1.1 linux/sound/core/pcm_memory.c - 1.1 linux/sound/core/pcm_lib.c - 1.1 linux/sound/core/pcm.c - 1.1 linux/sound/core/oss/route.c - 1.1 linux/sound/core/oss/rate.c - 1.1 linux/sound/core/oss/plugin_ops.h - 1.1 linux/sound/core/oss/pcm_plugin.h - 1.1 linux/sound/core/oss/pcm_plugin.c - 1.1 linux/sound/core/oss/pcm_oss.c - 1.1 linux/sound/core/oss/mulaw.c - 1.1 linux/sound/core/oss/mixer_oss.c - 1.1 linux/sound/core/oss/linear.c - 1.1 linux/sound/core/oss/io.c - 1.1 linux/sound/core/oss/copy.c - 1.1 linux/sound/core/oss/Makefile - 1.1 linux/sound/core/misc.c - 1.1 linux/sound/core/memory.c - 1.1 linux/sound/core/isadma.c - 1.1 linux/sound/core/init.c - 1.1 linux/sound/core/info_oss.c - 1.1 linux/sound/core/info.c - 1.1 linux/sound/core/hwdep.c - 1.1 linux/sound/core/device.c - 1.1 linux/sound/core/control.c - 1.1 linux/sound/core/Makefile - 1.1 linux/sound/core/Config.in - 1.1 linux/sound/Makefile - 1.1 linux/sound/Config.in - 1.1 linux/include/sound/pcm_oss.h - 1.1 linux/include/asm-x86_64/sembuf.h - 1.1 linux/include/asm-x86_64/semaphore.h - 1.1 linux/include/asm-x86_64/segment.h - 1.1 linux/include/asm-x86_64/scatterlist.h - 1.1 linux/include/asm-x86_64/rwsem.h - 1.1 linux/include/asm-x86_64/rwlock.h - 1.1 linux/include/asm-x86_64/resource.h - 1.1 linux/include/asm-x86_64/ptrace.h - 1.1 linux/include/asm-x86_64/processor.h - 1.1 linux/include/asm-x86_64/prctl.h - 1.1 linux/include/asm-x86_64/posix_types.h - 1.1 linux/include/asm-x86_64/poll.h - 1.1 linux/include/asm-x86_64/pgtable.h - 1.1 linux/include/asm-x86_64/pgalloc.h - 1.1 linux/include/asm-x86_64/pda.h - 1.1 linux/include/asm-x86_64/pci.h - 1.1 linux/include/asm-x86_64/parport.h - 1.1 linux/include/asm-x86_64/param.h - 1.1 linux/include/asm-x86_64/page.h - 1.1 linux/include/asm-x86_64/namei.h - 1.1 linux/include/asm-x86_64/mtrr.h - 1.1 linux/include/asm-x86_64/msr.h - 1.1 linux/include/asm-x86_64/msgbuf.h - 1.1 linux/include/asm-x86_64/mpspec.h - 1.1 linux/include/asm-x86_64/module.h - 1.1 linux/include/asm-x86_64/mmx.h - 1.1 linux/include/asm-x86_64/mmu_context.h - 1.1 linux/include/asm-x86_64/mmu.h - 1.1 linux/include/asm-x86_64/mman.h - 1.1 linux/include/asm-x86_64/mc146818rtc.h - 1.1 linux/include/asm-x86_64/locks.h - 1.1 linux/include/asm-x86_64/linux_logo.h - 1.1 linux/include/asm-x86_64/ldt.h - 1.1 linux/include/asm-x86_64/kmap_types.h - 1.1 linux/include/asm-x86_64/keyboard.h - 1.1 linux/include/asm-x86_64/kdebug.h - 1.1 linux/include/asm-x86_64/irq.h - 1.1 linux/include/asm-x86_64/ipcbuf.h - 1.1 linux/include/asm-x86_64/ipc.h - 1.1 linux/include/asm-x86_64/ioctls.h - 1.1 linux/include/asm-x86_64/ioctl.h - 1.1 linux/include/asm-x86_64/io_apic.h - 1.1 linux/drivers/usb/konicawc.c - 1.1 linux/include/asm-x86_64/io.h - 1.1 linux/include/asm-x86_64/init.h - 1.1 linux/include/asm-x86_64/ide.h - 1.1 linux/include/asm-x86_64/ia32_unistd.h - 1.1 linux/include/asm-x86_64/ia32.h - 1.1 linux/include/asm-x86_64/i387.h - 1.1 linux/include/asm-x86_64/hw_irq.h - 1.1 linux/include/asm-x86_64/hdreg.h - 1.1 linux/include/asm-x86_64/hardirq.h - 1.1 linux/include/asm-x86_64/floppy.h - 1.1 linux/include/asm-x86_64/fixmap.h - 1.1 linux/include/asm-x86_64/fcntl.h - 1.1 linux/include/asm-x86_64/errno.h - 1.1 linux/include/asm-x86_64/elf.h - 1.1 linux/include/asm-x86_64/e820.h - 1.1 linux/include/asm-x86_64/dma.h - 1.1 linux/include/asm-x86_64/div64.h - 1.1 linux/include/asm-x86_64/desc.h - 1.1 linux/include/asm-x86_64/delay.h - 1.1 linux/include/asm-x86_64/debugreg.h - 1.1 linux/include/asm-x86_64/current.h - 1.1 linux/include/asm-x86_64/cpufeature.h - 1.1 linux/include/asm-x86_64/checksum.h - 1.1 linux/include/asm-x86_64/calling.h - 1.1 linux/include/asm-x86_64/cache.h - 1.1 linux/include/asm-x86_64/byteorder.h - 1.1 linux/include/asm-x86_64/bugs.h - 1.1 linux/include/asm-x86_64/bootsetup.h - 1.1 linux/include/asm-x86_64/boot.h - 1.1 linux/include/asm-x86_64/bitops.h - 1.1 linux/include/asm-x86_64/atomic.h - 1.1 linux/include/asm-x86_64/apicdef.h - 1.1 linux/include/asm-x86_64/apic.h - 1.1 linux/include/sound/yss225.h - 1.1 linux/include/sound/ymfpci.h - 1.1 linux/include/sound/wavefront_fx.h - 1.1 linux/include/sound/wavefront.h - 1.1 linux/include/sound/version.h - 1.1 linux/include/sound/util_mem.h - 1.1 linux/include/sound/trident.h - 1.1 linux/include/sound/timer.h - 1.1 linux/include/sound/tea6330t.h - 1.1 linux/include/sound/soundmem.h - 1.1 linux/include/sound/soundfont.h - 1.1 linux/include/sound/sndmagic.h - 1.1 linux/include/sound/snd_wavefront.h - 1.1 linux/include/sound/sfnt_info.h - 1.1 linux/include/sound/seq_virmidi.h - 1.1 linux/include/sound/seq_oss_legacy.h - 1.1 linux/include/sound/seq_oss.h - 1.1 linux/include/sound/seq_midi_event.h - 1.1 linux/include/sound/seq_midi_emul.h - 1.1 linux/include/sound/seq_kernel.h - 1.1 linux/include/sound/seq_instr.h - 1.1 linux/include/sound/seq_device.h - 1.1 linux/include/sound/sb16_csp.h - 1.1 linux/include/sound/sb.h - 1.1 linux/include/sound/rawmidi.h - 1.1 linux/include/sound/pcm_params.h - 1.1 linux/include/sound/emux_synth.h - 1.1 linux/include/sound/pcm.h - 1.1 linux/include/sound/opl3.h - 1.1 linux/include/sound/mpu401.h - 1.1 linux/include/sound/mixer_oss.h - 1.1 linux/include/sound/minors.h - 1.1 linux/include/sound/initval.h - 1.1 linux/include/sound/info.h - 1.1 linux/include/sound/i2c.h - 1.1 linux/include/sound/hwdep.h - 1.1 linux/include/sound/gus.h - 1.1 linux/include/sound/es1688.h - 1.1 linux/include/asm-x86_64/system.h - 1.1 linux/include/sound/emux_legacy.h - 1.1 linux/include/sound/emu8000_reg.h - 1.1 linux/include/sound/emu8000.h - 1.1 linux/include/sound/emu10k1_synth.h - 1.1 linux/include/sound/emu10k1.h - 1.1 linux/include/sound/driver.h - 1.1 linux/include/sound/cs8427.h - 1.1 linux/include/sound/cs8403.h - 1.1 linux/include/sound/cs46xx.h - 1.1 linux/include/sound/cs4231.h - 1.1 linux/include/sound/core.h - 1.1 linux/include/sound/control.h - 1.1 linux/include/sound/asoundef.h - 1.1 linux/include/sound/asound_fm.h - 1.1 linux/include/sound/asound.h - 1.1 linux/include/sound/asequencer.h - 1.1 linux/include/sound/ak4531_codec.h - 1.1 linux/include/sound/ainstr_simple.h - 1.1 linux/include/sound/ainstr_iw.h - 1.1 linux/include/sound/ainstr_gf1.h - 1.1 linux/include/sound/ainstr_fm.h - 1.1 linux/include/sound/ad1848.h - 1.1 linux/include/sound/ad1816a.h - 1.1 linux/include/sound/ac97_codec.h - 1.1 linux/include/asm-x86_64/a.out.h - 1.1 linux/include/asm-x86_64/serial.h - 1.1 linux/include/asm-x86_64/setup.h - 1.1 linux/include/asm-x86_64/shmbuf.h - 1.1 linux/include/asm-x86_64/shmparam.h - 1.1 linux/include/asm-x86_64/sigcontext.h - 1.1 linux/include/asm-x86_64/siginfo.h - 1.1 linux/include/asm-x86_64/signal.h - 1.1 linux/include/asm-ppc/todc.h - 1.1 linux/include/asm-x86_64/smp.h - 1.1 linux/include/asm-ppc/thread_info.h - 1.1 linux/include/asm-x86_64/smplock.h - 1.1 linux/include/asm-x86_64/socket.h - 1.1 linux/include/asm-x86_64/socket32.h - 1.1 linux/include/asm-x86_64/sockios.h - 1.1 linux/include/asm-ppc/pplus.h - 1.1 linux/include/asm-ppc/ppc_asm.h - 1.1 linux/include/asm-x86_64/softirq.h - 1.1 linux/include/asm-ppc/ppc4xx_pic.h - 1.1 linux/include/asm-x86_64/spinlock.h - 1.1 linux/include/asm-ppc/ppc405_dma.h - 1.1 linux/include/asm-ppc/pmac_feature.h - 1.1 linux/include/asm-x86_64/stat.h - 1.1 linux/include/asm-ppc/pc_serial.h - 1.1 linux/include/asm-ppc/open_pic.h - 1.1 linux/include/asm-x86_64/statfs.h - 1.1 linux/include/asm-x86_64/string.h - 1.1 linux/include/asm-ppc/iSeries/veth-proc.h - 1.1 linux/include/asm-ppc/mpc10x.h - 1.1 linux/include/asm-x86_64/termbits.h - 1.1 linux/include/asm-x86_64/termios.h - 1.1 linux/include/asm-ppc/ibm4xx.h - 1.1 linux/include/asm-ppc/ibm403.h - 1.1 linux/include/asm-x86_64/user32.h - 1.1 linux/include/asm-ppc/iSeries/pmc_proc.h - 1.1 linux/include/asm-ppc/iSeries/mf_proc.h - 1.1 linux/include/asm-ppc/iSeries/mf.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_proc.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_pci.h - 1.1 linux/include/asm-alpha/thread_info.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_irq.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_io.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_fixup.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_dma.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_VpdInfo.h - 1.1 linux/include/asm-ppc/iSeries/iSeries_FlightRecorder.h - 1.1 linux/include/asm-ppc/iSeries/XmPciLpEvent.h - 1.1 linux/include/asm-ppc/iSeries/Paca.h - 1.1 linux/include/asm-ppc/iSeries/Naca.h - 1.1 linux/include/asm-ppc/iSeries/LparMap.h - 1.1 linux/include/asm-ppc/iSeries/LparData.h - 1.1 linux/include/asm-ppc/iSeries/ItVpdAreas.h - 1.1 linux/include/asm-ppc/iSeries/ItSpCommArea.h - 1.1 linux/include/asm-ppc/iSeries/ItLpRegSave.h - 1.1 linux/include/asm-x86_64/xor.h - 1.1 linux/include/asm-ppc/iSeries/ItLpQueue.h - 1.1 linux/include/asm-ppc/iSeries/ItLpPaca.h - 1.1 linux/include/asm-x86_64/vsyscall.h - 1.1 linux/include/asm-x86_64/vga.h - 1.1 linux/include/asm-ppc/iSeries/ItIplParmsReal.h - 1.1 linux/include/asm-x86_64/user.h - 1.1 linux/include/asm-ppc/iSeries/ItLpNaca.h - 1.1 linux/include/asm-ppc/iSeries/HvCallSc.h - 1.1 linux/include/asm-ppc/ans-lcd.h - 1.1 linux/include/asm-ppc/iSeries/IoHriProcessorVpd.h - 1.1 linux/include/asm-ppc/iSeries/IoHriMainStore.h - 1.1 linux/include/asm-x86_64/unistd.h - 1.1 linux/include/asm-ppc/iSeries/HvTypes.h - 1.1 linux/include/asm-x86_64/unaligned.h - 1.1 linux/include/asm-ppc/iSeries/HvReleaseData.h - 1.1 linux/include/asm-ppc/iSeries/HvLpEvent.h - 1.1 linux/include/asm-ppc/iSeries/HvLpConfig.h - 1.1 linux/include/asm-ppc/iSeries/HvCallXm.h - 1.1 linux/include/asm-ppc/iSeries/HvCallSm.h - 1.1 linux/include/asm-x86_64/ucontext.h - 1.1 linux/include/asm-ppc/iSeries/HvCallPci.h - 1.1 linux/include/asm-ppc/iSeries/HvCallCfg.h - 1.1 linux/include/asm-x86_64/uaccess.h - 1.1 linux/include/asm-x86_64/types.h - 1.1 linux/include/asm-ppc/iSeries/HvCallHpt.h - 1.1 linux/include/asm-ppc/gt64260.h - 1.1 linux/include/asm-ppc/gt64260_defs.h - 1.1 linux/include/asm-ppc/iSeries/HvCallEvent.h - 1.1 linux/include/asm-ppc/harrier.h - 1.1 linux/include/asm-x86_64/tlb.h - 1.1 linux/include/asm-x86_64/timex.h - 1.1 linux/include/asm-x86_64/thread_info.h - 1.1 linux/include/asm-ppc/i8259.h - 1.1 linux/include/asm-ppc/iSeries/HvCall.h - 1.1 linux/scripts/Menuconfig - 1.15 linux/net/x25/x25_timer.c - 1.6 linux/net/x25/x25_subr.c - 1.7 linux/net/x25/x25_out.c - 1.8 linux/net/x25/x25_in.c - 1.9 linux/net/x25/x25_facilities.c - 1.6 linux/net/x25/af_x25.c - 1.25 linux/net/unix/garbage.c - 1.12 linux/net/unix/af_unix.c - 1.41 linux/net/sunrpc/xprt.c - 1.22 linux/net/sunrpc/svcsock.c - 1.16 linux/net/sunrpc/svc.c - 1.11 linux/net/sunrpc/sched.c - 1.27 linux/net/sunrpc/clnt.c - 1.15 linux/net/rose/rose_timer.c - 1.5 linux/net/rose/rose_subr.c - 1.6 linux/net/rose/rose_route.c - 1.9 linux/net/rose/rose_out.c - 1.5 linux/net/rose/rose_in.c - 1.5 linux/net/rose/af_rose.c - 1.23 linux/net/packet/af_packet.c - 1.30 linux/net/netsyms.c - 1.42 linux/net/netrom/nr_timer.c - 1.5 linux/net/netrom/nr_subr.c - 1.5 linux/net/netrom/nr_out.c - 1.5 linux/net/netrom/nr_in.c - 1.4 linux/net/netrom/af_netrom.c - 1.22 linux/net/netlink/af_netlink.c - 1.18 linux/net/irda/af_irda.c - 1.32 linux/net/ipx/af_spx.c - 1.16 linux/net/ipx/af_ipx.c - 1.25 linux/net/ipv6/udp.c - 1.24 linux/net/ipv6/tcp_ipv6.c - 1.33 linux/net/ipv6/raw.c - 1.22 linux/net/ipv6/proc.c - 1.10 linux/net/ipv6/ndisc.c - 1.19 linux/net/ipv6/mcast.c - 1.17 linux/net/ipv6/ipv6_sockglue.c - 1.14 linux/net/ipv6/ip6_output.c - 1.14 linux/net/ipv6/ip6_flowlabel.c - 1.6 linux/net/ipv6/icmp.c - 1.18 linux/net/ipv6/datagram.c - 1.10 linux/net/ipv6/af_inet6.c - 1.20 linux/net/ipv4/udp.c - 1.29 linux/net/ipv4/tcp_timer.c - 1.23 linux/net/ipv4/tcp_output.c - 1.28 linux/net/ipv4/tcp_ipv4.c - 1.42 linux/net/ipv4/tcp_input.c - 1.35 linux/net/ipv4/tcp.c - 1.37 linux/net/ipv4/syncookies.c - 1.14 linux/net/ipv4/raw.c - 1.21 linux/net/ipv4/ipconfig.c - 1.28 linux/net/ipv4/ip_sockglue.c - 1.18 linux/net/ipv4/ip_output.c - 1.30 linux/net/ipv4/igmp.c - 1.16 linux/net/ipv4/icmp.c - 1.27 linux/net/ipv4/af_inet.c - 1.32 linux/net/core/sock.c - 1.24 linux/net/core/datagram.c - 1.12 linux/net/ax25/ax25_subr.c - 1.7 linux/net/ax25/ax25_std_timer.c - 1.4 linux/net/ax25/ax25_std_in.c - 1.4 linux/net/ax25/ax25_in.c - 1.11 linux/net/ax25/ax25_ds_timer.c - 1.4 linux/net/ax25/ax25_ds_in.c - 1.5 linux/net/ax25/af_ax25.c - 1.24 linux/net/appletalk/ddp.c - 1.20 linux/mm/mmap.c - 1.46 linux/mm/memory.c - 1.75 linux/kernel/sys.c - 1.28 linux/kernel/signal.c - 1.27 linux/kernel/sched.c - 1.59 linux/kernel/ksyms.c - 1.134 linux/kernel/kmod.c - 1.18 linux/kernel/fork.c - 1.49 linux/kernel/exit.c - 1.41 linux/include/net/x25.h - 1.10 linux/include/net/udp.h - 1.7 linux/include/net/tcp.h - 1.28 linux/include/net/spx.h - 1.3 linux/include/net/sock.h - 1.29 linux/include/net/route.h - 1.16 linux/include/net/rose.h - 1.6 linux/include/net/netrom.h - 1.6 linux/include/net/irda/irda.h - 1.15 linux/include/net/ipx.h - 1.8 linux/include/net/ip6_route.h - 1.6 linux/include/net/ip.h - 1.16 linux/include/net/icmp.h - 1.7 linux/include/net/checksum.h - 1.7 linux/include/net/ax25.h - 1.8 linux/include/net/af_unix.h - 1.5 linux/include/linux/tcp.h - 1.9 linux/include/linux/sched.h - 1.62 linux/include/linux/proc_fs.h - 1.33 linux/include/linux/nbd.h - 1.11 linux/include/linux/ipv6.h - 1.3 linux/include/linux/ip.h - 1.4 linux/include/linux/init.h - 1.16 linux/include/linux/igmp.h - 1.6 linux/include/linux/if_ec.h - 1.5 linux/include/linux/fs.h - 1.150 linux/include/linux/dcache.h - 1.21 linux/include/linux/atalk.h - 1.5 linux/include/asm-sparc64/pgtable.h - 1.31 linux/include/asm-sparc64/page.h - 1.14 linux/include/asm-sparc64/irq.h - 1.11 linux/include/asm-sparc/pgtable.h - 1.23 linux/include/asm-sparc/page.h - 1.14 linux/include/asm-ppc/system.h - 1.20 linux/include/asm-ppc/spinlock.h - 1.12 linux/include/asm-ppc/smp.h - 1.14 linux/include/asm-ppc/serial.h - 1.11 linux/include/asm-ppc/scatterlist.h - 1.8 linux/include/asm-ppc/ptrace.h - 1.9 linux/include/asm-ppc/prom.h - 1.14 linux/include/asm-ppc/processor.h - 1.30 linux/include/asm-ppc/posix_types.h - 1.8 linux/include/asm-ppc/pgtable.h - 1.30 linux/include/asm-ppc/pci-bridge.h - 1.9 linux/include/asm-ppc/page.h - 1.14 linux/include/asm-ppc/ohare.h - 1.6 linux/include/asm-ppc/mmu_context.h - 1.13 linux/include/asm-ppc/mmu.h - 1.10 linux/include/asm-ppc/mediabay.h - 1.6 linux/include/asm-ppc/mbx.h - 1.8 linux/include/asm-ppc/machdep.h - 1.21 linux/include/asm-ppc/kgdb.h - 1.5 linux/include/asm-ppc/keyboard.h - 1.11 linux/include/asm-ppc/irq.h - 1.15 linux/include/asm-ppc/io.h - 1.16 linux/include/asm-ppc/ide.h - 1.15 linux/include/asm-ppc/hardirq.h - 1.15 linux/include/asm-ppc/gg2.h - 1.4 linux/include/asm-ppc/feature.h - 1.12 linux/include/asm-ppc/fads.h - 1.6 linux/include/asm-ppc/dma.h - 1.9 linux/include/asm-ppc/delay.h - 1.6 linux/include/asm-ppc/dbdma.h - 1.5 linux/include/asm-ppc/cache.h - 1.10 linux/include/asm-ppc/byteorder.h - 1.8 linux/include/asm-ppc/bootinfo.h - 1.9 linux/include/asm-ppc/bitops.h - 1.11 linux/include/asm-ppc/atomic.h - 1.10 linux/include/asm-ppc/amigaints.h - 1.6 linux/include/asm-ppc/8xx_immap.h - 1.5 linux/include/asm-mips/pgtable.h - 1.16 linux/include/asm-mips/page.h - 1.8 linux/include/asm-m68k/page.h - 1.10 linux/include/asm-i386/system.h - 1.24 linux/include/asm-i386/smplock.h - 1.14 linux/include/asm-i386/processor.h - 1.33 linux/include/asm-i386/pgtable.h - 1.29 linux/include/asm-i386/page.h - 1.24 linux/include/asm-i386/mmu_context.h - 1.17 linux/include/asm-i386/bitops.h - 1.11 linux/include/asm-arm/page.h - 1.14 linux/include/asm-alpha/unistd.h - 1.17 linux/include/asm-alpha/uaccess.h - 1.7 linux/include/asm-alpha/system.h - 1.18 linux/include/asm-alpha/sysinfo.h - 1.3 linux/include/asm-alpha/spinlock.h - 1.13 linux/include/asm-alpha/smp.h - 1.18 linux/include/asm-alpha/processor.h - 1.15 linux/include/asm-alpha/page.h - 1.15 linux/include/asm-alpha/mmu_context.h - 1.12 linux/include/asm-alpha/io.h - 1.18 linux/include/asm-alpha/fpu.h - 1.7 linux/include/asm-alpha/current.h - 1.3 linux/include/asm-alpha/bitops.h - 1.11 linux/include/asm-alpha/asm_offsets.h - 1.3 linux/fs/vfat/namei.c - 1.26 linux/fs/ufs/truncate.c - 1.16 linux/fs/ufs/namei.c - 1.14 linux/fs/sysv/namei.c - 1.15 linux/fs/sysv/inode.c - 1.30 linux/fs/smbfs/sock.c - 1.12 linux/fs/smbfs/dir.c - 1.18 linux/fs/romfs/inode.c - 1.31 linux/fs/readdir.c - 1.13 linux/fs/qnx4/truncate.c - 1.5 linux/fs/qnx4/namei.c - 1.13 linux/fs/qnx4/inode.c - 1.31 linux/fs/proc/root.c - 1.27 linux/fs/proc/inode.c - 1.19 linux/fs/proc/generic.c - 1.27 linux/fs/proc/base.c - 1.34 linux/fs/proc/array.c - 1.38 linux/fs/ntfs/fs.c - 1.39 linux/fs/nfsd/vfs.c - 1.45 linux/fs/nfsd/nfssvc.c - 1.19 linux/fs/nfsd/export.c - 1.26 linux/fs/nfs/dir.c - 1.34 linux/fs/ncpfs/sock.c - 1.12 linux/fs/ncpfs/inode.c - 1.27 linux/fs/ncpfs/dir.c - 1.27 linux/fs/namei.c - 1.47 linux/fs/msdos/namei.c - 1.26 linux/fs/minix/namei.c - 1.16 linux/fs/minix/inode.c - 1.30 linux/fs/lockd/svc.c - 1.16 linux/fs/lockd/clntproc.c - 1.16 linux/fs/isofs/namei.c - 1.10 linux/fs/inode.c - 1.65 linux/fs/hfs/file.c - 1.16 linux/fs/hfs/dir_nat.c - 1.10 linux/fs/hfs/dir_dbl.c - 1.10 linux/fs/hfs/dir_cap.c - 1.10 linux/fs/fat/inode.c - 1.37 linux/fs/fat/file.c - 1.20 linux/fs/ext2/super.c - 1.26 linux/fs/ext2/namei.c - 1.22 linux/fs/ext2/inode.c - 1.42 linux/fs/ext2/balloc.c - 1.18 linux/fs/dquot.c - 1.49 linux/fs/devpts/root.c - 1.14 linux/fs/coda/dir.c - 1.22 linux/fs/buffer.c - 1.111 linux/fs/binfmt_misc.c - 1.19 linux/fs/binfmt_elf.c - 1.39 linux/fs/autofs/waitq.c - 1.6 linux/fs/autofs/root.c - 1.17 linux/fs/autofs/dir.c - 1.9 linux/fs/affs/namei.c - 1.16 linux/fs/affs/inode.c - 1.18 linux/fs/affs/file.c - 1.25 linux/fs/adfs/dir.c - 1.16 linux/drivers/video/vgacon.c - 1.18 linux/drivers/video/fbmem.c - 1.45 linux/drivers/usb/usb.c - 1.69 linux/drivers/usb/Makefile - 1.48 linux/drivers/usb/Config.in - 1.53 linux/drivers/sound/yss225.h - 1.4 linux/drivers/sound/yss225.c - 1.4 linux/drivers/sound/wf_midi.c - 1.10 linux/drivers/sound/wavfront.c - 1.21 linux/drivers/sound/waveartist.h - 1.5 linux/drivers/sound/waveartist.c - 1.15 linux/drivers/sound/vidc_fill.S - 1.5 linux/drivers/sound/vidc.h - 1.5 linux/drivers/sound/vidc.c - 1.12 linux/drivers/sound/v_midi.h - 1.3 linux/drivers/sound/v_midi.c - 1.8 linux/drivers/sound/ulaw.h - 1.3 linux/drivers/sound/uart6850.c - 1.10 linux/drivers/sound/uart401.c - 1.10 linux/drivers/sound/tuning.h - 1.3 linux/drivers/sound/trix.c - 1.12 linux/drivers/sound/sys_timer.c - 1.7 linux/drivers/sound/sscape.c - 1.14 linux/drivers/sound/soundvers.h - 1.3 linux/drivers/sound/soundcard.c - 1.24 linux/drivers/sound/sound_timer.c - 1.8 linux/drivers/sound/sound_syms.c - 1.8 linux/drivers/sound/sound_firmware.h - 1.3 linux/drivers/sound/sound_firmware.c - 1.5 linux/drivers/sound/sound_core.c - 1.22 linux/drivers/sound/sound_config.h - 1.6 linux/drivers/sound/sound_calls.h - 1.7 linux/drivers/sound/sonicvibes.c - 1.37 linux/drivers/sound/skeleton.c - 1.6 linux/drivers/sound/sgalaxy.c - 1.10 linux/drivers/sound/sequencer_syms.c - 1.5 linux/drivers/sound/sequencer.c - 1.9 linux/drivers/sound/sb_mixer.h - 1.6 linux/drivers/sound/sb_mixer.c - 1.11 linux/drivers/sound/sb_midi.c - 1.7 linux/drivers/sound/sb_ess.h - 1.3 linux/drivers/sound/sb_ess.c - 1.13 linux/drivers/sound/sb_common.c - 1.20 linux/drivers/sound/sb_card.c - 1.32 linux/drivers/sound/sb_audio.c - 1.9 linux/drivers/sound/sb.h - 1.11 linux/drivers/sound/pss.c - 1.11 linux/drivers/sound/pas2_pcm.c - 1.8 linux/drivers/sound/pas2_mixer.c - 1.9 linux/drivers/sound/pas2_midi.c - 1.8 linux/drivers/sound/pas2_card.c - 1.7 linux/drivers/sound/os.h - 1.6 linux/drivers/sound/opl3sa2.c - 1.15 linux/drivers/sound/opl3sa.c - 1.10 linux/drivers/sound/opl3.h - 1.5 linux/drivers/sound/opl3.c - 1.10 linux/drivers/sound/msnd_pinnacle.h - 1.4 linux/drivers/sound/msnd_pinnacle.c - 1.20 linux/drivers/sound/msnd_classic.h - 1.4 linux/drivers/sound/msnd_classic.c - 1.3 linux/drivers/sound/msnd.h - 1.6 linux/drivers/sound/msnd.c - 1.10 linux/drivers/sound/mpu401.c - 1.13 linux/drivers/sound/midibuf.c - 1.9 linux/drivers/sound/midi_synth.h - 1.4 linux/drivers/sound/midi_synth.c - 1.6 linux/drivers/sound/midi_syms.c - 1.3 linux/drivers/sound/midi_ctrl.h - 1.3 linux/drivers/sound/maui.c - 1.10 linux/drivers/sound/mad16.c - 1.15 linux/drivers/sound/iwmem.h - 1.4 linux/drivers/sound/ics2101.c - 1.8 linux/drivers/sound/hex2hex.c - 1.3 linux/drivers/sound/gus_wave.c - 1.9 linux/drivers/sound/gus_vol.c - 1.6 linux/drivers/sound/gus_midi.c - 1.9 linux/drivers/sound/gus_linearvol.h - 1.3 linux/drivers/sound/gus_hw.h - 1.3 linux/drivers/sound/gus_card.c - 1.8 linux/drivers/sound/es1371.c - 1.38 linux/drivers/sound/es1370.c - 1.37 linux/drivers/sound/dmabuf.c - 1.9 linux/drivers/sound/dm.h - 1.3 linux/drivers/sound/dev_table.h - 1.15 linux/drivers/sound/dev_table.c - 1.11 linux/drivers/sound/cs4232.c - 1.11 linux/drivers/sound/coproc.h - 1.3 linux/drivers/sound/bin2hex.c - 1.4 linux/drivers/sound/audio_syms.c - 1.3 linux/drivers/sound/audio.c - 1.8 linux/drivers/sound/adlib_card.c - 1.10 linux/drivers/sound/ad1848_mixer.h - 1.4 linux/drivers/sound/ad1848.c - 1.16 linux/drivers/sound/ad1816.c - 1.15 linux/drivers/sound/README.FIRST - 1.3 linux/drivers/sound/Makefile - 1.33 linux/drivers/sound/Config.in - 1.30 linux/drivers/sound/COPYING - 1.3 linux/drivers/sound/CHANGELOG - 1.3 linux/drivers/scsi/sd.c - 1.55 linux/drivers/scsi/aha1542.c - 1.24 linux/drivers/pci/pci.c - 1.53 linux/drivers/net/yellowfin.c - 1.30 linux/drivers/net/via-rhine.c - 1.33 linux/drivers/net/pcnet32.c - 1.31 linux/drivers/net/ni52.c - 1.16 linux/drivers/net/ne.c - 1.20 linux/drivers/net/mace.c - 1.17 linux/drivers/net/eexpress.c - 1.18 linux/drivers/net/eepro100.c - 1.39 linux/drivers/net/bmac.c - 1.19 linux/drivers/net/acenic.c - 1.37 linux/drivers/net/Makefile - 1.53 linux/drivers/net/Config.in - 1.57 linux/drivers/net/3c59x.c - 1.32 linux/drivers/net/3c509.c - 1.28 linux/drivers/net/3c505.c - 1.24 linux/drivers/char/serial.c - 1.56 linux/drivers/char/pcwd.c - 1.18 linux/drivers/char/ftape/lowlevel/fdc-io.c - 1.6 linux/drivers/block/nbd.c - 1.34 linux/drivers/block/loop.c - 1.52 linux/drivers/block/ll_rw_blk.c - 1.92 linux/drivers/Makefile - 1.29 linux/arch/sparc64/solaris/signal.c - 1.4 linux/arch/sparc64/kernel/sys_sunos32.c - 1.36 linux/arch/sparc64/kernel/sys_sparc32.c - 1.43 linux/arch/sparc64/kernel/signal32.c - 1.21 linux/arch/sparc64/kernel/signal.c - 1.19 linux/arch/sparc64/config.in - 1.52 linux/arch/sparc/kernel/sys_sunos.c - 1.35 linux/arch/sparc/kernel/signal.c - 1.22 linux/arch/ppc/vmlinux.lds - 1.13 linux/arch/ppc/mm/init.c - 1.38 linux/arch/ppc/mm/fault.c - 1.18 linux/arch/ppc/mm/Makefile - 1.8 linux/arch/ppc/lib/string.S - 1.8 linux/arch/ppc/lib/locks.c - 1.9 linux/arch/ppc/lib/checksum.S - 1.7 linux/arch/ppc/kernel/traps.c - 1.24 linux/arch/ppc/kernel/time.c - 1.18 linux/arch/ppc/kernel/softemu8xx.c - 1.7 linux/arch/ppc/kernel/smp.c - 1.32 linux/arch/ppc/kernel/signal.c - 1.14 linux/arch/ppc/kernel/setup.c - 1.41 linux/arch/ppc/kernel/residual.c - 1.9 linux/arch/ppc/kernel/ptrace.c - 1.12 linux/arch/ppc/kernel/prom.c - 1.28 linux/arch/ppc/kernel/process.c - 1.34 linux/arch/ppc/kernel/prep_time.c - 1.8 linux/arch/ppc/kernel/prep_setup.c - 1.29 linux/arch/ppc/kernel/prep_pci.c - 1.15 linux/arch/ppc/kernel/prep_nvram.c - 1.9 linux/arch/ppc/kernel/ppc_ksyms.c - 1.39 linux/arch/ppc/kernel/ppc_asm.tmpl - 1.5 linux/arch/ppc/kernel/ppc8xx_pic.h - 1.6 linux/arch/ppc/kernel/ppc8xx_pic.c - 1.8 linux/arch/ppc/kernel/ppc-stub.c - 1.9 linux/arch/ppc/kernel/pmac_time.c - 1.15 linux/arch/ppc/kernel/pmac_setup.c - 1.28 linux/arch/ppc/kernel/pmac_pic.h - 1.6 linux/arch/ppc/kernel/pmac_pic.c - 1.22 linux/arch/ppc/kernel/pmac_pci.c - 1.19 linux/arch/ppc/kernel/pci.h - 1.7 linux/arch/ppc/kernel/pci.c - 1.25 linux/arch/ppc/kernel/open_pic.h - 1.11 linux/arch/ppc/kernel/open_pic.c - 1.22 linux/arch/ppc/kernel/mk_defs.c - 1.15 linux/arch/ppc/kernel/misc.S - 1.34 linux/arch/ppc/kernel/local_irq.h - 1.10 linux/arch/ppc/kernel/irq.c - 1.33 linux/arch/ppc/kernel/indirect_pci.c - 1.7 linux/arch/ppc/kernel/idle.c - 1.21 linux/arch/ppc/kernel/i8259.h - 1.4 linux/arch/ppc/kernel/i8259.c - 1.9 linux/arch/ppc/kernel/head.S - 1.30 linux/arch/ppc/kernel/feature.c - 1.16 linux/arch/ppc/kernel/chrp_time.c - 1.11 linux/arch/ppc/kernel/chrp_setup.c - 1.28 linux/arch/ppc/kernel/chrp_pci.c - 1.20 linux/arch/ppc/kernel/checks.c - 1.5 linux/arch/ppc/kernel/bitops.c - 1.5 linux/arch/ppc/kernel/apus_setup.c - 1.23 linux/arch/ppc/kernel/align.c - 1.8 linux/arch/ppc/kernel/Makefile - 1.26 linux/arch/ppc/defconfig - 1.37 linux/arch/ppc/config.in - 1.44 linux/arch/ppc/boot/Makefile - 1.17 linux/arch/ppc/amiga/config.c - 1.16 linux/arch/ppc/amiga/cia.c - 1.7 linux/arch/ppc/amiga/amiints.c - 1.12 linux/arch/ppc/Makefile - 1.23 linux/arch/ppc/8xx_io/uart.c - 1.18 linux/arch/ppc/8xx_io/fec.c - 1.17 linux/arch/ppc/8xx_io/enet.c - 1.17 linux/arch/ppc/8xx_io/commproc.c - 1.12 linux/arch/ppc/8xx_io/Makefile - 1.7 linux/arch/mips/kernel/signal.c - 1.15 linux/arch/mips/kernel/irixsig.c - 1.11 linux/arch/mips/config.in - 1.27 linux/arch/m68k/kernel/signal.c - 1.15 linux/arch/m68k/config.in - 1.26 linux/arch/i386/kernel/vm86.c - 1.12 linux/arch/i386/kernel/signal.c - 1.23 linux/arch/i386/kernel/ptrace.c - 1.21 linux/arch/i386/kernel/process.c - 1.45 linux/arch/i386/kernel/i386_ksyms.c - 1.45 linux/arch/i386/kernel/entry.S - 1.48 linux/arch/i386/kernel/apm.c - 1.39 linux/arch/i386/config.in - 1.73 linux/arch/arm/kernel/signal.c - 1.19 linux/arch/arm/kernel/ecard.c - 1.17 linux/arch/arm/config.in - 1.33 linux/arch/alpha/mm/init.c - 1.20 linux/arch/alpha/mm/fault.c - 1.16 linux/arch/alpha/kernel/traps.c - 1.19 linux/arch/alpha/kernel/smp.c - 1.31 linux/arch/alpha/kernel/signal.c - 1.13 linux/arch/alpha/kernel/ptrace.c - 1.13 linux/arch/alpha/kernel/process.c - 1.22 linux/arch/alpha/kernel/osf_sys.c - 1.28 linux/arch/alpha/kernel/head.S - 1.6 linux/arch/alpha/kernel/entry.S - 1.25 linux/arch/alpha/kernel/check_asm.c - 1.4 linux/arch/alpha/kernel/Makefile - 1.19 linux/arch/alpha/config.in - 1.41 linux/arch/alpha/Makefile - 1.11 linux/Rules.make - 1.15 linux/Makefile - 1.185 linux/MAINTAINERS - 1.96 linux/net/decnet/dn_nsp_out.c - 1.11 linux/net/decnet/dn_nsp_in.c - 1.16 linux/net/decnet/af_decnet.c - 1.29 linux/include/net/dn_route.h - 1.5 linux/include/net/dn_nsp.h - 1.5 linux/include/net/dn.h - 1.8 linux/include/linux/ide.h - 1.38 linux/fs/hpfs/file.c - 1.19 linux/fs/hpfs/dir.c - 1.12 linux/fs/efs/namei.c - 1.3 linux/drivers/sound/cmpci.c - 1.32 linux/arch/ppc/xmon/xmon.c - 1.18 linux/arch/ppc/xmon/subr_prf.c - 1.4 linux/arch/ppc/xmon/start.c - 1.17 linux/arch/ppc/xmon/nonstdio.h - 1.3 linux/drivers/block/cpqarray.c - 1.41 linux/kernel/ptrace.c - 1.19 linux/fs/file.c - 1.10 linux/drivers/sound/esssolo1.c - 1.35 linux/net/khttpd/waitheaders.c - 1.7 linux/net/khttpd/prototypes.h - 1.3 linux/net/khttpd/main.c - 1.10 linux/net/khttpd/datasending.c - 1.10 linux/net/khttpd/accept.c - 1.4 linux/drivers/sound/vwsnd.c - 1.14 linux/drivers/sound/ac97.h - 1.6 linux/drivers/net/sis900.c - 1.30 linux/drivers/net/sb1000.c - 1.15 linux/net/core/netfilter.c - 1.14 linux/net/atm/svc.c - 1.11 linux/net/atm/resources.c - 1.7 linux/net/atm/pvc.c - 1.10 linux/net/atm/mpc.c - 1.9 linux/net/atm/common.c - 1.17 linux/include/linux/netfilter_ipv4.h - 1.7 linux/include/linux/atmdev.h - 1.10 linux/arch/ppc/kernel/semaphore.c - 1.6 linux/arch/ppc/kernel/ppc_asm.h - 1.10 linux/arch/ppc/kernel/head_8xx.S - 1.15 linux/arch/ppc/kernel/gemini_setup.c - 1.21 linux/arch/ppc/kernel/gemini_prom.S - 1.7 linux/arch/ppc/kernel/gemini_pci.c - 1.9 linux/arch/ppc/kernel/entry.S - 1.24 linux/arch/sh/kernel/signal.c - 1.15 linux/arch/sh/config.in - 1.23 linux/drivers/sound/maestro_tables.h - 1.2 linux/drivers/sound/maestro.h - 1.2 linux/drivers/sound/maestro.c - 1.28 linux/include/asm-sh/pgtable.h - 1.23 linux/include/asm-ppc/gemini_serial.h - 1.8 linux/include/asm-ppc/gemini.h - 1.6 linux/fs/udf/inode.c - 1.29 linux/fs/udf/namei.c - 1.20 linux/include/linux/spinlock.h - 1.14 linux/include/asm-ppc/pci.h - 1.16 linux/drivers/sound/nm256_coeff.h - 1.3 linux/drivers/sound/nm256_audio.c - 1.14 linux/drivers/sound/nm256.h - 1.3 linux/drivers/sound/ac97.c - 1.6 linux/drivers/net/dmfe.c - 1.23 linux/drivers/net/tokenring/olympic.h - 1.9 linux/drivers/net/tokenring/olympic.c - 1.17 linux/drivers/net/tokenring/ibmtr.c - 1.20 linux/arch/ppc/kernel/sleep.S - 1.6 linux/arch/ppc/kernel/qspan_pci.c - 1.5 linux/arch/ppc/kernel/m8xx_setup.c - 1.22 linux/arch/ppc/8xx_io/Config.in - 1.7 linux/include/linux/pci_ids.h - 1.58 linux/include/asm-ppc/rpxlite.h - 1.5 linux/include/asm-ppc/rpxclassic.h - 1.7 linux/include/asm-ppc/mpc8xx.h - 1.8 linux/mm/highmem.c - 1.36 linux/fs/bfs/dir.c - 1.18 linux/drivers/pci/pci.ids - 1.41 linux/include/asm-alpha/pgalloc.h - 1.12 linux/arch/ppc/mm/mem_pieces.c - 1.6 linux/arch/ppc/kernel/pmac_nvram.c - 1.11 linux/arch/ppc/kernel/oak_setup.h - 1.5 linux/arch/ppc/kernel/oak_setup.c - 1.10 linux/arch/ppc/kernel/head_4xx.S - 1.6 linux/arch/ppc/configs/walnut_defconfig - 1.16 linux/arch/ppc/configs/pmac_defconfig - 1.4 linux/arch/ppc/configs/oak_defconfig - 1.16 linux/arch/ppc/configs/mbx_defconfig - 1.11 linux/arch/ppc/configs/gemini_defconfig - 1.18 linux/arch/ppc/configs/common_defconfig - 1.24 linux/arch/ppc/configs/apus_defconfig - 1.12 linux/arch/alpha/math-emu/math.c - 1.4 linux/include/asm-ppc/walnut.h - 1.5 linux/include/asm-ppc/oak.h - 1.7 linux/include/asm-ppc/board.h - 1.5 linux/drivers/sound/trident.h - 1.14 linux/drivers/sound/trident.c - 1.33 linux/drivers/net/aironet4500_core.c - 1.17 linux/kernel/timer.c - 1.18 linux/drivers/scsi/scsi_merge.c - 1.37 linux/include/asm-ppc/hw_irq.h - 1.7 linux/fs/openpromfs/inode.c - 1.17 linux/fs/cramfs/inode.c - 1.24 linux/drivers/usb/usbmouse.c - 1.17 linux/drivers/usb/usbkbd.c - 1.23 linux/drivers/usb/hid.h - 1.17 linux/drivers/usb/hid-debug.h - 1.7 linux/drivers/net/arcnet/com90io.c - 1.9 linux/Documentation/usb/error-codes.txt - 1.6 linux/arch/ppc/mm/4xx_tlb.h - 1.3 linux/arch/ppc/kernel/ppc4xx_pic.c - 1.4 linux/arch/ppc/kernel/ppc4xx_pic.h - 1.4 linux/arch/ppc/mm/4xx_tlb.c - 1.4 linux/drivers/usb/inode.c - 1.22 linux/include/asm-m68k/pgalloc.h - 1.8 linux/fs/autofs4/waitq.c - 1.7 linux/fs/autofs4/root.c - 1.13 linux/drivers/sound/ac97_codec.c - 1.22 linux/arch/ia64/ia32/ia32_signal.c - 1.8 linux/arch/ppc/kernel/walnut_setup.h - 1.3 linux/arch/ppc/kernel/walnut_setup.c - 1.7 linux/arch/ppc/kernel/pci-dma.c - 1.4 linux/arch/ppc/kernel/galaxy_pci.c - 1.4 linux/arch/ia64/config.in - 1.23 linux/arch/alpha/kernel/pci_iommu.c - 1.18 linux/arch/ia64/kernel/signal.c - 1.12 linux/drivers/sound/via82cxxx_audio.c - 1.26 linux/drivers/net/gmac.c - 1.13 linux/drivers/net/gmac.h - 1.6 linux/include/asm-ia64/page.h - 1.11 linux/include/asm-ppc/heathrow.h - 1.6 linux/drivers/net/8139too.c - 1.35 linux/fs/devfs/base.c - 1.33 linux/drivers/net/skfp/h/cmtdef.h - 1.2 linux/drivers/net/tulip/tulip_core.c - 1.38 linux/include/asm-mips64/pgtable.h - 1.11 linux/include/asm-mips64/page.h - 1.5 linux/arch/mips64/config.in - 1.18 linux/arch/mips64/kernel/signal32.c - 1.10 linux/arch/mips64/kernel/signal.c - 1.9 linux/drivers/usb/wacom.c - 1.17 linux/drivers/sound/pas2.h - 1.2 linux/drivers/sound/opl3_hw.h - 1.2 linux/drivers/sound/mpu401.h - 1.4 linux/drivers/sound/gus.h - 1.2 linux/drivers/sound/cs4232.h - 1.3 linux/drivers/sound/ad1848.h - 1.3 linux/net/econet/af_econet.c - 1.9 linux/include/linux/usb.h - 1.30 linux/drivers/usb/serial/ftdi_sio.h - 1.6 linux/drivers/sound/awe_wave.h - 1.3 linux/drivers/sound/awe_wave.c - 1.11 linux/drivers/sound/awe_hw.h - 1.3 linux/drivers/sound/aedsp16.c - 1.7 linux/drivers/sound/aci.c - 1.9 linux/drivers/ide/ide-proc.c - 1.11 linux/drivers/ide/ide-dma.c - 1.18 linux/drivers/ide/ide-disk.c - 1.24 linux/drivers/net/wan/comx.c - 1.15 linux/net/ipv4/netfilter/iptable_mangle.c - 1.10 linux/net/ipv4/netfilter/ip_queue.c - 1.13 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.14 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.11 linux/drivers/isdn/avmb1/capifs.c - 1.15 linux/drivers/sound/dmasound/dmasound_q40.c - 1.7 linux/drivers/sound/dmasound/dmasound_paula.c - 1.7 linux/drivers/sound/dmasound/dmasound_core.c - 1.9 linux/drivers/sound/dmasound/dmasound_awacs.c - 1.10 linux/drivers/sound/dmasound/dmasound_atari.c - 1.8 linux/drivers/sound/dmasound/dmasound.h - 1.5 linux/drivers/sound/dmasound/Makefile - 1.3 linux/drivers/sound/dmasound/Config.in - 1.2 linux/fs/ramfs/inode.c - 1.17 linux/drivers/usb/serial/ftdi_sio.c - 1.31 linux/drivers/sound/i810_audio.c - 1.22 linux/drivers/sound/emu10k1/voicemgr.h - 1.4 linux/drivers/sound/emu10k1/voicemgr.c - 1.4 linux/drivers/sound/emu10k1/timer.h - 1.4 linux/drivers/sound/emu10k1/timer.c - 1.3 linux/drivers/sound/emu10k1/recmgr.h - 1.3 linux/drivers/sound/emu10k1/recmgr.c - 1.4 linux/drivers/sound/emu10k1/mixer.c - 1.8 linux/drivers/sound/emu10k1/midi.h - 1.2 linux/drivers/sound/emu10k1/midi.c - 1.11 linux/drivers/sound/emu10k1/main.c - 1.14 linux/drivers/sound/emu10k1/irqmgr.h - 1.4 linux/drivers/sound/emu10k1/irqmgr.c - 1.4 linux/drivers/sound/emu10k1/icardwav.h - 1.4 linux/drivers/sound/emu10k1/icardmid.h - 1.2 linux/drivers/sound/emu10k1/hwaccess.h - 1.7 linux/drivers/sound/emu10k1/hwaccess.c - 1.4 linux/drivers/sound/emu10k1/emuadxmg.c - 1.3 linux/drivers/sound/emu10k1/efxmgr.h - 1.4 linux/drivers/sound/emu10k1/efxmgr.c - 1.5 linux/drivers/sound/emu10k1/cardwo.h - 1.4 linux/drivers/sound/emu10k1/cardwo.c - 1.7 linux/drivers/sound/emu10k1/cardwi.h - 1.4 linux/drivers/sound/emu10k1/cardwi.c - 1.6 linux/drivers/sound/emu10k1/cardmo.h - 1.3 linux/drivers/sound/emu10k1/cardmo.c - 1.5 linux/drivers/sound/emu10k1/cardmi.h - 1.5 linux/drivers/sound/emu10k1/cardmi.c - 1.5 linux/drivers/sound/emu10k1/audio.h - 1.3 linux/drivers/sound/emu10k1/audio.c - 1.15 linux/drivers/sound/emu10k1/Makefile - 1.6 linux/drivers/sound/emu10k1/8010.h - 1.4 linux/include/linux/if_pppox.h - 1.5 linux/include/asm-ppc/mpc8260.h - 1.4 linux/include/asm-ppc/est8260.h - 1.4 linux/drivers/usb/serial/digi_acceleport.c - 1.23 linux/drivers/sound/dmasound/awacs_defs.h - 1.3 linux/drivers/net/pppox.c - 1.8 linux/drivers/net/pppoe.c - 1.18 linux/arch/ppc/kernel/ppc8260_pic.h - 1.3 linux/arch/ppc/kernel/ppc8260_pic.c - 1.4 linux/arch/ppc/kernel/m8260_setup.c - 1.14 linux/arch/ppc/8260_io/uart.c - 1.10 linux/arch/ppc/8260_io/Config.in - 1.3 linux/include/asm-s390/page.h - 1.6 linux/include/asm-s390/pgtable.h - 1.10 linux/arch/s390/kernel/signal.c - 1.9 linux/Documentation/filesystems/Locking - 1.6 linux/include/asm-ppc/time.h - 1.9 linux/drivers/usb/storage/usb.c - 1.18 linux/drivers/usb/storage/debug.c - 1.7 linux/drivers/usb/serial/keyspan_usa28msg.h - 1.4 linux/drivers/usb/serial/keyspan_usa26msg.h - 1.4 linux/drivers/usb/serial/keyspan.h - 1.9 linux/drivers/usb/serial/keyspan.c - 1.21 linux/arch/alpha/vmlinux.lds.in - 1.8 linux/fs/jffs/inode-v23.c - 1.20 linux/fs/jffs/intrep.c - 1.11 linux/drivers/sound/Hwmcode.h - 1.2 linux/drivers/sound/724hwmcode.h - 1.3 linux/include/net/inet_ecn.h - 1.3 linux/drivers/mtd/mtdblock.c - 1.12 linux/arch/ppc/kernel/xics.h - 1.3 linux/arch/ppc/kernel/xics.c - 1.4 linux/arch/ppc/kernel/pmac_backlight.c - 1.5 linux/arch/ppc/configs/rpxlite_defconfig - 1.11 linux/arch/ppc/configs/rpxcllf_defconfig - 1.12 linux/arch/ppc/configs/est8260_defconfig - 1.12 linux/arch/ppc/configs/bseip_defconfig - 1.11 linux/drivers/net/tun.c - 1.12 linux/net/ipv4/tcp_minisocks.c - 1.11 linux/Documentation/cachetlb.txt - 1.9 linux/drivers/sound/emu10k1/ecard.h - 1.5 linux/drivers/sound/emu10k1/ecard.c - 1.3 linux/drivers/sound/cs46xx.c - 1.18 linux/drivers/sound/cs461x_image.h - 1.5 linux/drivers/sound/cs461x.h - 1.3 linux/drivers/media/video/saa5249.c - 1.7 linux/drivers/md/raid1.c - 1.18 linux/arch/ppc/8260_io/fcc_enet.c - 1.5 linux/drivers/block/cciss.c - 1.29 linux/drivers/block/cciss_cmd.h - 1.9 linux/include/asm-ppc/highmem.h - 1.6 linux/include/asm-ppc/keylargo.h - 1.5 linux/mm/oom_kill.c - 1.14 linux/drivers/usb/pegasus.h - 1.9 linux/kernel/context.c - 1.6 linux/arch/alpha/lib/ev6-memset.S - 1.2 linux/include/asm-parisc/page.h - 1.2 linux/drivers/usb/serial/keyspan_usa49msg.h - 1.3 linux/include/asm-parisc/pgalloc.h - 1.4 linux/arch/parisc/kernel/signal.c - 1.3 linux/drivers/sound/ymfpci_image.h - 1.3 linux/drivers/sound/ymfpci.h - 1.7 linux/drivers/sound/ymfpci.c - 1.21 linux/arch/parisc/config.in - 1.5 linux/mm/shmem.c - 1.29 linux/fs/reiserfs/stree.c - 1.20 linux/fs/reiserfs/super.c - 1.18 linux/fs/reiserfs/prints.c - 1.12 linux/fs/reiserfs/namei.c - 1.19 linux/fs/reiserfs/journal.c - 1.23 linux/fs/reiserfs/item_ops.c - 1.6 linux/fs/reiserfs/fix_node.c - 1.17 linux/fs/reiserfs/file.c - 1.9 linux/fs/reiserfs/dir.c - 1.11 linux/include/linux/reiserfs_fs.h - 1.20 linux/arch/ppc/kernel/proc_rtas.c - 1.3 linux/arch/ppc/kernel/open_pic_defs.h - 1.5 linux/arch/ppc/kernel/error_log.h - 1.3 linux/arch/ppc/kernel/error_log.c - 1.3 linux/arch/ppc/configs/power3_defconfig - 1.9 linux/arch/ppc/configs/ibmchrp_defconfig - 1.9 linux/arch/s390x/kernel/signal32.c - 1.5 linux/include/asm-s390x/pgtable.h - 1.6 linux/arch/s390x/kernel/signal.c - 1.6 linux/include/asm-s390x/page.h - 1.5 linux/drivers/sound/maestro3.h - 1.2 linux/drivers/sound/maestro3.c - 1.12 linux/drivers/sound/cs4281/cs4281pm.h - 1.2 linux/drivers/sound/cs4281/cs4281pm-24.c - 1.2 linux/drivers/sound/cs4281/cs4281m.c - 1.11 linux/drivers/sound/cs4281/cs4281_wrapper-24.c - 1.3 linux/drivers/sound/cs4281/cs4281_hwdefs.h - 1.2 linux/arch/s390x/kernel/linux32.c - 1.9 linux/drivers/sound/cs4281/Makefile - 1.2 linux/arch/cris/config.in - 1.11 linux/arch/cris/kernel/signal.c - 1.7 linux/include/asm-cris/pgtable.h - 1.7 linux/include/asm-cris/page.h - 1.3 linux/include/asm-ppc/tqm8xx.h - 1.6 linux/include/asm-ppc/spd8xx.h - 1.5 linux/include/asm-ppc/ivms8.h - 1.5 linux/drivers/usb/serial/io_usbvend.h - 1.6 linux/drivers/usb/serial/io_ionsp.h - 1.2 linux/drivers/usb/serial/io_fw_down2.h - 1.2 linux/drivers/usb/serial/io_fw_down.h - 1.2 linux/drivers/usb/serial/io_fw_boot2.h - 1.2 linux/drivers/usb/serial/io_fw_boot.h - 1.2 linux/drivers/usb/serial/io_edgeport.h - 1.3 linux/drivers/usb/serial/io_edgeport.c - 1.20 linux/arch/ppc/configs/TQM860L_defconfig - 1.10 linux/arch/ppc/configs/TQM850L_defconfig - 1.9 linux/arch/ppc/configs/TQM823L_defconfig - 1.9 linux/arch/ppc/configs/SPD823TS_defconfig - 1.9 linux/arch/ppc/configs/SM850_defconfig - 1.9 linux/arch/ppc/configs/IVMS8_defconfig - 1.10 linux/net/wanrouter/af_wanpipe.c - 1.4 linux/drivers/sound/aci.h - 1.3 linux/drivers/sound/cs46xx_wrapper-24.h - 1.2 linux/drivers/sound/cs46xxpm-24.h - 1.3 linux/drivers/sound/cs46xxpm.h - 1.2 linux/include/linux/if_wanpipe.h - 1.2 linux/arch/ppc/boot/tree/misc.S - 1.2 linux/include/asm-ppc/ppc4xx.h - 1.2 linux/include/asm-ppc/ppc4xx_serial.h - 1.2 linux/include/asm-ppc/rpxhiox.h - 1.2 linux/fs/freevxfs/vxfs_lookup.c - 1.5 linux/arch/ppc/kernel/apus_pci.h - 1.2 linux/arch/ppc/kernel/apus_pci.c - 1.4 linux/arch/ppc/boot/utils/size - 1.2 linux/arch/ppc/boot/utils/sisize - 1.2 linux/arch/ppc/boot/utils/sioffset - 1.2 linux/arch/ppc/boot/utils/piggyback.c - 1.2 linux/arch/ppc/boot/utils/offset - 1.2 linux/arch/ppc/boot/utils/mksimage.c - 1.2 linux/arch/ppc/boot/utils/mkirimg - 1.2 linux/arch/ppc/boot/utils/mkevimg - 1.3 linux/arch/ppc/boot/utils/Makefile - 1.3 linux/arch/ppc/boot/tree/main.c - 1.3 linux/arch/ppc/boot/tree/ld.script - 1.3 linux/arch/ppc/boot/tree/irSect.h - 1.2 linux/arch/ppc/boot/tree/irSect.c - 1.2 linux/arch/ppc/boot/tree/Makefile - 1.3 linux/arch/ppc/boot/prep/vreset.c - 1.3 linux/arch/ppc/boot/prep/misc.c - 1.6 linux/arch/ppc/boot/prep/kbd.c - 1.2 linux/arch/ppc/boot/prep/head.S - 1.3 linux/arch/ppc/boot/prep/Makefile - 1.6 linux/arch/ppc/boot/pmac/ld.script - 1.3 linux/arch/ppc/boot/pmac/dummy.c - 1.2 linux/arch/ppc/boot/pmac/coffmain.c - 1.4 linux/arch/ppc/boot/pmac/chrpmain.c - 1.4 linux/arch/ppc/boot/pmac/Makefile - 1.5 linux/arch/ppc/boot/mbx/rdimage.c - 1.2 linux/arch/ppc/boot/mbx/qspan_pci.c - 1.2 linux/arch/ppc/boot/mbx/pci.c - 1.2 linux/arch/ppc/boot/mbx/misc.c - 1.4 linux/arch/ppc/boot/mbx/m8xx_tty.c - 1.3 linux/arch/ppc/boot/mbx/m8260_tty.c - 1.2 linux/arch/ppc/boot/mbx/iic.c - 1.3 linux/arch/ppc/boot/mbx/head_8260.S - 1.2 linux/arch/ppc/boot/mbx/head.S - 1.2 linux/arch/ppc/boot/mbx/gzimage.c - 1.2 linux/arch/ppc/boot/mbx/embed_config.c - 1.2 linux/arch/ppc/boot/mbx/Makefile - 1.3 linux/arch/ppc/boot/lib/zlib.c - 1.2 linux/arch/ppc/boot/images/Makefile - 1.2 linux/arch/ppc/boot/common/ns16550.c - 1.3 linux/arch/ppc/boot/common/no_initrd.c - 1.2 linux/arch/ppc/boot/common/misc-simple.c - 1.3 linux/arch/ppc/boot/common/crt0.S - 1.3 linux/arch/ppc/boot/common/Makefile - 1.2 linux/arch/ppc/boot/chrp/main.c - 1.4 linux/arch/ppc/boot/chrp/Makefile - 1.4 linux/net/bluetooth/af_bluetooth.c - 1.4 linux/net/bluetooth/hci_sock.c - 1.4 linux/net/bluetooth/l2cap_core.c - 1.5 linux/fs/sysv/itree.c - 1.5 linux/arch/ppc/mm/hashtable.S - 1.3 linux/drivers/sound/emu10k1/passthrough.c - 1.4 linux/drivers/sound/emu10k1/passthrough.h - 1.4 linux/drivers/sound/btaudio.c - 1.7 linux/drivers/sound/rme96xx.c - 1.5 linux/drivers/sound/rme96xx.h - 1.2 linux/arch/alpha/kernel/srm_env.c - 1.3 linux/arch/ppc/mm/4xx_mmu.c - 1.3 linux/arch/ppc/mm/cachemap.c - 1.3 linux/arch/ppc/mm/mmu_decl.h - 1.3 linux/arch/ppc/mm/pgtable.c - 1.3 linux/arch/ppc/mm/ppc_mmu.c - 1.2 linux/include/asm-ppc/btext.h - 1.2 linux/arch/ppc/kernel/pmac_smp.c - 1.3 linux/arch/ppc/boot/common/ofcommon.c - 1.2 linux/arch/ppc/kernel/l2cr.S - 1.2 linux/arch/ppc/kernel/cputable.c - 1.3 linux/arch/ppc/kernel/chrp_smp.c - 1.3 linux/arch/ppc/kernel/btext.c - 1.3 linux/drivers/usb/usbvideo.h - 1.6 linux/drivers/usb/usbvideo.c - 1.7 linux/drivers/sound/nec_vrc5477.c - 1.5 linux/drivers/sound/ite8172.c - 1.6 linux/drivers/net/ns83820.c - 1.8 linux/drivers/usb/hid-core.c - 1.7 linux/drivers/usb/hid-input.c - 1.3 linux/drivers/usb/hiddev.c - 1.5 linux/fs/jffs2/background.c - 1.7 linux/fs/jffs2/dir.c - 1.6 linux/drivers/mtd/devices/blkmtd.c - 1.5 linux/fs/namespace.c - 1.14 linux/fs/isofs/compress.c - 1.5 linux/fs/isofs/zisofs.h - 1.2 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.2 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.3 linux/fs/jbd/journal.c - 1.7 linux/fs/ext3/inode.c - 1.7 linux/fs/ext3/namei.c - 1.4 linux/drivers/hotplug/pci_hotplug_core.c - 1.4 linux/include/linux/bio.h - 1.7 linux/fs/driverfs/inode.c - 1.8 linux/fs/bio.c - 1.11 linux/drivers/usb/serial/kl5kusb105.h - 1.2 linux/fs/xfs/pagebuf/page_buf.c - 1.6 linux/drivers/block/cciss_scsi.c - 1.3 linux/include/linux/init_task.h - 1.6 linux/net/ipv4/tcp_diag.c - 1.2 linux/fs/ext2/ext2.h - 1.3 linux/arch/ppc/Config.help - 1.4 linux/drivers/usb/Config.help - 1.3 linux/drivers/sound/dmasound/Config.help - 1.2 linux/drivers/sound/Config.help - 1.2 linux/drivers/net/pcmcia/Config.help - 1.2 From owner-linux-xfs@oss.sgi.com Thu Feb 14 16:33:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F0XR503322 for linux-xfs-outgoing; Thu, 14 Feb 2002 16:33:27 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F0XJ903297 for ; Thu, 14 Feb 2002 16:33:19 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1ENXEtm002732 for ; Thu, 14 Feb 2002 15:33:14 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA08438; Thu, 14 Feb 2002 17:31:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA28146; Thu, 14 Feb 2002 17:31:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1ENUah00951; Thu, 14 Feb 2002 17:30:36 -0600 Subject: Re: Oopses in kfree From: Steve Lord To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com, oz@soton.ac.uk In-Reply-To: <3C6B9436.A6F50C8@soton.ac.uk> References: <3C5E8CFA.CACF28C3@soton.ac.uk> <1013126082.21881.65.camel@jen.americas.sgi.com> <3C6B9436.A6F50C8@soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 17:30:36 -0600 Message-Id: <1013729436.27090.12.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-14 at 04:40, Ian D. Hardy wrote: > Steve+ > > I enabled the 'CONFIG_DEBUG_SLAB' option in the kernel (taking a recent > CVS of the 2.4.17 XFS from 12th Feb) and have had the following Oops (which I > hope means more to you than to me!). > > > Feb 14 00:41:31 blue00 kernel: kfree: bad ptr f8f3d000h. > Feb 14 00:41:31 blue00 kernel: invalid operand: 0000 > Feb 14 00:41:32 blue00 kernel: CPU: 1 > Feb 14 00:41:32 blue00 kernel: EIP: 0010:[kmem_cache_free+54/128] Not > tainted > Feb 14 00:41:32 blue00 kernel: EFLAGS: 00010086 > Feb 14 00:41:32 blue00 kernel: eax: 0000001d ebx: 00e3cf40 ecx: 0000002e > edx: 00000000 > Feb 14 00:41:32 blue00 kernel: esi: d42520e4 edi: f8f3d000 ebp: 00000000 > esp: f7ee1e30 > Feb 14 00:41:32 blue00 kernel: ds: 0018 es: 0018 ss: 0018 > Feb 14 00:41:32 blue00 kernel: Process kswapd (pid: 5, stackpage=f7ee1000) > Feb 14 00:41:32 blue00 kernel: Stack: c02b3322 f8f3d000 d4252130 d42520e4 > 00000000 00000000 00000286 c74bfecc > Feb 14 00:41:32 blue00 kernel: c01f6f86 f8f3d000 c01cabfe f8f3d000 > 00014460 d42520e4 d42520e4 00000000 > Feb 14 00:41:32 blue00 kernel: c01cac6f d42520e4 00000000 d42520e4 > c01c78ae d42520e4 00000001 c01e649a > Feb 14 00:41:32 blue00 kernel: Call Trace: [change_termios+118/400] > [xlog_recover_do_efi_trans+158/192] [xlog_recover_do_efd_trans+79/256] > [xlog_regrant_write_log_space+94/784] [linvfs_follow_link+10/240] > Feb 14 00:41:32 blue00 kernel: Code: 0f 0b 83 c4 08 8b 15 8c 85 3f c0 8b 2c 1a > 89 7c 24 14 b8 00 > 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: 83 c4 08 add $0x8,%esp > Code; 00000004 Before first symbol > 5: 8b 15 8c 85 3f c0 mov 0xc03f858c,%edx > Code; 0000000a Before first symbol > b: 8b 2c 1a mov (%edx,%ebx,1),%ebp > Code; 0000000e Before first symbol > e: 89 7c 24 14 mov %edi,0x14(%esp,1) > Code; 00000012 Before first symbol > 12: b8 00 00 00 00 mov $0x0,%eax > > > Ian > Well, it has bits of interesting stack in there. Were you running on the filesystem at the time, or attempting to mount it? Also, do you have some very large complex directories, or very large files out there? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 14 16:42:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F0gLa03491 for linux-xfs-outgoing; Thu, 14 Feb 2002 16:42:21 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F0gI903469 for ; Thu, 14 Feb 2002 16:42:18 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04531 for ; Thu, 14 Feb 2002 15:43:36 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA08658 for ; Thu, 14 Feb 2002 17:41:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA33424 for ; Thu, 14 Feb 2002 17:41:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1ENdeZ01123; Thu, 14 Feb 2002 17:39:40 -0600 Message-Id: <200202142339.g1ENdeZ01123@jen.americas.sgi.com> Date: Thu, 14 Feb 2002 17:39:40 -0600 Subject: TAKE - fix some direct I/O corner cases Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Feb 14 15:40:24 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111857a linux/fs/xfs/linux/xfs_iops.c - 1.123 - Deal with a corner case where we do a mix of buffered and direct I/O to a file. If asking for extents for a direct write and finding delalloc extents there, convert them to real. linux/fs/xfs/pagebuf/page_buf_io.c - 1.8 - Fix the direct I/O path for writes from uninitialized malloced memory, basically do not lock the pages around the I/O. We don't need to anyway, so this is also a direct I/O speed up. From owner-linux-xfs@oss.sgi.com Thu Feb 14 17:43:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F1hP904139 for linux-xfs-outgoing; Thu, 14 Feb 2002 17:43:25 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F1hD904117 for ; Thu, 14 Feb 2002 17:43:13 -0800 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g1F0hBH06324; Fri, 15 Feb 2002 00:43:11 GMT From: "Ian D. Hardy" Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id AAA1851874; Fri, 15 Feb 2002 00:43:11 GMT Message-Id: <200202150043.AAA1851874@plum.sucs.soton.ac.uk> Subject: Re: Oopses in kfree To: lord@sgi.com (Steve Lord) Date: Fri, 15 Feb 2002 00:43:10 +0000 (GMT) Cc: i.d.hardy@soton.ac.uk (Ian D. Hardy), linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk In-Reply-To: <1013729436.27090.12.camel@jen.americas.sgi.com> from "Steve Lord" at Feb 14, 2002 05:30:36 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, > > On Thu, 2002-02-14 at 04:40, Ian D. Hardy wrote: > > Steve+ > > > > I enabled the 'CONFIG_DEBUG_SLAB' option in the kernel (taking a recent > > CVS of the 2.4.17 XFS from 12th Feb) and have had the following Oops (which I > > hope means more to you than to me!). > > > > > > Feb 14 00:41:31 blue00 kernel: kfree: bad ptr f8f3d000h. > > Feb 14 00:41:31 blue00 kernel: invalid operand: 0000 > > Feb 14 00:41:32 blue00 kernel: CPU: 1 > > Feb 14 00:41:32 blue00 kernel: EIP: 0010:[kmem_cache_free+54/128] Not > > tainted > > Feb 14 00:41:32 blue00 kernel: EFLAGS: 00010086 > > Feb 14 00:41:32 blue00 kernel: eax: 0000001d ebx: 00e3cf40 ecx: 0000002e > > edx: 00000000 > > Feb 14 00:41:32 blue00 kernel: esi: d42520e4 edi: f8f3d000 ebp: 00000000 > > esp: f7ee1e30 > > Feb 14 00:41:32 blue00 kernel: ds: 0018 es: 0018 ss: 0018 > > Feb 14 00:41:32 blue00 kernel: Process kswapd (pid: 5, stackpage=f7ee1000) > > Feb 14 00:41:32 blue00 kernel: Stack: c02b3322 f8f3d000 d4252130 d42520e4 > > 00000000 00000000 00000286 c74bfecc > > Feb 14 00:41:32 blue00 kernel: c01f6f86 f8f3d000 c01cabfe f8f3d000 > > 00014460 d42520e4 d42520e4 00000000 > > Feb 14 00:41:32 blue00 kernel: c01cac6f d42520e4 00000000 d42520e4 > > c01c78ae d42520e4 00000001 c01e649a > > Feb 14 00:41:32 blue00 kernel: Call Trace: [change_termios+118/400] > > [xlog_recover_do_efi_trans+158/192] [xlog_recover_do_efd_trans+79/256] > > [xlog_regrant_write_log_space+94/784] [linvfs_follow_link+10/240] > > Feb 14 00:41:32 blue00 kernel: Code: 0f 0b 83 c4 08 8b 15 8c 85 3f c0 8b 2c 1a > > 89 7c 24 14 b8 00 > > 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: 83 c4 08 add $0x8,%esp > > Code; 00000004 Before first symbol > > 5: 8b 15 8c 85 3f c0 mov 0xc03f858c,%edx > > Code; 0000000a Before first symbol > > b: 8b 2c 1a mov (%edx,%ebx,1),%ebp > > Code; 0000000e Before first symbol > > e: 89 7c 24 14 mov %edi,0x14(%esp,1) > > Code; 00000012 Before first symbol > > 12: b8 00 00 00 00 mov $0x0,%eax > > > > > > Ian > > > > Well, it has bits of interesting stack in there. Were you running on > the filesystem at the time, or attempting to mount it? > > Also, do you have some very large complex directories, or very large > files out there? > > Steve > At the time of the above crash the system had been running for ~14hours with all file systems mounted. There is a single XFS filesystem (/scratch), a number of 'efs2' filesystems (/, /boot, /usr, /var) and a 'reiserfs' system (/usr/local). The XFS filesystem is ~560Gbytes in size and is ~90% full, there's a small number of ~2Gbyte files on the file system. The majority of the IO activity is NFS access to/from the XFS filesystem (/scratch), there was also a Legato Networker backup session doing a full backup of /scratch at the time of the crash (the last few crashes have been during full backups, though this is not always the case - I'm inclined to think that it is simply likely to fail during a backup due to the increased filesystem activity). There's nothing that I can see strange in the directory structure. (/scratch is implemented on a GForce RI hardware RAID (5) unit that is connected to the server via a QLogic QLA2200 FC HBA). Ian -- //////////////////////////////////////////////////////////////////////////// Ian Hardy Research Services Computing Services email: idh@soton.ac.uk Southampton University i.d.hardy@soton.ac.uk Southampton S017 1BJ, UK. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From owner-linux-xfs@oss.sgi.com Thu Feb 14 18:52:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F2qJW05196 for linux-xfs-outgoing; Thu, 14 Feb 2002 18:52:19 -0800 Received: from net.rongage.org (root@lns-saginaw.net [63.83.235.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F2qF905174 for ; Thu, 14 Feb 2002 18:52:15 -0800 Received: from [192.168.10.23] (home.rongage.org [64.113.37.136]) by net.rongage.org (8.10.2/8.10.2) with ESMTP id g1F1qAN28991 for ; Thu, 14 Feb 2002 20:52:11 -0500 Subject: [patch] XFS and EVMS, kernel 2.4.16 combo patch From: Ron Gage To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 14 Feb 2002 20:46:58 -0500 Message-Id: <1013737622.309.4.camel@portable> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The following patch is a merge of the most recent EVMS from IBM and the most recent XFS release against kernel 2.4.16 It appears to work here (Toshiba laptop) but it did require a rebuild of the PCMCIA utils after installing... This is a combination of the XFS kernel patch, the EVMS 2.4 generic patch, and the EVMS 2.4.16 specific patch. Ron Gage - Saginaw, Michigan From owner-linux-xfs@oss.sgi.com Thu Feb 14 18:54:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F2skA05334 for linux-xfs-outgoing; Thu, 14 Feb 2002 18:54:46 -0800 Received: from net.rongage.org (root@lns-saginaw.net [63.83.235.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F2rP905305 for ; Thu, 14 Feb 2002 18:53:25 -0800 Received: from [192.168.10.23] (home.rongage.org [64.113.37.136]) by net.rongage.org (8.10.2/8.10.2) with ESMTP id g1F1r7N29012 for ; Thu, 14 Feb 2002 20:53:08 -0500 Subject: [patch] XFS and EVMS, kernel 2.4.16 combo patch From: Ron Gage To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-OMu1yQh6lhKl1fPJ4UQ5" X-Mailer: Evolution/1.0 (Preview Release) Date: 14 Feb 2002 20:47:55 -0500 Message-Id: <1013737679.309.7.camel@portable> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-OMu1yQh6lhKl1fPJ4UQ5 Content-Type: text/plain Content-Transfer-Encoding: 7bit This time, I'll include the attachment! :) The following patch is a merge of the most recent EVMS from IBM and the most recent XFS release against kernel 2.4.16 It appears to work here (Toshiba laptop) but it did require a rebuild of the PCMCIA utils after installing... This is a combination of the XFS kernel patch, the EVMS 2.4 generic patch, and the EVMS 2.4.16 specific patch. Ron Gage - Saginaw, Michigan --=-OMu1yQh6lhKl1fPJ4UQ5 Content-Type: application/x-gzip Content-Disposition: attachment; filename=linux-2.4.16_xfs_evms.gz Content-Transfer-Encoding: base64 H4sICM9kbDwAA2xpbnV4LTIuNC4xNl94ZnNfZXZtcy5kaWZmAOxbW1Mjx5J+ Rr+iAvscQyA1krgNhGdiBIixdiTQQQwePxEtdUlq0+qS+wKDY2N/+36ZWdXd AoHHftuIJWwYdVdlZeX1y6xSEE6nqpGoRq52ozDOv+2em0m+0HHmZ6GJd8/m fjzTqdrN02Q3TSZvDao1Go03qWzc5FqN9FK13qlm+6TVPNnfV+1ms1Xb2dn5 riU2bua5utBj1aKJJ63Dk/YxUWjXPn5UjYP9+qHawe8j9fFjTRml8iyMGkxP VX/aXqtp1MufH9Q0mJpk4Weq0XjQSYqlmc7CBEQqfTa+7e177bV0wjjFHNW4 5em6PU2XiZk9m9/yWsdrZmN6lsc0p7aDyd/WzsXkttdcOxkT7oKxWzvRYaqT FzT2vG9e8/d1092Eyb1qf/h3679nCTS2QoXpLieLSeg3Js/42vPAWGsd3Ymf BItZ4vgaDofr9k4iXb+t5XIZVNRCCm8dHZPGW++a9XabdW7fpspM1eLecV0H /2n4p74rHwR6nM/cR+XHQa2ycU/dzHWqlej80ST3ysRqbLK5CvfeHdJw5UfL ua+WkZ+RxaReTdV2vjoB7TTsT22ntgNaCsN0mjn2iLtCrRMDI4e9gN9p6n0j 5kSDdV4nm+vaDj2AGvwwYZ7CLNQY5i9MPFPgClTrCmzQYPX1YqSmYaTTpzTT C0+pXqZCsOQnk3mY6UmWJxr2Geilxq84k93ETwVz08QsrHmZ+BFaU+nc5FFQ 22FJTEySgEr0pB5DCCSbh2l1X46Fe53EOsLoQHskhf+XzauyUUPnSzXVKKSj 2MT32ntk4nv7zXrrkE38etUVG9Uf9qyfp9nyZHcXv73YX9BevYlZ7C7z8e6K G69+akhE8DI/8WZ/fnhNZSV9k6ZeOguFdmJ+x77TXShjNzCPcWT8YHeyCO5A jp/KGiw5D0G+XOafEgzyxRL0mt7eKr3/m2yrmurfDlRmTJTqbEWrtasY9hTG bybIE2UzpJfo3//ejP+pBX8FAkw8DWdwDW+uo+VfJOqVsW9AgpVxnNcvzYNC GG/tnRy0/wYyeEnIAoTW8UmzddJslgChdWgTBv1t4Q35k0JmiiIdwKHbh57x 1G8mV4scEcmPUqPm/oNWvpqHs3kj0g9w2yAJ4dNFTMmelpqowL8D/RBO8GQO APEEKo8+QkhmVJovlybJOEd0bwcj9VkCwHUeZ+FCq63u12H3ujfoXt50+tu1 nbOry4vepzsaWttRiqckdqysjtB1Q8EFRjcOYwA0uwRztfSTLCThhPGsTnZV JyqDc8sfpztAGg514M5XKQZG/AnhwJ9QUFKK/r/Wf+QhcqfKESga6dKn3ZGN 0q6WGIzUp/xgEcZhmiWsEOaAOY7MLIRoic6DiaCy1FPDSPtIrA9hGmZqnrED PT4+eqnJk4nG1Jn2Yp2VjqQfFuku0yQ6zHSgkRPAAsXUMaUHcE+aSC1vBfcc 3NUSDhqOI3pJ4loi/At/ksUjUlyYYVyUzyjV+CnDPSQJJvSLeYTWkzqtQGEd E/CvWMUaJgOSY1hHEMi/ofNESW75KYU4scfEXxCVIEzvySNNEljTYRYwh0aF fgR0orBpyBSuC/MZGwPTgcI5efLgvoE01bnY2MCP/RlIDZnrFZO561+ddfp3 593bu8Gn67th/8un3iUxMarYSMTEeuddFsPobNRz1uGJZYk4SICJGEGgwqly JunMDa9THUFTOmBGLavnVyM1dFb4Jq8YeTfsXN/0bnpXl6/wipRqZnH4J+mZ FFbYN9mlVb4iJTWWZplHfkLrE5GqI6h0Mtfka4PT61T9W3XxZ9tTx8f/cpmZ 3YvdlpRM+iUaWUUYUFdgCA/gISjCKaZ5JKmeNlOqahT7y9EcGrzQPmOKdVsf XXaGo1+ubiq7ZslP7Ry7aKRhnMTWJMELikUpqKdEHYwTOBHF0fw8JvNiFgg6 JSayEqJhDIZcjJKR5Xia7abAA1gePrwxK+Jcsao4szWTaR5PSMI0P4wnUR5Q MLJDM1qa8pr1f44apfJgebsgznzR/OpIPGc+CT35pWDPKfr1w/j+TcmeX/du u/3e5efvFq2EUYT9KAuXCBCBnwZqDCe5Z++1cXM1XD6ESZbDiXiYHcOVg6Ja w1oVR781A8lz/CU8/luIclPD6eFlGIMFWNj5AgRoMhk8hScKXSZG2oODIrBN ciDNmJCmdUWXC9gwl5mhue2D5k7B/FYp+TrHI/zhQMBR2gp+uxT1qR+oU+b4 WlO0YFfeOj293nayXxU63lTEjU+0RVhDOIslOiZ64S9Vb/dKPSYA22qKKJ4n YhV+LNaZ+lMWWbEg/iNePaCDzGbWhUFu5oDKuTCVFE0LjvMwysQSRY6LukIK T800A1aXMezchgASRW7Y7gPEH6hHiumQNc2eA9cX41FaREh7BDgQ6iaZSeyC Y40ZCAFBJUJzp4HMeG1Yvh2s2KPmkdU4m0LDkqs4jSfmIQxIn6R7iGNM1U1R WmhZzjrOatR2ERPCYU1zkK94HsuRdsgczJ/SZ4labQ1v020psvw01QvwJEGB bXaZhBSJZLCaJSZfYsrtJwqooCgKrJoV3vZBkJfU38hcNRGWSOWG8L4QUCOw D9TMRlLJNVStxZRreQ/1FcQD8BEuiST4LYIPPjvSVOMV8SkQJ+VajSTOImZO uvGMooAVYokBx4SN0kxgYsixThJ5FQUhwj5DQogAJF/IhRmDBEpT6fS+vmoo ePfMUNzof24sRMlS+YemQrMlbHBY+n7L8Hjqc4PwE+bpb1lDaQpVS6jikaox lMovNC8WXR28CJPEJCQ3sRHJiAEBfbMkp2eVKS4KpNSX4OHgn6AfQQlmyWoH TKKcQjIDaOeAjKe+Gg7PGMP6kzlZGXHiCgR/ggidFmou4DLpvgK9rcrAt1Mn RzMKZA8Ipv6YQTxrY5pThC7t7Wq0237V4K5G7e+AXq7YUc1vewcvTIS6OEnR f2MXmcqq2ABxRUmsb43gVuzDAkN49pDNF8pCBvOTJ0EjVTsmaRX4glEAhb97 wTbB2mTF5oWMzh/ekKVw+d2SPKfOoeqThaxKsXd5cXV3dg0kC/jNgtQZU5Cy kVayjR/oNvWprc7tJIaOqguzsCONLBwhkjCKTVCOUAa30ywiI5nzcFfH8Cc4 1thAOGFGO86R4yPhVKnNM/gQiX9TTDiiDhstxAl1Yl+WzG1Jiy2XQVP9qNNs m70NyRJOmdr1N7vQukDizQqzUl9KOz3kLYFjljLGjCFh1jLBdhK7YGlYQl9o nuupDzC2yThJzYyB22ZkclD40iC/e+VI6GOT43sqAysOiEzNM7BipBdpidVL 92NGxz5SILPLlhtji372E9Gz7hvkifMBBMGJoS0TWfJbGyKELOWLApL5XMc1 uLKwuoff+AudSfJIrYXQwiJNrjlvDDsNBxWMnRsErnSpJ+H0SW1SRXxHE+54 wvuDzZV6kUEdYqML+hHFmk0EZ40Nv183fbMoXaMwMh6qgCk3SdWWYB/a9wGr nYTHAwnWcUVY8I3MP9Lauajt1HDxTr+8uSsjiE4M30/Y1gI95frXduxXRcFy fSVkEJ4YbDtB15T1w9P+Z657CYQoi/ltu+YF1k/J9ECY0J7Dw8W/pV3UOjo4 4n5R691Bq956Z/tFP1caF7zRwEw8k8x28RdbzRbRD3PzmJkPHsU1NnXe2h+5 yXwiUKme2RNtIcn5iCoQjlO2kUBwf4q0lCIIwQr8J3XJfaTh1QjxvyOJ48xW bn2EjEIoLjhdoMKmwXedMw5L+JNavEDV5EJP5j5Qy4LXhz6w9CzxQ0LtNi+5 whAuHDslAuRI/oUIv1wKNkCFyk/gGs9mFouwfXdiYkJcm6Ic6Z62XJSEFlLa Hn+YOHJJOJtnqY1BIQImkUhTMwkFxJOB+mK8oBKECQP2J89umiKCJGlfHK0C I1zlRYwRqqfPCx0wnJHVAR5KkkjjT1wHMBiiygBAkicLY2zZFhkFEstcq4dH iawJO0lZHwhAlShZZfyCB3HFwbbC1aEUoM9kDLI2Er00GDjSQC+I7xtoIjaI /U+ulbQ1uDl/6Up4SKb62iwR5jTy03ldXXcGAqzCRUjtFwCcJVWX00zbg7r9 gxafY7T2D1vH9aO29aQRuPtNUTZxQdshogyLEubjoGvUl4tRBXFYBAvEphhB IppwQzjicu+phGpjH4ggX0rQWqWBpAMdaFhlIP5EmfU0n07J86x/Fi407Hzq 3p1+ueCs/irPErNfnDKJTgh+LLHGOJ/a/qLzQbJzZG0qG4Akx8LCBHCAMnNg 8YBZWkhVFH5MTcbBTM7or21ZpGxd1g8kC6ZzsWjrvGEMwiWOoIECjSdgBdl4 riOKg0nGxwjgwX8i92IMTjzZIiize3rOBXKWH/iZv4YdkUmFK6ZjbOgvuaJ1 8pic2jVWCgneVURYlCBExopuyw26y7aVGXMfmVO4XnBAAdyezRI987mggK9O hGuaxnSIg97uVelMVSW7FjKxuM5mfApqlrst9V6QLLYlYcHKF9Wk5qoH0iWe EnjZAz4yHiTKrnAQ0GAxV8xgyTGzLc49EFMUKj6L82eS9MnqMYlraWffsg9W lpZJB3zlFETapmymnmEJjD71Cot26nueYvAeaYbm0kiO63Rg4opjP0aY+R0+ iLhLuyqdw4oFFRjAuAuDFv/Swr1rZBZ3yO7Oa1kHyOfUNeN82cjmtHeq7yDg aj0YUQ/TBloSUeWzZNc64kdGh71IdhkKx3GeaUkwDz5qWaoDpG1HPT2Mxuo8 ISPI6ArKhX+v7fOUKhMKBNK9O80STVDaRXQ+mxYCdCyNl4rLkW02yzCQSwYV sblaO4V6fKmFrF1e66mASE4xVWUTHnQY5dXTyQ/O0p0w3bmKO1oK6XFJk7FK g9turjKLdIEKiQfWVeW0G6bwVy5ELdlqVFj1nYrjsBv9I99ZcRzm91Xf+U7H kYMofvrMeehygmeYHt1KcN0Kg3mnWIZ7inM5T5LwCUWFEtKrYjBTSVgJYfoi YznDDyPplvglH/XVYwuXiyAvBzlQc7DqtuhBErC5UckgZW3Mdk6uez7oDHsr bm2fSMg4p6AuEJwbongl3m45L04QCwhVWJHLF+UQgUiBq7O/7l6hRiks+YQm oGgdiZ9WVj0RNkZwJ4q/FXa2vp6PUBWAq0124YBR4YUeJzlh0tbx8VFh3QUb YSrMjoHnQlQEdBXEdkNTu8SiXMKB8teBVlWc/2HEXxXnf75c3XQqPpEWaKKi RGpD2BNLqhCXdFJDFUEEfJVJOuUihfpV3BHY4rLTGiErmmuNdNv2s8gVJTZP qGkYENSWaoTBQFmk+2k1OBd5nCwaHKTVIE69TwEwAoEp4HOdRVX5DAKHn2k+ BuE1QTCePNnU4yIJ88Ar2mhEV+/IoHg7RZh5M8bUqflhHsES0yhDuz2dXYSo ZsgOxjp7pJ69oCfaElMj2ibPxHNsa42aueDaLvRcq9faj7ikH+Vjd/ZWUfH1 zVr9rlUvgxwn3mfAMS3LHHsPClJO3NppPi4P4vSa5yxHtmJNPYeMoaDP1xRI 9NIF406OFBYcgVjbdKgLy7eNciKxnnr1cMfVk9wXCai/Ia3wcGIdEazTPS9Q CDPfda25wKKGrfYX3MpbLqNQundS/XeCB8qClY607bjyzcwCnbvz4875befy rHv+Sm3BNUEU3msXIcva3zqK2IakHC5c3h2h8uc7hsftvfr+kS1cUuqm+Or0 utv57MrUmE0JWjqw5SAFRhgxo857/bRMqFfEIgUFPJAaygU8iYTrUhDMIfnD JqBzE/+UiVURlTyOqASk3ZGOoMb72Dxy90rS65wqoMBoiVj23gm3zGZ8KP4M yH0+Py0OS207u6xS5HytAS5tauVLlDN7G0UXr4nCsxHlTT4rkNRaNvsu7ICr THFY/Y2MAdhKghOsI5/YRjO/h74c7JcTnzG2fs9NQTcEUZNKZ4qTAmrkkADh aFWy98GY/vcWC6dEivV0DsvFgMK7u3FW57/UANDZhPsGn4MxwxF3OsQJ5AGm zNU5ylGiIGdW1ARGBcovJKrK2ay9V2QHU4g0hHpe8igjGnYEmcG25/Kx7fs0 OmROoPVHrglqWwBdYUQCz8S3Jeo6DVnhU150rZQwXiIwFsCqSo9uzBJUzzMa 4k6tVzbDm2df5cZpaVHEC0fZPDOUdyZsuJTpnBV2+v3Rb9QVX5tgYaQOgFUN 925wdf6l3+UyhIZYvFjg+/ETN3vADKMr8xg7KnWucl3ThYUDw3DIb9UdJPxI Y+fRfxIQJ7ePHCh0V0IVI0ML2eqcWxnwZ76cObrxW/YQCdAFFsteVJxgVzTl hv227VWQhwDZQi5mOqWN2pbTiniuLrh/cUlZliMFjJhyRHEGXs5jZiO6QYu/ JQm57pN5azB9Og+XMGeHucl6iL6rw1BWSZZhs8cbhoPAEnzvTk7fM3tAwxeO dAoZh5nE1ZeHbJDAr3jjzokYE/Oiq/utyyZnsaF7BnRIAnRCYaISNwkGF3UM hr8nZCFltp7MjdpsbaoPioqnCUXiXdkih41Vy6BgwIRMck8AE/sgAAHTRf6x wo6d8AupC+xjWyW4T1xYA3xPugQnwkXzNS74VpJ29BTz1ZvKWeZzz+kbX86K 0qfFmK7xMZR02aC0Fut/K+bC6iuOax0BymDlkRkjGus1FwKlCuq8T+qasslU mKhDKpn6nU7b+SKXW8LEOnVbeQal2Crg2IlfIJbiEh7RsGYo9xzFxYu7XDyB us5iEDQ8Bh6FV1KVb7dlaxJLh5AKk3HVuA0trm6QS1hFLqSzYkaTxddGPrxX bW/Pa7Us8CiYcdZMZyebSD3qHjyBiXSz6IMxvwKN6+QR2GiqWs1Gu/mvSu+s cuWouns+RzTUGikVs+44QfVG55cvesD08HsvE69cw+VbyH91rbiCdHebzUbv 8rz79e27vutmvH7FeN3ojV8hif/KY9VuqtY+fQWpffSdF43XkqteN353sn98 sndUXjfe36/vqR38PmDUuNGQwy0TV64t3l50bqolF5sUpP1rGAfmMVWXN6xH 9/H4oKYeptyNYIJXiDAPoX50qr+1V83o1EBJ6czfkOAJO44DfxHYykPsL33t CxLfpfyqZE6UW+z7zIYywUs7GXR6lzf4v3s9ej6/8qqq+crjjYsk5LvkrUO6 S97cO2m/fpe8Ou9NXbaO2nIUSH8xghTaP9lgKo1v7YOPD+T74nl0FlhTo5ON ARBvxidp/O0gyPaiB4Dy2+imO6jtDE82RiHKHdjDp8RfAg6nqhejXhqcbACc 6KQBWX6sNPD4TWSS4GPxoGTh+dBfTzb+ogVY2wGL9rIHNV5r6uu7Q7XX6Hdv u3017HzqXX5SW8NOd1uNvgyHV6hrFXjuxTOjBiaK/aSmwBAVbuYjMCOAEC+9 Rp/+veby8rn07fMVTdpnGwPIhb8ScKia707axyet1z21mPT29f/6ERRovx14 C5WjZFSIzNhW5+bsF9n3e7UP3X05dZ9ah7VG9+vNdaeYUNtZ/UyypxD6uXt9 2e1fd/vdzqj7/sctO2Db+3GrpE+fHPXtH7eqlLbtV37a78jQ8LstX1DojDY2 3qsft86ur0aju7OrwRBGtO1jzf75ujeAnursbN2b2QTW9cN7+lGXVzddxf/E I6X0bJI22t5xyzs8pHTKjVRNxZqAZ4uykvKbUBaqMpKVVi/IDIyc5rpYYi9S 8dFuoou459u+5uR/23v39jSOZHH4b/wpOk5igwQSV10jn8UStjnWbUF24o3z zDPAIM0KGMIMsrSJz2d/69Ld03MFxXn3l2zWTyJgurqmL9XVVdXVVeStbaAk JIb3VVng3TC6x0B+acZ5gj2zJw++y/fzuNgNpG4BSK4dWEHsL618lIEvGrev ir43dSIXBmF4pBHVC0qiQmigKo0ByyZjT5qa2K0C9l5ojrrxgdVVVwKtFh4A mszZEJX3kZGnV16AaGPjNQCzbT1n9Abesbt1DzIt1syZI8ISmR9DKiiatX17 imdokTZAz0FgJRwodaHGSKdkePjt8wkJSbvoP+P6N8qUgmjLkeFy/ey+UyPo HVfGATlPAIjhurc1UYSH2LSdyl6txAo3OrPYC58UaXOmyfkHzwzKNICu4Y+G Q4hIhGGCF3hURFOMNpOZ+HkJgqnyNUOR1BhbkJGOLy9lT45hiDqwLnup6xK4 4vlZWslsyjf6YP8AsQAdSvhC31n7bYf2BapzdXF50u2VtskPx4V95HXn/C0K 41C67Q/c2Tb09xZFxCfipHMJOm9Bl4ycOUh5oAhK+V0XKKkSXnZx8uq0/RqL KiesMEPX6JHFDKxwBPyw0ztFtHgd5clm+/u3+MP+dPtk8+rs8rIHzf0BwZ5I Yb2geKHBRzULjTDLCI+EETx+Iz6CICPlzf6bzump4BEQbwDZG/Hmon91fMwf 1EoRGVRgjsAFgd0BmkoBpghwwvCL/lWveykuXv7v8cXlB/w8eXd2SSMdDrce WT0o1G8Qk34XPAKGDYcIhv6gMPIqblBB/3Lm8Xu75X3Yi6pNpAUkgq8RFN7L 9Q9wdiw5IZYlKt1vijQeeDlMAW0iucztwF8OgOl+W650vy3HaM7qnh+XSoRa IwYQiQHI+HtUgSrf47oeBhWQDgIPXTx9eDbzKvD0GiUT+HlRpxEWojL2ptCV MXqxVcjoBiupMgZoicSeuDaxeXqIKwhdManmKiB3DGttrLSPV732Wce6vAAJ rdODfutepzXhySasU2Bboh0ZwXa/3zl7efoBxtDoNw7I1ywS1JvsltIqg3JG Ql33Je634UKcuAP8f8smsQAeYbEynpFvmS+mUzEG5d4JhDsfwt4wQHnPHTs/ iyK8VpskSuUHut3X61i84KEzygQJvEyj58eqSyCY0YWWXr8yg36Fvx4iv6b4 i23W1Kd6rSpFHQWhm3J2UsJxlK3fno7gP9h0oQ1J2Jen7zr/iIAPJksn8Lzg JvyWWvPNxRU6FVuXx91I/RsvQOfb7bspi67e4J/Y+0R99KeMVNTuhKPF3QJf qV/KdK3HRUlStf06inx1dDmikTgGvnPOYw+iHXIeZUdB7rg18YOYB6PcUrdu CFi2WCpWW3idBRfFVjCdb8C3zQJQjeKPJfVUFFT7hzf2YlsaR6GuBbQeDCZb Q91BtLN7KKNPAcrisjQE6G+A3jPJwtFiur1RgU2AapI02agSNbR25RgU/OHC nYMKMLkfufbEu97e2PJE4qH6Qu/Ygl1wyRvSlnqmBsr2p9R3JGTYmipoKx9O R75s+9YN36bXb5jewgP9y59PXDwzIFz66cgboqWLEIQrMTo10Em1u8vpkdoX espy15t1VNU267vVcp1VtidqfgWe825/U8QtqBQqIuJJRW5pms1KvsN8BQWG C+lBKIbjiX3NuvMtiVoYvaLMp2FkZ8RQAi5MKmrk7IOCjlAzNLK7eP3ha8Of kNulvWPY6u4tAzytNeS3LfIO1jf1ZsYrEB97cqE8Jvf0sefB7NJWwW206lbT moGYDu8alsrsj6GxpbUMsdEmbh0bG08aNr6io8eixQbsr0MHSF+KzAPX8ObP 6KlA15nQOqocohGfds1xjbc1EbfDNnF1A3vBLiToOTFxyGaHPn/YNGjq2za7 eKX0hEKO4BaiH3xT9G8c2Cul+DdfwK5T8R2kogoMlS9+FWi5qYBW8NzflreF DsTH4tbGx9J2pSs+1hT5Xs+fwy7AZCZSXo5tyiDCiKCmtrq2+dAQys47V99f 9N72NZPErU286bRPQGTiqnhHkr+hNPPy4uIKBComdMCz1d8CEb5SoJ2zBF1v K7HBdP6teOKbjS1ffPMdMcAYqPomm5ddF9/mybcdZ79sKOt4+n3Hj3hdpDb0 8D0zkAMxWk6nD8BC/raYgniRtQkwVwFOWkOOut8qN9mRFS33B0LuDojlmyKO Z0nO19FTaKZuYGQOS09F5TjKi+g8AsSH0xPr/RlM0LsfCrS7nZ5gbT1j+APn skQ+PttT251t8W3ybeW24BFfLhQqFbo6USGvavkMd1klhpT0M0kp4QNFQ+ET JKKSRgyMndEmxR2pg7DME3ZGF3CvovulpRSVBkoEzgQt5elVDeFIjvtBbNbU KNwI1aZ3vTZ6CeSOGNUFiRrXNBHjbxv2SnLUK8lBr8TGvBIf8oo54pXIgMsH nia7zceRnVYJgdtsXb65OP9wUDCfqe8HK2a28Dc6n1LgYm77vqjR0gxnrkTr Lj7ZsuU1brpGmw0oXmRTTA0pJrUxdcZvtiYPS15T6+s2tZ7X1HpmUxuPaGo9 v6mNdZvayGsqr0NeaYV4w1JWZmKiNXWCbsdUFJaVkXymd2nwIVVLtQ4XxllJ PYbdlsKSVe7E849FdQL8sfTx14/Fj1veN9/wV/Gj/e7TT0I9/7g1u1ZFp+3+ mx97pz+ddD+WnuPmjZvxC0Oyx+HjzSBr4Dayh20DNxf4AnC3sIJEIbqtgMic cT5yIJQougWMhW9tpRjUacOgCGTbIFuxYB63iafBmIb2tHJtdK/t4xlIbf8A drgso3sqgtxDlF3YMhtiEz9qvHMqhbR99aZz9u4ItuCv1bOTzktQHvun7Zd8 cI7X743rKe3X3WOr/6Hf+zvUAn71NQqGaN61RyO6gPp16gUoBI5d6jAesR87 PtDNYI8+swkJ71iAz50iSS9bE1CKkidimYAZkxUFikdOwjPNdWYsBUt02vbC adMHEjUVMcmy/MCbW5aFenNgD0CZ3jrEgq1bP1jggwPxi9goqp8l8fkJheTB irApYk3F+LCqDPK3vSHaIGNL+V+dxW9sc01dg3GHDxD7ptkoEzVKCIS5jy+G fZM0AsCJrQWI9mn39Xlxr7ZfLx1y13AztwYO3g4mBFlzC6r2isVnQiRn0ywt 9EFhObPRRxkDWzYbB9XWimmMVM+dv1Z1H5cdfshlF1tkeHN59SKL1jk9/SOv OxgcZV6C717u0kuHTZ2vFLhCfzkT7eW1gKFFjwJYg/urZy4NUe4c7tD1Ofgr 1yBI37QEeP2V8EHGokRJPWPZFbIXnMKvlpjCkr7AEHjr2gtKUA1wvp54AxsD a43pgjOq6gCxjZsiYHEC5z7g9yNwZzaiE0N86LNnLwGvN7V3j5jauzWn9u73 mtq79aaW2Cv8lYszcyYLxEQLUU7II/7WdOakEz8adJ7J/39nH1qFFJDkpfiQ nJeglVmzOVy4/gouGgVJzF20WDt/CBBgdg5aewfVFQJMrH4+I601iJHCh2ak cuTRzxpd6PAgR/Owy94F6noRJvYH5ZgY1zbTTyMJkZiGSCmNYnu+oIXTOoAN rVHLn4Vk9cxJ2CdOCH/lgU2oUqPFLsSmLPvSJccomU7hP7QBmeo4n/zwQYIy OIdV9CGQUPp4LhQf/xhnWeRXH74gG4U8DrKN8yCuIn+URATWMINE3ocCtQUS 9SlZPPTJFZpujXGwg5uKM12GxyipxfQF2kMnKlW+xl3dU8P/JDKwoSVN2SJM g4pqxpFZBZdEcqwivVRYN9fFaoyMeBLaNnEcuX6G0S3DaU0jfox6Rg2RZyY5 KEOQ9DWli0PdjHYjZG17ayyqsH6ub1R9r8FCfqO8J+eVY3Iax37e8FaGW8XW AonHIOh8LgTYTKCYjiL10S/6R/H0Gznv552rpxih5OGp+OmQXHzZi7JKjndN lF53pP6BFteJeC5gOq7dIWrtvZ/xCsTzFMk1At+fuzMZhU/ulM9j+uZl9/z0 4vhtpNZ7ZzHwfEcAQLGEEeE8DkRTJF/c3erbUgwL/A/r6eVFv0O3GBWel+r+ TOQeTnh5/HlkCQj0hJpbAWxQAbq3PMcmGXcfTGh190F8E8MQHWJ4Gh/iTVa9 VBP5DdFbBM9jXvWqjnL1gWr5juWRKKJYAoieKyx8DdSiBsQsjILuYgi2A0fb mf/C53FMVH3sRmbj2LjJb95bIL8CIf0KwlGOuiMgMjxqmY3waDSXB+SLN1GQ dB6QYp9hHgDLuLEGD1hTvNmr76B4gx9ypeWLN0zr8jDqjyTjbJr3XgyEkn6P wvBnkUmF56s3gHSP5YTYga4R/tS7dbaG2fOShE2f/yRchBDqSAjNdQghBVEu RXDseek48LU6Ov+O0ZKj0NbNi2SJlLnSijAK7whLNhOVRoNYDdsnh2UMcuMt oEzEC6f+gqpI0WRXiSbcXoBA+yvej77z3JEYeZaMvWdBI4a3Rb5ZKOaBtXCu QfER+FHme08OhgW00FYEkuEvIM9Eqlp3dDZe5AoGLOpDRXxbCbpTRHrrddr9 i3Pr/KxrApbpXagloU4ntjfWoSngtYuHrYRLfBZcLi1JmFBfqlNCFaSA9elI IcmlIemOhB8yglbhn+g7u7CHeGvAcu5dvMvwz+m8sHACC70BLHw+ZG85oJOx ChVgulI92eycX/U+FMndBEBRR50v/ZuJ+Naxo+legGP5FD9pATy40/4BIPvt 9x0L9gajkj9PVIrQhwb9JpGf5GtjZkOw3SSYQRDUegDGtoNc8uHs5cWpdQ7c CHuEnQHOCQXf1OrlaNu+lhEvQIClRvU6/StUY6g3X2t1AEhKAEn3HLxlJ510 FzJ4D3NPWwVSuadwEnQXysVrfx7G+MTKeGvvkyPv+Bl+unM7uJFBfeS1FerF Qr2LecceOR419usqOYsamEhvYVXaE/d6hpIEL64SU4M5pqvJgGL+UOus6dA2 iWF4b/wY3UfIBM+fvDsc5uZuoyxhFyPgKzgBM5qA6v2Y/zllrELmlhPXJ/+T ie0HYrCwZ8Mb8hZekAMPWVA+LRjL3JsDFvky9WNk/jAamBiasFvYpdioGLMd H4RS9mhHgWIoyR5Vr5NBqlUtN9g5tbBFPNFEhCt05uJCpcWHg9JzgMLupITX d4bLBTpTo9kvo/61EwTAKTPLMSaLfQN/CH293uKRXdmYPxoMtb5R/VO3/k89 9s0/9dg3/1Rjj1G0hgE0ndreyh15ezhBJpCDDAB8BCBjMijegTjvqTb4leJW RUkKFhm8S9tNtJ+vbv0a0pa7V2/tryG9S7hcaUvCxBLgVRsH1UdIWxpJnrTV bO2gyzN+SANdgVkwMuWiC8p/9VC44jscx27v7334sblZIgm3AAqvYMEWwF51 e/0rq/MD6EXn7VPrfecYpAyxKdxD9DuCzbgoQb86gpHuH4P4IYFKdOSEELkg mRt6oSCePTPRw+MO6meqcrjxFegfnX4VgE4s6MHCwsB+snaZ4zwtlvPgR/en kjpDWWf2Fz+vM/cIlT/zCEFTdgGiJGxheCrROGjuPGLeNYpsPY127EY9Q1Nj RHgKFKQqZfiGtOeofFljP1ddi+tkduBN3WGKJud6+JBaW9uh5tZ2QyMyto0i MNPFOtLXrnFCFz+jua6IpDmcL0kXQ8oBwimYlq6Crh9QsBa8D4a6GFIhCt3d vtV7d37ePUcDHlCXgoHh/07UqkR1+Iz8esfFp9/bC4whd2A2Ai9uQxvEt5gt Ag1HMqaDjDdXliFhZ9cfZ0/Lwp/OLa28Wu6oWELlkAkXWaMRVYPWJ7YU7zpa IHYiz7MGblCslp9d01kqtsHCRpTkWgUMIw+Fc3uCYhK82Juo6/7D2/9hnLwI lzMZpglvCJSoC0dHwsCLVZ3FWkxRRbxevTQ0ZO7y0FB6iYimqNcOmvWDVvat 7RVospcJ2zOyDBoLh0Lipa6QmZteMB3Wmjt7tb1FMHzUMlly8N40i8c1bWV6 sezvshq1p66dA0PH4HdzUtmOL9/JOMmoeqHdljM7tS+7xzqAsuheVPABhsfl +pxt5aLvU1AkW7rHw4ZAC9HZkttGDpMG/XITMXXHrDYuHDpkpjiRwyFHS09b JqLobF1vCR5rRiFDQpUox5ZsGvTruYwuIgkcT5/nGJNMxsAKKGAUY8Ayyvci HhxQbK/RK5dKtiUP+CrOBMJNRBRwqWJALzrgLtIuMWIFz+peWDhw9FDCr7FK fLzec+Mt1jH+GbC5K8WAe/whdxaiFYabOhtu6srp5OkWqeqiCRwOfyEPmQjL wkyHFqbzcUZcEnl08HH2MXiaSksR8ytS1VOlmw/mslbhKWvoaAQpG8/17D0N 1XkuMh6Nko+G8hH3kNMB7oduNU9JKw/BwiejxBP1wvV6Rt3ADpA9R/dO4krp 18LBt5EnBV9mo+1ys15tlWv7686HpQUgDKSYMjtRgH/XXOVMDDwia5JsZaz9 0RnInqV/z5zgHUuaEzwyWX9OgHXhLp02G7LojzcPus1/nBlYhxNP5+vwYITK 574IQeobifENUds9wP9W+NqmoMh1tCWGC3/3Y/IJywUYKzFNsgbMWnBJSiDS ASBHONHW4kIfQ2LMPIzTCcLu/d6O0CKsGCyvYUMej2VAv/7ZpcDAHhzIB2vL SP8qzn+51jL1z+H4GrRKC2RiDEcKO+txr+jDNhQMl0FZqp00qzkyh6F1HpFa qNXJX1CAJ5GEpCMHHX1RtO5edlXUSGeCTggydvJMnJ91GZrc3bh1Rfh49n+4 4UvE1lm7/7b0Kz05OcNDHOnwliXHoyccjiW3Qklfl10O0soB9KE9hBBGQIwp uyqHAhuPldhFijw7ZDTRV17dXS2MPGs8gXVqBZOBhVYPEvaKfI60mTN0qFA9 2URBh0JZopxDp1RPNnHkSPiBViLKwTLwncm4aIwu9Dmny0KfNQRmQkgKkYpB Q59DD/HQbzlxnqv5UOn+QMrbWnMZE4WvtZQZctVyZiiKB0bu8zV0n2+0Dprr ONUk0OTbZKrswJKhduCsIGt9lGqO750607V1Di6hTA7r6DHUbL453mzUDFOS 6NNJ2nJhcAad0shXq13K1BhE2AJ9k/INFeELUNyhpNOEBo/eqCqIIQbUw3C5 IMyznhqJ8UrhTfFOL2iytHxjZ6397mnn/KosqvBfrtJtLNY2xaHlALC+zM6E 96JhcJy1SDRY2PN19GIJl0ueEob8j9Fc2KiSG+XOeh5fMST5GjGf0VWl01f2 2btWf1J2mHAbie1LfJkquWFlK7+hkYjDLrcaib1Q0iv5QEkyN076XR2jnczC zOUOczhjrK46Tg4rym7HvQkmCLWrwNKL62G5vP+Efdpryj7F61AIStBEr/Es NBMzhzuaoHEpYHf5TNDwqO9R4xCriweqK4dj6IXGLjpPzGyU705H1vrgscNh BcehLcg0UsfgLa19ecSMBrzb4lOQrWlXLORKFL50B7QCMRpgTFBixCAJoBsg 5tF+a70jd8DOCfMtxiLO2j+cvDzt9q8Ke/gYPWHQgRUJqLgxGuAeaAWlLAcT BDNdQciOzW4nuGjL3PGNO3uydJhfqhdIhCCSDyxqrk+ST8pjaIU1c+4DlFdU gwrkbjew8Bfu6arPQe478ABWvkfB45cbKvxRj8RPhybABkFgVXyMhke8I0IP Z7BXGG8n9NwCbVN643m3FZDgKDcYMOLnIxdkhzDVNEtt0uRrolE9AniYRAD8 Rfzyizh/d3papr/ic5lCEYk/0kP1lJ7x16fQgafY/s/5AwOU1FhjOBDszz0e 2IN1BoQ8QGkVrUMlBHz0Jx4W6oExLrKzxD+A12DSjYXFy78YGYGNyQ3wGcUY xGg8l6oA8iaXxxiZI/HD4jODOTJD0gcr5ANaxKO9l+3jt6XEQYp6p6jefzun JUzf6IiE2wCvZpRj2AXcIzye/E5zFX08KU8UoUrlRch93J+2JD9DhRBHRsIW SF5E3oPaGv2P1V0E08gNvFldifQlNqIH3CeOFMgl0vnlW5/6x+eTyHPHc+qt bDpyQPIU5CFezlIHuVBgfyqpcRbgv5ze4zsOs0BmfOEuLFOMOfoEQJ4l6hu0 kNFQ0jxjJOc6xQhxCaauOE0+C/m1poQUdLj6H4UPK+QhpHXzuBZijSjK6JGl iymOUOjzlkHOkouLBJkSgfT201KBNVtOB85CCQda51INV1sv7PyTeepkw0sK I9e+Jh+ARy1i2S2h6F6egsIrwsWcPO8kkidK3qZjok+gN3pzjK1OkZ7gBeXI ASYqluRlaEhiuQc4hRwWVeCzpyIMhlrmMMaLO+54aCq6otxbC0yALDupDRiw nWB2SJWoTJbLepjfxdXZLJTr4/Pa8y0MmS8PsRRKRrPwZV2VBMid3Xm3dKLV wbk3R4ZhcPL/OZ3LahhUClepN5avc2fXW4YNa20+ljGdUeacNp8wmEhTxHIk i7pD1mM8TrhEl6PUG9Lt4W9qs2wr0fG3o8yWLu5C/PBdbgpUa3PzMLlD4Aev G9UZJTx/Xk2AWQz8C5cXaFo5ngTEq4josFemiY4uXhmKjevkaTWgPrN3PLBs jE0YkJsAnakukuwq5iJfknH2mmzgaknFtiCDHFp3fHGKz1T1YkWnAxgt2S4q GyxRa5GN9ou1XFVVetiLGLeNbCaaDMsY91sUmWuWoD+mFqvVxW/9A/FttTm5 5xHHrkNd8Uyw9y+3/8b7ZKn9wS8qB/5426tSO200yBOrVa3KUSFP/5ML6/3Z 3o7V6fUuehR4oYh2qn739avLTpkkf8qjRQsImsI/WUcuC4CBOlcn3ffcw8oL x0XJDYfqq7Sxir6vKBr0qqte+7IshWrafBrGcXisRpNq9Duv4ZVPMe35eOJ9 glrqa/IdLbPGwFvORj7A8xeGNju/Q9BdlHOxRaD0wkTRwcJsRI2jJ5YHeycA WfD/xeV5pPdkq8Qr2Tjau/vlhjx30PITOX1pl7Hs6xmY096bhVczNHW8u7lZ 3mzhkQF6eTuucnJWkaO5IhBQ/X6LCIgfRHCc2P+S6arwQGZJuUPRvz5YPMhs esrcKE0XYU1OaawSRgE7nV3j/bRPeHGQ89uTW79DGepG/6NMHxmWj/7ZJblA pRtEQgXiySa65sNqtefukJascWKAz+kQA5+X4twn5ebNbOo+7r5NxGtJjfAR 0MOgWL3fqckAA5ubgBiqLWdBMZVP/oYx0MrlscoPk5IqC91mXOn6gnSBiWWW DtejAw46fpKZjKAXdAaEUpDvlcMNXsoXbhD1VsHNwZ27Rfri0H1EKyjxaMUm pST3toiuoNkbbVxFOXjIzIZVdiDDMVEX52DlwmbQPqUJZd8yeQLF9wB29FEe FFoWTK5lCcu68yZAK8DkraI8xf12NNgpf1t9Kg7E06PFU1HUQlL2TMSGHMWx uCDmR0UsICLnuUyb+vD8zpGDOBJy8A0M+v3R4c3aN1jETwowmmOSglmKDHdI 9Cjlntn+LYYyhf13uXC9pW8YJIhAkDYm9r8exElvF68vBvK+CE9VKFQ+E8WT noVvrf4qv9TUl7r60lDOgDTNgX9becGJkLfordCRH3d/Yv7YapI5fbfRVFc7 Q+6YxSjS7cJAf6SOrbuY2aqQPeqsqj1u0FHd8Swc1GLahlZLw0do4oxKHlye e4GMGQv6yHxiPwh7gdtVmHf0+VX/uRi4AScdxlTRznROFqdrjJek6M5bYNBc kO2BWbt4SIZhgFUyKTrQovR8nB/D9h9mw5uFNwM6kZEtmpShpIYpAlSwZieg jrJXc61WfibPB6yZF1iMMmDxJApZB0jzPCENplF+ljxNyBe9tJsquqci63jV aV+963Wss2MQX57hsSSd+GHgl617KB/ac5m3GjmuVGwzMLRXYZDMLurqXWuW n8WufynBHW+Or65S0mwTL5qLlbCh42B0OFsw5HLdh25LFqzEtLHfKT9LHIKk we2Wn8Xvx7F8ud9k97xaq5VFLfvQoNTTFrl7Irg8LKMKUSd9qBwepOVThR5i 4+V7MJmRS7N6VmhXI2Hl5hOfTkkrAXPwNrFLgVjKOsWaGRfa4yyV9IyrqJ25 zItsQUIRX0mU4nq4A0SbGbtbAG3WF0rXPDlWlyJPT65kLmx4+cSp0OVY2orw RcT46ciQJEf35XGfZ7G1X27hLO7pgDYFfwnir+tRIDpWnSaYWHY5NZ4M8VQ8 0A9CnpYzSxHzHAaZoX4OkEnAE5qDqMktCjOYR0HYiBbD40hyV2vkc+7ZuRGF MPs82wBKPzU3AOhe/P8uJ3ifubZ70Kwe1NZxIzcx5Hto0Qku/DVCIaogXTos oYzJhhtrZqjEnGCIOXG5vjQMoo7HxVHDKI86SR8bRSoqcS6W/lXvHa6Gfn48 BHun+aiAOAC/KhhGBCQ525HiiBv0LrpH5GQIS6ufHwxjd4+CYcCHDoaRGikm EjhRw3TbO00JeHx2+cPxm9cr4dD7/j8jikYeAawTyyAJl04KWbEMHkUPj4pl UNttUOIe/iRujetmTyAq44bho59X0p/jOt0WtfpONQsi8/mmfG5cyjSwRUr5 GmbiGVHq79M//eZWFnFMd/ZuV3CHKEiCJKLFcieYUSjj1kFLOU9VM6khVn/F hbtd5A74sVYkQCMe1R9qjedNhgpk6S9njcwdOhUyfWriUI/fq9PRrOfgti/3 azMaprEjG0E0ecPlCJoyUHAk1qrQaJL7+uZvCbYZD7WZsYOTGZNCGcuQqbSZ X3sOoMGsyBvC91iLxTTjFHYLpEOOd8w5qUELwIxuD1uyW5ZDKPKiHJtDvhYR rJz/L5/6NcQ0zoDV/JOKaZEQuRkxcqUakinTZc2nO18VcDUKkpzLSLH2UcVN t0GBq1fcRYvVzw+N26whm8WPaMB4ynInk9xFosZnMFoDoHvZt96dH7eP33RO /hS8GMZrpeAcB0qdtYjw+5vmbX3xubVHM4cfa85cr3N2cdVhWThj6v5cm+jc Xrj+cMXExYESExcHoEtIJ85QiBY5hcOw7+fLNUkMuRvmDk0cfuRJNn+qNAzz +XBFJNYIRHIOzNJYfvFadaVXfrR6fhhWttPjB5v04hFUg0gI1VjpfDbPKY0H cF0RvvWLg7eunAx/u/v+rL9nrVgh2fA5E5WAjUW6azZWBhjIQ5a/a1UpzQl+ xPMtrNye3r4+eZle8sPZxfmfgu0Zw9Y/22tVHzG/Mfjc+Y3Bftn8xpHl7207 pPzhx199fi9P9uqNq/5jpjhRJX+WE+BfONFJfCvmeofneuevPtdXfz+DkTt9 xFQnauTOdAL6yyY6ie6/a3rteW5VHzvPkRor5zkC/eXzHEX333lee553Hj3P O4+a553fd5531p/nnVqTZDD4+IvPsz1f+o+Y5Ch47gxHQb9semO48jPANGlu 8SOeRjCSr+w/dEIHvuPOHzGjMfjcKY3BftmcxpH9V9Baa34xHJo3e8QExyvk znAc+MumOIEtf+HuUP4s/PiNC9eY1j+Fvcnfdvxgr77zGCU4USN3PhPQXzah SXT5q7bBq7bxl1+1187UnbmPmOZ4hdxZjgN/2SQnsK1IPVklUQo+/jKr1h1M hzeLx+yyiRq585mA/rIJTaLL922qkY0fP/4yMzod3D9iNiPQuTMZgfyyWYyi yue7LU7p20qm9P2L8V3Pvn3EvEagc+c1Avll8xpFtSLDKJsnan958wTdb2s8 YmrjFXJnNw78ZROcwJbPfRvMfRt/Ie67mN8PJ5PxI6YzUSN3PhPQXzahSXT/ NSquO88TN3AeN8/RGqvmOQr9xfMcQ7dinps8z395o+InezLDu3xrT3O8Qu4s x4G/bJIT2PLnuM6OS/XaX3WOV09q/ix+4bT915aUGNFV/rcxmNRZifjOLh3R Xl6L+p6o7mP+gMaK5KEJBHkzs0su1/D3T+p8q984DhbW2L1fzmV7sCx8plDr J/HOxKpnzK/f2K+uWHJRkMTsRosfnxwiVj/fsXqH9E78+I/xDsT+368xBfcr 5uD+Syfh/i89CzerpuAmb/xvYjd/MEx/jbJtNXZWxvSO1M4f+WqdRh4+1pUO ZHH/jdW/ap+ftHsn1svuBY6cUdRp904/WJe97vnV2z/yJM3hY9U8RWGSUxUt p82I3GkbmMkaJqzaWjFbcQT5sddpwprmhP0HXdSisVh5OyABlT4pUe/+3zQt j7hfu0MTgx//YROjHKbVzej4aMXLzcmIl9E1DZoGyk8A0lojeyNJVM51Ncc0 6ZsqV/oTDCFV8ZeDkbsAqemoMHI9MQ1Gwh8sfYEhyOCnPXRngeffiKU/EO5s jtGrnIkzv/FmD8K/dgUGLvuIAWmmju/b1862W4dq8vt46VNaiKHviulIuI7j 1Br7TTGfzWGMRxhUZQq1K4XCeNgUMyfYvrGnCxsb4taHwh7OXYGJ6wPPC24w 3sQaYAJ92im9IPWs8oBdAzqdewsZ546c4hENurvPRmLq+kNo8si1xXC08Kbi xgvmk+W1RjFFFN8UFUIZfmwHgzg0Ma0hOe1z4Tcq/kL7+LJbKhQ2j6h5Rns0 xMvTd51/MIjRxzhU5/1Zn4FUv1RU/G+KVxeXJ91eabu3nDj+1hRIIIc0+SrA tTO7GSVTFqQCpRFpBIAyadCuu0tX+nYO6tm5TdMx5JJrrc6JZeCjwfyi88Pl Re/K4jSvRUzUeI1BJ/xbjm7yZHN7YwOE/Q3xyZ7cqjJRAWLzl5TzjtPOUTwO B5rzYIbxleBU/2+I4IASqFf8uTN0xy7GJZMxLxgEL+EdCG9u/wy46UYeolXB qBQcwV5F0qQgbswAs/CW1xxrSLUU6JOiDfGrfKFfhquQG2W0HRYihojZQgjQ gigcrdnxIgenx0c6ML1604aKKltSXzgYxKYRXF7DXs9lMFkOrxRGk8XIUzIY qwQOQ2FS9tlr1IRUEUWlFYBM8ON55QWG3CypqJ1FhR1bDFXLNKolGRpUB++k l6oAnPHXhjEyCZkK3BslHHOQuBKFR4NtTG0El72LY9gcnlCMX8oICiwkoEBd FCW5yBEzMUhQWUbP3CAdsoxJfawA/8L2wWF+KVZdWq7N6JqYTKzFJ2swuV21 Pg3A7DVqAGnpuE734mu1vCgJ2VjybTNsAsCPPRmLUcUzliGyLN/9FwzW4Kby YkDfKahNoXDtYWw9gHmg358VNQyW4zGFnJnYD8XBTUn8+qv4Sj6cYtiRET5l 2sBgqzrVLwdWKy4+iWfi+173qkNx/1xOLm95swmi83+s/oQNGTl3FGIqe3Jw drdvnYeBZy9yWGcMLG1iYiBmamhUWvYPWrWV05LAkSsJU7ioZjK5GOO8HcDi naTmBvIf/KwEwSoBUUbIoaxMMTqXjFAZNfrdf3SK9yVRRGLwxvB1W36DrzA9 pZJKudds8Q25vTKIpkxcSFjLuTWeUHBr7MkSeAlw6sCBr/MiDBEFoyOiEDLK F7AGZDyJnLsSuCzgC6W+0ymLckKifaVej5mrJQaMNd+pgbD5rt/RSYe9mYxh FgtA+rbz4eUF6IaUtQh7IAPrpUSCzwlKFeVbhshMV8PfqGjWMNwPfu9neMAh tnmRGM2mOtimNVYD7IquPVmxFhRQ5kpQALEgLqB6tLL1jnQMyVWwbyjwtT0i H/iopy8Eg9qNjEePJPBt3uop2Rq1CzYKoHJgfd5i5NMU8HNBzzk6tgoMyPHI ZfmQQynTvi7OL646BxQkUxo+3euZhxnkcATsIQY64+xYUfSwP4IQDiIPijAC FLWhQ+jmC+96YYOMa/sYchejrVIGaaxDjdgS4kpFW8OgpQMHNnLHQGNUJYyx N5cpcu3QnmEVDqQIaI4cezF5eC5owWBcNHfikZyD+b4AiDABU194c8AUOGby ry0tRhljCyLKjz+hosavBxEMwyxSKAx8Qs2dLmFMuSeRESJccpA5pQoGZUfs GK81oMYPHB3WLRxpkOGHN5hM8OlHIM+nhAcjeAYLb1Jpl4SH75wE7tys5Bu1 nLejl08xXDxNKlqznfuhMw+HYGLLaNz8PkyGPLd9n2ZJioseR5KczyfukDIx YqTcEcb+GKPykt7NcAy7IligLBugdnfrRMfPVnwEJphQY7jiqeejPCOOz05r ODaoGg+BAFjQxnCZzz8+x4hhMCfQDL+MkHXh33jLyYgGcsDjPPIw7K0Qb9sX SmY1UioEIrF2jkAHONQgJGYlSOBITkYMbsMAnAcoVEZr5kX6kyFCcXrk8gS9 YQ64B+4keODoKj5lYkdKwTJU+TVTpFzUPocIpTTrcuX6SK437mjE8UFlWxj1 1o0MoUBS1E61Ua5pMUptBRRPCbjS1dUH6+Ti/Mp6ddq9RJwctAlln0IBKO1I oQZ9vYhp+MriXRuE394P+REdWWzCCpUXPPxH8RlJ7mm4D1Oo1xsEj426CsLP MYk3NjdjxaockeRtjsmgyLxHqoorJloChtH/WcjEZ1I0UKkHVuHJ24oLhY0g eKi8GE/c+RbSoAXCqkQ1vCHZ1iVNoPJicY8ZCeABT/r+3g7POh5A75oZVHHg 9GSac3na75VwwDFWfSkMfM7rJW+SVcTNHqiOtAFp7p+9IT2RKduZkwjxvfMc lobkHpIF41YR3b5gxXvJGNeR5Y3rO5SNYkt/CGTozkbO/aFOnoAmnCNOV195 gb9Wi0dqYKoU9TgjtqEUKg7YxpIt/ExH2wvbHbWyJZ8QIk3sCUtjppO6Mnzk yjxG9XyBZ6+Ohj7+UEyENSO5GNFaC9oPK1ModIuvYFxRJ4PZqCCUDkVPbzwQ PjB6DOx6DTxvCPPNdQXrdN+ORKXyQiXnAJ7Hj6WSRymRCnzQ8Xvgo14U/Bto 4C2uTHfuWISEuqUBaO1AjaOjakloBRH/JXvPnT8M6SM68GjAPBCtxnDv/t4a Aa9eB265Cs53p7u16mp8Eg7xJUlzbMTviNONWWaSo/mcbANkba6j0b/RPKjt ZBJipGIuCZLC1pLkh1Y3EMPE81e0T1KEYf850uPA8ybi+d+XXgDC1nKOS/q5 WsN/f3dx1X6yySBk0hdtyiEqjlniEqeYAS5ezbT/P0FZh9iFeC4PGuxl4E2R C5M0F63afnd1QWcCK+rh3KBw1FQYRNGegEAgf/nirlGKIW0SVjbC09gAy69X pR0+fNm7V30xDgcpxL+gLEBAJSHid7KpI2duTXmUhIgj4PTTGs1J+/x1p3fx rh9HY5GhRHwTeah/dn647PS6Z53zq/Yp5Y3UDb7EIPEv5dqNDac6csEa0cgx qoTCx8zC8DGbZC2SxCJECnIxc5yRTMXxg+wrd/X5k03eyjH5GgxJ2Mb+624M NtHUH6L9DVsukfH4wj9oVYfCWBPGnmODtD91UvH1rjQ+Rr8KGy2DCApaAmlY osPJBU+Rh8dHk96IcoBF75QV3rTfd6z21VXv+OpUPISABiEZ7aJjr0i76Ela u8buk82xu1aoIJHOzLJO0Mbph2fG48dystQjswQj48vkmzUdV7DAsbq3PD5H QgMifCd5j78i1cGHc+8M4WMOuxN8YP4/Fz7pqGw8nAUT+OF6Q/rExT1yEaXv TJwh1h67Yw8+KL2QqjaiTQ7rzUADgU8M8YrtsEeWekRhmREz7G7wOQJdzR0/ EAY8ZdMrwJdtIo2eXvyzxXXpmG0NOPEzkivA02Q7P4uiPrMisi2VH0Aw9Qb/ rDyIzSMxQnCArtAirejnM08WCG0fjB+BSVt8CQ/BMKg931Db40Ql5WY19fzt pPP+8qqvqsHMzAM/CdV/d25dXHbO4RVnEhQtG/CW6RgP2xLHcYozcGOAP8E4 J6F4RfCx3T0g2jROWgvh06/xw1KcDQRpFfkeHpNxBA+slmhMAKGc08shL0ON 0Zs5aBkR4qUztNHQgso5YhxhbFDW0MnqPnnQGWdw76oAb13iSofRBo3fdUBb RxOM0fD+u0s8K0FkGGIU3kHqvDwTt3EKgDNMy2hsmd2Ka88bzTCztyAjleoN KcnSkAJL7haNRV/zMZb0KpSJMsbUW33iPiELLlpSKLA+5/xGbdscKtwEaPwA G+B37ucejhzZfqDaBDBP0M7goHHi4pMzQxuSO54xlQI7HLGpQjyU43Mmwgf9 437X/P3+rFQql5DPJUdLHBwhI1U7UNq7pr/tXVlvm2Kh3vHSgQiEkwTIjzRK lfAlSZdqlJ9sHr86bb/uW859YDGrIdKtdJl6aQkXmJxDEBznCDMw5THiCdAm sypMnXuPsaexruqPfPPMM0ojL4/iiMDpviKBdGb+ciHtgjNYNEq9nTmfWB7Q kgRmbiBbIBt3ZSFa1LxlgDkaid60GZbJHRYeJkVbQLFPxjrODPvz0lV5YW8H S3cyEvWtFhu+0kYVevBNkQGtutWEbvvBCBpSMoHXho0O2mr4x0FLrl/IARXM 9kNHh+75q7Mrq33xjmls4M7GU+g8jCvy/TTYztnejgnrTPd2ADZDfR/7a+Yk gF2ftb6kAm8UxeQL9ZhUdpQv6jUVwDj7FNWsly9f1PY5pQt88NkWWkIHo/Fk 6d9YU3f24zlsOr32GVo6fxFoDRM1/CMw6Z4QdfxLv2sbb/6Bn1UymVU/H8ZQ 2fcRVLVqtdyqwr8yhRLVHzX8S6h21BcE1ThhGcjzO/OA1hosfT6l/Yj59hJn t8+eyYNf3DPxF8r2pyDd0CmuKqDTXOnIYJHqYjEm5b0g8VLm4o3BDR+vf7Ld IOq4QC+hw3noaYheOTEsnCCaEPcrejklb5aGAn5OmNk+RbIeghUJlgxPxH7J +nm1eMDOXOpyI8/0cAkbMVr9cNeyFo4PQtyIj63pK+xvRfPIjxomE5SmnYOH 2d8EiyCVF3gcDltM5YVteXO/8oKGLrWxVPUd+U5cRstDxwn4yMl3/FumhcY4 ox/KwwC9OUgJpWRezwDAHJNa2AfjaZRG8MX00jVbTz4jQH/rdmIWFHhoVvQI 9tipG1iDG9Wf7L5wheHEQWuxGxRfvrGQjqj/5CaBGqzMGz5F7cyy7DEm4gmr aNRADdnjIY37BAakTwsSy35eOksHmH/g3jlF+VKqwwT6CbgqnqabJWZXeDyQ eGjA0Y+GnInYOyefSmTSx0jnv4cXWN2LRP/ZD5sjvGOU4qbKTUjdAuk+ZDD4 4yuS+MkujsY+SrGpB0EnIoP3neDUxd6mDiUieX4ni6UVS9UuDank2kMmTh58 JirZdb9oLxb4BobjeslZqsoSZcTvtF+3u+c6UbEwGm66LaRTS7zbsrYdeFN3 yHV5InDkZ4pu+ZbyPtqN96vN0G5sciB3EWg6J0sq+kUBmRN904PcMSO78orl rkbRGJyaQj5Y4JKJvy39XYIs3rTBNnY4aVqzvqu7FSG6M3ImStBcHKzn/LwS 5tz5lLZ2IzBpNHfIRzhTECYtlDktWpe+7mt0Pcmnn6VzzA5b+1v1Pd2/2MQY BDOxl6D5LdLezw9AcrJcD5gJfpEz73oWJi6kKczkbmmsVRE3YAf5mg5GeedF pxyZrh2A9C6N6htLAriGkVOQY2eqJMcWhTRBTpbE5Dj5lMQxEuPq6F7d2Dto ZHtdxaplSnE7O+U9skbsSMakZCTLOkFriPW+0+t3L84tq/CUEFo7W82t6lMA reA2M4PVhY9BG4evmMtD/oYhfyIi59okgAcPc8enw+/ueffq76/O22edPrnA Rvc8yXmpjkXma4sP9n2x4QOv/Bl+KfZMZi1emVhYkqtnF7gu9A2+1LX3VcTD UnA60cr2xpOKcnVVfhlsbUVfVjY/jNGKxCBo513O0IXB8cmLgGor340K6fDK W8XfEscsRU0eWMVHU3hob0c/Tuoj4SDX2S3QCB4GDh7So9xFCXpHI5mUkxIj 8qj4wgmGWypf53gJHXPKhAZdHz4R9MAe4NvYnwGNLYuJC2vAl/6+drCFFbaf VIzEqZQUFbMq0VuGwYSccYfTUZnOR1XKdfItticsbLhYCK1cWAE2dlEiUVjc jX2YJz9jnjC1sHOHSd+dO+luOh35/A3JJAs1HfQpcFyUZQLnb+im4/NKrRRC /PgrvRUAi9lWDyVOFkcqne75+/apErs10nK8HKiHBWzWrYu0Wch2wYd48UL0 3708Pjvpv+m+usJC2VQsfCbLztr9t7hcKizqLDGfYYn79OJInLV/ILNkv4RM jHxOQf88lGfsLqL5v+r9K/hH+6cBAPCquZed3hmNAR1ewu4PTZQnpkMb6OLv Vv/D+fGB8ft156p/1b7q0zPlwhwpplZxMbW7yF07Eu/6Pbb/g2ijdQhnCU0F 1uiO0B+WapHtXtd63bvUtb6C7dG5XnjLuTWHLpZKlI5V1fmKkqyC8nHcvkSP Qat9ctY9L5V4nw4HINrwEae+DBu8PprPNDmxqa8UUGAD6rk46bw/lJMnVwV2 FKkKPX9prPEBjzENin6iRrkkJwNzo1sBpUjnPYtplozw5Kg/GzGlyNYgx4Ft J7ixyPNcL8pnsxHLLdgoAOVOGX3iEcH2zzADM+aTq7yQ1vjKC9dayEVDLcqE 0u2kJoCU4wB1FOXLw1ZWOucXVy9P3+oWfdW3un14UEQEpUTjzHpycAu0UlE6 oPWLknPYwa+Q6cdxpE6aSKwAoUmaqO/i/IBEMK7H2483KyK3Yp4k/edLzIwO 5VELbDG41TRrrTJnH2dqGOBsw3Z1Y0t2KlPJjjTCkvKBIeenADa2Ac4jlCLj 41cS+4E3S2IgEKMF2OEDRX88EKOFN5cDBU9wNKQcFrIpEdGEsj1M0ESlLX7D FVASKFXq4YOeNKlHlsSkHvlUH47Vd0R1D1PI5BuvVLVcqWe3hdNFf1nqkcLH 7ZQyCA9vcBFu8HEV/54TP1XCEWYHH/IyKJbohAr4n5weeorTYyAj+KKJriz6 p+2X1ttO77xDGcPTUF+PQXO2/Vu2TT3+Fbp+SfeQ06KDPrbwHuRbokjpA9PG /aJ2GEKJFKw0QwZhMWuvSpoXf0jVVms3mPJ7DFLKTfEZY9E6Du22zFkiY8k7 brLAHKxDs2G4fGgRGypV5F3USFAwathK+GztRiRBglV55aMiKA2V1AmtmfMp Z7jYzqI81JQgKbnxV+h3hi6kaGJnkQ4lTGgvYuYqn26cmSBlCw9cuhbmagUF RR6RfXKeLxxxvbQXNsiieCBVIImTjgYG3uiBTTLoHutLd1V79hCQk5I98JbS SxcrsWeBPEvgPtC7XTrGY+WnjC6/n2SFf6Ir8hB2UTzcAqgi5e1zFvqMbOah n5O4IYdR32jajX3nzJ4HdGkB6nKnSoZjndpFuE3PjsT/FRno16513vmeiEHb cTR0xFCmnddfLrxb6Ab2FTrH7Q0njeTd4QRGNwAF9phuqOEA0L0agiAk6p5b WZqBGGjuzZcT7v6M7lrgASe2yxfLOQ60N5MexdAy8mbGM8BAHvHZd7Y7QZ6f 4jgckpl6h6Sx0CAcl5nDEkmAslHwnC/D8a0+TZHQRRdkhLGkxjG8F28si4V7 fROoY1IiT5gqTO+I3ZjJ40h0d7f9gHuMh0QTz7tVPXz/qo+qwOza8bkeTfon FzQmXLmfQDZBBLBlw8soI6CLF/4QEvg8sCVv9jcfqHsL9Ck0YGtnS39QeeGD tld5EU5PXVko08qKcl5k10XcSplWSXKP0GCdXOgagixZ0rVarW1U1YAiUP2T 60tOCM3UjTMZbW2Jl7hIgAUuJ1tYmRB8TysGlSxnIT0IiR0MLNYyYG915dcK SARAuv7WDdYswKgtprd/sxfTreXtFse38RbXWAYanCSqGHGgwJRgXQk9bDnz 3Wu8UEG6H8CWFR6yTLHdE/+CLOLO5AjCDkk/QEX0Fuoqpqa+P1JzWJHUmyFv bWmriHWmR21MGmt0V2LBMvYO4JCH2pWuVW5gRIH9lrIJo1aieBx8gffA38Po c0O7xeehZdTgj2SwZeNjxazLXPZI8mFpCE4vZP7L74gYRqO7OJtr0RYbWzGC 3vxY5oN1fhv7kTXXYkASNoUFUcm2Vg8z2RCph2syIoTVrCizoh44AmfNCaUJ UngfK0/ISo+UKGStx8oUstpjpApZ5bFyhdnAbMmCqK7Hoh3dD6BXqyahUw2R tqAbziwUEVpi5+S5s3D8uQcMCH0Ikc7GQE+cnljep4HxmqFHFlXcTltjKMmo VVYxz6LiMkxFqZqmJMoO7xw1jvIr7u/Vy41mttS6bdzUx/+A4JuRjSkkNIFW R3QAhqmK8GJ9H85wNQUAvscvbPI6kWOJixG0gRs9rPgAYRkHefJNaOZn+goe USaNYiDuXFsk9tqSko5i0jUTyGN2iiirN8/Wjc2DDPTMYVm3ueEE2pvUM1S/ oYR4fvo2gQJDlsIR7hPh5sQKPTaPty20DfFffWKv9w2gSMvCSTRElBwujOcX ePboxZnwZpyy+Kg8B1N4kB7bp7Mab2iYSiA3D1HX0ZlWiV1PYiIEUfdj6GFN gUUeJO7vYS7TzVoV8wfU1IWm2HiUeJMZ8X1G3syIMaJ5uBIsHpDS+XYiBhti FLAayM7kIvsiqz63G9gZ8FVBF0a35PWpylrzYHZGdsOkvkfWjRokIlRJ98Tj PI4ZKZ+2x7QX+S5jJ4wQl8m8BIY9yTAXBc5i6vzrX972Pz2oZk+sexCF0+1H 6aAJg1I6WCx6VL160Mp1v87Gk+suRZcnasrkFN7Ftv3ptu9cUzyUaNgCLFna dHMkPdQBuWfqoAZV3ArII1B7m3qB3FMfnGALFBK8WRa9dv+qj56USdzoTjn2 zZvlfKjWwNhBtYYyc5JflYQQ4S02eSsBSVndccPSKl9tWzXfd6vn+S5/fu++ cF7vVs9nC+8IbcLfWktOaGxYOz9c0U2F5NhqcyqO7pNKomZ4CwgnlLbVlELT 7XqA4aOQ41BksRneXfaDgSv3ZHsI+/F0zjF36OK1D8LYBAUEjuLzoD1A1XXh CUsESDZCSxY2CFxTICx78SA+eYtbe4FRqMpiChoAszw7UDF/5Egyp0TMxm1q FEDJdxNb5hO1Tlx5Jx868wNdyUBhgKgaCedKvxc7GL6boKA8ewglyccigWjH UTNygkHnjRp6XGw26mq5qn/KBE9HIWKDPw8T5XOQIgOP7hugdiY2MKSOAaYD Eh3q6U+f/99rBMwXFzfwoEGPQSm2O5sHsBoIzeGlIz4oDUNN0FC1KDZbY2c3 NlSZ/4oZB0l4kNm3uu3T03evL0qHSUzHJx10cjyxLrsXx1cgfTwd3kDFA+HB Hiy+/drjGwH0BSZgOaHveBMzs1UZTSFE8puLSxUKbPpdOsxfsL/3hKl/GEL4 eMKXE2h5weaN0vlo8sB6DTQYGypSurqB4SCGJHpodQ764o4fiGfgK5cYMCKj LoyE4ljo+TK8wcggy4XvSO2ArkYwxQOzYKLYZaLY29MnLOqfipQll8jIs2TL ixx2imdEDjvS4thji8K/c9TJdAHNWzihRgs6O4w6u6DA6z450vxA6vc0sshQ cNJUc2dP6JAe9wLr7OKkU0oZ5xQ6RBNBZKEeRX5J18JarUo+VLV6TQ91zlb0 7xlGgLgk/o4P+D4NW2qEXOlKO2WyswVf9rIYShS9BZlKbTG1F7dSeCcfvq9K W2RAlX4xoyWHEpG3+W2l7uICuYa5kniYaAFghPcoBtIRRxn7t2Ix7uhCbEDm fTTeoqrMQ11vNWio6zvxXUH9o+Nn5941Wf3n/we023OQD9JIA3IdBTAG9cMP PxywmeYTm5Ns9KUlaUEKkLC1e3dycGkaYc6+EnFSp/dIh4f0EEwgXPE1wjSp TpbEhDn59FGBGo1q+aJ4lRbLJn3uq1NLGJFz55rHQDEhw0ilrSNhfIuvYqtW GgcVhwMh0pL2C7y5pKA0i2N7IAyi2vy0r8zYr7xYKrVaujh0jfmO4JMOz4zk KA0LIVm3VULucui7OS8+M2FI+3OmXDiaL4PibASFVI8fhr/FkVDCEQfEbDVJ sa631OIpaEA06y7nqlXPUKRk10vV5kvgnJ1erxi+CsZuRYeTg5Z0YeGhy0Uk NCKjAcq8L11J5PyB7PLq7Mr0KakesM6PJb3O6wOpQ9UbRH0oXe5L03/eWEg3 4uzBKGS1EQnMnPfpLUxnyjjESLKwmiQfMbyrSfNxbTQIlInQHIjPim7T/ZWY ejMZFN8VzmJSsjSFUcmSSPzj5kG9cVDLTiESq5rvpFvnMDvwUTfci3C1TXE4 4Y+F/lFHwvz57JmIQCw8j+5QGItWOwyyFY4uSRFqAw8fVyC2xEPAM7XnrvTP xVux6tIRO0kB7Dw4DH8PlmO2BOGMy4tMhQI8he/Kr8qy0HBFjsToTu0XX7+6 lFYpfd0AWyiomnSzK/HFBxX55ZXtks2e2oUb+Lc+HvgsZ0oDpRM8ZOocFw7t /BwZgGtQT7YohAvOkShpMpVOaWedM3XHAR7rg+YCdRhZH/nkGeyxrKaijO0u C7qNjWEkI6jXGWBzasqCXihxGGMmihFLaIneWZX90HFK4aW8QiMksClvbuj3 qENH/V2yZrQxLuxxYAXw4iL1jRz/JKaDPF8x86pnhr+YvF+fuhq9VD959ZjC Mp7ZDxRPoYkhiuoUoqiatQ69dTzla2jp2ayV6SSmAtKCqnYgZBiYYDnwQTZF ex1KcUhVJF5Jd21pYyEX7fCfDMI2YjXKuKZLMl/4jnPtNCADicgDKb4B7Dii gmLcreOgSwqZUsJ/IFgGDyy8SKMPHbZJeTm86EtCXqwuXsvHszaSudFSTUI6 2h2l4wFKt7G4ktyBmxfJInL/Ty0Bgpp5VLL6YgGWT+1746bB7+/AXvlFm+GL uOT7H/qo++f6SaqwCnkgBtnngPFl5VwQvE2eX6zvwyfXlxz8bRi2ij2Z39jb HNrjJo4qE9Bce5lA5LxJgYJ3MVAwxgrODhaWjSWxLptVM0gqx0iV/ofKj/LC Or94dXF6evF9oUr3g0nHIk8DWJnkH4AE47OBUFc6bfded151TzuFalPXIiPm wCHr0uDBWKQYnZMjmmPwjRiqk26vc3yl3s6vdzGyBd36EGzYRycfvp4xvHGG t2zLuei/2q6xBVRj656/7/a7L087tCpl4wipO7tz+by6u31RDjez7R9O+mcq 1q7E88o6eXf56qRQqKK+A/pzpM2v0B8dS2tYio4Tw4nnO3i2iEFhEDaD4hJz d0BBSdPifkVAF9O1CC8EyyS7EITYPxId3pOiCHW1/Uz2n4Ujn+Qo1mW9mkNy dBmdB3kVyUXppJBOJjfIpSrqOgXOAQXTHa0i30wSki38Y1LQYqroZw3oa2fm LNzhehTnNvZ21iE5Ey6L5kyY38zpIkh+G9UZk86TmqSui94Hk8AovjAFCmZS 8/AwYzudkkM2mE7JmQRW/39EYGsQwM0ny8W42SsnRgHmkoACilzQbKKxqpad yysfSzYRUGKReiNGBK+6vf4V2nlBUWqfWu9pygvV+3o1Erf+Q/+4faqLoXzP YBBvT152zgGBWVzjM3oyo74nQvEFYq3AnzFJtHQEiRPa7bf5ZGKxnGPoayOM f7y1dBmne9K+6lhXpy/D1o5HIUyv0z9+0zl5d9oxyodhOXXk1bvz4yu8nRqC DCIdMvoyto2+nIL6NxFAgccCw+BB63t/F3fUQUGXNGlp4HUHjOgHeqWHruMc n6m8DlPCKX0ED9Pg8Ko7UEzX42M6m8JqQg5Bc0k5BIsTM2yk2Xk3V+EJyblV P6in5XmIEgjmFKDQ9tY9+pWAZj+MPYqRNScAANJsNcP5V/kMgBnVavvkGsi/ oXWS6fBBj7dcDB1lFMAzAJPj4IsxMBLGMMCcO96smJYRJTEE82CBpp3VU6MA cydGAWnhBodz96DaPKg+gsdoLLk8pkXhKuCvTDoAg6TuXqMEzIc2l1e99nHH 6neuLi5xCfYjgyZLLyz6hAl6fXFxwpLrPW8LVWQtm85sORUdCtCEJhSldHZe Wcev4PPIAC9Hii9jxc1ocTtaXKtGi/8RLW7GivvR4r1Y8VWkGGMMRYq7HbO4 Hi8+idRuxosvIsV7CeQXl6e6uFFNK7Z63fPXVXNwsoBqGqiWDVTXQPUE0PmV 0dgmxWKio6UZO+YGtn8r09zqKj2jf7VqWAUP7KdOHPr9WQhdN6Dv3EWwBA5O puVYnfZxWKdp1LEnIDNThNb4S7qvdIW9lJfoXS1Z8VJVZMErsyKG9cJVE0PQ PdFNrZsIXD70+3xo5HeypBXUssJlRtd/cQyKFFpeFIvvzyy8Ti6eCX5UeeGQ zY6SEBUbxvP7oY/3AhUqDPyPbiCYJ4qcEZ2FRqowufO1ON9y5vrBOpuSAszl fAoochTYOKjif+tzPo1lhXTFMnZD54MOw2Gc9ywf/R5ADigU6vUGbiewIVGI CJR/VKGM/BjV8qg6SKuBO8LKzVgJemjb6JmJha1wB6NC8rwYBhMoa1UTZcMJ 4sWyWlqZz2V19qWFJlOMCiWN88ELx89nA6W0Ki7oIL5SA5WzUqs3D+gm0nd6 NJWxLsufLzL89k5zLY3LgMskCANG5wYTqN0ftJoHrb211PwIknxy4PQ7e//V uL5YpcdBf4w8rMDXlodxUtdiPCZgLp1plhHN8lTfybuBno1lhW6/w8r9jsp4 FmMceIzk7zQLMA31Wpx9QPly9smdjbi4lc1dsHgnk79A6U42h8HSbB6DpXXp fSS+Uik8LKvd73fOXp5+sCwK3aZL5PNOr7SSg0x39m7X4SAmXNbMmjBhaAGY T8xjAbOyFgeJIPmvpfD/IVvBmVjP8Dd15/5aRGTAZRKRAUNE9L/LiRB1NPy1 duT8r+QOEST5RMS8YSdBRIoe7ve+mByMTeu+9ls2rft6PhmnUZdsOdV6DGXB e086p+0PBWzA+Uu8aQfF65ALjPn65LKe3BKFzCMZQ+xATxHU4nFLaRw0QZbN zpSdg+a/ZPNvI5tQfMknnPl8uA7VGGBZJGOAhCIIkgnSSyvbsygLx2+xK4dT xTrrY3YrvcMIQzhNo8Pmyu0sT+j9A+9OMPrrEY3f2K+uQzUmXBbZmDDxBKW1 g1p2gtJMJPmEs0uEs/tn0ZH+wOSCg74mvdysRS03K2nlJqlNk7m/tXvQaK4l Cxso/qNOL//IdHKzJpXM7cVam1EEMJNWTCCaa/KxqErG0lrvGCKJ5Usce1ZJ D+lkdt9MJzNlmJWiTJbHTt6OpJr0x6QbHPtHkM568m8MNJd8YqLrbyagtUXg Gl+O+qOSUOVPSkTr2vIOBFZZTlchpl8HlBbMHSwDdBFdt8rdZG3YgXNj37ne Yu0KMGXoWLo+PDprPw6aInKuXYWyvK4JKqNx5q105S2avcBDiLR1HZY+Kkpn SvWYk0DtoFkzM800OdNMU8XKUiR91oeV/K7f6RWKte++a9RK0sUDXZhf4ZlM eF+SXNfVvXLlh2LeX5FXuD6GB3RF+YxujtB9CqNQRArRXT/6qpIOT4j+Jn2M VMIBP9idnryvVbr2SeAs+CI/dKjXObt4d37F3tVmT3tnV3S2Vyjij5OL89MP v8I3DCr8pneB44A/z9rnJxTDi8amfdU96/z6UTJDPs7QFoGCkbcCWUJN3muV DqmcgZODCLm+ynNLt9+McPwpFTHhexBg8rdZatX/fXlSLuh6FBAFs8bh8sd4 eCOhwmpwsB6MC6izD+hqQZh6F292YiE6qKuLHTKHMtS75BOEfmAvgjK51GMu OI5iMnDpQkZgJI6GR2HMRhnlibiuPIkw3URgwji5nTML3MB1fKkRyWOjuE4k MwxMKWsDpjgoWCrrADUHkw5wSodSotLM+UQ1UqqcO5+S8DamPch4RxvLjJCz 8WwwKVVo8EvmXjO4sbwxXtnmZhVjN07wKSU1waDVz8T/0YUXpN6SihvAAVHw EtxuLCIK84WlP8Dw7WPfclOjn/wT3l7PLh4u7CnFMIHVKUOkpEU4kbW1Y1hb bUG8TnWyNEnasFq9RYVuH8MGilNPAa+uMVUbrpRPGAKDurfD3dtVi03i73Ij OAK/jv7PSRP58hEfwwNCX96wSLb852lql/nSQFoJYeaOkoNPlbMc18K8Iiqi Esb4wtMc/mK5h0ahnBG+j40X8xUrVAUmME9PCFsoyCccz4qBcA5MEPpNWDA6 E94d3JDevZY759wby0OKOsO5K0in3NltlOu7RjgauQF0Z+J/7dlzn4KX0djw JeZixR6WKPobxrfDCyl08i0PptQJuK60dUOxyfDeOV0NH2P2eJxrPPiXIe8w GCG/QV8jZ2dCnyU2vHfi+oEzGz7EAp1hAGcK6H1Imq07dYdGe+d2AAxRpWsw LvskMOD4PR4F9p59S/g+g7V0R426FYif3ZEV/OYmybDpYbyEXx6NqcCRSgjS m5VSI36VcVXiLXV5dfAwVm08zq0XhyeuuGYFWPwUmSK/XYkZijTS/6046MpS tDFEQisw0ZzGEHIk+UibvghVStPuOVFPFkJ+Olbx8RE43qJ8DHrfcfEGYvL1 hPdR/YHGIGfmFiUa87vgI88uKRwW3sl7quxjKQU/5nD7xOF2682VmyTvciu3 wextNH+blLWfoF4BrCIZkNcYCLwgqsBkVFJgKf7A4gumFIC/So6/uw29A0XE B9ggJCr3XxQTU5fiUo+UYnooPxUEI4bg1CUKooL6Yfzl3AIf804OHkAXJTZ4 Zt/L9PTwTpZk1exSkCcKmWkhPy1s+PR5GILw2IT8EEG8uRwJNnPttvRIqKRz Kkm3OyScA8rIIRLRLAu4hcIKmQ0d3yhPy5zk841J6tCJkj3C2Lw6wdJ2GPgy zsqxJT97c47+u5zhTmeGOp66MxhamGraz9Uv2dMmycW7e6241CGpWFbTAgWR XVKmUNjVLxNCkrsC0T/jQocCuA/fISUOLXD4A0PiwGi8nGiO6HZvt6pni4gQ mQPpS3clnaeDg4WoS6cqyJZ3h6aWWKjKMvwdjy3mfCZO35mNOKtYHGskYWiZ mR9XC5EpdhgncGKM1nLGmogF0k/I0BT+WPse8dPgl/L2uj1XwQEyenE3pUZY 8meMq5cOlWRnRiqLyBcyqDZPzn5Nx+7kZiwcCsKEm0iYRUWGcOPA3Yq7o8kk CaPbSVGdInWuH1FnkyPys0IBSrKTEllKXTVdOPOJPYT+9/rnZXEDEOPlZPJg ykbSbSt8tQ7gxqFN45uhdORKa6qqwJ+xOv6adULpmyKpso6x31SJQQoRrqnw wDvGNxYGAuOIFJmhXS1r2agLAOYL2xNnxl/GN2GusLmNzgrG7DBSRD++KSW7 EMO5AUjn/JUy3mp0MXI2o11kyAFaItWDAuoIzo62O/gcjpOGiu1b+639+D0p CiINTGnPfPaq1+l0z18XCrUd8/HxaafdA9hG3TBwYYxWeLbTNFX3Lhqrrz6I ovzCeal+Vc+tk/ZVO/YI1fe+Ut1rjTob5BrABvejgak5PK8KNhuJc8zRqqPy g46rnBPoOcFtJFlLTOtEHKbFJ8wKnNgyA1akNxKZJoVSkPUQUelQD8puS2br VMKaxIK0A/Lf0F6MrMENp2KOce/UDoamFuobJcPWqZHLgq0vpQRqsxSDB8Xx uDPFDI2s0BlYMHV2KTrSMrUKj4PKCBTrDufdS24L5ohwY/wHCtuQ4GBmoAY9 HonanLgTGWNiVKEWpRJl4XMjtTrFRV+z9iojOkgNNzmexxGgbFO6BEjevauu dttIYlAG9f2DKnq3hgb1fY4rX4vSKU2vPRrBJjFDfUUNiPwpNq7nxjDKRFKT 9aAThTC6qmKYpdFY1ZzCenKroZgD46NS4lV6EzJ3Ix2WGJmvcXtGqlfrnaJc L1xv7dOZW8wr9DBd//BqLXf4EHYdX3hp74PVzJrDKpI0IbPp0oRKIc51j3oS aCL3QmsGhfJRRS1+86J3dWyddc8veqLWMLzcO6+6li6CfbGxg3IWPBVX7hTD dizwndHj3P67c+visnN+2bs40zj3w62TDlk1xiadqHKMKBPL+fteW1dvGn75 3fqFerxjbNNn3ePexfHFSUdj3muuns3pylmc5s7e9IsO6Kh67gFdo0oMBT+i 89V3gktgp8cY2sQZ8VajczpfvraGXFAWz7is8oIvqxkXSeHxKR81yeo6CzrU D3NCZ9WXLYiiMFqQiSEkBGdCRz6XerMs0Eflhdz98GAwLTW7QijBInnOo2z0 Vbt/hffZixThFWrJjOWRbbWkRY3GPuk5jf1GGPJVX8rQUcDkxm6ZsdT4GW3q ukpYgQIfCROcnpSrdJZpMGYfz9Is+/p64YCqeueEN0yKcquO9s+/8T5xM1DL 87XglANjkYQ1v6YDJNRl59fwbY2NmG/frVwwEipn0UiIlKAO2RFIc1AYm3Er cgW+VuPD7QwLn7KgpRrv0AjEdjkMIzsbheFh37581z09sepWy7hA+rpz/rb/ 4axPV0iFUDSDVHeHqUIfpiUBf6hwSdjE2cWJzADeN52y9IV9gTHFY2dNI0Dm ozbLbRaR+Oq4G5st4ROueAKBsPnKxUW/BbMicOIr7vl62yetKliJa++3qoKl buevIjysAPrhKsrTYNmkp0GStNdc7fadhiOTc+/ulWt1tMmVazsqC1khnkVl 5NzH7E0bmCYnKd5xIScX8RYyiGlEuEaGAjzD4riLG2iAwrwpOe81DUGRdDPZ r75WXNSnrAci4+VCv30z4+1JTqY5Nac3TahyxF/jrE1XklpqTjXNlLEfIbBq qWyW+AgDBow9D6jMFEz5jGLVS+nzRuiCxUOijbFxSzH3RXYHVCECj2eAc9Mu Z+7Py1iXBWuY+XSRSOiTQ4pJPSbSiN/p7fG5TXaW02T9fq9bxXf8iT1YxXQY JpvjcHmS3dRXX2VLIMjkNS12OmglrSNGGmOZmrgYzcQcU9+NQv9mgfaDTHDW BxN5kqPwqSYls9K/8mpFXmWAoDCTqGLqp7G38TuUDZ9xr5z8B3+Y56Abhcoh AAnxBWqCRpH0yDV9+aTpUBvJCqiXW8cXvY71rt/pW5fdk6NWnf3DYAwOKFvM EDMxkB/Fwtn6ds7hMWTVq3b3/KoDlRplXefOBr196asojYGN8SxG0vUurHrc PqHXNY3XwQPl1TFfeOStG3gyQQE6tEEdNsIThrcnL4+AosPqoKYD1LYH04bv YeuvTBJfZfugkvQK78/Irto7aXfOLs6P9qj9zCMOxLE3g4UwEbf+J3s+Ur6r S+lFh1VfX0EHjt90jvb5/aomqDzMdjinHeeYndsLe+oEqK5oBOiSdXz6rn/V 6R3VquHoYZAfjgmBI0GqAI4BNiT0e6IxkFhevnt1BAJsIa39MiZqvAHy33tS nq1ep33SfgN/jmp1DIGCkuAZiGh0TKSVi3jF9g9mxYZQFdVRbbSidBpqNRsc 3UifQr7qW6edNtAe4AgHYQJKCPTboZjRkt4A8qTbs84vrrqvPhzVmiF0eBGF KMWVDoLx2vQeC30yj2qtsPbUvnenyymFIsORxoR+5BZjczPEALrCkXQKnLDr qLYToZahHO37sR8faX0AcXx1alEGHQpq7R/kx8rjX3fMlVYxGA2WzWE0yBfs MlEcmRtN7OKrsXFIBHzYyDpudNOVW3N8L0amnJ1ESP4zBVSQvq6BfQQWBo/z WCXm3IgY6QgPRElisBcLO6bmq7NcubdIF5G28mulXIHYcHYTWU+XuUNlem3N R6V+exS4tb7fu+FRsm4NdHhMpVU32J4Cc09GCTeKojSpH8fvRrakiTyDDsN6 uab1nX1ySdzX8YMieqs/nUdSjnH2FxUSQ+m+Jy9LST8cshW/UKqykZH8vVS2 KafrcCgoXy76l8/YyRxtBOhc7uC1lqn9IOwhBqeCcZehxznXzmxEd16Ed4vG K+UTDS9DAh6RbwVgxMy7wl8O0Lt7sZwxxxosr2W8x1q9zrv7jup/RH2DVTeh NATo1nLId24s3GWtEUacQs8IeAk6aEPrR/AKeTRAFldzyAxDR+f9WT+ifuAd CQvnS5mZjCGjRuD76QxXBbbX7vSw3vjICe/DLEF1hRGaQkvUc9V0d+hYyEN/ 3Gn+JPMw7TDP2dVizS/i6TiYDJ+WMV7mEEbjc1k/Hamne/rpNBjRaROV1MZV gt/EEuwPPW3IpwjPB6tVPFL9rMyCzSYJ2E0QZ2S64Pi/z8lHlEcCRk8n8Mnm chsIB0uD8zZkEi5JAUCteAw4OPJm8nM85i+OvVBuDJxmO1jMhtN5EYgPNKSn AAKdbZQwtUNVJpMgOCz/sfETPn/+sfpcFeHLXtrD20/2YqSzF7oTN3ig13E8 bUwlTb5NlKoQNnVqA6wDPE+R8R4JmUog8RJTZSB5pOCgVIjewPcmsMeWSTzV /fo4eyqTMRTgmQWYj0TNeMAU9+sRhSbFqIdWp907/QC/JBDu47DcHf75ObX3 R2Hn5QCq8dtswgh60IbI6KW0JfYe+aJ0dONxNr7q4/HROK3RwrWGK+O9yWn8 1qd7HyCkedcz1+ds5BhwkDPxIqO7cxcehwdE7QHlNkoAgg0vGdPxWfMTlXcn QsFPkfMcPS23VJKgAj4Wm0eixSlrYqwFU/4AgJRN+WB2p05WOdo+1KtQjSSm Rt4tpgIMoomvi3KWJQ6oBqOWq1EtqlEtyQnBAgoFzLBml+HFrBAcoYpgzW8e fPrNDoEgs97ySxRcSfr+NYg37aKhsRrpWZSbXx6fHXfb5L/jBtZ8OB26tjXy oR200k88vlA0sf3AMByjASptVyiEe4FEcA574MhAsiUOSpHt5XOmRZl0uxQh hHXM7TP71iGtIyY5xIpNYSRWZIYQr1YP6vW8SELxuvlKNwklNeVe5A3+WflG Uce77kltp4QEunRHtZ0tL1Z+doExmPsEcUun23GIyzMqnE+hZDNS8rZ9eopW fq6sTsc9JBV3PHN+FkUN2m3vNEtlvGL0tWgPQc+ncJmwNtsTEDvOvNHCBhEK vv+N+o+Z+bZgCW3Zyxd0lUNUxjOv4k3doDJG9aciY1gCs84SMnkID4Qawy2Q 7tAhcjZaVUN3JS11jZwZHquEXBotTaEGWULRLklLqlGc392DerYLSKxqLi3o 4L77KWmL38JsJ0+ZbqfeyBRbY2tNzXKKzKodIkLBNX406GiJauEZriBl8u3D e5RKvNklIt6rq4TLnR8uL3pXFrz55QXe3gw4FOpy4ljzJelOUQh0BIT2IQww 36U8p8zsi2yk4YhkWXzuaVmqXz/+dJgF6M3jcNHWJJGVUmEieJIgqgQdqQbe BE3RUoXNgVX2ZwDmalEhGdiksnwBF0ebBmxUeJwkQ+fGxhVE+CkptNd44SYx 7FhMnsZyJ9hjXqRdBaLQmDwTtrRrlP9LynBBczuzJ8qcl9qqWGezj6iTTWSb sKX2q3hpfrFRSGfWspu1aoOPdXdS+5m0eCcxJ6zcuSDUjpRJjxuxc5GgyToN IKumhOdj7GrUsBsfxbssLPh6po9YgWEooXi0yd7FTSkpyO17RD5bJItugMws pqVk4d00AP0WTS6qfw3S8GotlWc3xn+uF/Ygicblo6+UAnSUTXZI+sEmC+IO rikYU7keSGRDpDFUVtJKMdiFtVSLs86d5Ey3yU7SCSG7rLN9OKUVmHVqMHJT ivjOAeaLsMajZA+h+ZHi+ITovKXpZZQ3MqsImqx62OJAZ7vp/Kd3cXFlnXTe p7GByNlyJoA+PU32MO1wOmWYgJDkckx/UQwAuA7ai9OWjz2KIuLb6cSA6/t7 6pJEtJbZfpFKg6qQEtTRzXjpKiGPGpLMOOtEODlEAxTxhtL/KVkc81Jmt240 I5EEITA9AzDTMIdDfECwGMSE4c2CvU0THUyCcI57yvzc2N1NJRr0gqUsImlz wIkj3MXPKasPvZ24pBKJmiuFkXbv+I3Vb+xXS6zXZZdHIuuaEnVieS5+Jie0 0iFrQyB/4XFB4AhVwrHMAWkZIzO4dJxAOTQv++2oIS5T9JUngVmyrypOEX5V 0aOOIeN1c8VfDvDeqGZ4W6GumOppRalHUktwGwHVKfXypDTaJvyXlhwHKLyR X+fD8XpLG04Lv9ABI04vHoz2+OjGOr14/bp7/rr8FOO4SzEN2Ptgef0ULYPi GQ+DlSguo6HAG5ODXrm602yWyYb4LGJ+RetiVMgvhEYENEeqQ09tqXvGlhu+ e6bQA6SgV0g7ZeIlUtosGA5fJy/5lOyXqrJpJulrOt1GRQ39mhLEZZaZlGU+ fxRZRSquONOWok9VmW2oK6TfWCB4YhJ1uW1muP48QbuLtMok/U2lVUZZtRQA I/h2LvgNIzFeeFO+QkGWK8UhCwUgHG3JkbmDEfsJOZnKV0gYvMlD7SVmjRhl y4GPLWV7UqHQDScKxFfySN3c26kqm7S6BjZ3Z7RXFp8heOg6Q9ipZ0dCbqly lyNo7SyjLrgo/x8ePB5NHKxwr4Edt6jHgt7LG1nKmzfVPSYswWva8pY2xn/o u1N3YsuAH8ZGTmclykT8/gwWwsipOOOxMwx84S+HNwLDe3DG1EjohxyXtVXu cpucOB5vyqb4DD3Z/CW8wBtS2WH8IRn0YZgzHcX4ymLeVG2iyU8UDw8VjfLE EeYwd72elQIdZFOBfPczdqXGX9QEXYmfywbh6YT8yngidt8QnJqNwGog4qD6 /eFKkAswi2TECpJJ5VJTPPQFAkhlU2FhjE+FBZFsgnsHjWpe8q1ozRW7n9z+ quV6Vfl7UvZnbxmoBOpx1v8Duj3gzQe6vOpM594C0xsvYVgnHMQMxQR3JvB8 VOno6oCnCJqUXXlxN5XG/GfsufGh/6bd66DcgmAYTQs0GwVx2QMh/Pte96rD gk0ChQFQUidERaGh0AoL9czflRdjTmKulk6yUOfaVreVVVZx86I/eklO5piq 3qgvc5qHeewRJgNpEcvKWL2MI8GdOFTHJUWZkeU7TNYtjzjC6ZFNV8cQKbuo nipmskTfqqV4lPsCD3TVwYRqrSIe6Mv9cl6kpsGO7dyVxYzMKGWsVRZqhkqH MbJJXQKslJO7RtoiMItjy8As0jt2bR8P2xutPJt4vG6+HbRKV4zwoxG9tPK2 eI9Jj+DPd9/BRkmZ2t90X11VatWSGWCuS7HLeMPA46WZ+Jez8PAZnzKim5Tz 3AfOHNDh/MKeiqco8z+l6sUZjPoBHUvBsiGe8lUJE3NTkm3og7Pg2+CgvX6i o3yqduPQQXyYwd6bOsoiBhMy8uQT9JgLzV/8xrnnYyjJB/HJBiVnvJyUQh+p LbyXLq8nS/83xkpVw/BXC0de2hH2GO3rnP547HySjmKqYZQUkuqi3HfNRy5h g4wXIxABnl9cdQ5U1+e2j/5XMDTKpwab9S9vxs5o1Ai5n66+khI6jvPeGL9X gpsgflroLIELDd9DETYAQn1Xz/EZPYR1TJ/qgjiQgjwThQcwEcQ+VG31Ctjr UJxSj32xKYq6h8/E61eX1j8uzjsUKu1QIUCOo2pUXtAgSKZD2y8+wF2XQDc3 DwmW/xqPS/o0GR8Af9IXfYAv8CM2Y6JGA9NRlxyIu1WTL4yMl+yM2u0/i083 yCSL6rLOZihRwYchUFFMxBuga2wEht+yyU9FFCmdqDtDIQqIzh0Hlj9ceJNJ he6C+8FyPC5RbRWOC8hluMSMkOyy6SyGwGVRChkv7Gs0DpM1YAvh1cHfAF1f cPsismT/F7mC0GcPViI3i1pEkh25wtwPHXYikMuD4wW6gTPlQIdcYSudHZKD dBoj5IIYC+SHhaulw1LAHnko7RyA3pLD/FStXF2ltSPtmPAJQgXJALhiJ2iJ gFXjB8A5iprRfw4d155srvKIpi8ygoK6RoeLgOqjB8k8WCCdwAdJ9wm3bIVA vV4K9cFCWkBIB0YqhIoYehBK6JI616u88Ab/pPg8FaLconqs5Ib+aful1euc 0AoT/yPqGy8/XKHPMajX31/0TsSBqJb4MGTiO6vfEzk3CXUH6iRROu4VTOxk KhcVJizcXNE/GZ1QNLuU3BaB/wb45wdCHWEyXg4QKm3xGVSmHCTTCE2XxWhN P09JYV3LI7ewYi7FEbmpUxDonOifXVZ8e+wob8ztOxyUbdcja35ZXKEtfSba 7p39Lxe+fBfQg7/BRuMGto/Hvi/K4sx+4Pj08j53wvYCcv/YvU435tBthZQC 7WCaVsm4iGdcUd4vt3gVLT7JQFd3U9o5iGEdid73FMTDeneOH52TwydG0BsV 70bWOcz1CGS3Kkui1xsgqYF0w5b2f3T8nVJCxzHFVGUNEiV05GQuJjaWvQSC omMVDm94qb2GDzRW2lRtIYBeKHyqG3rIkkBD2XAjuzFVgxVh4ydU63DayxWV eixDhS+uSpczwPAjN6KMSH8iaSneD9o+dNVaVtXsaqcwU9DK8PXnsBluyZZN 7cWt0bI+CUIYKNwe/rx0QciiQGRbQrQnn+wHn8WXEW8bGCEyTImtcYxcn93C 0f+HA8gO50tf3GAgYBDExAc0bOD8seM38QG8/jC2l5NAo/GGw+XCl1subj9M GVIZs2ekBDM1kKCIol2ZdkCNQkerHJJ4N7bdyVYoVAHDj9FbzFtajm/MCIHD HbVBGJR+Nz/Uli7GLC0HIMgU7+ZHciEIgIP/UdGas3VA+Yol3gUwsdizWAUp DkQr/Mox5FhFQ/jKkWChvvuPzqGkFlhb72YD1+ZolNdL9CZkI8m2rIkNLsoF 8SLzlSwyofapYL8jlSt8TIuDH2r3N7lx1KJuZvQ/bkQMBk1kv0XyrZx5arof nEBq28oTgXwQAvhVFqj1aRtJZuvFMwIPtXG1hL8TKaA4hgao6ueRmvhYhz6H O2OV98XQ1QBp0h0CoZKTHIkJ+gq4NQ+c4nw6QsFCwGeczHJc9cmeKkDMcLhy IP3r9vHa8iZexOEj3M8cU8xsA11gNO4IBCjNhniyGvGkkiBNujOQeykghZ5T KhFUpGL8BuQGuyZwpxPrQwcoqtbL+3yAXVPx93j5XJ6d8GKAR6S2hPH0jOuL h9jHiC2MfPSm0y1SuumykTKKVbQlMHSPKBqXdxWmVXhMA6Ivl4sQazaCYHOb EWJbA9dnEa5F1buiHPofqz/x2lUPQAmj37Bo2yNg9LDtjZ2FMxvS/R7SVBAD 6C+fWJ9nhcMO1M2q0KpZEnzbHZ2XitJcqvyXNplVKE9UJNQZ7F3QCg4zEfrC 0sFNp9cTT6PUzRfdYXxQX34AJQd1UnZjFhHrLft47NAC2m3Ewn5VpaZQyV9M 09FvXNCr1tHv8dp/82qkrMKbtb1dyYsKJrtC/TpQSpEiyzK3PvTvMqad51rO RqVzfnHWOaNlhgDRGS8SG9ODTTti+NMYYxzaklqCj8Ch7JYRTHwc5ZfSGwrP lIgIi0p93dScqYRGX/iOVhGChpHAJaYcc/ZQEA+PTuNUadBF8gaYeMwVsErm 7Qh5neKRZGqt354nKVEKuFGbKxqV1yrzLEnkUfL8mlfQyF0kA4ryPhLOG4tc bG9ocgoenXRCH8Kgw7g0LuVRLK/eL6PYx+GI0qrZ2nQifY2XQjWZ0i8mVBoA eTMIffobEfIkixgbWH4TgeYQBJ0m5JLiL6FUlkKDRT0yzALj4yMjOpKRI02d xeNMGdM1rjIQvugzFbMpyTCxGcozjfhlo7pbrsu9h3gfxa6VhISdwZYhfZL8 f0Q6HkvmSFvyOCTe2fdn7VNQzi34PDnpyaBHqT2XIvvj8UieWEhFVyADCMOT 2BDpS0SC5p6wcWm966RhAe9kJDpENzXTSrehXpGiu2FXIwG19YzCSBNePDEJ D0xCTe8rAvr1VwZ+IUK3zGgNXr2x7pN1+ChCUzw3788sGnBtKGRq4DFNGcMU muB6aStgxWSGE0mt5+CCZT7Olr6o8pwtMrlJQv2cZcnzQSzMMORxUcKOx48L fTvgI7NdUa8f1PZWOLnoevknxxQtcrOhg0ZGTtblwbHk3jHfElR7Xd/0/sMR Qek6LI+c9ssZJI07jgtoKM1B5re8QpB8rlL8dMlwgval4cKFXdqeCDy/o+v4 lAjJDYRH10LGqooW46GiCqYtBo6NVwLxEE8mfqPqiyf/H11kufG+1gEA --=-OMu1yQh6lhKl1fPJ4UQ5-- From owner-linux-xfs@oss.sgi.com Fri Feb 15 02:20:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FAKpt12641 for linux-xfs-outgoing; Fri, 15 Feb 2002 02:20:51 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FAKm912619 for ; Fri, 15 Feb 2002 02:20:48 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 7A4EF835FF5; Fri, 15 Feb 2002 04:21:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 7004D2800458 for ; Fri, 15 Feb 2002 04:21:36 -0500 (EST) Date: Fri, 15 Feb 2002 04:21:36 -0500 (EST) From: Mike Burger To: linux-xfs@oss.sgi.com Subject: Question...xfsdump error message? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk During my xfsdump jobs, I see this quite frequently: /usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for inode 16849570 /usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for inode 17305709 /usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for inode 17363663 /usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for inode 17363664 Can anyone tell me what it means? I was going to ask about an xfsrestore propensity to restore files with the user/group ID of the user restoring the files...then I read the man page and saw the -o option. D'oh!!! From owner-linux-xfs@oss.sgi.com Fri Feb 15 02:58:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FAwJE13505 for linux-xfs-outgoing; Fri, 15 Feb 2002 02:58:19 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FAwE913482 for ; Fri, 15 Feb 2002 02:58:14 -0800 Received: from auto-nb1.xs4all.nl (edge.coltex.nl [194.151.97.115]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1F9w9dQ044924; Fri, 15 Feb 2002 10:58:10 +0100 (CET) Message-Id: <4.3.2.7.2.20020215105453.02c43cc0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Feb 2002 10:56:00 +0100 To: Mike Burger , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Question...xfsdump error message? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 04:21 15-2-2002 -0500, Mike Burger wrote: >During my xfsdump jobs, I see this quite frequently: > >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for >inode 16849570 >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for >inode 17305709 >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for >inode 17363663 >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for >inode 17363664 > >Can anyone tell me what it means? They are harmless and can occur quite frequently on a busy filesystem during backup. XFS uses a bulkstat to get information for a lot of inodes at once to speed up the process. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Feb 15 05:05:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FD51717110 for linux-xfs-outgoing; Fri, 15 Feb 2002 05:05:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FD4t917087 for ; Fri, 15 Feb 2002 05:04:55 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id NAA2094524 for ; Fri, 15 Feb 2002 13:04:50 +0100 (CET) mail_from (ivanr@sgi.com) From: ivanr@sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA02550; Fri, 15 Feb 2002 23:03:34 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id XAA10374; Fri, 15 Feb 2002 23:03:33 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Fri, 15 Feb 2002 23:03:33 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Seth Mos cc: Mike Burger , Subject: Re: Question...xfsdump error message? In-Reply-To: <4.3.2.7.2.20020215105453.02c43cc0@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Feb 2002, Seth Mos wrote: > At 04:21 15-2-2002 -0500, Mike Burger wrote: > >During my xfsdump jobs, I see this quite frequently: > > > >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for > >inode 16849570 > >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for > >inode 17305709 > >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for > >inode 17363663 > >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for > >inode 17363664 > > > >Can anyone tell me what it means? > > They are harmless and can occur quite frequently on a busy filesystem > during backup. > > XFS uses a bulkstat to get information for a lot of inodes at once to speed > up the process. I'm starting to think that maybe I should just remove that warning ... maybe just make it a debugging message. There doesn't seem to be much point to a warning message that: . is common . is harmless . and is ignored Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 15 07:40:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FFeB825635 for linux-xfs-outgoing; Fri, 15 Feb 2002 07:40:11 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FFe5925613 for ; Fri, 15 Feb 2002 07:40:05 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA08987 for ; Fri, 15 Feb 2002 06:41:23 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA13127; Fri, 15 Feb 2002 08:38:48 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA13836; Fri, 15 Feb 2002 08:38:48 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id IAA17978; Fri, 15 Feb 2002 08:38:48 -0600 (CST) Message-Id: <200202151438.IAA17978@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI rights Date: Fri, 15 Feb 2002 08:38:47 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" > >Are you saying that rights do exist and are checked at the DMAPI level? If >so, does this mean that a DMAPI program could use rights to synchronize >between DMAPI calls but must use some other mechanism to coordinate with >non-DMAPI clients of the filesystem? > >Let me clarify a bit. Let's say that I have two DMAPI programs that want >to modify the DM attributes of the same file using the dm_set_dmattr() >call. If they both call dm_request_right() to get a DM_RIGHT_EXCL right to >the file, one will get the right while the other will block. When the >initial program finally calls dm_release_right() the second program will >get the DM_RIGHT_EXCL and continue. Is that correct? No, we don't block. You just get the vn_hold/vn_rele. The spec talks about it in terms of programs, implying processes, but it's actually meaning tokens, right? Two tokens, referring to the same file, use rights to decide which of the tokens does, or doesn't, get to be acted on. Dean From owner-linux-xfs@oss.sgi.com Fri Feb 15 08:44:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FGibW27057 for linux-xfs-outgoing; Fri, 15 Feb 2002 08:44:37 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FGiP927033 for ; Fri, 15 Feb 2002 08:44:25 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA99216; Fri, 15 Feb 2002 10:41:13 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1FFiLf66348; Fri, 15 Feb 2002 08:44:21 -0700 Subject: Re: DMAPI rights To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Fri, 15 Feb 2002 09:06:18 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/15/2002 08:44:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You are right. Each of the 'programs' I was mentioning before will have its own token. The dm_request_right() call simply asks the DMAPI to attach the requested right to the token. Any subsequent call using that token would have the right. However, I don't think it's a question of deciding who gets to do what by looking at the rights on their token. Rather its a question of whether or not the DMAPI will attach the requested right to your token or not depending on what rights are attached to other tokens for the same object. After your token has the right, you can do any operation that the right allows. -------------- I've taken a closer look at the XFS DMAPI code, and I think I've figured out how it works. There are rights involved, but like you said dm_request_right() and dm_release_right() don't attach/remove rights to/from the caller's token. Between that and the fact that tokens delivered with events never have rights attached, it is impossible for a DMAPI client to ever have rights attached to his token. This means that any DMAPI call requiring a token with rights attached must use the special DM_NO_TOKEN (I discovered this the hard way when most calls were returning EACCES). This way, each individual DMAPI call will acquire the appropriate locks (tdp locks as I recall) needed to synchronize with the other DMAPI calls. The end result is that XFS DMAPI ensures that individual DMAPI calls will not interfere with one another but that any further synchronization must be taken care of at a higher level. So our new client code implements its own locking to allow a string of DMAPI calls against a particular file while blocking any other DMAPI calls that would modify the file or its attributes. -------------- Do you have any idea how to fix the problem of the ne_mode field not returned with the remove event, or is this something that I'll have to find a workaround for? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: linux-xfs@oss.sgi.com Sent by: Subject: Re: DMAPI rights owner-linux-xfs@o ss.sgi.com 02/15/2002 08:38 AM >From: "James A Goodwin" > >Are you saying that rights do exist and are checked at the DMAPI level? If >so, does this mean that a DMAPI program could use rights to synchronize >between DMAPI calls but must use some other mechanism to coordinate with >non-DMAPI clients of the filesystem? > >Let me clarify a bit. Let's say that I have two DMAPI programs that want >to modify the DM attributes of the same file using the dm_set_dmattr() >call. If they both call dm_request_right() to get a DM_RIGHT_EXCL right to >the file, one will get the right while the other will block. When the >initial program finally calls dm_release_right() the second program will >get the DM_RIGHT_EXCL and continue. Is that correct? No, we don't block. You just get the vn_hold/vn_rele. The spec talks about it in terms of programs, implying processes, but it's actually meaning tokens, right? Two tokens, referring to the same file, use rights to decide which of the tokens does, or doesn't, get to be acted on. Dean From owner-linux-xfs@oss.sgi.com Fri Feb 15 09:39:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FHdkv31700 for linux-xfs-outgoing; Fri, 15 Feb 2002 09:39:46 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FHdg931678 for ; Fri, 15 Feb 2002 09:39:42 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 IAA11500 for ; Fri, 15 Feb 2002 08:35:17 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA14674; Fri, 15 Feb 2002 10:38:20 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA23933; Fri, 15 Feb 2002 10:38:20 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA18259; Fri, 15 Feb 2002 10:38:19 -0600 (CST) Message-Id: <200202151638.KAA18259@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI rights Date: Fri, 15 Feb 2002 10:38:19 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" >Do you have any idea how to fix the problem of the ne_mode field not >returned with the remove event, or is this something that I'll have to find >a workaround for? Here's what I've been using for now.... In xfs_remove(), where dm_send_namesp_event(DM_EVENT_REMOVE) is called, place dp->i_d.di_mode in the appropriate place in the parameter list, replacing the zero that is there now. That'll give you the info, and I suspect everything there should be fine. Our HSM doesn't use this event, so it's hard for me to see if I'm causing problems by doing this. Dean From owner-linux-xfs@oss.sgi.com Fri Feb 15 09:43:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FHhGg31837 for linux-xfs-outgoing; Fri, 15 Feb 2002 09:43:16 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FHhD931814 for ; Fri, 15 Feb 2002 09:43:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 IAA11802 for ; Fri, 15 Feb 2002 08:38:48 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA14637 for ; Fri, 15 Feb 2002 10:41:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA51946 for ; Fri, 15 Feb 2002 10:41:55 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1FGeRJ04537; Fri, 15 Feb 2002 10:40:27 -0600 Message-Id: <200202151640.g1FGeRJ04537@jen.americas.sgi.com> Date: Fri, 15 Feb 2002 10:40:27 -0600 Subject: TAKE - small optimization in setattr To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Too many access checks in here. Date: Fri Feb 15 08:39:51 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111886a linux/fs/xfs/linux/xfs_iops.c - 1.124 - Remove unneeded inode_change_ok call from setattr, we already do our own internal checking. From owner-linux-xfs@oss.sgi.com Fri Feb 15 10:34:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FIYv603972 for linux-xfs-outgoing; Fri, 15 Feb 2002 10:34:57 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FIYr903945 for ; Fri, 15 Feb 2002 10:34:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA02425 for ; Fri, 15 Feb 2002 09:36:11 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA14251 for ; Fri, 15 Feb 2002 11:33:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA23448 for ; Fri, 15 Feb 2002 11:33:35 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1FHXZJ29907; Fri, 15 Feb 2002 11:33:35 -0600 Message-Id: <200202151733.g1FHXZJ29907@stout.americas.sgi.com> Date: Fri, 15 Feb 2002 11:33:35 -0600 From: Eric Sandeen Subject: TAKE - remove unneeded test from pagebuf_delalloc_convert Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The change checked in for linvfs_pb_bmap last night takes care of this case now, no need to do it twice. Date: Fri Feb 15 09:32:13 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111895a linux/fs/xfs/pagebuf/page_buf_io.c - 1.9 - Remove unneeded test (bmap now does this ahead of this point) From owner-linux-xfs@oss.sgi.com Fri Feb 15 11:16:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FJGME06047 for linux-xfs-outgoing; Fri, 15 Feb 2002 11:16:22 -0800 Received: from mail.get2chip.com ([64.169.83.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FJGJ906025 for ; Fri, 15 Feb 2002 11:16:19 -0800 Message-ID: <3C6D506C.26EFF8A2@get2chip.com> Date: Fri, 15 Feb 2002 10:16:12 -0800 From: ccroswhite@get2chip.com Reply-To: ccroswhite@get2chip.com MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4 kernel up to date? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I am curious how up to date the 2.4 kernel is that can be checked out of oss.sgi. Being there is no patch aginst 2.4.18-rc1 yet (and dare I not ask for it), I need to know if it is remotely close to the or identical to the 2.4.18-rc1 branch of the linux kernel. TIA, Chris Croswhite Get2Chip, Inc. From owner-linux-xfs@oss.sgi.com Fri Feb 15 11:23:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FJNUF06227 for linux-xfs-outgoing; Fri, 15 Feb 2002 11:23:30 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FJNO906205 for ; Fri, 15 Feb 2002 11:23:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA03750 for ; Fri, 15 Feb 2002 10:23:21 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA15629; Fri, 15 Feb 2002 12:22:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA42695; Fri, 15 Feb 2002 12:22:06 -0600 (CST) Subject: Re: 2.4 kernel up to date? From: Eric Sandeen To: ccroswhite@get2chip.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C6D506C.26EFF8A2@get2chip.com> References: <3C6D506C.26EFF8A2@get2chip.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 12:22:06 -0600 Message-Id: <1013797326.28192.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk CVS is as up-to-date as the most recently released Linux kernel - 2.4.17. When 2.4.18 is released, CVS will be updated as quickly as possible. OTOH, the 2.4.18-rc1 patch goes into the current XFS tree fairly cleanly, so if you're feeling impatient, you might give it a shot yourself. -Eric On Fri, 2002-02-15 at 12:16, ccroswhite@get2chip.com wrote: > Hello, > > I am curious how up to date the 2.4 kernel is that can be checked out of > oss.sgi. Being there is no patch aginst 2.4.18-rc1 yet (and dare I not > ask for it), I need to know if it is remotely close to the or identical > to the 2.4.18-rc1 branch of the linux kernel. > > TIA, > Chris Croswhite > Get2Chip, Inc. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Feb 15 11:31:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FJVsQ06565 for linux-xfs-outgoing; Fri, 15 Feb 2002 11:31:54 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FJVo906541 for ; Fri, 15 Feb 2002 11:31:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1FJVjxV024665 for ; Fri, 15 Feb 2002 11:31:46 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA09726; Fri, 15 Feb 2002 12:30:29 -0600 (CST) Received: from sgi.com (sX7Xc/ikowBpp5VGfwzluV+6HIKY4MUA@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA07530; Fri, 15 Feb 2002 12:30:29 -0600 (CST) Message-ID: <3C6D53F4.30602@sgi.com> Date: Fri, 15 Feb 2002 12:31:16 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: ccroswhite@get2chip.com CC: linux-xfs@oss.sgi.com Subject: Re: 2.4 kernel up to date? References: <3C6D506C.26EFF8A2@get2chip.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ccroswhite@get2chip.com wrote: >Hello, > >I am curious how up to date the 2.4 kernel is that can be checked out of >oss.sgi. Being there is no patch aginst 2.4.18-rc1 yet (and dare I not >ask for it), I need to know if it is remotely close to the or identical >to the 2.4.18-rc1 branch of the linux kernel. > >TIA, >Chris Croswhite >Get2Chip, Inc. > The CVS tree is still 2.4.17. We will not make a 2.4.18 based kernel available until 2.4.18 actually comes out. We do have 2.4.18-pre9 running here, but we are not making things public yet, the reason being that the extended attribute/acl kernel interface will be changing in this version to use the new system calls. A new user space will be required for this so we do not want to just put this out willy nilly. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 15 11:45:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FJj1r06847 for linux-xfs-outgoing; Fri, 15 Feb 2002 11:45:01 -0800 Received: from ente.berdmann.de (frnk-d514e1e2.dsl.mediaWays.net [213.20.225.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FJir906812 for ; Fri, 15 Feb 2002 11:44:53 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16bnLh-0006dX-00; Fri, 15 Feb 2002 19:44:45 +0100 Message-ID: <3C6D571D.7F98DC7A@berdmann.de> Date: Fri, 15 Feb 2002 19:44:45 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: ivanr@sgi.com CC: Seth Mos , Mike Burger , linux-xfs@oss.sgi.com Subject: Re: Question...xfsdump error message? References: Content-Type: multipart/mixed; boundary="------------E92391A150EB28F0DD921583" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------E92391A150EB28F0DD921583 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for > > >inode 16849570 Here's my patch for Amanda 2.4.2p2 against it: --------------E92391A150EB28F0DD921583 Content-Type: text/plain; charset=us-ascii; name="amanda-sendbackup-xfs-bulkstat.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="amanda-sendbackup-xfs-bulkstat.diff" --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup-dump.c Sat Oct 20 15:59:20 2001 +++ amanda-2.4.2p2-20011020/client-src/sendbackup-dump.c Sun Jan 27 11:56:18 2002 @@ -97,6 +97,10 @@ { DMP_SIZE, "xfsdump: media file size [0-9][0-9]* bytes", 1}, /* Irix 6.2 xfs dump */ + /* warnings to be ignored */ + { DMP_WARNING, "^xfsdump: WARNING: failed to get valid bulkstat information for inode" }, /* Linux xfsdump */ + { DMP_WARNING, "^xfsdump: WARNING: failed to get bulkstat information for inode" }, /* Linux xfsdump */ + /* strange dump lines */ { DMP_STRANGE, "should not happen" }, { DMP_STRANGE, "Cannot open" }, --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup.c Sat Oct 20 15:59:20 2001 +++ amanda-2.4.2p2-20011020/client-src/sendbackup.c Sun Jan 27 11:51:50 2002 @@ -755,6 +755,7 @@ switch(typ) { case DMP_NORMAL: case DMP_SIZE: + case DMP_WARNING: startchr = '|'; break; default: --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup.h Sat May 27 23:20:32 2000 +++ amanda-2.4.2p2-20011020/client-src/sendbackup.h Sun Jan 27 11:51:50 2002 @@ -53,7 +53,7 @@ */ typedef enum { - DMP_NORMAL, DMP_STRANGE, DMP_SIZE, DMP_ERROR + DMP_NORMAL, DMP_WARNING, DMP_STRANGE, DMP_SIZE, DMP_ERROR } dmpline_t; typedef struct regex_s { --------------E92391A150EB28F0DD921583-- From owner-linux-xfs@oss.sgi.com Fri Feb 15 12:40:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FKe1D07976 for linux-xfs-outgoing; Fri, 15 Feb 2002 12:40:01 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FKdw907952 for ; Fri, 15 Feb 2002 12:39:58 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA03746 for ; Fri, 15 Feb 2002 11:41:16 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA16657 for ; Fri, 15 Feb 2002 13:38:42 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA74913 for ; Fri, 15 Feb 2002 13:38:41 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1FJbBr10122; Fri, 15 Feb 2002 13:37:11 -0600 Message-Id: <200202151937.g1FJbBr10122@jen.americas.sgi.com> Date: Fri, 15 Feb 2002 13:37:11 -0600 Subject: TAKE - minor code cleanup - use constants when we have them To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Feb 15 11:37:58 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111913a linux/fs/xfs/xfs_vfsops.c - 1.335 - Use XFS_EFI_MAX_FAST_EXTENTS and XFS_EFD_MAX_FAST_EXTENTS rather than a hard coded constant. From owner-linux-xfs@oss.sgi.com Fri Feb 15 12:49:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FKnAI08541 for linux-xfs-outgoing; Fri, 15 Feb 2002 12:49:10 -0800 Received: from amsfep13-int.chello.nl (amsfep13-int.chello.nl [213.46.243.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FKn1908519 for ; Fri, 15 Feb 2002 12:49:01 -0800 Received: from ancalagon ([212.187.7.111]) by amsfep13-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with SMTP id <20020215194854.DCMD13478.amsfep13-int.chello.nl@ancalagon> for ; Fri, 15 Feb 2002 20:48:54 +0100 Message-ID: <003101c1b659$6d97e420$6f07bbd4@vesc> From: "Esger Abbink" To: References: Subject: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) Date: Fri, 15 Feb 2002 20:46:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk the drive is a tandberg SLR the -q parameter did the trick though, maybe its time to document it? new problem: how do i get xfsdump to compress stuff? ----- Original Message ----- From: Mike Burger To: Cc: Sent: Thursday, February 14, 2002 3:29 AM Subject: Re: xfsdump aborts after assertion failure > Hi, Esger. > > I just went through the same thing. > > Is the tape drive a QIC drive (TR-something)? > > If so, try using the -q parameter, instead of the -b (-q is/was previously > undocumented), and see how you make out. > > On Wed, 13 Feb 2002, E. Abbink wrote: > > > Hi, > > > > i have a problem dumping my xfs filesystem. > > > > setup: > > 2.4.17 stock kernel patched with latest(1.0.2) xfs and various (suse) > > patches. > > xfsdump & xfsprogs are downloaded latest versions as well. > > xfs filesystem mounted in root reiser filesystem. xfs filesystem is a > > LVM on MD raid1. > > backup device is a tandberg slr24 on a adaptec 78xx. > > > > when i try to backup a test directory on the xfs filesystem with the > > following command: > > > > xfsdump -o -m -b 1024 -f /dev/st0 -s backup_test /fsdata > > > > i get the following assertion: > > > > .. > > xfsdump: dumping ino map > > xfsdump: drive_minrmt.c:1862: do_get_write_buf: Assertion > > 'contextp->dc_nextp < contextp->dc_recendp' failed. > > Aborted > > > > Note that the Aborted line does not _immediately_ follow the assertion > > line, some time passes. > > > > If anyone could shed any light on this that would be very helpful as i'm > > kinda stumped atm. > > > > Esger > > > > > From owner-linux-xfs@oss.sgi.com Fri Feb 15 13:57:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FLvxu13055 for linux-xfs-outgoing; Fri, 15 Feb 2002 13:57:59 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FLvp913028 for ; Fri, 15 Feb 2002 13:57:51 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA07078 for ; Fri, 15 Feb 2002 12:59:09 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA16424 for ; Fri, 15 Feb 2002 14:56:34 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA18149 for ; Fri, 15 Feb 2002 14:56:34 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1FKt4x10539; Fri, 15 Feb 2002 14:55:04 -0600 Message-Id: <200202152055.g1FKt4x10539@jen.americas.sgi.com> Date: Fri, 15 Feb 2002 14:55:04 -0600 Subject: TAKE - reduce synchronous transaction use in xfs To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This removes the synchronous transactions from the delete path in XFS. This work was mostly done by Glen Overby, I am just putting the code into the Linux tree here. I have been running this code on my workstation for several weeks without problems, it has also been in pretty much every kernel I have run stress tests on for the last month, it appears very solid now. This was long thought to be the sole cause of slower delete speed in XFS, this turns out not to be the case, it does help delete speed, but if you go and delete 30000 files in one go it will not make a large difference for you. That issue is the next thing being tackled. This will certainly help SOME of the cases of files full of NULLs after a crash as one way this happened was a synchronous transaction forcing an inode modification out to the disk with a new size before the data was written out. Steve Date: Fri Feb 15 12:47:53 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111915a linux/fs/xfs/xfsidbg.c - 1.172 - Add dumping of new perag structures linux/fs/xfs/xfs_ag.h - 1.41 - Add a per-AG busy list (xfs_perag_busy_t). linux/fs/xfs/xfs_trans_priv.h - 1.18 - Prototypes for busy list management. linux/fs/xfs/xfs_trans_item.c - 1.29 - Transaction busy list management (add, free). linux/fs/xfs/xfs_mount.c - 1.269 - Break up perag structure allocation - it gets too large for big filesystems with the new code. linux/fs/xfs/xfs_inode.c - 1.326 - Remove setting of synchronous transactions where they can be replaced by using the busy list. linux/fs/xfs/xfs_trans.c - 1.129 - Add to each transaction a list of per-AG busy list entries. When the transaction commits, clear those entries. linux/fs/xfs/xfs_trans.h - 1.110 - Add to the transaction structure a list of per-AG busy list entries. linux/fs/xfs/xfs_alloc.c - 1.145 - er-AG busy list management. Search per-AG busy list on allocation, remove setting of synchronous transactions where the busy list will take over. Mark removed blocks in the busy list. linux/fs/xfs/xfs_alloc.h - 1.50 - Prototypes for per-AG busy list management & busy list ktrace definitions. linux/fs/xfs/xfs_bmap.c - 1.280 - Remove setting of synchronous transactions where they can be replaced by using the busy list. From owner-linux-xfs@oss.sgi.com Fri Feb 15 13:58:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FLwhu13141 for linux-xfs-outgoing; Fri, 15 Feb 2002 13:58:43 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FLwd913119 for ; Fri, 15 Feb 2002 13:58:39 -0800 Received: (qmail 2625 invoked by uid 1000); 15 Feb 2002 21:04:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Feb 2002 21:04:37 -0000 Date: Fri, 15 Feb 2002 23:04:37 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: RAID5 internal log question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi >From the XFS FAQ and other threads on this list I understand that is recommended to have the log of an XFS partition out of a RAID5. Is that performance impact that bad also with hardware RAID ? Because its rather strange to make that external log reside out of the RAID with hardware RAID (I have to reboot and use the BIOS configuration tool to setup another logical device which should not be RAID5 just only for the XFS log). Thanks ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Fri Feb 15 14:20:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FMKe613765 for linux-xfs-outgoing; Fri, 15 Feb 2002 14:20:40 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FMKa913743 for ; Fri, 15 Feb 2002 14:20:36 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16bpmU-00076Q-00; Fri, 15 Feb 2002 16:20:34 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g1FLKWX16482; Fri, 15 Feb 2002 16:20:32 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Mihai RUSU Cc: Linux XFS List Subject: Re: RAID5 internal log question References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 15 Feb 2002 16:20:32 -0500 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Mihai" == Mihai RUSU writes: Mihai> From the XFS FAQ and other threads on this list I understand Mihai> that is recommended to have the log of an XFS partition out of Mihai> a RAID5. Is that performance impact that bad also with hardware Mihai> RAID ? No. Only with Linux Software RAID5 because of the way it does stripe caching. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Feb 15 14:23:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FMNce13945 for linux-xfs-outgoing; Fri, 15 Feb 2002 14:23:38 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FMNY913923 for ; Fri, 15 Feb 2002 14:23:34 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA48900; Fri, 15 Feb 2002 16:20:19 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1FLNMf125598; Fri, 15 Feb 2002 14:23:22 -0700 Subject: dm_handle_to_path To: roehrich@sgi.com Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Fri, 15 Feb 2002 15:23:20 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/15/2002 02:23:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, I've found another one. The dm_handle_to_path() call gives an EBADF any time you supply the same directory handle for both the directory and target arguments. I've looked at the libdm code and the introductory comments indicate that this specific situation was foreseen and specifically designed to work. I'm making the call just after receiving a remove event. I'm trying to convert the file handle for the parent directory of the object into a pathname. I can then append the name of the file to the returned directory path for use in a dm_path_to_handle() call to get the handle for the object. Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Fri Feb 15 14:26:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FMQpm14096 for linux-xfs-outgoing; Fri, 15 Feb 2002 14:26:51 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FMQk914074 for ; Fri, 15 Feb 2002 14:26:46 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1FLQUc17177; Fri, 15 Feb 2002 15:26:30 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: RAID5 internal log question From: Austin Gonyou To: Mihai RUSU Cc: Linux XFS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 15:26:30 -0600 Message-Id: <1013808390.16590.9.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You could potentially exacerbate an IO issue, even with HW RAID, when running in a degraded mode(failed drive) or during a rebuild.The outer logging, if on a mirror, would be able to provide good through put and ensure you don't have too many problems. On Fri, 2002-02-15 at 15:04, Mihai RUSU wrote: > Hi > > >From the XFS FAQ and other threads on this list I understand that is > recommended to have the log of an XFS partition out of a RAID5. Is that > performance impact that bad also with hardware RAID ? > Because its rather strange to make that external log reside out of the > RAID with hardware RAID (I have to reboot and use the BIOS configuration > tool to setup another logical device which should not be RAID5 just only > for the XFS log). > > Thanks > > ---------------------------- > Mihai RUSU > "... and what if this is as good as it gets ?" -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Fri Feb 15 14:36:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FMabl14286 for linux-xfs-outgoing; Fri, 15 Feb 2002 14:36:37 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FMaX914264 for ; Fri, 15 Feb 2002 14:36:33 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-239.quicknet.nl [212.58.163.239]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1FLaRLg079914; Fri, 15 Feb 2002 22:36:31 +0100 (CET) Message-Id: <4.3.2.7.2.20020215223304.036f5cd0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Feb 2002 22:34:17 +0100 To: Mihai RUSU , Linux XFS List From: Seth Mos Subject: Re: RAID5 internal log question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:04 15-2-2002 +0200, Mihai RUSU wrote: >Hi > > From the XFS FAQ and other threads on this list I understand that is >recommended to have the log of an XFS partition out of a RAID5. Is that >performance impact that bad also with hardware RAID ? >Because its rather strange to make that external log reside out of the >RAID with hardware RAID (I have to reboot and use the BIOS configuration >tool to setup another logical device which should not be RAID5 just only >for the XFS log). Just with software raid. Most hardware raid controllers have cache onboard which will make it far less noticeable. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Feb 15 14:56:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FMugX14618 for linux-xfs-outgoing; Fri, 15 Feb 2002 14:56:42 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FMuW914596 for ; Fri, 15 Feb 2002 14:56:32 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1FMuQxV002330 for ; Fri, 15 Feb 2002 14:56:27 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA18110; Fri, 15 Feb 2002 15:55:07 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA73107; Fri, 15 Feb 2002 15:55:07 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA12915; Fri, 15 Feb 2002 15:55:07 -0600 (CST) Message-Id: <200202152155.PAA12915@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path Date: Fri, 15 Feb 2002 15:55:06 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" >Dean, > >I've found another one. > >The dm_handle_to_path() call gives an EBADF any time you supply the same >directory handle for both the directory and target arguments. I've looked >at the libdm code and the introductory comments indicate that this specific >situation was foreseen and specifically designed to work. > >I'm making the call just after receiving a remove event. I'm trying to >convert the file handle for the parent directory of the object into a >pathname. I can then append the name of the file to the returned directory >path for use in a dm_path_to_handle() call to get the handle for the >object. Sure, here's an old note I have on that. I'm still amazed that handle_to_path exists. Should never have been in the spec, if you ask me :) What are you going to do when someone mounts the filesystem on multiple mount points? Or does a bind mount? Are you trying to keep track of the path, or are you just using it temporarily? Dean ----------- > >Subject: RE: using dmapi to sync filesystems (was using xfsdump...) >From: Matthijs van der Klip >Date: Thu, 13 Dec 2001 17:08:44 +0100 >To: "'Dean Roehrich'" >From matthijs.van.der.klip@nos.nl Thu Dec 13 10: 06:11 2001 > >This message is in MIME format. Since your mail reader does not understand >this format, some or all of this message may not be legible. > >------_=_NextPart_001_01C183F0.71F8D1AA >Content-Type: text/plain; > charset="iso-8859-1" > >>I'll take a look at it. > >I just took a look for myself and it looks like all this is >unimplemented: > >from dm_handle_to_path: > > if (dm_handle_to_ino(targhanp, targhlen, &ino)) > return -1; /* leave errno set from dm_handle_to_ino */ > >from dm_handle_to_ino: > > if (parse_handle(hanp, hlen, NULL, inop, NULL) == DM_HANDLE_FILE) > return(0); > errno = EBADF; > return(-1); > > >Function dm_handle_to_path uses function dm_handle_to_ino which always >returns a 'bad file descriptor' error. > > >Best regards, > >Matthijs van der Klip > > From owner-linux-xfs@oss.sgi.com Fri Feb 15 14:58:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FMw7b14766 for linux-xfs-outgoing; Fri, 15 Feb 2002 14:58:07 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FMw1914737 for ; Fri, 15 Feb 2002 14:58:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1FMvrxV002426 for ; Fri, 15 Feb 2002 14:57:56 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA18097 for ; Fri, 15 Feb 2002 15:56:37 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA04500 for ; Fri, 15 Feb 2002 15:56:37 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1FLubk02222; Fri, 15 Feb 2002 15:56:37 -0600 Message-Id: <200202152156.g1FLubk02222@stout.americas.sgi.com> Date: Fri, 15 Feb 2002 15:56:37 -0600 From: Eric Sandeen Subject: TAKE - repair xfs_repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk xfs_repair was in somewhat bad shape, so: xfsprogs-1.3.19 (15 February 2002) - fix xfs_repair option parsing for external logs - add xfs_repair option parsing for realtime device - fix xfs_repair version (-V) option - should not require an argument - add -L, -V, and -r arguments to usage string - document verbose (-v) and -r options in manpage Date: Fri Feb 15 13:54:14 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:111936a cmd/xfsprogs/VERSION - 1.40 - Bump version cmd/xfsprogs/doc/CHANGES - 1.53 - Document changes cmd/xfsprogs/man/man8/xfs_repair.8 - 1.4 - Add documentation for -v and -r cmd/xfsprogs/repair/init.c - 1.3 - set up realtime device if one is specified cmd/xfsprogs/repair/globals.h - 1.4 - add variables for realtime device argument cmd/xfsprogs/repair/xfs_repair.c - 1.4 - Add -L, -v, and -r arguments to usage string Fix -V argument parsing - it doesn't take a option handle -r realtime device argument From owner-linux-xfs@oss.sgi.com Fri Feb 15 15:17:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FNH4K15171 for linux-xfs-outgoing; Fri, 15 Feb 2002 15:17:04 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FNH0915148 for ; Fri, 15 Feb 2002 15:17:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1FNGsxV003336 for ; Fri, 15 Feb 2002 15:16:54 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA17898 for ; Fri, 15 Feb 2002 16:15:38 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA57472 for ; Fri, 15 Feb 2002 16:15:37 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1FMFbk02382; Fri, 15 Feb 2002 16:15:37 -0600 Message-Id: <200202152215.g1FMFbk02382@stout.americas.sgi.com> Date: Fri, 15 Feb 2002 16:15:37 -0600 From: Eric Sandeen Subject: TAKE - fix handling of bogus log, rt mount opts Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk doing something like: (note the misspelled device) $ mount -o rtdev=/dev/sad3 /dev/sda2 /mnt/sda2/ will blow up; when we go look for the device we get a negative dentry from a previous failed lookup, and just carry on, which will lead to a null pointer dereference... boom. Make sure we return an error in this case, before we blow up! Date: Fri Feb 15 14:11:02 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111941a linux/fs/xfs/linux/xfs_super.c - 1.156 - Watch out for negative dentries when looking up log, rtdev devices from mount options. From owner-linux-xfs@oss.sgi.com Fri Feb 15 15:52:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FNqA615499 for linux-xfs-outgoing; Fri, 15 Feb 2002 15:52:10 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FNq4915476 for ; Fri, 15 Feb 2002 15:52:04 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08970 for ; Fri, 15 Feb 2002 14:53:22 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA18404 for ; Fri, 15 Feb 2002 16:50:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA79198 for ; Fri, 15 Feb 2002 16:50:46 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1FMokw05049; Fri, 15 Feb 2002 16:50:46 -0600 Message-Id: <200202152250.g1FMokw05049@stout.americas.sgi.com> Date: Fri, 15 Feb 2002 16:50:46 -0600 From: Eric Sandeen Subject: TAKE - make "osyncisdsync" the default Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "osyncisdsync" makes us go faster, and it's how other Linux filesystems are set up, anyway - so make it the default. If you don't want this behavior, use the aptly-named "osyncisosync" option to get "true" (but slower) o_sync. "osyncisdsync" is still accepted as a mount option, but it's a no-op now. Date: Fri Feb 15 14:48:36 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111946a linux/fs/xfs/xfs_vfsops.c - 1.336 - replace XFSMNT_OSYNCISDSYNC handling with XFSMNT_OSYNCISOSYNC linux/fs/xfs/xfs_clnt.h - 1.26 linux/fs/xfs/xfs_mount.h - 1.133 - new XFSMNT_OSYNCISOSYNC flag (replaces XFSMNT_OSYNCISDSYNC) linux/fs/xfs/linux/xfs_lrw.c - 1.122 - Make osyncisdsync the default, osyncisosync (XFS_MOUNT_OSYNCISOSYNC) overrides. linux/fs/xfs/linux/xfs_super.c - 1.157 - Handle new osyncisosync mount option, osyncisdsync is the default, so handling it is a no-op. From owner-linux-xfs@oss.sgi.com Fri Feb 15 16:06:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G06xr15883 for linux-xfs-outgoing; Fri, 15 Feb 2002 16:06:59 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G06q915860 for ; Fri, 15 Feb 2002 16:06:52 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g1FN65d03936; Fri, 15 Feb 2002 17:06:05 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: RAID5 internal log question From: Austin Gonyou To: Seth Mos Cc: Mihai RUSU , Linux XFS List In-Reply-To: <4.3.2.7.2.20020215223304.036f5cd0@pop.xs4all.nl> References: <4.3.2.7.2.20020215223304.036f5cd0@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 17:06:04 -0600 Message-Id: <1013814364.16590.12.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I disagree a little bit. If you have poor hardware, or "low-cost" hardware pushing your RAID subsystem, then I'd say you will have bad IO in these instances. In general, if you buy decent hardware, there shouldn't be a problem with this, some caching RAID controllers though, still use simms, and from experience, perform way slower than the newer ones with DIMMs(PC100, etc). On Fri, 2002-02-15 at 15:34, Seth Mos wrote: > At 23:04 15-2-2002 +0200, Mihai RUSU wrote: > >Hi > > > > From the XFS FAQ and other threads on this list I understand that is > >recommended to have the log of an XFS partition out of a RAID5. Is that > >performance impact that bad also with hardware RAID ? > >Because its rather strange to make that external log reside out of the > >RAID with hardware RAID (I have to reboot and use the BIOS > configuration > >tool to setup another logical device which should not be RAID5 just > only > >for the XFS log). > > Just with software raid. Most hardware raid controllers have cache > onboard > which will make it far less noticeable. > > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Fri Feb 15 16:16:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G0GIx16078 for linux-xfs-outgoing; Fri, 15 Feb 2002 16:16:18 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G0GD916056 for ; Fri, 15 Feb 2002 16:16:13 -0800 Received: from nowaydude.rearden.com ([64.160.169.126] helo=zip.com.au) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16braN-0002LD-00; Fri, 15 Feb 2002 23:16:11 +0000 Message-ID: <3C6D9686.5444468A@zip.com.au> Date: Fri, 15 Feb 2002 15:15:18 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-rc1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: "linux-xfs@oss.sgi.com" Subject: Re: TAKE - make "osyncisdsync" the default References: <200202152250.g1FMokw05049@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > "osyncisdsync" makes us go faster, and it's how other Linux > filesystems are set up, anyway - so make it the default. > The comment lies :) /* For now, when the user asks for O_SYNC, we'll actually * provide O_DSYNC. */ if (status >= 0) { if ((file->f_flags & O_SYNC) || IS_SYNC(inode)) status = generic_osync_inode(inode, OSYNC_METADATA|OSYNC_DATA); } On other filesystems, O_SYNC writes actually sync both metadata and data, as well as the inode, if i_size changed. For default behaviour I suggest the best semantics are for an O_SYNC write to guarantee that the written data will be available after a crash. From owner-linux-xfs@oss.sgi.com Fri Feb 15 16:36:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G0aT316327 for linux-xfs-outgoing; Fri, 15 Feb 2002 16:36:29 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G0aF916305 for ; Fri, 15 Feb 2002 16:36:15 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1G0aAxV006222 for ; Fri, 15 Feb 2002 16:36:10 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA18790; Fri, 15 Feb 2002 17:34:53 -0600 (CST) Received: from sgi.com (8k/rpedKZiBlGS3MMmYOixlToORcwMAu@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA31909; Fri, 15 Feb 2002 17:34:52 -0600 (CST) Message-ID: <3C6D9B4A.2000601@sgi.com> Date: Fri, 15 Feb 2002 17:35:38 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Andrew Morton CC: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: TAKE - make "osyncisdsync" the default References: <200202152250.g1FMokw05049@stout.americas.sgi.com> <3C6D9686.5444468A@zip.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Morton wrote: >Eric Sandeen wrote: > >>"osyncisdsync" makes us go faster, and it's how other Linux >>filesystems are set up, anyway - so make it the default. >> > >The comment lies :) > > /* For now, when the user asks for O_SYNC, we'll actually > * provide O_DSYNC. */ > if (status >= 0) { > if ((file->f_flags & O_SYNC) || IS_SYNC(inode)) > status = generic_osync_inode(inode, OSYNC_METADATA|OSYNC_DATA); > } > >On other filesystems, O_SYNC writes actually sync both metadata >and data, as well as the inode, if i_size changed. > >For default behaviour I suggest the best semantics are for >an O_SYNC write to guarantee that the written data will be >available after a crash. > Ah, but we do not go there: /* Handle various SYNC-type writes */ if (ioflags & O_SYNC) { /* Flush all inode data buffers */ error = -fsync_inode_buffers(ip); if (error) goto out; /* * If we're treating this as O_DSYNC and we have not updated the * size, force the log. */ if (!(mp->m_flags & XFS_MOUNT_OSYNCISOSYNC) && !(xip->i_update_size)) { /* * If an allocation transaction occurred * without extending the size, then we have to force * the log up the proper point to ensure that the * allocation is permanent. We can't count on * the fact that buffered writes lock out direct I/O * writes - the direct I/O write could have extended * the size nontransactionally, then finished before * we started. xfs_write_file will think that the file * didn't grow but the update isn't safe unless the * size change is logged. * * Force the log if we've committed a transaction * against the inode or if someone else has and * the commit record hasn't gone to disk (e.g. * the inode is pinned). This guarantees that * all changes affecting the inode are permanent * when we return. */ xfs_inode_log_item_t *iip; xfs_lsn_t lsn; iip = xip->i_itemp; if (iip && iip->ili_last_lsn) { lsn = iip->ili_last_lsn; xfs_log_force(mp, lsn, XFS_LOG_FORCE | XFS_LOG_SYNC); } else if (xfs_ipincount(xip) > 0) { xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE | XFS_LOG_SYNC); } } else { /* * O_SYNC or O_DSYNC _with_ a size update are handled * the same way. * * If the write was synchronous then we need to make * sure that the inode modification time is permanent. * We'll have updated the timestamp above, so here * we use a synchronous transaction to log the inode. * It's not fast, but it's necessary. * * If this a dsync write and the size got changed * non-transactionally, then we need to ensure that * the size change gets logged in a synchronous * transaction. */ tp = xfs_trans_alloc(mp, XFS_TRANS_WRITE_SYNC); if ((error = xfs_trans_reserve(tp, 0, XFS_SWRITE_LOG_RES(mp), 0, 0, 0))) { /* Transaction reserve failed */ xfs_trans_cancel(tp, 0); } else { /* Transaction reserve successful */ xfs_ilock(xip, XFS_ILOCK_EXCL); xfs_trans_ijoin(tp, xip, XFS_ILOCK_EXCL); xfs_trans_ihold(tp, xip); xfs_trans_log_inode(tp, xip, XFS_ILOG_CORE); xfs_trans_set_sync(tp); error = xfs_trans_commit(tp, 0, (xfs_lsn_t)0); xfs_iunlock(xip, XFS_ILOCK_EXCL); } } From owner-linux-xfs@oss.sgi.com Fri Feb 15 16:45:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G0jO816501 for linux-xfs-outgoing; Fri, 15 Feb 2002 16:45:24 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G0jJ916479 for ; Fri, 15 Feb 2002 16:45:19 -0800 Received: from nowaydude.rearden.com ([64.160.169.126] helo=zip.com.au) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16bs2X-0003HS-00; Fri, 15 Feb 2002 23:45:17 +0000 Message-ID: <3C6D9D57.FA92EA6A@zip.com.au> Date: Fri, 15 Feb 2002 15:44:23 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-rc1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord CC: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: TAKE - make "osyncisdsync" the default References: <200202152250.g1FMokw05049@stout.americas.sgi.com> <3C6D9686.5444468A@zip.com.au> <3C6D9B4A.2000601@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen Lord wrote: > > Andrew Morton wrote: > > >Eric Sandeen wrote: > > > >>"osyncisdsync" makes us go faster, and it's how other Linux > >>filesystems are set up, anyway - so make it the default. > >> > > > >The comment lies :) > > > > /* For now, when the user asks for O_SYNC, we'll actually > > * provide O_DSYNC. */ > > if (status >= 0) { > > if ((file->f_flags & O_SYNC) || IS_SYNC(inode)) > > status = generic_osync_inode(inode, OSYNC_METADATA|OSYNC_DATA); > > } > > > >On other filesystems, O_SYNC writes actually sync both metadata > >and data, as well as the inode, if i_size changed. > > > >For default behaviour I suggest the best semantics are for > >an O_SYNC write to guarantee that the written data will be > >available after a crash. > > > > Ah, but we do not go there: > Now I'm lost. Eric's commit message seems to indicate that other filesystems do not sync metadata with O_SYNC, which isn't the case. What is the proposed XFS behaviour with O_SYNC?? Thanks. From owner-linux-xfs@oss.sgi.com Fri Feb 15 17:03:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G139x16833 for linux-xfs-outgoing; Fri, 15 Feb 2002 17:03:09 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G134916811 for ; Fri, 15 Feb 2002 17:03:04 -0800 Received: (qmail 18374 invoked by uid 1000); 16 Feb 2002 00:09:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Feb 2002 00:09:04 -0000 Date: Sat, 16 Feb 2002 02:09:04 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: old problem, gcc problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi There was a discussion on this list about a DAC960 crash happening in rare ocasions with the following configuration: SMP, HIGHMEM, DAC960 and RH kernels 2.4.9-13 (SGI_XFS_1.0.2 too). This has the bugid http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56603 . Now redhat says the last errata kernel release 2.4.9-21 fixes this bug (at least in their labs). Also they said that me using egcs 2.91.66 to compile this kernels (yes I used the custom version) could run into more trouble couse the recommended gcc version to compile 2.4.9-21 is 2.95.3 as per Documentation/Changes. AFAIK SGI recommends egcs 2.91.66 to compile Release 1.0.2. I want to try out 2.4.9-21 which I know they are contributed but should be fine as long as they have the exactly same XFS bits as 2.4.9-13 (whioch I consider it pretty stable). But I don't know hich compiler version to use ?! Thanks PS: thanks for the hardware RAID5 tips :) ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Fri Feb 15 18:47:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G2ljj18707 for linux-xfs-outgoing; Fri, 15 Feb 2002 18:47:45 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G2la918683 for ; Fri, 15 Feb 2002 18:47:36 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1G2lVxV009629 for ; Fri, 15 Feb 2002 18:47:31 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA19183; Fri, 15 Feb 2002 19:46:14 -0600 (CST) Received: from sgi.com (ScuO6RKBQWsHEYewRIUkQ4belaLILXuP@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id TAA27545; Fri, 15 Feb 2002 19:46:14 -0600 (CST) Message-ID: <3C6DBA11.5040701@sgi.com> Date: Fri, 15 Feb 2002 19:46:57 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Andrew Morton CC: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: TAKE - make "osyncisdsync" the default References: <200202152250.g1FMokw05049@stout.americas.sgi.com> <3C6D9686.5444468A@zip.com.au> <3C6D9B4A.2000601@sgi.com> <3C6D9D57.FA92EA6A@zip.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Morton wrote: >Stephen Lord wrote: > >>Andrew Morton wrote: >> >>>Eric Sandeen wrote: >>> >>>>"osyncisdsync" makes us go faster, and it's how other Linux >>>>filesystems are set up, anyway - so make it the default. >>>> >>>The comment lies :) >>> >>> /* For now, when the user asks for O_SYNC, we'll actually >>> * provide O_DSYNC. */ >>> if (status >= 0) { >>> if ((file->f_flags & O_SYNC) || IS_SYNC(inode)) >>> status = generic_osync_inode(inode, OSYNC_METADATA|OSYNC_DATA); >>> } >>> >>>On other filesystems, O_SYNC writes actually sync both metadata >>>and data, as well as the inode, if i_size changed. >>> >>>For default behaviour I suggest the best semantics are for >>>an O_SYNC write to guarantee that the written data will be >>>available after a crash. >>> >>Ah, but we do not go there: >> > >Now I'm lost. Eric's commit message seems to indicate that >other filesystems do not sync metadata with O_SYNC, which >isn't the case. > >What is the proposed XFS behaviour with O_SYNC?? > >Thanks. > File data is always pushed out to disk. Basically, if we did not update the inode size during this write then the last transaction which affected the inode is flushed out to the on disk log. If the inode size was changed by the write then a new transaction is created with the inode in it and flushed out to disk immediately. The difference between the two behaviors is in the old default we always do the transaction at the end of the write. The only consequence is that the inode timestamps are not forced out to disk as part of each and every write. Having the last transaction which modified the inode forced out to disk makes all the metadata associated with the write safe. So the only 'metadata' affected by this change is the inode timestamps, this is actually the default behavior on a number of unix implementations. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 15 22:30:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G6Uxh23485 for linux-xfs-outgoing; Fri, 15 Feb 2002 22:30:59 -0800 Received: from sera.symmetry.symmsys.com (usr49@[216.51.91.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G6Uo923463 for ; Fri, 15 Feb 2002 22:30:51 -0800 Received: from sera (sera [127.0.0.1]) by sera.symmetry.symmsys.com (Postfix) with ESMTP id CD9572155D6 for ; Fri, 15 Feb 2002 22:26:37 -0500 (EST) Subject: How do I apply the CVS xfs patch? From: Francis Yom To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 22:26:37 -0500 Message-Id: <1013829997.5938.15.camel@sera> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I would like to apply the CVS patch to 2.4.17. Specifically ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4 But when I unpack and look at it, it contains all kinds of stuff that is not -i386 related. So patch -p1 < has all kinds of failures. So how do I apply this for the -i386 2.4.17 tree? Thanks! Francis > Date: Wed Jan 30 12:55:07 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:110651a > linux/fs/buffer.c - 1.100 > - Fix up return values used in xfs writepage call, plus a couple > of other tweaks. > > linux/fs/xfs/linux/xfs_iops.c - 1.120 > - Fix up return values used in xfs writepage > > linux/fs/xfs/pagebuf/page_buf_io.c - 1.5 > - No longer return a count of pages written in the write full page > path, > and ensure that we write out pages passed into writepage from the > mmap path. There is a patch against 2.4.17 which was made on Feb 10th: ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4 .17-xfs-2002-02-10.cvs-patch.bz2 Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software From owner-linux-xfs@oss.sgi.com Fri Feb 15 22:53:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G6rQl23698 for linux-xfs-outgoing; Fri, 15 Feb 2002 22:53:26 -0800 Received: from ente.berdmann.de (frnk-d514e1de.dsl.mediaWays.net [213.20.225.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G6rM923676 for ; Fri, 15 Feb 2002 22:53:23 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16bxmd-0005ZA-00; Sat, 16 Feb 2002 06:53:15 +0100 Message-ID: <3C6DF3CB.834DA82F@berdmann.de> Date: Sat, 16 Feb 2002 06:53:15 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Esger Abbink CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) References: <003101c1b659$6d97e420$6f07bbd4@vesc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > how do i get xfsdump to compress stuff? 1. use hardware compression 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k From owner-linux-xfs@oss.sgi.com Fri Feb 15 23:11:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G7BqT24054 for linux-xfs-outgoing; Fri, 15 Feb 2002 23:11:52 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G7Bh924032 for ; Fri, 15 Feb 2002 23:11:43 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id GAA2079992 for ; Sat, 16 Feb 2002 06:46:34 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA74483; Fri, 15 Feb 2002 21:46:01 -0800 (PST) Date: Fri, 15 Feb 2002 23:46:00 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Francis Yom cc: Subject: Re: How do I apply the CVS xfs patch? In-Reply-To: <1013829997.5938.15.camel@sera> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The CVS patch will patch a linux/ tree, and create a cmd/ tree, so do something like this: $ mkdir cvs $ cd cvs $ tar xvzf linux-2.4.17.gz $ ls linux/ $ patch -p0 < /path/to/linux-xfs-cvs.patch $ ls linux/ cmd/ On 15 Feb 2002, Francis Yom wrote: > Hi, > > I would like to apply the CVS patch to 2.4.17. Specifically > ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4 > > But when I unpack and look at it, it contains all kinds of stuff that > is not -i386 related. So patch -p1 < has all kinds of > failures. > > So how do I apply this for the -i386 2.4.17 tree? > > Thanks! > Francis > > > > > > Date: Wed Jan 30 12:55:07 PST 2002 > > Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > > > Modid: 2.4.x-xfs:slinx:110651a > > linux/fs/buffer.c - 1.100 > > - Fix up return values used in xfs writepage call, plus a couple > > of other tweaks. > > > > linux/fs/xfs/linux/xfs_iops.c - 1.120 > > - Fix up return values used in xfs writepage > > > > linux/fs/xfs/pagebuf/page_buf_io.c - 1.5 > > - No longer return a count of pages written in the write full page > > path, > > and ensure that we write out pages passed into writepage from the > > mmap path. There is a patch against 2.4.17 which was made on Feb 10th: > > ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4 > > > .17-xfs-2002-02-10.cvs-patch.bz2 Steve -- Steve > Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software > > > From owner-linux-xfs@oss.sgi.com Sat Feb 16 01:01:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1G91WO25023 for linux-xfs-outgoing; Sat, 16 Feb 2002 01:01:32 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1G91N925001 for ; Sat, 16 Feb 2002 01:01:24 -0800 Received: (qmail 16853 invoked from network); 16 Feb 2002 08:02:38 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 16 Feb 2002 08:02:38 -0000 Date: Sat, 16 Feb 2002 03:02:38 -0500 (EST) From: Shawn Starr To: Francis Yom cc: linux-xfs@oss.sgi.com Subject: Re: How do I apply the CVS xfs patch? In-Reply-To: <1013829997.5938.15.camel@sera> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 2.4.17 + XFS CVS applies cleanly or should. if its compressed do: zcat < file | patch -p1 -E -d location/of/linux/tree if you have the file in the tree, you don't need the -d option. Shawn. On 15 Feb 2002, Francis Yom wrote: > Hi, > > I would like to apply the CVS patch to 2.4.17. Specifically > ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4 > > But when I unpack and look at it, it contains all kinds of stuff that > is not -i386 related. So patch -p1 < has all kinds of > failures. > > So how do I apply this for the -i386 2.4.17 tree? > > Thanks! > Francis > > > > > > Date: Wed Jan 30 12:55:07 PST 2002 > > Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > > > Modid: 2.4.x-xfs:slinx:110651a > > linux/fs/buffer.c - 1.100 > > - Fix up return values used in xfs writepage call, plus a couple > > of other tweaks. > > > > linux/fs/xfs/linux/xfs_iops.c - 1.120 > > - Fix up return values used in xfs writepage > > > > linux/fs/xfs/pagebuf/page_buf_io.c - 1.5 > > - No longer return a count of pages written in the write full page > > path, > > and ensure that we write out pages passed into writepage from the > > mmap path. There is a patch against 2.4.17 which was made on Feb 10th: > > ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4 > > > .17-xfs-2002-02-10.cvs-patch.bz2 Steve -- Steve > Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software > > > > > From owner-linux-xfs@oss.sgi.com Sat Feb 16 10:41:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GIf0c30622 for linux-xfs-outgoing; Sat, 16 Feb 2002 10:41:00 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GIet930600 for ; Sat, 16 Feb 2002 10:40:55 -0800 Received: (qmail 30974 invoked by uid 1000); 16 Feb 2002 17:46:56 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Feb 2002 17:46:56 -0000 Date: Sat, 16 Feb 2002 19:46:56 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: Re: old problem, gcc problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Feb 2002, Mihai RUSU wrote: > Hi > > There was a discussion on this list about a DAC960 crash happening in rare > ocasions with the following configuration: SMP, HIGHMEM, DAC960 and RH > kernels 2.4.9-13 (SGI_XFS_1.0.2 too). This has the bugid > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56603 . > Now redhat says the last errata kernel release 2.4.9-21 fixes this bug (at > least in their labs). Also they said that me using egcs 2.91.66 to compile > this kernels (yes I used the custom version) could run into more trouble > couse the recommended gcc version to compile 2.4.9-21 is 2.95.3 as per > Documentation/Changes. AFAIK SGI recommends egcs 2.91.66 to compile > Release 1.0.2. I want to try out 2.4.9-21 which I know they are > contributed but should be fine as long as they have the exactly same XFS > bits as 2.4.9-13 (whioch I consider it pretty stable). But I don't know > hich compiler version to use ?! > Hi again As from a former discussion Eric Sandeen mentioned that there is no clear answer to this tricky question (which compiler to use for compiling XFS: egcs which is recommended by the XFS developers or gcss 2.95.3 as per Documentation/Changes) I want to test out my compiled kernel. I need to upgrade to solve that DAC960 issue. I know SGI runs some QA tests, I want to know if there are some public available XFS/kernel tests ? ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Sat Feb 16 12:48:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GKmTC31752 for linux-xfs-outgoing; Sat, 16 Feb 2002 12:48:29 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GKmP931729 for ; Sat, 16 Feb 2002 12:48:25 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA13302 for ; Sat, 16 Feb 2002 11:44:01 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA21518; Sat, 16 Feb 2002 11:47:53 -0800 (PST) Date: Sat, 16 Feb 2002 13:47:52 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Mihai RUSU cc: Linux XFS List Subject: Re: old problem, gcc problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Feb 2002, Mihai RUSU wrote: > I want to test out my compiled kernel. I need to > upgrade to solve that DAC960 issue. I know SGI runs some QA tests, I want > to know if there are some public available XFS/kernel tests ? Sure; just check out the cvs repository, and under cmd/xfstests there are 60+ tests you can run. Just edit cmds/xfstests/common.config for your hostname (to set test partitions, be careful, SCRATCH_DEV and SCRATCH_LOGDEV will be overwritten during the tests). Then run [xfstests]# ./check 0?? and it will run through all the tests. -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 17 11:10:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1HJA6P20088 for linux-xfs-outgoing; Sun, 17 Feb 2002 11:10:06 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1HJA0920056 for ; Sun, 17 Feb 2002 11:10:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1HI9stm016866 for ; Sun, 17 Feb 2002 10:09:54 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA32328 for ; Sun, 17 Feb 2002 12:08:39 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA44734 for ; Sun, 17 Feb 2002 12:08:39 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1HI8de21131; Sun, 17 Feb 2002 12:08:39 -0600 Message-Id: <200202171808.g1HI8de21131@stout.americas.sgi.com> Date: Sun, 17 Feb 2002 12:08:39 -0600 From: Eric Sandeen Subject: TAKE - kdb #ifdef fix, DelallocPage() macro fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk kdb/modules/kdbm_pg.c had "#if defined(CONFIG_XFS)," but this should be CONFIG_XFS_FS, CONFIG_XFS is never defined. Also, the DelallocPage() macro was then unhappy with the way it was being called from kdb - DelallocPage(&page) - so toss a couple extra parentheses into the macro definition to make sure things get evaluated in the right order. Thanks to Shawn Starr for finding the #ifdef problem. Date: Sun Feb 17 10:00:11 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111980a linux/include/linux/mm.h - 1.78 - Add extra ()'s in DelallocPage() macro for precedence problems if we do something like DelallocPage(&page) linux/kdb/modules/kdbm_pg.c - 1.49 - Fix #ifdef for whether XFS is present - CONFIG_XFS_FS not CONFIG_XFS From owner-linux-xfs@oss.sgi.com Sun Feb 17 13:15:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1HLFEw22106 for linux-xfs-outgoing; Sun, 17 Feb 2002 13:15:14 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1HLF3922083 for ; Sun, 17 Feb 2002 13:15:03 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16cXi3-0002pQ-00; Sun, 17 Feb 2002 15:14:56 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g1HKEqg09582; Sun, 17 Feb 2002 15:14:52 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Austin Gonyou Cc: Seth Mos , Mihai RUSU , Linux XFS List Subject: Re: RAID5 internal log question References: <4.3.2.7.2.20020215223304.036f5cd0@pop.xs4all.nl> <1013814364.16590.12.camel@UberGeek> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 17 Feb 2002 15:14:51 -0500 In-Reply-To: <1013814364.16590.12.camel@UberGeek> Message-ID: Lines: 68 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Austin" == Austin Gonyou writes: [XFS vs. RAID5 performance] Seth>> Just with software raid. Most hardware raid controllers have Seth>> cache onboard which will make it far less noticeable. Austin> I disagree a little bit. If you have poor hardware, or Austin> "low-cost" hardware pushing your RAID subsystem, then I'd say Austin> you will have bad IO in these instances. Austin> In general, if you buy decent hardware, there shouldn't be a Austin> problem with this, some caching RAID controllers though, still Austin> use simms, and from experience, perform way slower than the Austin> newer ones with DIMMs(PC100, etc). This seems to be an area of constant confusion. Let me describe why XFS sucks on Linux software RAID5. It has nothing to do with controllers, physical disk layout, or anything like that. RAID5 works by saving a N-1 chunks of data followed by a chunk of parity information (the location of the checksum chunk is actually interleaved between devices with RAID5, but whatever). These N-1 data chunks + the parity blob make out a stripe. Every time you update any chunk of data you need to read in the rest of the data chunks in that stripe, calculate the parity, and then write out the modified data chunk + parity. This sucks performance-wise because a write could worst case end up causing N-2 reads (at this point you have your updated chunk in memory) followed by 2 writes. The Linux RAID5 personality isn't quite that stupid and actually uses a slightly different algorithm involving reading old data + parity off disk, masking, and then writing the new data + parity back. In any case Linux software RAID keeps a stripe cache around to cut down on the disk I/Os caused by parity updates. And this cache really improves performance. Now. Unlike the other Linux filesystems, XFS does not stick to one I/O size. The filesystem data blocks are 4K (on PC anyway), but log entries will be written in 512 byte chunks. Unfortunately these 512 byte I/Os will cause the RAID5 code to flush its entire stripe cache and reconfigure it for 512 byte I/O sizes. Then, a few ms later, we come back and do a 4K data write, causing the damn thing to be flushed again. And so on. IOW, Linux software RAID5 code was written for filesystems like ext2 that only do fixed size I/Os. So the real problem is that because XFS keeps switching the I/O size, the RAID5 code effectively runs without a stripe cache. And that's what's making the huge sucking sound. This will be fixed - eventually... By moving the XFS journal to a different device (like a software RAID1 as we suggest in the FAQ), you can work around this problem. And finally - All the hardware RAID controllers I have worked with stick to one I/O size internally and don't have this problem. They do read-modify-write on their own preferred size I/Os anyway. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Feb 17 16:45:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I0jNU24999 for linux-xfs-outgoing; Sun, 17 Feb 2002 16:45:23 -0800 Received: from smtp1.home.se (smtp1.home.se [195.66.35.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I0jJ924977 for ; Sun, 17 Feb 2002 16:45:20 -0800 Received: from tiresome@home.se [217.208.124.233] by home.se with Novell Internet Messaging System Web Client; Mon, 18 Feb 2002 00:40:00 Subject: can't mount anymore.. From: Daniel Nordin To: linux-xfs@oss.sgi.com Date: Sun, 17 Feb 2002 23:40:00 GMT X-Sender: Novell Internet Messaging System Web Client MIME-Version: 1.0 Message-ID: <1013989200.357tiresome@home.se> Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I installed xfs on a Pentium Pro with a Promise TX-133 IDE controller, Slackware 8.0 and kernel 2.4.17-xfs. Then I made a xfs partition on a 80Gb IDE HD. It worked just fine. Now I have an Alpha W/S with Redhat 7.1, the same IDE controller and the same kernel version. But now when I try to mount the xfs-partition it says: XFS: Trying to mount file system with 4096 bytes XFS: Only page-sized (8192 bytes) blocksize currently works XFS: SB validate failed so... what is my problem and how do I solve it ??? From owner-linux-xfs@oss.sgi.com Sun Feb 17 16:58:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I0wew25417 for linux-xfs-outgoing; Sun, 17 Feb 2002 16:58:40 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I0wY925395 for ; Sun, 17 Feb 2002 16:58:34 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1HNwStm020827 for ; Sun, 17 Feb 2002 15:58:29 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15591; Mon, 18 Feb 2002 10:57:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA62620; Mon, 18 Feb 2002 10:57:11 +1100 (AEDT) Date: Mon, 18 Feb 2002 10:57:10 +1100 From: Nathan Scott To: Daniel Nordin Cc: linux-xfs@oss.sgi.com Subject: Re: can't mount anymore.. Message-ID: <20020218105710.C161559@wobbly.melbourne.sgi.com> References: <1013989200.357tiresome@home.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1013989200.357tiresome@home.se>; from tiresome@home.se on Sun, Feb 17, 2002 at 11:40:00PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sun, Feb 17, 2002 at 11:40:00PM +0000, Daniel Nordin wrote: > I installed xfs on a Pentium Pro with a Promise TX-133 IDE > controller, Slackware 8.0 and kernel 2.4.17-xfs. Then I > made a xfs partition on a 80Gb IDE HD. It worked just fine. > > Now I have an Alpha W/S with Redhat 7.1, the same IDE > controller and the same kernel version. > But now when I try to mount the xfs-partition it says: > > XFS: Trying to mount file system with 4096 bytes > XFS: Only page-sized (8192 bytes) blocksize currently works > XFS: SB validate failed > > so... what is my problem and how do I solve it ??? > Currently the filesystem blocksize must be the same as the page size. Your original kernel would have had a 4K page size, but your Alpha kernel has an 8K pagesize. You can xfsdump, mkfs, xfsrestore to workaround this, or wait a little while longer until the multiple blocksize support is complete. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 17 18:24:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I2O0t27432 for linux-xfs-outgoing; Sun, 17 Feb 2002 18:24:00 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I2Nt927410 for ; Sun, 17 Feb 2002 18:23:55 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1I2NmxV008806 for ; Sun, 17 Feb 2002 18:23:48 -0800 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA16282; Mon, 18 Feb 2002 12:22:30 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA36194; Mon, 18 Feb 2002 12:22:27 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 18 Feb 2002 12:22:27 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: "Bernhard R. Erdmann" cc: Esger Abbink , Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) In-Reply-To: <3C6DF3CB.834DA82F@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Feb 2002, Bernhard R. Erdmann wrote: > > how do i get xfsdump to compress stuff? xfsdump does not compress stuff. > 1. use hardware compression > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k Option 2 will nullify all of xfsdump's fault tolerance features when writing to tape. In other words, if there's a tape error or you hit the end of tape, xfsdump can't recover. I understand of course that this might be fine for some, but many sites don't like to take chances with their backups. Just thought I'd mention this in case it was an issue. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Feb 17 18:31:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I2Vtb27722 for linux-xfs-outgoing; Sun, 17 Feb 2002 18:31:55 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I2Vq927700 for ; Sun, 17 Feb 2002 18:31:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA04025 for ; Sun, 17 Feb 2002 17:31:50 -0800 (PST) mail_from (ivanr@omen.melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA16321 for ; Mon, 18 Feb 2002 12:30:33 +1100 Received: (from ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA36468; Mon, 18 Feb 2002 12:30:33 +1100 (EST) Date: Mon, 18 Feb 2002 12:30:33 +1100 (EST) From: Ivan Rayner Message-Id: <200202180130.MAA36468@omen.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ivanr@omen.melbourne.sgi.com Subject: TAKE - minor xfsdump and xfsrestore changes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Feb 17 17:29:49 PST 2002 Workarea: omen.melbourne.sgi.com:/hosts/snort/home/ivanr/isms/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:111984a cmd/xfsdump/doc/CHANGES - 1.34 - update for minor xfsdump/xfsrestore changes cmd/xfsdump/dump/content.c - 1.17 - change builkstat failure WARNING to TRACE message cmd/xfsdump/restore/tree.c - 1.13 - avoid assertion failure for cumulative restores with -B option cmd/xfsdump/common/util.c - 1.7 - change builkstat failure WARNING to TRACE message From owner-linux-xfs@oss.sgi.com Sun Feb 17 18:32:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I2WUk27856 for linux-xfs-outgoing; Sun, 17 Feb 2002 18:32:30 -0800 Received: from smtp2.orcon.net.nz (smtp2.orcon.net.nz [210.55.12.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I2WP927833 for ; Sun, 17 Feb 2002 18:32:25 -0800 Received: from mail.orcon.net.nz (mail.orcon.net.nz [210.55.12.3]) by smtp2.orcon.net.nz (8.11.4/8.11.1) with ESMTP id g1I1WIl29731 for ; Mon, 18 Feb 2002 14:32:18 +1300 Received: from localhost.localdomain (210-86-52-148.jetstart.xtra.co.nz [210.86.52.148]) by mail.orcon.net.nz (8.11.4/8.11.1) with ESMTP id g1I1W9t25925 for ; Mon, 18 Feb 2002 14:32:10 +1300 Subject: latest binutils and 2.5-xfs From: mdew To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1013953500.3032.18.camel@mdew> Mime-Version: 1.0 X-Mailer: Evolution/1.0.2 Date: 18 Feb 2002 02:45:12 +1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk is there a linux-kernel patch for the binutils problem? (Debian Sid with 2.5.5pre1) make[2]: Leaving directory `/usr/src/linux-2.5-xfs/linux/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux-2.5-xfs/linux/arch/i386/lib' make[1]: Entering directory `/usr/src/linux-2.5-xfs/linux' ld -m elf_i386 -T /usr/src/linux-2.5-xfs/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o init/do_mounts.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o /usr/src/linux-2.5-xfs/linux/arch/i386/lib/lib.a /usr/src/linux-2.5-xfs/linux/lib/lib.a /usr/src/linux-2.5-xfs/linux/arch/i386/lib/lib.a drivers/parport/driver.o drivers/base/base.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/cdrom/driver.o sound/sound.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/i2c/i2c.o net/network.o --end-group -o vmlinux drivers/net/net.o(.data+0xd4): undefined reference to `local symbols in discarded section .text.exit' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.5-xfs/linux' make: *** [vmlinux] Error From owner-linux-xfs@oss.sgi.com Sun Feb 17 18:40:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I2ejt28117 for linux-xfs-outgoing; Sun, 17 Feb 2002 18:40:45 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I2eg928095 for ; Sun, 17 Feb 2002 18:40:42 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA17576 for ; Sun, 17 Feb 2002 17:36:16 -0800 (PST) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA16349; Mon, 18 Feb 2002 12:39:24 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA36531; Mon, 18 Feb 2002 12:39:24 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 18 Feb 2002 12:39:24 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: "Bernhard R. Erdmann" cc: linux-xfs@oss.sgi.com Subject: Re: Question...xfsdump error message? In-Reply-To: <3C6D571D.7F98DC7A@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Feb 2002, Bernhard R. Erdmann wrote: > > > >/usr/sbin/xfsdump: WARNING: failed to get valid bulkstat information for > > > >inode 16849570 > > Here's my patch for Amanda 2.4.2p2 against it: + { DMP_WARNING, "^xfsdump: WARNING: failed to get bulkstat information for inode" }, /* Linux xfsdump */ I'm not sure if you should filter this one out. That indicates an actual error from the bulkstat ioctl, not just a mismatch in the inode information. Have you actually seen xfsdump procude this message? Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Feb 17 18:52:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I2qTB28439 for linux-xfs-outgoing; Sun, 17 Feb 2002 18:52:29 -0800 Received: from amsfep16-int.chello.nl (amsfep16-int.chello.nl [213.46.243.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I2qN928417 for ; Sun, 17 Feb 2002 18:52:23 -0800 Received: from burner ([212.187.7.111]) by amsfep16-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with SMTP id <20020218014828.EWRL19167.amsfep16-int.chello.nl@burner> for ; Mon, 18 Feb 2002 02:48:28 +0100 Message-ID: <001401c1b81e$e29accd0$6f07bbd4@burner> From: "Esger Abbink" To: References: Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) Date: Mon, 18 Feb 2002 02:52:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So, as i understand it there is no "safe" compression aside from hardware compression while using xfsdump. as the data volume is quite big, i really need compression. recommandations for backup software anyone? ----- Original Message ----- From: To: "Bernhard R. Erdmann" Cc: "Esger Abbink" ; Sent: Monday, February 18, 2002 2:22 AM Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) > On Sat, 16 Feb 2002, Bernhard R. Erdmann wrote: > > > > how do i get xfsdump to compress stuff? > > xfsdump does not compress stuff. > > > 1. use hardware compression > > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k > > Option 2 will nullify all of xfsdump's fault tolerance features when > writing to tape. In other words, if there's a tape error or you hit the > end of tape, xfsdump can't recover. > > I understand of course that this might be fine for some, but many sites > don't like to take chances with their backups. Just thought I'd mention > this in case it was an issue. > > Ivan > > -- > Ivan Rayner > ivanr@sgi.com > From owner-linux-xfs@oss.sgi.com Sun Feb 17 19:14:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I3EXw29172 for linux-xfs-outgoing; Sun, 17 Feb 2002 19:14:33 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I3ES929149 for ; Sun, 17 Feb 2002 19:14:28 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1I2EMtm022669 for ; Sun, 17 Feb 2002 18:14:22 -0800 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA16493; Mon, 18 Feb 2002 13:13:05 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA35819; Mon, 18 Feb 2002 13:13:04 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 18 Feb 2002 13:13:03 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Esger Abbink cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) In-Reply-To: <001401c1b81e$e29accd0$6f07bbd4@burner> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Feb 2002, Esger Abbink wrote: > So, as i understand it there is no "safe" compression aside from > hardware compression while using xfsdump. > > as the data volume is quite big, i really need compression. > recommandations for backup software anyone? Well, if you aren't using ACLs or other extended attribute information, then you could use any generic backup utility like tar, cpio, bru, etc. (Hopefully the generic utilities will start handling these things now that the interfaces are defined.) Or you could spend alot of money on Networker (which also probably doesn't support EAs on Linux). Or you could buy yourself a new tape drive that supports compression. Or you could just buy yourself more tapes. :) Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Feb 17 20:07:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I474n04811 for linux-xfs-outgoing; Sun, 17 Feb 2002 20:07:04 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I46q904788 for ; Sun, 17 Feb 2002 20:06:53 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA08917 for ; Sun, 17 Feb 2002 19:06:48 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA76847; Mon, 18 Feb 2002 14:05:29 +1100 (AEDT) Date: Mon, 18 Feb 2002 14:05:29 +1100 From: Timothy Shimmin To: Esger Abbink Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) Message-ID: <20020218140529.G2733461@boing.melbourne.sgi.com> References: <001401c1b81e$e29accd0$6f07bbd4@burner> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <001401c1b81e$e29accd0$6f07bbd4@burner>; from e.abbink@chello.nl on Mon, Feb 18, 2002 at 02:52:13AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk my 2 cents... On Mon, Feb 18, 2002 at 02:52:13AM +0100, Esger Abbink wrote: > So, as i understand it there is no "safe" compression aside from hardware > compression while using xfsdump. > I think "safe" is a subjective thing here. I think it is more a question of "safer". Option 2 may still be considered viable for some. If one has tape errors then things probably aren't going to be pretty ;-) If one uses the tape strategy (e.g. by "-f /dev/st0" as opposed to stdout), and something happens to the tape such that we get an error on reading on restore - then it allows us to move onto the next media file in the dump. But this is only of some comfort -> the rest of the data in the corrupt media file is gone, we may only have one media file, there may be other errors in other media files. (Hmmm.. and if one was desperate to restore as much as possible, and one had a tape error, then having gzip'ed data would probably make things pretty tricky to recover stuff.) --Tim > as the data volume is quite big, i really need compression. recommandations > for backup software anyone? > > ----- Original Message ----- > From: > To: "Bernhard R. Erdmann" > Cc: "Esger Abbink" ; > Sent: Monday, February 18, 2002 2:22 AM > Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion > failure) > > > > On Sat, 16 Feb 2002, Bernhard R. Erdmann wrote: > > > > > > how do i get xfsdump to compress stuff? > > > > xfsdump does not compress stuff. > > > > > 1. use hardware compression > > > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k > > > > Option 2 will nullify all of xfsdump's fault tolerance features when > > writing to tape. In other words, if there's a tape error or you hit the > > end of tape, xfsdump can't recover. > > > > I understand of course that this might be fine for some, but many sites > > don't like to take chances with their backups. Just thought I'd mention > > this in case it was an issue. > > > > Ivan > > > > -- > > Ivan Rayner > > ivanr@sgi.com > > > > From owner-linux-xfs@oss.sgi.com Sun Feb 17 20:49:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I4n7h05450 for linux-xfs-outgoing; Sun, 17 Feb 2002 20:49:07 -0800 Received: from amsfep11-int.chello.nl (amsfep11-int.chello.nl [213.46.243.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I4mu905427 for ; Sun, 17 Feb 2002 20:48:56 -0800 Received: from burner ([212.187.7.111]) by amsfep11-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with SMTP id <20020218034849.HHBF1211.amsfep11-int.chello.nl@burner> for ; Mon, 18 Feb 2002 04:48:49 +0100 Message-ID: <002301c1b82f$2a255d30$6f07bbd4@burner> From: "Esger Abbink" To: References: <001401c1b81e$e29accd0$6f07bbd4@burner> <20020218140529.G2733461@boing.melbourne.sgi.com> Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) Date: Mon, 18 Feb 2002 04:48:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, so with one backup (media file?) per tape it really doesnt matter either way. ----- Original Message ----- From: "Timothy Shimmin" To: "Esger Abbink" Cc: Sent: Monday, February 18, 2002 4:05 AM Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) > my 2 cents... > > On Mon, Feb 18, 2002 at 02:52:13AM +0100, Esger Abbink wrote: > > So, as i understand it there is no "safe" compression aside from hardware > > compression while using xfsdump. > > > I think "safe" is a subjective thing here. > I think it is more a question of "safer". > Option 2 may still be considered viable for some. > If one has tape errors then things probably aren't going to be pretty ;-) > If one uses the tape strategy (e.g. by "-f /dev/st0" as opposed > to stdout), and something happens to the tape such that we > get an error on reading on restore - then it allows us to > move onto the next media file in the dump. But this is only > of some comfort -> the rest of the data in the corrupt media > file is gone, we may only have one media file, there may be > other errors in other media files. > > > (Hmmm.. and if one was desperate to restore as much as possible, > and one had a tape error, then having gzip'ed data would > probably make things pretty tricky to recover stuff.) > > --Tim > > > as the data volume is quite big, i really need compression. recommandations > > for backup software anyone? > > > > ----- Original Message ----- > > From: > > To: "Bernhard R. Erdmann" > > Cc: "Esger Abbink" ; > > Sent: Monday, February 18, 2002 2:22 AM > > Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion > > failure) > > > > > > > On Sat, 16 Feb 2002, Bernhard R. Erdmann wrote: > > > > > > > > how do i get xfsdump to compress stuff? > > > > > > xfsdump does not compress stuff. > > > > > > > 1. use hardware compression > > > > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k > > > > > > Option 2 will nullify all of xfsdump's fault tolerance features when > > > writing to tape. In other words, if there's a tape error or you hit the > > > end of tape, xfsdump can't recover. > > > > > > I understand of course that this might be fine for some, but many sites > > > don't like to take chances with their backups. Just thought I'd mention > > > this in case it was an issue. > > > > > > Ivan > > > > > > -- > > > Ivan Rayner > > > ivanr@sgi.com > > > > > > > From owner-linux-xfs@oss.sgi.com Sun Feb 17 23:30:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I7Ur911225 for linux-xfs-outgoing; Sun, 17 Feb 2002 23:30:53 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I7Ul911203 for ; Sun, 17 Feb 2002 23:30:47 -0800 Received: from auto-nb1.xs4all.nl (edge.coltex.nl [194.151.97.115]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1I6UiYE001764; Mon, 18 Feb 2002 07:30:45 +0100 (CET) Message-Id: <4.3.2.7.2.20020218072456.03810458@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Feb 2002 07:28:29 +0100 To: Daniel Nordin , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: can't mount anymore.. In-Reply-To: <1013989200.357tiresome@home.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:40 17-2-2002 +0000, Daniel Nordin wrote: >I installed xfs on a Pentium Pro with a Promise TX-133 IDE >controller, Slackware 8.0 and kernel 2.4.17-xfs. Then I >made a xfs partition on a 80Gb IDE HD. It worked just fine. > >Now I have an Alpha W/S with Redhat 7.1, the same IDE >controller and the same kernel version. >But now when I try to mount the xfs-partition it says: > >XFS: Trying to mount file system with 4096 bytes >XFS: Only page-sized (8192 bytes) blocksize currently works >XFS: SB validate failed > >so... what is my problem and how do I solve it ??? You can't exchange the disks between machines that have different page sizes. Alpha has a 8K pagesize while Intel has 4K. There is work in progress to mount disks with a blocksize smaller then pagesize. This would also mean that if a disk has been formatted on a alpha with 8K pagesize and intel box can not mount it. However mounting a disk with a blocksize larger then pagesize is currently not possible. This is explained in the FAQ as well. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Feb 17 23:48:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I7m1O11516 for linux-xfs-outgoing; Sun, 17 Feb 2002 23:48:01 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I7lm911493 for ; Sun, 17 Feb 2002 23:47:48 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA00264 for ; Sun, 17 Feb 2002 22:47:46 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA85528; Mon, 18 Feb 2002 17:46:28 +1100 (AEDT) Date: Mon, 18 Feb 2002 17:46:28 +1100 From: Timothy Shimmin To: Esger Abbink Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) Message-ID: <20020218174627.I2733461@boing.melbourne.sgi.com> References: <001401c1b81e$e29accd0$6f07bbd4@burner> <20020218140529.G2733461@boing.melbourne.sgi.com> <002301c1b82f$2a255d30$6f07bbd4@burner> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <002301c1b82f$2a255d30$6f07bbd4@burner>; from e.abbink@chello.nl on Mon, Feb 18, 2002 at 04:48:44AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 18, 2002 at 04:48:44AM +0100, Esger Abbink wrote: > Ok, so with one backup (media file?) per tape it really doesnt matter either > way. > A "media file" refers to the data between file marks on the tape (as one can set with "mt -f tape weof"). xfsdump in tape mode, splits up the dump into media files; typically each of size 256Mb (50Mb for QIC tapes, or user-definable with -d). [On IRIX, the media file size is based on the tape device sub-type field (which isn't available in Linux), with 512Mb for DAT, 2GB for Exabyte, 4GB for DLT,...] --Tim > ----- Original Message ----- > From: "Timothy Shimmin" > To: "Esger Abbink" > Cc: > Sent: Monday, February 18, 2002 4:05 AM > Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion > failure) > > > > my 2 cents... > > > > On Mon, Feb 18, 2002 at 02:52:13AM +0100, Esger Abbink wrote: > > > So, as i understand it there is no "safe" compression aside from > hardware > > > compression while using xfsdump. > > > > > I think "safe" is a subjective thing here. > > I think it is more a question of "safer". > > Option 2 may still be considered viable for some. > > If one has tape errors then things probably aren't going to be pretty ;-) > > If one uses the tape strategy (e.g. by "-f /dev/st0" as opposed > > to stdout), and something happens to the tape such that we > > get an error on reading on restore - then it allows us to > > move onto the next media file in the dump. But this is only > > of some comfort -> the rest of the data in the corrupt media > > file is gone, we may only have one media file, there may be > > other errors in other media files. > > > > > > (Hmmm.. and if one was desperate to restore as much as possible, > > and one had a tape error, then having gzip'ed data would > > probably make things pretty tricky to recover stuff.) > > > > --Tim > > > > > as the data volume is quite big, i really need compression. > recommandations > > > for backup software anyone? > > > > > > ----- Original Message ----- > > > From: > > > To: "Bernhard R. Erdmann" > > > Cc: "Esger Abbink" ; > > > Sent: Monday, February 18, 2002 2:22 AM > > > Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after > assertion > > > failure) > > > > > > > > > > On Sat, 16 Feb 2002, Bernhard R. Erdmann wrote: > > > > > > > > > > how do i get xfsdump to compress stuff? > > > > > > > > xfsdump does not compress stuff. > > > > > > > > > 1. use hardware compression > > > > > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k > > > > > > > > Option 2 will nullify all of xfsdump's fault tolerance features when > > > > writing to tape. In other words, if there's a tape error or you hit > the > > > > end of tape, xfsdump can't recover. > > > > > > > > I understand of course that this might be fine for some, but many > sites > > > > don't like to take chances with their backups. Just thought I'd > mention > > > > this in case it was an issue. > > > > > > > > Ivan > > > > > > > > -- > > > > Ivan Rayner > > > > ivanr@sgi.com > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Feb 18 00:03:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I83hc11907 for linux-xfs-outgoing; Mon, 18 Feb 2002 00:03:43 -0800 Received: from ente.berdmann.de (frnk-d514e134.dsl.mediaWays.net [213.20.225.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I83d911885 for ; Mon, 18 Feb 2002 00:03:40 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16chpk-0004Hj-00; Mon, 18 Feb 2002 08:03:32 +0100 Message-ID: <3C70A744.C5183832@berdmann.de> Date: Mon, 18 Feb 2002 08:03:32 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: ivanr@sgi.com CC: Esger Abbink , linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertionfailure) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k > > Option 2 will nullify all of xfsdump's fault tolerance features when > writing to tape. In other words, if there's a tape error or you hit the > end of tape, xfsdump can't recover. Good point. Does xfsdump's fault tolerance depend on writing/reading to/from tape itself or will xfsrestore be happy when being fed out of a pipe, too? From owner-linux-xfs@oss.sgi.com Mon Feb 18 00:07:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I871H12059 for linux-xfs-outgoing; Mon, 18 Feb 2002 00:07:01 -0800 Received: from ente.berdmann.de (frnk-d514e134.dsl.mediaWays.net [213.20.225.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I86w912037 for ; Mon, 18 Feb 2002 00:06:58 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16chsy-0004Kj-00; Mon, 18 Feb 2002 08:06:52 +0100 Message-ID: <3C70A80C.F6A482FC@berdmann.de> Date: Mon, 18 Feb 2002 08:06:52 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: ivanr@sgi.com CC: linux-xfs@oss.sgi.com Subject: Re: Question...xfsdump error message? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > + { DMP_WARNING, "^xfsdump: WARNING: failed to get bulkstat information for inode" }, /* Linux xfsdump */ > > I'm not sure if you should filter this one out. That indicates an > actual error from the bulkstat ioctl, not just a mismatch in the inode > information. > > Have you actually seen xfsdump procude this message? Yes, I did. It happens rarely, but I have some Amanda mails stating this message. From owner-linux-xfs@oss.sgi.com Mon Feb 18 01:14:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I9E2e13116 for linux-xfs-outgoing; Mon, 18 Feb 2002 01:14:02 -0800 Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I9Dv913093 for ; Mon, 18 Feb 2002 01:13:57 -0800 Received: from xs4.xs4all.nl (dirk@xs4.xs4all.nl [194.109.6.45]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1I8DuAZ039741 for ; Mon, 18 Feb 2002 09:13:56 +0100 (CET) Received: (from dirk@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) id JAA15535 for linux-xfs@oss.sgi.com; Mon, 18 Feb 2002 09:13:56 +0100 (CET) Date: Mon, 18 Feb 2002 09:13:56 +0100 From: dirk To: xfs Subject: Re: latest binutils and 2.5-xfs Message-ID: <20020218091356.A14960@xs4all.nl> Mail-Followup-To: xfs References: <1013953500.3032.18.camel@mdew> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1013953500.3032.18.camel@mdew>; from mdew@orcon.net.nz on Mon, Feb 18, 2002 at 02:45:12AM +1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 18, 2002 at 02:45:12AM +1300, mdew wrote: > > > is there a linux-kernel patch for the binutils problem? > You can "patch" it yourself. > discarded section .text.exit' Remove the line with ".text.exit" from vmlinux.lds. Unfortunately I am at work and can't check the exact path or file name. But it's probably in arch/i386. I had the same problem so you can look up my mail about it. It was about 2 weeks ago I think. Dirk From owner-linux-xfs@oss.sgi.com Mon Feb 18 05:44:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IDi4x26232 for linux-xfs-outgoing; Mon, 18 Feb 2002 05:44:04 -0800 Received: from hulda.harnosand.office.se ([212.75.75.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IDi1926210 for ; Mon, 18 Feb 2002 05:44:02 -0800 content-class: urn:content-classes:message Subject: change blocksize? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 18 Feb 2002 13:42:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <30595D6D3E2A2A40A1A3BEDEF22DCE6C059462@hulda.harnosand.office.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: change blocksize? Thread-Index: AcG4ecEqde+SlNYYQkadU7ySBXtrRg== From: "Daniel Nordin" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1IDi2926211 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is it possible to change blocksize on a XFS partition it becomes mountable on a different machine than it was created on? If so.. what command and how? From owner-linux-xfs@oss.sgi.com Mon Feb 18 05:56:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IDuvr28802 for linux-xfs-outgoing; Mon, 18 Feb 2002 05:56:57 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IDus928780 for ; Mon, 18 Feb 2002 05:56:54 -0800 Received: from auto-nb1.xs4all.nl (edge.coltex.nl [194.151.97.115]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1ICulih034881; Mon, 18 Feb 2002 13:56:52 +0100 (CET) Message-Id: <4.3.2.7.2.20020218135420.02ca3370@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Feb 2002 13:54:32 +0100 To: "Daniel Nordin" , From: Seth Mos Subject: Re: change blocksize? In-Reply-To: <30595D6D3E2A2A40A1A3BEDEF22DCE6C059462@hulda.harnosand.off ice.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:42 18-2-2002 +0100, Daniel Nordin wrote: >Is it possible to change blocksize on a XFS partition it becomes mountable >on a different machine than it was created on? >If so.. what command and how? Nope. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Feb 18 06:57:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IEvY130181 for linux-xfs-outgoing; Mon, 18 Feb 2002 06:57:34 -0800 Received: from fruit.eu.org (qmailr@34dyn21.com21.casema.net [212.64.15.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IEvT930159 for ; Mon, 18 Feb 2002 06:57:29 -0800 Received: (qmail 34978 invoked by uid 500); 18 Feb 2002 13:57:18 -0000 Date: Mon, 18 Feb 2002 14:57:18 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: chown32() weirdness Message-ID: <20020218145718.N22191@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk oi! It seems XFS is suprisingly "empowering" these days :) Below is a transcript which shows a problem with recent CVS kernels. It's the CVS version from today (see the uname output). bzzrt:/home/wsl% cd /tmp bzzrt:/tmp% id uid=500(wsl) gid=500(wsl) groups=500(wsl),100(users) bzzrt:/tmp% touch feh bzzrt:/tmp% ls -li feh 8433 -rw-r--r-- 1 wsl wsl 0 Feb 18 14:50 feh bzzrt:/tmp% chown 0.0 feh bzzrt:/tmp% ls -li feh 8433 -rw-r--r-- 1 root root 0 Feb 18 14:50 feh bzzrt:/tmp% mount ... /dev/ide/host0/bus0/target0/lun0/part8 on /tmp type xfs (rw,logbufs=8) ... bzzrt:/tmp% uname -a Linux bzzrt 2.4.17-xfs #1 Mon Feb 18 13:52:34 CET 2002 i686 unknown bzzrt:/tmp% -- Wessel Dankers The monitor needs another box of pixels. From owner-linux-xfs@oss.sgi.com Mon Feb 18 09:41:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IHfUY06018 for linux-xfs-outgoing; Mon, 18 Feb 2002 09:41:30 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IHfQ905996 for ; Mon, 18 Feb 2002 09:41:26 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA09526 for ; Mon, 18 Feb 2002 08:42:48 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA92490; Mon, 18 Feb 2002 08:40:53 -0800 (PST) Date: Mon, 18 Feb 2002 10:40:52 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Wessel Dankers cc: Subject: Re: chown32() weirdness In-Reply-To: <20020218145718.N22191@fruit.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hm, we used to call inode_change_ok() in linvfs_setattr - which would not have allowed this - but it was recently removed as "unneeded" since xfs has it's own internal checks... let me go look at those internal checks. -Eric On Mon, 18 Feb 2002, Wessel Dankers wrote: > It seems XFS is suprisingly "empowering" these days :) > Below is a transcript which shows a problem with recent CVS kernels. > It's the CVS version from today (see the uname output). From owner-linux-xfs@oss.sgi.com Mon Feb 18 09:51:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IHpNg06235 for linux-xfs-outgoing; Mon, 18 Feb 2002 09:51:23 -0800 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IHpH906213 for ; Mon, 18 Feb 2002 09:51:17 -0800 Received: from user-2iniap3.dialup.mindspring.com ([165.121.43.35] helo=waltsathlon.localhost.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16cr0U-0003hn-00 for linux-xfs@oss.sgi.com; Mon, 18 Feb 2002 11:51:14 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id C6B77E01436; Mon, 18 Feb 2002 08:50:27 -0800 (PST) Message-ID: <3C7130D3.7030508@mindspring.com> Date: Mon, 18 Feb 2002 08:50:27 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: Wessel Dankers Cc: linux-xfs@oss.sgi.com Subject: Re: chown32() weirdness References: <20020218145718.N22191@fruit.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Oops. Good catch. FWIW, I just tried it with CVS build as of 1.31.02 and I'm not allowed to do this. "Operation not permitted" However, that means the server I just swapped out on Saturday and rebuilt with a freshly checked out XFS probably needs fixin' :) -Walt Wessel Dankers wrote: > oi! > > It seems XFS is suprisingly "empowering" these days :) > Below is a transcript which shows a problem with recent CVS kernels. > It's the CVS version from today (see the uname output). > > bzzrt:/home/wsl% cd /tmp > bzzrt:/tmp% id > uid=500(wsl) gid=500(wsl) groups=500(wsl),100(users) > bzzrt:/tmp% touch feh > bzzrt:/tmp% ls -li feh > 8433 -rw-r--r-- 1 wsl wsl 0 Feb 18 14:50 feh > bzzrt:/tmp% chown 0.0 feh > bzzrt:/tmp% ls -li feh > 8433 -rw-r--r-- 1 root root 0 Feb 18 14:50 feh > bzzrt:/tmp% mount > ... > /dev/ide/host0/bus0/target0/lun0/part8 on /tmp type xfs (rw,logbufs=8) > ... > bzzrt:/tmp% uname -a > Linux bzzrt 2.4.17-xfs #1 Mon Feb 18 13:52:34 CET 2002 i686 unknown > bzzrt:/tmp% > > -- > Wessel Dankers > > The monitor needs another box of pixels. > > From owner-linux-xfs@oss.sgi.com Mon Feb 18 10:03:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1II3SX06575 for linux-xfs-outgoing; Mon, 18 Feb 2002 10:03:28 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1II3O906553 for ; Mon, 18 Feb 2002 10:03:24 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA28756 for ; Mon, 18 Feb 2002 08:58:59 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA56622; Mon, 18 Feb 2002 09:02:52 -0800 (PST) Date: Mon, 18 Feb 2002 11:02:51 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Wessel Dankers cc: Subject: Re: chown32() weirdness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, I guess this is a difference between Irix and Linux... bonnie% id uid=38415(sandeen) gid=10(engr) bonnie% touch feh bonnie% ls -li feh 4435055 -rw-r--r-- 1 sandeen engr 0 Feb 18 08:51 feh bonnie% chown 0.0 feh bonnie% ls -li feh 4435055 -rw-r--r-- 1 root sys 0 Feb 18 08:51 feh bonnie% uname -a IRIX64 bonnie 6.5 01091821 IP27 bonnie% rm feh feh: 644 mode. Remove ? (yes/no)[no] : y Perhaps we should be more Linux-like here, though... -Eric On Mon, 18 Feb 2002, Eric Sandeen wrote: > Hm, we used to call inode_change_ok() in linvfs_setattr - which > would not have allowed this - but it was recently removed as "unneeded" > since xfs has it's own internal checks... let me go look at those internal > checks. > > -Eric From owner-linux-xfs@oss.sgi.com Mon Feb 18 10:06:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1II6m506713 for linux-xfs-outgoing; Mon, 18 Feb 2002 10:06:48 -0800 Received: from fruit.eu.org (qmailr@34dyn21.com21.casema.net [212.64.15.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1II6i906691 for ; Mon, 18 Feb 2002 10:06:45 -0800 Received: (qmail 35514 invoked by uid 500); 18 Feb 2002 17:06:43 -0000 Date: Mon, 18 Feb 2002 18:06:43 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: chown32() weirdness Message-ID: <20020218180643.O22191@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sandeen@sgi.com on Mon, Feb 18, 2002 at 11:02:51AM -0600 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 2002-02-18 11:02:51-0600, Eric Sandeen wrote: > Ok, I guess this is a difference between Irix and Linux... Hm. That means I can just push someone over their quota by chowning a big file to them (especially if it's in a directory they do not have access to). That doesn't sound right. Regards, -- Wessel Dankers Some one needed the powerstrip, so they pulled the switch plug. From owner-linux-xfs@oss.sgi.com Mon Feb 18 10:11:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IIBwm06892 for linux-xfs-outgoing; Mon, 18 Feb 2002 10:11:58 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IIBs906870 for ; Mon, 18 Feb 2002 10:11:54 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA29671 for ; Mon, 18 Feb 2002 09:07:29 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA53446; Mon, 18 Feb 2002 09:11:23 -0800 (PST) Date: Mon, 18 Feb 2002 11:11:23 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Wessel Dankers cc: Subject: Re: chown32() weirdness In-Reply-To: <20020218180643.O22191@fruit.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yep, that does sound like a problem. ;-) -Eric On Mon, 18 Feb 2002, Wessel Dankers wrote: > On 2002-02-18 11:02:51-0600, Eric Sandeen wrote: > > Ok, I guess this is a difference between Irix and Linux... > > Hm. That means I can just push someone over their quota by chowning a big > file to them (especially if it's in a directory they do not have access > to). That doesn't sound right. > > Regards, > > -- > Wessel Dankers > > Some one needed the powerstrip, so they pulled the switch plug. > From owner-linux-xfs@oss.sgi.com Mon Feb 18 10:13:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IID1g07022 for linux-xfs-outgoing; Mon, 18 Feb 2002 10:13:01 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IICv907000 for ; Mon, 18 Feb 2002 10:12:58 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g1IHCFA26757; Mon, 18 Feb 2002 18:12:15 +0100 Date: Mon, 18 Feb 2002 18:12:15 +0100 From: Christoph Hellwig To: Eric Sandeen Cc: Wessel Dankers , linux-xfs@oss.sgi.com Subject: Re: chown32() weirdness Message-ID: <20020218181215.A26602@caldera.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sandeen@sgi.com on Mon, Feb 18, 2002 at 11:02:51AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 18, 2002 at 11:02:51AM -0600, Eric Sandeen wrote: > Ok, I guess this is a difference between Irix and Linux... There are two possible chown semantics. Linux has a restricted chown by default that only allows root to change owners and thus defines _POSIX_CHOWN_RESTRICTED. Some other systems (dunno about IRIX) allow both variants, depending on configuration. Then pathconf() with _PC_CHOWN_RESTRICTED is used to find out which semantics apply to a specific filename. Christoph From owner-linux-xfs@oss.sgi.com Mon Feb 18 11:02:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IJ2eV07650 for linux-xfs-outgoing; Mon, 18 Feb 2002 11:02:40 -0800 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IJ1X907618 for ; Mon, 18 Feb 2002 11:01:33 -0800 Received: from user-2iniap3.dialup.mindspring.com ([165.121.43.35] helo=waltsathlon.localhost.net) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16cs6R-0004BH-00 for linux-xfs@oss.sgi.com; Mon, 18 Feb 2002 13:01:27 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 88409E0143B; Mon, 18 Feb 2002 10:00:41 -0800 (PST) Message-ID: <3C714149.9060506@mindspring.com> Date: Mon, 18 Feb 2002 10:00:41 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: Wessel Dankers Cc: linux-xfs@oss.sgi.com Subject: Re: chown32() weirdness References: <20020218180643.O22191@fruit.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was more afraid of the setuid, possibe local root exploit. Maybe that would be caught? -Walt Wessel Dankers wrote: > On 2002-02-18 11:02:51-0600, Eric Sandeen wrote: > >>Ok, I guess this is a difference between Irix and Linux... >> > > Hm. That means I can just push someone over their quota by chowning a big > file to them (especially if it's in a directory they do not have access > to). That doesn't sound right. > > Regards, > > -- > Wessel Dankers > > Some one needed the powerstrip, so they pulled the switch plug. > > From owner-linux-xfs@oss.sgi.com Mon Feb 18 11:24:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IJOhx07967 for linux-xfs-outgoing; Mon, 18 Feb 2002 11:24:43 -0800 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IJOa907945 for ; Mon, 18 Feb 2002 11:24:37 -0800 Received: from user-2iniap3.dialup.mindspring.com ([165.121.43.35] helo=waltsathlon.localhost.net) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 16csSn-0004Lx-00 for linux-xfs@oss.sgi.com; Mon, 18 Feb 2002 13:24:33 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 3C29FE0143E; Mon, 18 Feb 2002 10:23:47 -0800 (PST) Message-ID: <3C7146B3.1050300@mindspring.com> Date: Mon, 18 Feb 2002 10:23:47 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: Walt H Cc: Wessel Dankers , linux-xfs@oss.sgi.com Subject: Re: chown32() weirdness References: <20020218180643.O22191@fruit.eu.org> <3C714149.9060506@mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just checked it. No problem with setuid exploit. Permissions are stripped on chown, and you're not allowed to setuid afterwards. -Walt Walt H wrote: > I was more afraid of the setuid, possibe local root exploit. Maybe that > would be caught? > > -Walt > > > Wessel Dankers wrote: > >> On 2002-02-18 11:02:51-0600, Eric Sandeen wrote: >> >>> Ok, I guess this is a difference between Irix and Linux... >>> >> >> Hm. That means I can just push someone over their quota by chowning a big >> file to them (especially if it's in a directory they do not have access >> to). That doesn't sound right. >> >> Regards, >> >> -- >> Wessel Dankers >> >> Some one needed the powerstrip, so they pulled the switch plug. >> >> > > From owner-linux-xfs@oss.sgi.com Mon Feb 18 11:42:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IJg8C08211 for linux-xfs-outgoing; Mon, 18 Feb 2002 11:42:08 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IJg5908189 for ; Mon, 18 Feb 2002 11:42:05 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1IIfxtm014321 for ; Mon, 18 Feb 2002 10:41:59 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA39229 for ; Mon, 18 Feb 2002 12:40:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA20528 for ; Mon, 18 Feb 2002 12:40:44 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1IIeh710749; Mon, 18 Feb 2002 12:40:43 -0600 Message-Id: <200202181840.g1IIeh710749@stout.americas.sgi.com> Date: Mon, 18 Feb 2002 12:40:43 -0600 From: Eric Sandeen Subject: TAKE - Restrict chown Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We removed xfs's call to inode_change_ok, but then we missed Linux's check for chown capability, relying on XFS. XFS was configured to allow unrestricted chown, which is not the way Linux behaves... In short, don't allow non-super-users to give away files with chown(). Date: Mon Feb 18 10:37:23 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:111992a linux/fs/xfs/linux/xfs_globals.c - 1.25 - Don't let non-super-user give away files by default From owner-linux-xfs@oss.sgi.com Mon Feb 18 11:48:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IJmJP08393 for linux-xfs-outgoing; Mon, 18 Feb 2002 11:48:19 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IJmH908370 for ; Mon, 18 Feb 2002 11:48:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1IImBtm014549 for ; Mon, 18 Feb 2002 10:48:11 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA30990 for ; Mon, 18 Feb 2002 12:46:56 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.34 #1 (Debian)) id 16csoR-0008GC-00 for ; Mon, 18 Feb 2002 12:46:55 -0600 Date: Mon, 18 Feb 2002 12:46:55 -0600 From: Nathan Straz To: Linux XFS List Subject: Re: old problem, gcc problem Message-ID: <20020218184655.GQ15924@sgi.com> Mail-Followup-To: Linux XFS List References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Feb 16, 2002 at 07:46:56PM +0200, Mihai RUSU wrote: > I know SGI runs some QA tests, I want to know if there are some public > available XFS/kernel tests ? You could try out any of the disk benchmarks or some of the file tests in the Linux Test Project. See my sig for URL. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Feb 18 11:49:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IJnat08534 for linux-xfs-outgoing; Mon, 18 Feb 2002 11:49:36 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IJnT908511 for ; Mon, 18 Feb 2002 11:49:30 -0800 Received: (qmail 19675 invoked by uid 1000); 18 Feb 2002 18:55:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2002 18:55:37 -0000 Date: Mon, 18 Feb 2002 20:55:37 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Eric Sandeen cc: Linux XFS List Subject: Re: TAKE - Restrict chown In-Reply-To: <200202181840.g1IIeh710749@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I tested changing the owner of a file with a 2.4.9-13XFS_SGI_1.0.2 and it seems I dont have the permissions to do it (the right linux answer). Now does this problem affect Release 1.0.2 too (maybe I havent tested it the right way) ? If so it would be nice to have a patch against those kernels or just point me to the lines where you did the change :) Thanks On Mon, 18 Feb 2002, Eric Sandeen wrote: > We removed xfs's call to inode_change_ok, but then we missed Linux's > check for chown capability, relying on XFS. XFS was configured > to allow unrestricted chown, which is not the way Linux behaves... > > In short, don't allow non-super-users to give away files with > chown(). > > > Date: Mon Feb 18 10:37:23 PST 2002 > Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:111992a > linux/fs/xfs/linux/xfs_globals.c - 1.25 > - Don't let non-super-user give away files by default > > > ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Mon Feb 18 11:56:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IJuGp08784 for linux-xfs-outgoing; Mon, 18 Feb 2002 11:56:16 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IJu9908762 for ; Mon, 18 Feb 2002 11:56:09 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA03755 for ; Mon, 18 Feb 2002 10:57:31 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA87472; Mon, 18 Feb 2002 10:55:37 -0800 (PST) Date: Mon, 18 Feb 2002 12:55:36 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Mihai RUSU cc: Linux XFS List Subject: Re: TAKE - Restrict chown In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 1.0.2 should not have this problem. It only existed in CVS from Fri Feb 15 16:39:51 2002 UTC until now. -Eric On Mon, 18 Feb 2002, Mihai RUSU wrote: > Hi > > I tested changing the owner of a file with a 2.4.9-13XFS_SGI_1.0.2 and it > seems I dont have the permissions to do it (the right linux answer). Now > does this problem affect Release 1.0.2 too (maybe I havent tested it the > right way) ? If so it would be nice to have a patch against those kernels > or just point me to the lines where you did the change :) > > Thanks > > On Mon, 18 Feb 2002, Eric Sandeen wrote: > > > We removed xfs's call to inode_change_ok, but then we missed Linux's > > check for chown capability, relying on XFS. XFS was configured > > to allow unrestricted chown, which is not the way Linux behaves... > > > > In short, don't allow non-super-users to give away files with > > chown(). > > > > > > Date: Mon Feb 18 10:37:23 PST 2002 > > Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > > > Modid: 2.4.x-xfs:slinx:111992a > > linux/fs/xfs/linux/xfs_globals.c - 1.25 > > - Don't let non-super-user give away files by default > > > > > > > > ---------------------------- > Mihai RUSU > "... and what if this is as good as it gets ?" > From owner-linux-xfs@oss.sgi.com Mon Feb 18 12:27:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IKR1109313 for linux-xfs-outgoing; Mon, 18 Feb 2002 12:27:01 -0800 Received: from com.esnaola.org (aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IKQu909291 for ; Mon, 18 Feb 2002 12:26:56 -0800 Received: from localhost (localhost [127.0.0.1]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 390C220D8E9 for ; Mon, 18 Feb 2002 20:26:52 +0100 (CET) Received: from localhost.localdomain (neotrantor.esnaola.org [192.168.33.18]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 3577D20D8E8 for ; Mon, 18 Feb 2002 20:26:49 +0100 (CET) Subject: linux 2.4xfs + freeswan 1.95 From: Lionel DARNIS To: Linux XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Feb 2002 20:27:02 +0100 Message-Id: <1014060422.11833.10.camel@neotrantor> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I try to compile my cvs kernel 2.4.17xfs + freeswan 1.95 and I obtain : drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux' make: *** [vmlinux] Error 2 An idea ?? thanks in advance. See ya, Lionel From owner-linux-xfs@oss.sgi.com Mon Feb 18 12:34:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IKYgB09586 for linux-xfs-outgoing; Mon, 18 Feb 2002 12:34:42 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IKYC909561 for ; Mon, 18 Feb 2002 12:34:12 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KK4ZX9>; Mon, 18 Feb 2002 11:36:34 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0AF@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'linux-xfs@oss.sgi.com'" , "'linux-lvm@sistina.com'" Subject: RE: Oops unmounting snapshot of xfs filesystem Date: Mon, 18 Feb 2002 11:36:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B8B3.8F88AB80" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B8B3.8F88AB80 Content-Type: text/plain; charset="iso-8859-1" Klaus Strebel's suggestion to use 2.91.66 (kgcc) for the kernel did solve the oops from snapshot umounting, in ordinary circumstances. Thanks! However, I still have similar behavior, from umounting an invalid (filled-up) snapshot. I took three snapshots of a single xfs logical volume, mounted the snapshots, and ran I-O on the source until the snapshots were invalidated. I then umounted two of the snapshots. I saw xfs_force_shutdown messages in syslog for each umount, and the second umount oopsed. Here's the syslog entries: <6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 on /dev/volgr0/lvol1: out of space <6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 on /dev/volgr0/lvol2: out of space <6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 on /dev/volgr0/lvol3: out of space <1> Feb 14 15:24:43 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol1 <1> Feb 14 15:24:43 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol1 <4> Feb 14 15:24:43 kernel: I/O error in filesystem ("lvm(58,1)") meta-data dev 0x3a01 block 0xa00020 <4> Feb 14 15:24:43 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 14 15:24:43 kernel: xfs_force_shutdown(lvm(58,1),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01b934e <4> Feb 14 15:24:43 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,1) <4> Feb 14 15:24:43 kernel: Please umount the filesystem, and rectify the problem(s) <1> Feb 14 15:24:48 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol2 <1> Feb 14 15:24:48 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol2 <4> Feb 14 15:24:48 kernel: I/O error in filesystem ("lvm(58,2)") meta-data dev 0x3a02 block 0xa00020 <4> Feb 14 15:24:48 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 14 15:24:48 kernel: xfs_force_shutdown(lvm(58,2),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01b934e <4> Feb 14 15:24:48 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,2) <4> Feb 14 15:24:48 kernel: Please umount the filesystem, and rectify the problem(s) <1> Feb 14 15:24:48 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000020 [oops snipped, but output of ksymoops attached to message] System details: Celeron with 512 MB of RAM and WD 45GB harddrives. 128 MB swap, one vg consisting of a one-drive RAID 0. Kernel 2.4.16 with 12/14/01 xfs CVS. LVM CVS of 1/21/02 (functionally identical to 1.0.2, I believe). LVM's linux-2.4.11-VFS-lock.patch. xfs_fs_freeze() patch posted by Eric Sandeen. Anselm Kruis' writable snapshot patch. Snapshots were mounted ro,nouuid,norecovery. The only action taken to the snapshots was mounting. I hope to try it soon with 2.4.17, as Adrian Head suggested. Has anyone else run this case with xfs snapshots? Why does umount result in I/O activity to a read-only, norecovery file system? Thanks, Dale Stephenson steph@snapserver.com > -----Original Message----- > From: Klaus Strebel [mailto:klaus.strebel@eigner.com] > Sent: Monday, February 11, 2002 2:46 AM > To: Stephenson, Dale > Cc: 'linux-xfs@oss.sgi.com'; 'linux-lvm@sistina.com' > Subject: Re: Oops unmounting snapshot of xfs filesystem > > > Stephenson, Dale wrote: > > I have been running into an oops when umounting the > snapshot of an xfs > > filesystem, or following the umount. For instance, a > umount followed by an > > lvremove will oops in the lvremove, while a > mount/umount/mount/umount > > sequence will oops on the second or third umount. > > > > What does seem consistent is the error message logged on > each umount. Here > > are the messages from a mount/umount sequence: > > > > <4> Feb 7 11:20:00 kernel: Mounting filesystem "lvm(58,1)" > in no-recovery > > mode. Filesystem will be inconsistent. > > <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write > for readonly LV > > /dev/volgr0/lvol1 > > <2> Feb 7 11:20:02 kernel: lvm - lvm_map: ll_rw_blk write > for readonly LV > > /dev/volgr0/lvol1 > > <4> Feb 7 11:20:02 kernel: I/O error in filesystem > ("lvm(58,1)") meta-data > > dev 0x3a01 block 0xa00020 > > <4> Feb 7 11:20:02 kernel: ("xlog_iodone") error 5 > buf count 1024 > > <4> Feb 7 11:20:02 kernel: > xfs_force_shutdown(lvm(58,1),0x2) called from > > line 939 of file xfs_log.c. Return address = 0xc01b3cbc > > <4> Feb 7 11:20:02 kernel: Log I/O Error Detected. Shutting down > > filesystem: lvm(58,1) > > <4> Feb 7 11:20:02 kernel: Please umount the filesystem, > and rectify the > > problem(s) > > > > I've attached the oops (run through ksymoops) from this > particular umount. > > The snapshot is mounted ro,nouuid,norecovery. The source > of the snapshot > > contains an unmounted xfs filesystem, which was unmounted > at the time of > > snapshot creation. There has been no intentional I/O > activity to the > > snapshot, either. > > > > It looks to me like xfs is trying to flush something to > disk on the umount, > > even though the filesystem is read only and no recovery. I > would not have > > expected this. Is it correct behavior? > > > > I made the snapshot writeable, but kept the mount options > the same. I was > > able to mount/umount many times without oops, I/O errors, or > > xfs_force_shutdown. > > > > I did notice similar behavior when a full snapshot returns > an I/O error -- > > xfs_force_shutdown, with an oops following soon thereafter. > > > > System details: > > Celeron with 512 MB of RAM and WD 45GB harddrives. > > 128 MB swap, one vg consisting of a one-drive RAID 0. > > Kernel 2.4.16 with 12/14/01 xfs CVS. > > LVM CVS of 1/21/02 (functionally identical to 1.0.2, I believe). > > LVM's linux-2.4.11-VFS-lock.patch. > > xfs_fs_freeze() patch posted by Eric Sandeen. > > Anselm Kruis' writable snapshot patch. > > Had the same, disappeared when compiled the kernel with gcc-2.91.66 ! > Seems to be a compiler issue. > > Ciao > Klaus > > -- > Klaus Strebel > UNIX-Engineer > klaus.strebel@eigner.com > EIGNER - Precision Lifecycle Management - > > ------_=_NextPart_000_01C1B8B3.8F88AB80 Content-Type: application/octet-stream; name="oops.out" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="oops.out" ksymoops 2.4.0 on i686 2.4.9-2buildsmp. Options used -V (default) -k ksyms (specified) -L (specified) -O (specified) -M (specified) Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/net/ap= pletalk/appletalk.o) for appletalk Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/adm1024.o) for adm1024 Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/i2c-proc.o) for i2c-proc Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/i2c-dev.o) for i2c-dev Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/i2c/i2c-core.o) for i2c-core Error (expand_objects): cannot stat(/lib/modules/2.4.16-2snap/kernel/driver= s/net/eepro100.o) for eepro100 Unable to handle kernel NULL pointer dereference at virtual address 0000002= 0=20 c012ea83=20 Oops: 0000=20 CPU: 0=20 EIP: 0010:[] Not tainted=20 Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206=20 eax: 00000000 ebx: 00000000 ecx: 00003a02 edx: 00003a02=20 esi: 00000006 edi: 00000000 ebp: 00000000 esp: c0719d60=20 ds: 0018 es: 0018 ss: 0018=20 Process umount (pid: 6416, stackpage=3Dc0719000)=20 Stack: c3e403a0 00000000 c0718000 c2bfe000 3a020168 00000000 c012eb68 c3e40= 3a0=20=20 00000001 c3ace220 c016f038 00003a02 00000001 00000000 c01d18c2 c3ace= 220=20=20 00000000 c3ada680 c2f50000 00000400 c01b934e c2bfe000 00000002 c02b2= 7c7=20=20 Call Trace: [] [] [] [] [= ]=20=20 [] [] [] [] [] []=20=20 [] [] [] [] [] []=20=20 [] [] [] [] []=20=20 Code: 8b 53 20 89 54 24 14 0f b7 54 24 12 66 39 53 0c 75 7b 83 7b=20=20 >>EIP; c012ea83 <=3D=3D=3D=3D=3D Trace; c012eb68 <__invalidate_buffers+20/7c> Trace; c016f038 Trace; c01d18c2 Trace; c01b934e Trace; c016bcd8 Trace; c016c62c Trace; c01b9388 Trace; c01b9aa2 Trace; c01baf6a Trace; c01bb0b0 Trace; c01b8c94 Trace; c01c1032 Trace; c01c84d1 Trace; c01d2c7a Trace; c01da7cc Trace; c0131ef8 Trace; c014098e <__mntput+1e/624> Trace; c013582f Trace; c0141201 Trace; c0120665 Trace; c014121c Trace; c0106d7b <__up_wakeup+1057/2274> Code; c012ea83 00000000 <_EIP>: Code; c012ea83 <=3D=3D=3D=3D=3D 0: 8b 53 20 mov 0x20(%ebx),%edx <=3D=3D=3D=3D=3D Code; c012ea86 3: 89 54 24 14 mov %edx,0x14(%esp,1) Code; c012ea8a 7: 0f b7 54 24 12 movzwl 0x12(%esp,1),%edx Code; c012ea8f c: 66 39 53 0c cmp %dx,0xc(%ebx) Code; c012ea93 10: 75 7b jne 8d <_EIP+0x8d> c012eb10 Code; c012ea95 12: 83 7b 00 00 cmpl $0x0,0x0(%ebx) 6 errors issued. Results may not be reliable. ------_=_NextPart_000_01C1B8B3.8F88AB80-- From owner-linux-xfs@oss.sgi.com Mon Feb 18 12:46:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IKkX809803 for linux-xfs-outgoing; Mon, 18 Feb 2002 12:46:33 -0800 Received: from dream.lapseofthought.com (adsl-66-124-80-202.dsl.snfc21.pacbell.net [66.124.80.202]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IKkP909780 for ; Mon, 18 Feb 2002 12:46:25 -0800 Received: (from drich@localhost) by dream.lapseofthought.com (8.11.6/8.11.6) id g1IIjWv31875; Mon, 18 Feb 2002 10:45:32 -0800 Date: Mon, 18 Feb 2002 10:45:31 -0800 (PST) From: Dan Rich X-X-Sender: To: Subject: Kernel OOPS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm seeing the following crash on my server. This system is a SMP system with a Highpoint IDE Raid controller and a Buslogic SCSI card (I'm mentioning that because the crash appears to go away if I remove the SCSI interface). From the output of ksymoops, it appears to be crashing in the xfs routines. kernel BUG at /misc/src/linux-2.4.17/include/asm/spinlock.h:86! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: 00000040 ebx: ef24aab4 ecx: c05107ac edx: 00003e7c esi: ecd80930 edi: 00000202 ebp: e2babd48 esp: e2babd30 ds: 0018 es: 0018 ss: 0018 Process python (pid: 1678, stackpage=e2bab000) Stack: c03e6520 00000056 ef24ab60 ecd80930 ef24aab4 00000000 e2babd6c c020962b ef24aab4 ecd80930 00000000 00000000 00000000 ef582594 ecd80930 e2babe20 c0217191 ef525800 ecd80930 00000000 00000000 00000000 ffffffff ffffffff Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5e 58 c6 83 ac 00 00 00 01 57 9d eb 74 8b 46 28 8b 8b >>EIP; c020c4c6 <===== Trace; c020962a Trace; c0217190 Trace; c023b798 Trace; c02044c8 Trace; c021d3aa Trace; c021d93a Trace; c0229ec2 Trace; c01441b2 Trace; c0142bb4 Trace; c0142c3c Trace; c01076fa Code; c020c4c6 00000000 <_EIP>: Code; c020c4c6 <===== 0: 0f 0b ud2a <===== Code; c020c4c8 2: 5e pop %esi Code; c020c4c8 3: 58 pop %eax Code; c020c4ca 4: c6 83 ac 00 00 00 01 movb $0x1,0xac(%ebx) Code; c020c4d0 b: 57 push %edi Code; c020c4d2 c: 9d popf Code; c020c4d2 d: eb 74 jmp 83 <_EIP+0x83> c020c548 Code; c020c4d4 f: 8b 46 28 mov 0x28(%esi),%eax Code; c020c4d8 12: 8b 8b 00 00 00 00 mov 0x0(%ebx),%ecx Entering kdb (current=0xe2baa000, pid 1678) on processor 0 Oops: invalid operand eax = 0x00000040 ebx = 0xef24aab4 ecx = 0xc05107ac edx = 0x00003e7c esi = 0xecd80930 edi = 0x00000202 esp = 0xe2babd30 eip = 0xc020c4c7 ebp = 0xe2babd48 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 1 warning issued. Results may not be reliable. -- Dan Rich | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) From owner-linux-xfs@oss.sgi.com Mon Feb 18 12:51:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IKpfX10039 for linux-xfs-outgoing; Mon, 18 Feb 2002 12:51:41 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IKpc910016 for ; Mon, 18 Feb 2002 12:51:38 -0800 Received: from pooh.lsc.hu (pooh.lsc.hu [195.56.172.131]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA16431 for ; Mon, 18 Feb 2002 11:45:49 -0800 (PST) mail_from (gcs@lsc.hu) Received: by pooh.lsc.hu (Postfix, from userid 547) id 994C7E039B; Mon, 18 Feb 2002 20:38:13 +0100 (CET) Date: Mon, 18 Feb 2002 20:38:13 +0100 From: GCS To: Linux XFS List Subject: Re: linux 2.4xfs + freeswan 1.95 Message-ID: <20020218203813.A3073@lsc.hu> References: <1014060422.11833.10.camel@neotrantor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014060422.11833.10.camel@neotrantor>; from xfs@esnaola.org on Mon, Feb 18, 2002 at 08:27:02PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 18, 2002 at 08:27:02PM +0100, Lionel DARNIS wrote: > drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols > in discarded section .text.exit' > make[1]: *** [kallsyms] Error 1 > make[1]: Leaving directory `/usr/src/linux' > make: *** [vmlinux] Error 2 > > An idea ?? Sure. You have a recent version of binutils right? It has some problems with kernel version 2.4.x and above. As the bug is in the kernel, there will be some workaround for it. It is true for newly created kernels only. So you have two options: - wait for a newer kernel which has the workaround for this problem, - read the README or whatsoever in binutils. It says you can also fix this. You have to edit a file in $KERNEL_HOME/arch/i386/some/file, and uncomment the discard line for .text.exit . It affects the kernel, but should not cause any harm. Cheers, GCS -- BorsodChem Joint-Stock Company Linux Support Center University of Miskolc Software engineer Programmer System administrator +36-48-512790 +36-20-4441745 From owner-linux-xfs@oss.sgi.com Mon Feb 18 12:55:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IKtGH10206 for linux-xfs-outgoing; Mon, 18 Feb 2002 12:55:16 -0800 Received: from com.esnaola.org (aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IKtA910184 for ; Mon, 18 Feb 2002 12:55:11 -0800 Received: from localhost (localhost [127.0.0.1]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 4174320D8E9; Mon, 18 Feb 2002 20:55:07 +0100 (CET) Received: from localhost.localdomain (neotrantor.esnaola.org [192.168.33.18]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 32C5220D8E8; Mon, 18 Feb 2002 20:55:05 +0100 (CET) Subject: Re: linux 2.4xfs + freeswan 1.95 From: Lionel DARNIS To: GCS Cc: Linux XFS List In-Reply-To: <20020218203813.A3073@lsc.hu> References: <1014060422.11833.10.camel@neotrantor> <20020218203813.A3073@lsc.hu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Feb 2002 20:55:18 +0100 Message-Id: <1014062118.11982.13.camel@neotrantor> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm so surprise 'cause I use the newer version of binutils and before the integration of freeswan the compile was fine...SO ?! I don't know ! Lionel On Mon, 2002-02-18 at 20:38, GCS wrote: > On Mon, Feb 18, 2002 at 08:27:02PM +0100, Lionel DARNIS wrote: > > drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols > > in discarded section .text.exit' > > make[1]: *** [kallsyms] Error 1 > > make[1]: Leaving directory `/usr/src/linux' > > make: *** [vmlinux] Error 2 > > > > An idea ?? > Sure. You have a recent version of binutils right? It has some problems > with kernel version 2.4.x and above. As the bug is in the kernel, there will > be some workaround for it. It is true for newly created kernels only. > So you have two options: > - wait for a newer kernel which has the workaround for this problem, > - read the README or whatsoever in binutils. It says you can also fix this. > You have to edit a file in $KERNEL_HOME/arch/i386/some/file, and uncomment > the discard line for .text.exit . It affects the kernel, but should not > cause any harm. > > Cheers, GCS > -- > BorsodChem Joint-Stock Company Linux Support Center University of Miskolc > Software engineer Programmer System administrator > +36-48-512790 +36-20-4441745 From owner-linux-xfs@oss.sgi.com Mon Feb 18 13:38:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ILcMn10807 for linux-xfs-outgoing; Mon, 18 Feb 2002 13:38:22 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ILcH910785 for ; Mon, 18 Feb 2002 13:38:18 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA56340 for ; Mon, 18 Feb 2002 21:38:21 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA03927; Mon, 18 Feb 2002 12:37:43 -0800 (PST) Date: Mon, 18 Feb 2002 14:37:42 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Dan Rich cc: Subject: Re: Kernel OOPS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Feb 2002, Dan Rich wrote: > I'm seeing the following crash on my server. This system is a SMP system > with a Highpoint IDE Raid controller and a Buslogic SCSI card (I'm > mentioning that because the crash appears to go away if I remove the SCSI > interface). From the output of ksymoops, it appears to be crashing in the > xfs routines. Please turn spinlock debugging off, it's not compatible with the way xfs handles signed chars... we need to do something about this some day. :) -Eric From owner-linux-xfs@oss.sgi.com Mon Feb 18 13:44:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ILi6G11212 for linux-xfs-outgoing; Mon, 18 Feb 2002 13:44:06 -0800 Received: from mail.riodata.de (firewall.riodata.de [62.16.139.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ILi2911189 for ; Mon, 18 Feb 2002 13:44:02 -0800 Received: from kaperfahrt.nebelschwaden.de (62.16.151.244) by mail.riodata.de (5.5.031) id 3C4CBEF10003E555 for linux-xfs@oss.sgi.com; Mon, 18 Feb 2002 21:47:36 +0100 Received: from nazgul.nebelschwaden.de (nazgul.nebelschwaden.de [172.16.36.10]) by kaperfahrt.nebelschwaden.de (Postfix) with ESMTP id 03A4EE53F for ; Mon, 18 Feb 2002 21:43:47 +0100 (CET) Received: from nebelschwaden.de (localhost [127.0.0.1]) by nazgul.nebelschwaden.de (Postfix) with ESMTP id F26371FB4 for ; Mon, 18 Feb 2002 21:43:53 +0100 (CET) Message-ID: <3C716789.3000908@nebelschwaden.de> Date: Mon, 18 Feb 2002 21:43:53 +0100 From: Ede Wolf Reply-To: listac@nebelschwaden.de User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:0.9.8) Gecko/20020208 X-Accept-Language: de, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If I understand right, star (a tar "successor") is able to handle ACLs and is supposed to have other advantages like improved speed and a fifo buffer. Though not yet personally tested. http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/star.html Info is inside the tarball, none on the page. Just in case you wonder. Btw.: talking about xfsdump: Is there a tool/addon that writes a tape catalog, so I can locate data without a tape beeing inserted ? The contents of /var/xfsdump seems more some kind of meta-data.Would be really nice to be able to browe some kind of database to see on which tapes what files are located. > Well, if you aren't using ACLs or other extended attribute information, > then you could use any generic backup utility like tar, cpio, bru, etc. > (Hopefully the generic utilities will start handling these things now that > the interfaces are defined.) From owner-linux-xfs@oss.sgi.com Mon Feb 18 13:58:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ILwqE12814 for linux-xfs-outgoing; Mon, 18 Feb 2002 13:58:52 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ILwk912792 for ; Mon, 18 Feb 2002 13:58:46 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA57391 for ; Mon, 18 Feb 2002 21:58:50 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA39707; Mon, 18 Feb 2002 14:57:28 -0600 (CST) Received: from sgi.com (pJwUkaziX2kUnTMf2+fiLjZKwmRlA6C8@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA65195; Mon, 18 Feb 2002 14:57:26 -0600 (CST) Message-ID: <3C716AEF.10609@sgi.com> Date: Mon, 18 Feb 2002 14:58:23 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Christoph Hellwig CC: Eric Sandeen , Wessel Dankers , linux-xfs@oss.sgi.com Subject: Re: chown32() weirdness References: <20020218181215.A26602@caldera.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig wrote: >On Mon, Feb 18, 2002 at 11:02:51AM -0600, Eric Sandeen wrote: > >>Ok, I guess this is a difference between Irix and Linux... >> > >There are two possible chown semantics. Linux has a restricted chown >by default that only allows root to change owners and thus defines >_POSIX_CHOWN_RESTRICTED. > >Some other systems (dunno about IRIX) allow both variants, depending >on configuration. Then pathconf() with _PC_CHOWN_RESTRICTED is used to >find out which semantics apply to a specific filename. > > Christoph > Irix does support both, and by removing the double permissions check I made xfs fall back to the default Irix behavior. Looks like Eric has around found the switch inside xfs to make this work the linux way. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 18 14:51:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IMpLw14000 for linux-xfs-outgoing; Mon, 18 Feb 2002 14:51:21 -0800 Received: from ente.berdmann.de (frnk-d514e11f.dsl.mediaWays.net [213.20.225.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IMpH913978 for ; Mon, 18 Feb 2002 14:51:17 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16cvgf-0006G0-00; Mon, 18 Feb 2002 22:51:05 +0100 Message-ID: <3C717749.B4EAB857@berdmann.de> Date: Mon, 18 Feb 2002 22:51:05 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: listac@nebelschwaden.de CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) References: <3C716789.3000908@nebelschwaden.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Btw.: talking about xfsdump: Is there a tool/addon that writes a tape > catalog, so I can locate data without a tape beeing inserted ? The > contents of /var/xfsdump seems more some kind of meta-data.Would be > really nice to be able to browe some kind of database to see on which > tapes what files are located. Amanda (http://www.amanda.org/) is a nice tool keeping a catalogue. You can browse it with an FTP-like interface no matter if you used dump/xfsdump/ufsdump/backup/tar for backup. The index is stored in gzipped plain text. If you're really lost in space, you can even zgrep for your files. From owner-linux-xfs@oss.sgi.com Mon Feb 18 15:28:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1INS7J01331 for linux-xfs-outgoing; Mon, 18 Feb 2002 15:28:07 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1INS3901309 for ; Mon, 18 Feb 2002 15:28:04 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA60089 for ; Mon, 18 Feb 2002 23:28:08 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA04619 for linux-xfs@oss.sgi.com; Tue, 19 Feb 2002 09:26:44 +1100 (EST) Date: Tue, 19 Feb 2002 09:26:44 +1100 (EST) From: Nathan Scott Message-Id: <200202182226.JAA04619@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Feb 18 14:22:14 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:111999a cmd/xfsmisc/README - 1.5 cmd/xfsmisc/2.4.18-pre3-ac2-quotactl.patch - 1.1 - Patch (against Alan Cox's tree, with 32-bit UID VFS quota) that integrates XFS quota with the new quota interfaces. Experimental, now being reworked with the 32-bit UID VFS quota being reworked also (to allow both old and new VFS formats to co-exist), but it might still be useful to folks merging XFS with the current 32bit UID quota (ac) patches. From owner-linux-xfs@oss.sgi.com Mon Feb 18 15:31:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1INVMe01487 for linux-xfs-outgoing; Mon, 18 Feb 2002 15:31:22 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1INV8901459 for ; Mon, 18 Feb 2002 15:31:08 -0800 Received: (qmail 16964 invoked from network); 18 Feb 2002 22:31:05 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 18 Feb 2002 22:31:05 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id DEB4F3000BA; Tue, 19 Feb 2002 08:31:01 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 836F716D; Tue, 19 Feb 2002 09:31:01 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Lionel DARNIS Cc: Linux XFS List Subject: Re: linux 2.4xfs + freeswan 1.95 In-reply-to: Your message of "18 Feb 2002 20:27:02 BST." <1014060422.11833.10.camel@neotrantor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Feb 2002 09:30:56 +1100 Message-ID: <4394.1014071456@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 18 Feb 2002 20:27:02 +0100, Lionel DARNIS wrote: > >I try to compile my cvs kernel 2.4.17xfs + freeswan 1.95 and I obtain : > > >drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols >in discarded section .text.exit' Old bugs in kernel being caught by new binutils. There are a lot of patches in 2.4.17-pre3 through 2.4.18-rc1 to remove the kernel bugs. Since you just added freeswan the bug might be in freeswan rather than the main kernel. Run this script in the top level of your linux tree to list the offending objects and report to l-k or freeswan accordingly, this is not an XFS problem. Search the archives first, most of the kernel bugs have been fixed. #!/usr/bin/perl -w # # reference_discarded.pl (C) Keith Owens 2001 # # List dangling references to vmlinux discarded sections. use strict; die($0 . " takes no arguments\n") if($#ARGV >= 0); my %object; my $object; my $line; my $ignore; $| = 1; printf("Finding objects, "); open(OBJDUMP_LIST, "find . -name '*.o' | xargs objdump -h |") || die "getting objdump list failed"; while (defined($line = )) { chomp($line); if ($line =~ /:\s+file format/) { ($object = $line) =~ s/:.*//; $object{$object}->{'module'} = 0; $object{$object}->{'size'} = 0; $object{$object}->{'off'} = 0; } if ($line =~ /^\s*\d+\s+\.modinfo\s+/) { $object{$object}->{'module'} = 1; } if ($line =~ /^\s*\d+\s+\.comment\s+/) { ($object{$object}->{'size'}, $object{$object}->{'off'}) = (split(' ', $line))[2,5]; } } close(OBJDUMP_LIST); printf("%d objects, ", scalar keys(%object)); $ignore = 0; foreach $object (keys(%object)) { if ($object{$object}->{'module'}) { ++$ignore; delete($object{$object}); } } printf("ignoring %d module(s)\n", $ignore); # Ignore conglomerate objects, they have been built from multiple objects and we # only care about the individual objects. If an object has more than one GCC: # string in the comment section then it is conglomerate. This does not filter # out conglomerates that consist of exactly one object, can't be helped. printf("Finding conglomerates, "); $ignore = 0; foreach $object (keys(%object)) { if (exists($object{$object}->{'off'})) { my ($off, $size, $comment, $l); $off = hex($object{$object}->{'off'}); $size = hex($object{$object}->{'size'}); open(OBJECT, "<$object") || die "cannot read $object"; seek(OBJECT, $off, 0) || die "seek to $off in $object failed"; $l = read(OBJECT, $comment, $size); die "read $size bytes from $object .comment failed" if ($l != $size); close(OBJECT); if ($comment =~ /GCC\:.*GCC\:/m) { ++$ignore; delete($object{$object}); } } } printf("ignoring %d conglomerate(s)\n", $ignore); printf("Scanning objects\n"); foreach $object (keys(%object)) { my $from; open(OBJDUMP, "objdump -r $object|") || die "cannot objdump -r $object"; while (defined($line = )) { chomp($line); if ($line =~ /RELOCATION RECORDS FOR /) { ($from = $line) =~ s/.*\[([^]]*).*/$1/; } if (($line =~ /\.text\.exit$/ || $line =~ /\.data\.exit$/ || $line =~ /\.exitcall\.exit$/) && ($from !~ /\.text\.exit$/ && $from !~ /\.data\.exit$/ && $from !~ /\.exitcall\.exit$/)) { printf("Error: %s %s refers to %s\n", $object, $from, $line); } } close(OBJDUMP); } printf("Done\n"); From owner-linux-xfs@oss.sgi.com Mon Feb 18 19:35:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J3ZNS05042 for linux-xfs-outgoing; Mon, 18 Feb 2002 19:35:23 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J3ZI905020 for ; Mon, 18 Feb 2002 19:35:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1J2ZBtm024720 for ; Mon, 18 Feb 2002 18:35:12 -0800 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA24325; Tue, 19 Feb 2002 13:33:55 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA39756; Tue, 19 Feb 2002 13:33:55 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 19 Feb 2002 13:33:55 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: "Bernhard R. Erdmann" cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump & compression? (was: Re: xfsdump aborts after assertionfailure) In-Reply-To: <3C70A744.C5183832@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Feb 2002, Bernhard R. Erdmann wrote: > > > 2. xfsdump -J -F - / | gzip | dd of=$TAPE bs=32k > > > > Option 2 will nullify all of xfsdump's fault tolerance features when > > writing to tape. In other words, if there's a tape error or you hit the > > end of tape, xfsdump can't recover. > > Good point. Does xfsdump's fault tolerance depend on writing/reading > to/from tape itself or will xfsrestore be happy when being fed out of a > pipe, too? xfsdump's fault tolerance for tapes, is based on splitting a dump into a number of media files and tape records and writing regular file marks. If something goes wrong, xfsdump will ask for a new tape and continue from the last file mark which was OK. With dumping to a file or pipe, xfsdump wont do any of that. The dump will be interspersed with file headers which xfsrestore will use to verify the contents, but there's no concept of xfsdump backing up and continuing a dump from an earlier position if something goes wrong. In your example, if something goes wrong, xfsdump will probably just exit early with a dump INTERRUPTED message. If there's a problem on the tape that xfsdump didn't detect, then upon restoration, xfsrestore will probably just exit early, assuming the pipe from dd broke. If you use dd with xfsdump, xfsrestore will not be able to read directly from the tape, as the dump will have been written with the drive_simple strategy (ie. the format used for files or pipes). You'd have to use dd to read from the tape, so if there's a tape error dd wont do anything to recover. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Mon Feb 18 19:37:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J3bC205174 for linux-xfs-outgoing; Mon, 18 Feb 2002 19:37:12 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J3b9905151 for ; Mon, 18 Feb 2002 19:37:09 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1J3b3xV012345 for ; Mon, 18 Feb 2002 19:37:04 -0800 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA24348; Tue, 19 Feb 2002 13:35:47 +1100 From: ivanr@sgi.com Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA39726; Tue, 19 Feb 2002 13:35:46 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 19 Feb 2002 13:35:46 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: "Bernhard R. Erdmann" cc: linux-xfs@oss.sgi.com Subject: Re: Question...xfsdump error message? In-Reply-To: <3C70A80C.F6A482FC@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Feb 2002, Bernhard R. Erdmann wrote: > > + { DMP_WARNING, "^xfsdump: WARNING: failed to get bulkstat information for inode" }, /* Linux xfsdump */ > > > > I'm not sure if you should filter this one out. That indicates an > > actual error from the bulkstat ioctl, not just a mismatch in the inode > > information. > > > > Have you actually seen xfsdump procude this message? > > Yes, I did. It happens rarely, but I have some Amanda mails stating this > message. Hmm. Well, if they happen from now on, it might be worth reporting them to the list -- they could possibly indicate a kernel bug. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Mon Feb 18 20:04:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J44xb05651 for linux-xfs-outgoing; Mon, 18 Feb 2002 20:04:59 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J44n905626 for ; Mon, 18 Feb 2002 20:04:50 -0800 Received: (qmail 7639 invoked from network); 19 Feb 2002 03:06:05 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 19 Feb 2002 03:06:05 -0000 Subject: Re: TAKE - quota patch From: Shawn Starr To: xfs In-Reply-To: <20020219102742.M161559@wobbly.melbourne.sgi.com> References: <200202182226.JAA04619@snort.melbourne.sgi.com> <1014074159.23735.21.camel@unaropia> <20020219102742.M161559@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 18 Feb 2002 22:06:03 -0500 Message-Id: <1014087965.7601.1.camel@coredump> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk compile errors with quota_info and quota_mount_operations i believe. the structures are the same yet XFS's is has more. and superblock issues. Shawn. On Mon, 2002-02-18 at 18:27, Nathan Scott wrote: > On Mon, Feb 18, 2002 at 06:15:31PM -0500, Shawn Starr wrote: > > I wonder if this will fix some of the Quota compile problems with > > -pre9-ac4? > > > > XFS quota + Linux quota. > > > > Possibly - what is the compile failure message? > > This patch was the initial attempt at integrating XFS quota > and VFS quota well (as opposed to the hack in the XFS CVS > tree). A new version is in the works, and hopefully the > new one will be shipped by the 32bit uid quota maintainer > (Jan Kara) with his patches, so integration from then on > would be seamless. > > cheers. > > > Shawn. > > > > On Mon, 2002-02-18 at 17:26, Nathan Scott wrote: > > > > > > Date: Mon Feb 18 14:22:14 PST 2002 > > > Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs > > > > > > The following file(s) were checked into: > > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > > > > > > Modid: xfs-cmds:slinx:111999a > > > cmd/xfsmisc/README - 1.5 > > > cmd/xfsmisc/2.4.18-pre3-ac2-quotactl.patch - 1.1 > > > - Patch (against Alan Cox's tree, with 32-bit UID VFS quota) that > > > integrates XFS quota with the new quota interfaces. Experimental, > > > now being reworked with the 32-bit UID VFS quota being reworked > > > also (to allow both old and new VFS formats to co-exist), but it > > > might still be useful to folks merging XFS with the current 32bit > > > UID quota (ac) patches. > > > > > > > > > > > > > > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Mon Feb 18 20:19:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J4JO706210 for linux-xfs-outgoing; Mon, 18 Feb 2002 20:19:24 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J4JI906188 for ; Mon, 18 Feb 2002 20:19:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA07861 for ; Mon, 18 Feb 2002 19:19:17 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA24514; Tue, 19 Feb 2002 14:18:00 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA44252; Tue, 19 Feb 2002 14:18:00 +1100 (AEDT) Date: Tue, 19 Feb 2002 14:17:59 +1100 From: Nathan Scott To: Shawn Starr Cc: xfs Subject: Re: TAKE - quota patch Message-ID: <20020219141758.N161559@wobbly.melbourne.sgi.com> References: <200202182226.JAA04619@snort.melbourne.sgi.com> <1014074159.23735.21.camel@unaropia> <20020219102742.M161559@wobbly.melbourne.sgi.com> <1014087965.7601.1.camel@coredump> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014087965.7601.1.camel@coredump>; from spstarr@sh0n.net on Mon, Feb 18, 2002 at 10:06:03PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Feb 18, 2002 at 10:06:03PM -0500, Shawn Starr wrote: > compile errors with quota_info and quota_mount_operations i believe. the > structures are the same yet XFS's is has more. and superblock issues. > Thats certainly the area this patch targets. If you can send me more specific details like compile errors, etc, I should be able to comment further. Note: this patch is against the -ac tree, and _not_ XFS itself (ie. apply it first before applying any XFS patches). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 18 20:50:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J4ov006780 for linux-xfs-outgoing; Mon, 18 Feb 2002 20:50:57 -0800 Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J4og906755 for ; Mon, 18 Feb 2002 20:50:43 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel13.hp.com (Postfix) with ESMTP id 902CA400625; Mon, 18 Feb 2002 11:32:42 -0800 (PST) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 87258E000B2; Mon, 18 Feb 2002 11:32:42 -0800 (PST) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id <17ZBFT1X>; Mon, 18 Feb 2002 11:32:42 -0800 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'Steve Lord '" , "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: "''linux-xfs@oss.sgi.com' '" Subject: RE: nfsd lockups with xfs during SPEC SFS testing Date: Mon, 18 Feb 2002 11:32:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve + crew, Here's the latest list of our lockups during SPEC SFS NFS testing. Two consecutive tests locked up in lock_wait, either through mraccessf or mrupdatef. What are these functions trying to accomplish, and who could be holding the locks that mraccessf/mrupdatef are waiting for? Here are the call traces from magic_sysrq for the locked up processes for the two tests: run #1 task: kswapd (pid: 7) c01e60ed: c01e6040 T lock_wait c01e61dd: c01e61b4 T mrupdatef c01d5329: c01d5310 T xfs_finish_reclaim c01b88d5: c01b8870 T xfs_ilock_ra c01b8913: c01b8900 T xfs_ilock c01d5329: c01d5310 T xfs_finish_reclaim c01d5329: c01d5310 T xfs_finish_reclaim c01d52ec: c01d5110 t xfs_reclaim c01e5088: c01e5068 T vn_reclaim c01e54ad: c01e541c T vn_purge c01e55f5: c01e55b0 T vn_remove c01e44db: c01e44c0 T linvfs_clear_inode c01476a4: c014761c T clear_inode c014771f: c01476e4 t dispose_list c014796c: c01478b4 T prune_icache c01479a7: c014798c T shrink_icache_memory c012d0e9: c012d07c t shrink_caches c012d13c: c012d100 T try_to_free_pages c012d1d3: c012d190 t kswapd_balance_pgdat c012d22e: c012d21c t kswapd_balance c012d33d: c012d2a4 T kswapd c0105594: c010556c T kernel_thread run #2: c01e60ed: c01e6040 T lock_wait c01e619c: c01e614c T mraccessf c01cf9d4: c01cf990 T xfs_getattr c01b88f6: c01b8870 T xfs_ilock_ra c01b8913: c01b8900 T xfs_ilock c01cf9d4: c01cf990 T xfs_getattr c01cf9d4: c01cf990 T xfs_getattr c01e5347: c01e5310 T vn_revalidate c01cd57a: c01cd448 T xfs_dir_lookup_int c01b8a1f: c01b89dc T xfs_iunlock c01b886b: c01b885c T xfs_iunlock_map_shared c01d1baf: c01d1ac8 t xfs_lookup c01dfe5e: c01dfe48 T linvfs_revalidate_core c01df6ce: c01df634 T linvfs_lookup c013e145: c013e098 T lookup_hash c013e1eb: c013e194 T lookup_one_len c016262d: c0162360 T nfsd_lookup c0167fe8: c0167f14 t nfsd3_proc_lookup c015f943: c015f874 t nfsd_dispatch c02bd765: c02bd4d8 T svc_process c015f6e9: c015f49c t nfsd c0105594: c010556c T kernel_thread Both locked processes accessed mrupdatef and mraccessf through the following code in fs/xfs/xfs_iget.c:xfs_ilock_ra() if (lock_flags & XFS_ILOCK_EXCL) { mrupdatef(&ip->i_lock, PLTWAIT); ip->i_ilock_ra = return_address; } else if (lock_flags & XFS_ILOCK_SHARED) { mraccessf(&ip->i_lock, PLTWAIT); } -----Original Message----- From: Steve Lord To: HABBINGA,ERIK " "(HP-Loveland,ex1) Cc: 'linux-xfs@oss.sgi.com' Sent: 2/1/02 10:34 AM Subject: RE: nfsd lockups with xfs during SPEC SFS testing On Thu, 2002-01-31 at 16:38, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Steve, > A co-worker of mine sent me a patch containing the CVS bits at 3:21pm > Mountain time 1/30/02, he started the CVS download at 2:37pm Mountain time > 1/30/02 and ended it at 2:38pm Mountain time 1/30/02. I've been working on > a patch to remove the BKL from the nfsd process, and have been seeing > lockups in the xfs code. I saw these lockups with XFS CVS downloads from > 1/10/02 and 1/18/02. I finally started running SPEC tests with out my > nfsd-BKL-removal patch and still got lockups in the XFS code. So, I don't > think this is a regression. > > I ran another test this morning, and got a different profile of lockups. > I've attached the decoded output from alt-sysrq. kupdated is locked up in > xlog_grant_log_space, and all the nfsd processes are locked up either in: > > - fh_lock (all the nfsd3_proc_create->stext_lock->__down_failed->__down > cases) > - nfsd_sync (the nfsd_commit->stext_lock->__down_failed->__down cases) > - pagebuf_grab_lock (the > _pagebuf_find_lockable_buffer->stext_lock->__down_failed->__down cases) > - lock_wait (the xfs_access->mraccessf->lock_wait cases) > - xlog_grant_log_space > > I'll help anyway I can to track this problem down. > > Erik > Are you using anything unusual as the block device here? I would be suspicious of it not coming back with I/O completions. Basically all the places threads are waiting are places we wait blocked for a read or a write to complete. If you have other filesystems on the same device, can you do I/O to them? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Feb 18 22:33:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J6Xfd08087 for linux-xfs-outgoing; Mon, 18 Feb 2002 22:33:41 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J6XZ908065 for ; Mon, 18 Feb 2002 22:33:35 -0800 Received: (qmail 7932 invoked from network); 19 Feb 2002 05:34:52 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 19 Feb 2002 05:34:52 -0000 Subject: Re: TAKE - quota patch From: Shawn Starr To: Nathan Scott Cc: xfs In-Reply-To: <20020219141758.N161559@wobbly.melbourne.sgi.com> References: <200202182226.JAA04619@snort.melbourne.sgi.com> <1014074159.23735.21.camel@unaropia> <20020219102742.M161559@wobbly.melbourne.sgi.com> <1014087965.7601.1.camel@coredump> <20020219141758.N161559@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 19 Feb 2002 00:34:51 -0500 Message-Id: <1014096892.7605.26.camel@coredump> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sounds right on. That's the issue. I will have more compile time issues tomorrow. But I will be merging that ac patch then rc2-ac1 (we'll see) then XFS and see what I can fix :) until then..Zzzzz.. Shawn. On Mon, 2002-02-18 at 22:17, Nathan Scott wrote: > On Mon, Feb 18, 2002 at 10:06:03PM -0500, Shawn Starr wrote: > > compile errors with quota_info and quota_mount_operations i believe. the > > structures are the same yet XFS's is has more. and superblock issues. > > > > Thats certainly the area this patch targets. If you can send me > more specific details like compile errors, etc, I should be able > to comment further. > > Note: this patch is against the -ac tree, and _not_ XFS itself > (ie. apply it first before applying any XFS patches). > > cheers. > > -- > Nathan > > From owner-linux-xfs@oss.sgi.com Tue Feb 19 03:04:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JB42413062 for linux-xfs-outgoing; Tue, 19 Feb 2002 03:04:02 -0800 Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JB3q913038 for ; Tue, 19 Feb 2002 03:03:54 -0800 Received: from d1o836.telia.com (d1o836.telia.com [213.65.240.241]) by mailg.telia.com (8.11.6/8.11.6) with ESMTP id g1JA3oo08077 for ; Tue, 19 Feb 2002 11:03:50 +0100 (CET) Received: from localhost.localdomain (h42n2fls32o836.telia.com [217.208.105.42]) by d1o836.telia.com (8.10.2/8.10.1) with ESMTP id g1JA3WL20320 for ; Tue, 19 Feb 2002 11:03:34 +0100 (CET) Subject: linux 2.5.5-pre1 From: David Holm To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OzcHAsMWpuDLJ82900fG" X-Mailer: Evolution/1.0.2 Date: 19 Feb 2002 11:03:21 +0100 Message-Id: <1014113013.29703.2.camel@britain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-OzcHAsMWpuDLJ82900fG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I tried applying linux-2.5.5-pre1-xfs-2002-02-17.patch against my 2.5.5-pre1 tree today. I've been waiting for alsa integration for sooo long so I must upgrade now. However the xfs patch fails at nearly every hunk except for those that create new files. //David Holm --=-OzcHAsMWpuDLJ82900fG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8ciLp/ZJ6wQCuDu8RAn2EAKCrSgp67dtwzBfUoiTLbKo0LPCzIwCgpVG4 PMS0eJR7kqPOpVJalf2RSDE= =Cduy -----END PGP SIGNATURE----- --=-OzcHAsMWpuDLJ82900fG-- From owner-linux-xfs@oss.sgi.com Tue Feb 19 03:23:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JBNFH13420 for linux-xfs-outgoing; Tue, 19 Feb 2002 03:23:15 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JBNA913398 for ; Tue, 19 Feb 2002 03:23:11 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16d7LW-0001xO-00; Tue, 19 Feb 2002 11:18:02 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Bernhard R. Erdmann" Date: Tue, 19 Feb 2002 11:18:02 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2469) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C717749.B4EAB857@berdmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [OT] Amanda (was Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Feb 2002 22:51:05 +0100, Bernhard R. Erdmann wrote: [...] >Amanda (http://www.amanda.org/) is a nice tool keeping a catalogue. You >can browse it with an FTP-like interface no matter if you used >dump/xfsdump/ufsdump/backup/tar for backup. The index is stored in >gzipped plain text. If you're really lost in space, you can even zgrep >for your files. Well, Amanda *is* nice, I also use it in the office, but what really f*cks me off is that Amanda obviously can't span a filesystem across multiple tapes (or is it just me being too stupid to properly configure it?!). -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Feb 19 03:50:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JBoDX14012 for linux-xfs-outgoing; Tue, 19 Feb 2002 03:50:13 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JBmB913946 for ; Tue, 19 Feb 2002 03:48:11 -0800 Received: from ledzep.dyndns.org (12-237-133-3.client.attbi.com [12.237.133.3]) 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 CAA06739 for ; Tue, 19 Feb 2002 02:48:08 -0800 (PST) mail_from (ledzep37@attbi.com) Received: from attbi.com (IDENT:jo+95bbJbn54fNU6AFUukI3DROr+yPOn@localhost [127.0.0.1]) by ledzep.dyndns.org (8.11.6/8.11.6) with ESMTP id g1JAPOq06614 for ; Tue, 19 Feb 2002 04:25:24 -0600 Message-ID: <3C722814.416C9A85@attbi.com> Date: Tue, 19 Feb 2002 04:25:24 -0600 From: Jordan Breeding Organization: University of Texas at Dallas - Student X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.5-pre1-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel oops with current xfs CVS code and smp... Content-Type: multipart/mixed; boundary="------------6572B8388E8531B4CF0F92EC" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------6572B8388E8531B4CF0F92EC Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Hello, I have an smp system and have been using the Robert M. Love preempt patches for some time now with no problem. I have also been wanting to try out the xfs filesystem for some time now, so since the cvs tree was recently updated to the 2.5.5-pre1 kernel which has ALSA and preempt included I decided to try making an xfs system. Everything was going great, kernel build, recreating my filesystems, etc. until I needed to do the final reboot into my new kernel. The resulting smp and preempt kernel (also has current acpi and Robert M. Love's networking patches to allow contributions to /dev/random) will boot just fine but soon after booting the kernel and the userland init level stuff starts up the kernel will oops everytime. The only way I have found to make the kernel not oops was to boot it using the "nosmp" argument. I assume that xfs is tested fairly well with smp since it has been out for a while but I am guessing it has no gotten a lot of testing against the preempt stuff. Anyway if anyone knows what the problem is or how to fix it I would appreciate it greatly. I am attaching a copy of the oops (processed and raw) as well as my .config file. Thanks for the help and the great file system. Jordan Breeding Please Cc: me if possible as I am not currently on the list. --------------6572B8388E8531B4CF0F92EC Content-Type: text/plain; charset=iso-8859-15; name="oops" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="oops" invalid operand: 0000 CPU: 0 EIP: 0010:[] Not Tainted EFALGS: 00010082 eax: 00000038 ebx: 004a1e98 ecx: 00000038 edx: 00005c10 esi: 00000000 edi: f66a6000 ebp: f7a80750 esp: f66a7dd4 ds: 0018 es: 0018 ss: 0018 Process rm (pid: 1414, threadinfo=f66a600 task=f7296920) Stack: c0447520 00000056 f7a80750 f7a8acc4 f7a69800 f7366a04 f7a8ad70 00000292 f7a8ad70 0002c5b8 00000292 c01c8ac6 f7a8acc4 f7a80750 f7a69800 0002c5c8 f73669d0 f73669d0 00000000 f66a6000 c01d75f1 f7a69800 0002abb8 00000002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8b 4c 24 28 c6 81 ac 00 00 00 01 ff 4f 10 8b --------------6572B8388E8531B4CF0F92EC Content-Type: text/plain; charset=iso-8859-15; name="oops.processed" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="oops.processed" ksymoops 2.4.3 on i686 2.5.5-pre1-xfs. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.5.5-pre1-xfs (specified) -m /boot/System.map-2.5.5-pre1-xfs (specified) Warning (compare_maps): ksyms_base symbol idle_cpu_R__ver_idle_cpu not found in System.map. Ignoring ksyms_base entry invalid operand: 0000 CPU: 0 EIP: 0010:[] Not Tainted Using defaults from ksymoops -t elf32-i386 -a i386 eax: 00000038 ebx: 004a1e98 ecx: 00000038 edx: 00005c10 esi: 00000000 edi: f66a6000 ebp: f7a80750 esp: f66a7dd4 ds: 0018 es: 0018 ss: 0018 Stack: c0447520 00000056 f7a80750 f7a8acc4 f7a69800 f7366a04 f7a8ad70 00000292 f7a8ad70 0002c5b8 00000292 c01c8ac6 f7a8acc4 f7a80750 f7a69800 0002c5c8 f73669d0 f73669d0 00000000 f66a6000 c01d75f1 f7a69800 0002abb8 00000002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8b 4c 24 28 c6 81 ac 00 00 00 01 ff 4f 10 8b >>EIP; c01cb9d0 <===== Trace; c01c8ac6 Trace; c01d75f0 Trace; c01c3150 Trace; c01deea4 Trace; c01f5c34 Trace; c016565a Trace; c01f3e46 Trace; c016a364 Trace; c01657e6 Trace; c015de52 Trace; c01093fe Code; c01cb9d0 00000000 <_EIP>: Code; c01cb9d0 <===== 0: 0f 0b ud2a <===== Code; c01cb9d2 2: 83 c4 08 add $0x8,%esp Code; c01cb9d4 5: 8b 4c 24 28 mov 0x28(%esp,1),%ecx Code; c01cb9d8 9: c6 81 ac 00 00 00 01 movb $0x1,0xac(%ecx) Code; c01cb9e0 10: ff 4f 10 decl 0x10(%edi) Code; c01cb9e2 13: 8b 00 mov (%eax),%eax 1 warning issued. Results may not be reliable. --------------6572B8388E8531B4CF0F92EC Content-Type: text/plain; charset=iso-8859-15; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=".config" # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_PREEMPT=y # CONFIG_MULTIQUAD is not set CONFIG_HAVE_DEC_LOCK=y # # General options # # # ACPI Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=y # CONFIG_ACPI_THERMAL is not set # CONFIG_ACPI_DEBUG is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP is not set CONFIG_PNPBIOS=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y CONFIG_IPV6=y # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_IDEDISK_STROKE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=y CONFIG_IDE_TASK_IOCTL=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_PIIX_TUNING is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC_ADMA is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_PDC202XX_FORCE is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y CONFIG_IDEDMA_IVB=y # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_BUILD_FIRMWARE=y # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_DEBUG is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set CONFIG_NET_RANDOM=y # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=y # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=y CONFIG_PPP_MULTILINK=y # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=y CONFIG_PPP_SYNC_TTY=y CONFIG_PPP_DEFLATE=y CONFIG_PPP_BSDCOMP=y # CONFIG_PPPOE is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_KEYBDEV=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_GAMEPORT_PCIGAME is not set # CONFIG_GAMEPORT_FM801 is not set # CONFIG_GAMEPORT_CS461x is not set # CONFIG_SERIO is not set # CONFIG_SERIO_SERPORT is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_JOYSTICK_ANALOG is not set # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE_USB is not set # CONFIG_JOYSTICK_IFORCE_232 is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_DB9 is not set # CONFIG_JOYSTICK_GAMECON is not set # CONFIG_JOYSTICK_TURBOGRAFX is not set # # Character devices # CONFIG_ECC=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=512 # # I2C support # CONFIG_I2C=y CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_BITLP is not set # CONFIG_I2C_BITELV is not set # CONFIG_I2C_BITVELLE is not set # CONFIG_I2C_ALGOPCF is not set CONFIG_I2C_MAINBOARD=y # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_HYDRA is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_TSUNAMI is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_VIA is not set CONFIG_I2C_VIAPRO=y # CONFIG_I2C_VOODOO3 is not set CONFIG_I2C_ISA=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_PROC=y # # Hardware sensors support # CONFIG_SENSORS=y # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1024 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_FSCSCY is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_MAXILIFE is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_MTP008 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_THMC50 is not set CONFIG_SENSORS_VIA686A=y # CONFIG_SENSORS_W83781D is not set CONFIG_SENSORS_OTHER=y # CONFIG_SENSORS_BT869 is not set CONFIG_SENSORS_DDCMON=y CONFIG_SENSORS_EEPROM=y # CONFIG_SENSORS_MATORB is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y # CONFIG_AGP_INTEL is not set # CONFIG_AGP_I810 is not set CONFIG_AGP_VIA=y # CONFIG_AGP_AMD is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_ALI is not set # CONFIG_AGP_SWORKS is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=y # CONFIG_DRM_I810 is not set # CONFIG_DRM_MGA is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=y # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_CDDA_FS=y # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set CONFIG_UFS_FS=y CONFIG_UFS_FS_WRITE=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set CONFIG_HAVE_ATTRCTL=y # CONFIG_XFS_DMAPI is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_SMB_FS=y # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y # CONFIG_FB_RIVA is not set # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_VESA is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_MATROX is not set # CONFIG_FB_ATY is not set CONFIG_FB_RADEON=y # CONFIG_FB_ATY128 is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VIRTUAL is not set CONFIG_FBCON_ADVANCED=y # CONFIG_FBCON_MFB is not set # CONFIG_FBCON_CFB2 is not set # CONFIG_FBCON_CFB4 is not set CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y # CONFIG_FBCON_AFB is not set # CONFIG_FBCON_ILBM is not set # CONFIG_FBCON_IPLAN2P2 is not set # CONFIG_FBCON_IPLAN2P4 is not set # CONFIG_FBCON_IPLAN2P8 is not set # CONFIG_FBCON_MAC is not set # CONFIG_FBCON_VGA_PLANES is not set # CONFIG_FBCON_VGA is not set # CONFIG_FBCON_HGA is not set # CONFIG_FBCON_FONTWIDTH8_ONLY is not set CONFIG_FBCON_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_6x11 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # # Sound # CONFIG_SOUND=y # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # Advanced Linux Sound Architecture # CONFIG_SND=y # CONFIG_SND_RTCTIMER is not set CONFIG_SND_SEQUENCER=y # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_DEBUG is not set # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_DT0197H is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_CS46XX is not set CONFIG_SND_EMU10K1=y # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA686 is not set # CONFIG_SND_VIA8233 is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_LONG_TIMEOUT=y # CONFIG_USB_EHCI_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_ALT=y # CONFIG_USB_OHCI is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set CONFIG_USB_HID=y CONFIG_USB_HIDDEV=y # CONFIG_USB_WACOM is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_AUERSWALD is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_HIGHMEM=y CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_IOVIRT=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_KDB is not set # CONFIG_KDB_MODULES is not set # CONFIG_KALLSYMS is not set # CONFIG_FRAME_POINTER is not set # # Library routines # CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y --------------6572B8388E8531B4CF0F92EC-- From owner-linux-xfs@oss.sgi.com Tue Feb 19 04:18:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JCICm14715 for linux-xfs-outgoing; Tue, 19 Feb 2002 04:18:12 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JCI8914693 for ; Tue, 19 Feb 2002 04:18:08 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16d8Fq-0002Aj-00 for linux-xfs@oss.sgi.com; Tue, 19 Feb 2002 12:16:14 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Tue, 19 Feb 2002 12:16:14 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2469) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: xfstests on Debian testing: Should search for db1/ndbm.h Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, if I interpret things correctly the configure script ONLY searches for gdbm/ndbm.h. However, under Debian testing the ndbm.h include file is in db1/ndbm.h. I guess this should be added to the configure script. I'm using CVS source from Feb 6, 2002. Thanks, Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Feb 19 05:52:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JDqli15828 for linux-xfs-outgoing; Tue, 19 Feb 2002 05:52:47 -0800 Received: from ente.berdmann.de (frnk-d514e11f.dsl.mediaWays.net [213.20.225.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JDqh915806 for ; Tue, 19 Feb 2002 05:52:43 -0800 Received: from james.berdmann.de ([192.168.1.1]) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16d9l6-0007bM-00; Tue, 19 Feb 2002 13:52:36 +0100 Received: from be by james.berdmann.de with local (Exim 3.22 #1) id 16d9l5-0005Rg-00; Tue, 19 Feb 2002 13:52:35 +0100 Date: Tue, 19 Feb 2002 13:52:35 +0100 From: "Bernhard R. Erdmann" To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" Subject: Re: [OT] Amanda (was Re: xfsdump & compression? (was: Re: xfsdump aborts after assertion failure) Message-ID: <20020219135235.C20921@berdmann.de> References: <3C717749.B4EAB857@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rabe@RWTH-Aachen.DE on Tue, Feb 19, 2002 at 11:18:02AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 19, 2002 at 11:18:02AM +0100, Ralf G. R. Bergs wrote: [...] > Well, Amanda *is* nice, I also use it in the office, but what really f*cks me > off is that Amanda obviously can't span a filesystem across multiple tapes (or > is it just me being too stupid to properly configure it?!). No - currently this feature is not available. Usually, people back up subdirs of big filesystems larger than a single tape using tar. From owner-linux-xfs@oss.sgi.com Tue Feb 19 05:58:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JDwOK16077 for linux-xfs-outgoing; Tue, 19 Feb 2002 05:58:24 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JDw9916027 for ; Tue, 19 Feb 2002 05:58:09 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16d9mD-0002UH-00 for linux-xfs@oss.sgi.com; Tue, 19 Feb 2002 13:53:45 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Tue, 19 Feb 2002 13:53:45 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2469) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Failed check 064?! Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, what does it mean if my machine fails in check 064? I could not detect anything in the log file that could give me a hint... I've re-run 064, and this time there wasn't any error.... Ok, I've yet again re-run it, and this time there ARE comparison errors again: 064 57s ... - output mismatch (see 064.out.bad) 82,83c82,83 < xfsdump: ino map phase 3: pruning unneeded subtrees < xfsdump: ino map phase 4: estimating dump size --- > xfsdump: ino map phase 3: skipping (no pruning necessary) > xfsdump: ino map phase 4: skipping (size estimated in phase 2) 449a450,497 > dumpdir/file2 > dumpdir/file2_h1 > dumpdir/file2_h2 > dumpdir/file2_h3 > dumpdir/file2_h4 > dumpdir/file2_h5 > dumpdir/file3 > dumpdir/file3_h1 > dumpdir/file3_h2 > dumpdir/file3_h3 > dumpdir/file3_h4 > dumpdir/file3_h5 > dumpdir/file4 > dumpdir/file4_h1 > dumpdir/file4_h2 > dumpdir/file4_h3 > dumpdir/file4_h4 > dumpdir/file4_h5 > dumpdir/file5 > dumpdir/file5_h1 > dumpdir/file5_h2 > dumpdir/file5_h3 > dumpdir/file5_h4 > dumpdir/file5_h5 > dumpdir/file6 > dumpdir/file6_h1 > dumpdir/file6_h2 > dumpdir/file6_h3 > dumpdir/file6_h4 > dumpdir/file6_h5 > dumpdir/file7 > dumpdir/file7_h1 > dumpdir/file7_h2 > dumpdir/file7_h3 > dumpdir/file7_h4 > dumpdir/file7_h5 > dumpdir/file8 > dumpdir/file8_h1 > dumpdir/file8_h2 > dumpdir/file8_h3 > dumpdir/file8_h4 > dumpdir/file8_h5 > dumpdir/file9 > dumpdir/file9_h1 > dumpdir/file9_h2 > dumpdir/file9_h3 > dumpdir/file9_h4 > dumpdir/file9_h5 Failures: 064 Failed 1 of 1 tests And another run gave me YET a different output: diff 064.out 064.out.bad 449a450,479 > dumpdir/file5 > dumpdir/file5_h1 > dumpdir/file5_h2 > dumpdir/file5_h3 > dumpdir/file5_h4 > dumpdir/file5_h5 > dumpdir/file6 > dumpdir/file6_h1 > dumpdir/file6_h2 > dumpdir/file6_h3 > dumpdir/file6_h4 > dumpdir/file6_h5 > dumpdir/file7 > dumpdir/file7_h1 > dumpdir/file7_h2 > dumpdir/file7_h3 > dumpdir/file7_h4 > dumpdir/file7_h5 > dumpdir/file8 > dumpdir/file8_h1 > dumpdir/file8_h2 > dumpdir/file8_h3 > dumpdir/file8_h4 > dumpdir/file8_h5 > dumpdir/file9 > dumpdir/file9_h1 > dumpdir/file9_h2 > dumpdir/file9_h3 > dumpdir/file9_h4 > dumpdir/file9_h5 /usr/src/linux-2.4-xfs/cmd/xfstests# xfsdump xfsdump: version 3.0 Debian package ver. is 1.1.14-1. Source was fetched from the CVS repos. on Feb. 6th, 2002. Any idea?! Thanks, Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Feb 19 07:39:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JFdbI17517 for linux-xfs-outgoing; Tue, 19 Feb 2002 07:39:37 -0800 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JFdV917494 for ; Tue, 19 Feb 2002 07:39:32 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id g1JEdOw00563; Tue, 19 Feb 2002 15:39:24 +0100 Date: Tue, 19 Feb 2002 15:39:24 +0100 From: Krzysztof Rusocki To: Jordan Breeding Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel oops with current xfs CVS code and smp... Message-ID: <20020219143924.GA31817@main.braxis.co.uk> References: <3C722814.416C9A85@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <3C722814.416C9A85@attbi.com> User-Agent: Mutt/1.3.25i X-PGP-Key-URL: http://braxis.co.uk/~kszysiu/kszysiu.pgp Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 19, 2002 at 04:25:24AM -0600, Jordan Breeding wrote: > Hello, > > I have an smp system and have been using the Robert M. Love preempt > patches for some time now with no problem. I have also been wanting to > try out the xfs filesystem for some time now, so since the cvs tree was > recently updated to the 2.5.5-pre1 kernel which has ALSA and preempt > included I decided to try making an xfs system. Everything was going > great, kernel build, recreating my filesystems, etc. until I needed to > do the final reboot into my new kernel. The resulting smp and preempt > kernel (also has current acpi and Robert M. Love's networking patches to > allow contributions to /dev/random) will boot just fine but soon after > booting the kernel and the userland init level stuff starts up the > kernel will oops everytime. The only way I have found to make the > kernel not oops was to boot it using the "nosmp" argument. I assume > that xfs is tested fairly well with smp since it has been out for a > while but I am guessing it has no gotten a lot of testing against the > preempt stuff. Anyway if anyone knows what the problem is or how to fix > it I would appreciate it greatly. I am attaching a copy of the oops > (processed and raw) as well as my .config file. Thanks for the help and > the great file system. Hi Jordan, You're not first reporting oops with such backtrace. Turn off spinlock debugging, since it is not compatible with XFS. Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Tue Feb 19 07:59:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JFx1a17846 for linux-xfs-outgoing; Tue, 19 Feb 2002 07:59:01 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JFwv917824 for ; Tue, 19 Feb 2002 07:58:57 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA01288 for ; Tue, 19 Feb 2002 06:58:53 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA45264; Tue, 19 Feb 2002 08:57:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA89226; Tue, 19 Feb 2002 08:57:40 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1JEtWH03434; Tue, 19 Feb 2002 08:55:32 -0600 Subject: Re: Failed check 064?! From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Feb 2002 08:55:32 -0600 Message-Id: <1014130532.3393.26.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-19 at 06:53, Ralf G. R. Bergs wrote: > Hi there, > > what does it mean if my machine fails in check 064? I could not detect > anything in the log file that could give me a hint... > > I've re-run 064, and this time there wasn't any error.... > > Ok, I've yet again re-run it, and this time there ARE comparison errors again: > I have seen this too, I passed the issue on to the Australian folks. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 19 08:03:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JG3gx18143 for linux-xfs-outgoing; Tue, 19 Feb 2002 08:03:42 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JG3b918119 for ; Tue, 19 Feb 2002 08:03:37 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1JF3Wtm011395 for ; Tue, 19 Feb 2002 07:03:32 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA98917; Tue, 19 Feb 2002 07:03:00 -0800 (PST) Date: Tue, 19 Feb 2002 09:02:59 -0600 (CST) From: Eric Sandeen X-X-Sender: To: David Holm cc: Subject: Re: linux 2.5.5-pre1 In-Reply-To: <1014113013.29703.2.camel@britain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Let me take a look, the patch build process is automated, but sometimes it gets off-course. :) -Eric On 19 Feb 2002, David Holm wrote: > Hi, > I tried applying linux-2.5.5-pre1-xfs-2002-02-17.patch against my > 2.5.5-pre1 tree today. I've been waiting for alsa integration for sooo > long so I must upgrade now. > However the xfs patch fails at nearly every hunk except for those that > create new files. > > //David Holm > From owner-linux-xfs@oss.sgi.com Tue Feb 19 09:51:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JHpqg21702 for linux-xfs-outgoing; Tue, 19 Feb 2002 09:51:52 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JHpk921680 for ; Tue, 19 Feb 2002 09:51:46 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 IAA12077 for ; Tue, 19 Feb 2002 08:47:20 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA46074; Tue, 19 Feb 2002 10:50:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA14045; Tue, 19 Feb 2002 10:50:29 -0600 (CST) Subject: Re: linux 2.5.5-pre1 From: Eric Sandeen To: David Holm Cc: linux-xfs@oss.sgi.com In-Reply-To: <1014113013.29703.2.camel@britain> References: <1014113013.29703.2.camel@britain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Feb 2002 10:50:29 -0600 Message-Id: <1014137429.12554.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, new patch on the way to oss... I have to fix that script someday! -Eric On Tue, 2002-02-19 at 04:03, David Holm wrote: > Hi, > I tried applying linux-2.5.5-pre1-xfs-2002-02-17.patch against my > 2.5.5-pre1 tree today. I've been waiting for alsa integration for sooo > long so I must upgrade now. > However the xfs patch fails at nearly every hunk except for those that > create new files. > > //David Holm -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 19 10:35:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JIZvv22760 for linux-xfs-outgoing; Tue, 19 Feb 2002 10:35:57 -0800 Received: from dream.lapseofthought.com (adsl-66-124-80-202.dsl.snfc21.pacbell.net [66.124.80.202]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JIZe922737 for ; Tue, 19 Feb 2002 10:35:41 -0800 Received: (from drich@localhost) by dream.lapseofthought.com (8.11.6/8.11.6) id g1JHZLi11924; Tue, 19 Feb 2002 09:35:21 -0800 Date: Tue, 19 Feb 2002 09:35:21 -0800 (PST) From: Dan Rich X-X-Sender: To: Eric Sandeen cc: Subject: Re: Kernel OOPS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Feb 2002, Eric Sandeen wrote: > On Mon, 18 Feb 2002, Dan Rich wrote: > > > I'm seeing the following crash on my server. This system is a SMP system > > with a Highpoint IDE Raid controller and a Buslogic SCSI card (I'm > > mentioning that because the crash appears to go away if I remove the SCSI > > interface). From the output of ksymoops, it appears to be crashing in the > > xfs routines. > > Please turn spinlock debugging off, it's not compatible with the way xfs > handles signed chars... we need to do something about this some day. :) Ok, I did and that fixed *most* of my crashing. However, I still have the crash below when I'm trying to backup the system with amanda (in fact, this is the crash that got me to turn on spinlock debugging in the first place :) Any thoughts? Unable to handle kernel NULL pointer dereference at virtual address 0000009c c021d988 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: 00000074 ebx: 00000074 ecx: 00000008 edx: ffffffe8 esi: c04d1ac0 edi: 00000000 ebp: e4095964 esp: e4095960 ds: 0018 es: 0018 ss: 0018 Process xfsdump (pid: 15236, stackpage=e4095000) Stack: ffffffe8 e4095978 c01e8b94 00000074 00000288 c01e8639 e40959a0 c01e8639 ffffffe8 00000008 e31ce164 00545878 00000000 00000000 00b0184f bffffcc0 e40959ec c01ed70e ef4a2400 00000000 00b0184f 00000000 00000008 e40959dc Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f0 fe 4b 28 0f 88 25 1d 15 00 8b 43 08 85 c0 74 18 ff 43 04 >>EIP; c021d988 <===== Trace; c01e8b94 Trace; c01e8638 Trace; c01e8638 Trace; c01ed70e Trace; c01ee57c Trace; c01ee7a4 Trace; c01ed630 Trace; c020e82e Trace; c02089d0 Trace; c021d568 Trace; c01d465e Trace; c0207f62 Trace; c020c1ac <_pagebuf_free_lockable_buffer+2c/40> Trace; c02083e0 <_pagebuf_free_object+e0/110> Trace; c0208dc6 Trace; c01fcac4 Trace; c01de954 Trace; c01d49a0 Trace; c01d77e4 Trace; c01d6b10 Trace; c01308b0 Trace; c020d006 Trace; c020d07a Trace; c012838e Trace; c012bd80 Trace; c0128402 Trace; c0128550 Trace; c014d3be Trace; c0140000 Trace; c0146c10 Trace; c01467be Trace; c0146c10 Trace; c020d22a Trace; c0105864 Trace; c0105864 Trace; c01466f6 Trace; c0105864 Trace; c010705a Trace; c0105864 Code; c021d988 00000000 <_EIP>: Code; c021d988 <===== 0: f0 fe 4b 28 lock decb 0x28(%ebx) <===== Code; c021d98c 4: 0f 88 25 1d 15 00 js 151d2f <_EIP+0x151d2f> c036f6b6 Code; c021d992 a: 8b 43 08 mov 0x8(%ebx),%eax Code; c021d994 d: 85 c0 test %eax,%eax Code; c021d996 f: 74 18 je 29 <_EIP+0x29> c021d9b0 Code; c021d998 11: ff 43 04 incl 0x4(%ebx) Entering kdb (current=0xe4094000, pid 15236) on processor 0 Oops: Oops eax = 0x00000074 ebx = 0x00000074 ecx = 0x00000008 edx = 0xffffffe8 esi = 0xc04d1ac0 edi = 0x00000000 esp = 0xe4095960 eip = 0xc021d988 ebp = 0xe4095964 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 -- Dan Rich | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) From owner-linux-xfs@oss.sgi.com Tue Feb 19 11:45:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JJjDx23942 for linux-xfs-outgoing; Tue, 19 Feb 2002 11:45:13 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JJj9923920 for ; Tue, 19 Feb 2002 11:45:09 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1JIj4tm025703 for ; Tue, 19 Feb 2002 10:45:04 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA48152; Tue, 19 Feb 2002 12:43:48 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA19256; Tue, 19 Feb 2002 12:43:48 -0600 (CST) Subject: Re: Kernel OOPS From: Eric Sandeen To: Dan Rich Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Feb 2002 12:43:48 -0600 Message-Id: <1014144228.13157.13.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-19 at 11:35, Dan Rich wrote: > Ok, I did and that fixed *most* of my crashing. However, I still have the > crash below when I'm trying to backup the system with amanda (in fact, > this is the crash that got me to turn on spinlock debugging in the first > place :) > > Any thoughts? Hm, I've seen this before, but not here. I'll have to try to reproduce it locally to see what's going on. Does this happen every time you use amanda? And I assume you have amanda hooked up to use xfsdump? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 19 12:11:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JKB2C25624 for linux-xfs-outgoing; Tue, 19 Feb 2002 12:11:02 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JKAw925602 for ; Tue, 19 Feb 2002 12:10:58 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA05718 for ; Tue, 19 Feb 2002 11:10:57 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA48069 for ; Tue, 19 Feb 2002 13:09:42 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA29340 for ; Tue, 19 Feb 2002 13:09:41 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1JJ9fm23750; Tue, 19 Feb 2002 13:09:41 -0600 Message-Id: <200202191909.g1JJ9fm23750@stout.americas.sgi.com> Date: Tue, 19 Feb 2002 13:09:41 -0600 From: Eric Sandeen Subject: TAKE - Fix a couple gcc warnings Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk These were introduced in the non-synchronous transaction mod. Date: Tue Feb 19 11:08:50 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112050a linux/fs/xfs/xfs_trans_item.c - 1.30 - Fix a couple gcc warnings (uninitialized variable, wrong format in printk) From owner-linux-xfs@oss.sgi.com Tue Feb 19 12:51:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JKpsX26295 for linux-xfs-outgoing; Tue, 19 Feb 2002 12:51:54 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JKpo926271 for ; Tue, 19 Feb 2002 12:51:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09545 for ; Tue, 19 Feb 2002 11:51:47 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA48780 for ; Tue, 19 Feb 2002 13:50:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA98503 for ; Tue, 19 Feb 2002 13:50:30 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1JJoUG26349; Tue, 19 Feb 2002 13:50:30 -0600 Message-Id: <200202191950.g1JJoUG26349@stout.americas.sgi.com> Date: Tue, 19 Feb 2002 13:50:30 -0600 From: Eric Sandeen Subject: TAKE - Fix "debug" in xfs module description string Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just fixing a pet peeve... The xfs module / driver description string tells you if you have EAs, ACLs, etc turned on, and it's supposed to tell you if it's a debug build, as well. But it was looking for CONFIG_XFS_DEBUG in the auto-generated autoconf.h, which is never there, because CONFIG_XFS_DEBUG isn't an option that scripts/Configure knows about. So we always got "no debug enabled." So switch it on "#if defined XFSDEBUG" instead, since that gets set in the xfs Makefile. Works for me... Date: Tue Feb 19 11:44:38 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112059a linux/fs/xfs/linux/xfs_super.h - 1.14 - Make "debug" show up correctly in description string From owner-linux-xfs@oss.sgi.com Tue Feb 19 13:22:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JLMnC26858 for linux-xfs-outgoing; Tue, 19 Feb 2002 13:22:49 -0800 Received: from owl.chem-eng.northwestern.edu (IDENT:root@owl.chem-eng.northwestern.edu [129.105.205.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JLMf926836 for ; Tue, 19 Feb 2002 13:22:41 -0800 Received: (from scott@localhost) by owl.chem-eng.northwestern.edu (8.11.2/8.11.2) id g1JKMeV00633; Tue, 19 Feb 2002 14:22:40 -0600 Message-Id: <200202192022.g1JKMeV00633@owl.chem-eng.northwestern.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Re: nfsd & xfsdump strike again X-URL: http://broadbelt.chem-eng.northwestern.edu/~scott/ From: Scott McMillan Reply-To: Scott McMillan Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Feb 2002 14:22:40 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We've also been having problems with xfsdump on our NFS server (1ghz Athlon, software raid, 2.4.14 w/ xfs 1.0.2, RedHat 7.1). We can successfully dump smaller (< 1gb) filesystems with xfsdump-1.1.7, but we always generate a kernel oops when dumping larger filesystems (~15gb): Feb 14 12:10:58 winnie kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 14 12:10:58 winnie kernel: printing eip: Feb 14 12:10:58 winnie kernel: 00000000 Feb 14 12:10:58 winnie kernel: *pde = 00000000 Feb 14 12:10:58 winnie kernel: Oops: 0000 Feb 14 12:10:58 winnie kernel: CPU: 0 Feb 14 12:10:58 winnie kernel: EIP: 0010:[agp_frontend_cleanup+0/96] Not tainted Feb 14 12:10:58 winnie kernel: EIP: 0010:[<00000000>] Not tainted Feb 14 12:10:58 winnie kernel: EFLAGS: 00010282 Feb 14 12:10:58 winnie kernel: eax: 00000000 ebx: c3bc7640 ecx: c3bc789c edx: c03b4960 Feb 14 12:10:58 winnie kernel: esi: c3bc7840 edi: c3bc7640 ebp: c3bc7640 esp: c7045ec4 Feb 14 12:10:58 winnie kernel: ds: 0018 es: 0018 ss: 0018 Feb 14 12:10:58 winnie kernel: Process nfsd (pid: 617, stackpage=c7045000) Feb 14 12:10:58 winnie kernel: Stack: c016c714 c2194540 c3bc7840 c704d604 c7dea800 c016cb66 c3bc7640 c704d604 Feb 14 12:10:58 winnie kernel: 00000002 c70d9800 11270000 c036a270 c7dea9f0 00000002 c016ce89 c7dea800 Feb 14 12:10:58 winnie kernel: c704d614 00000002 00000001 00000001 c704d604 c704d490 c704d694 c704d600 Feb 14 12:10:58 winnie kernel: Call Trace: [nfsd_findparent+52/224] [find_fh_dentry+502/784] [fh_verify+521/1008] [nfsd3_proc_getattr+149/160] [nfsd_dispatch+211/416] Feb 14 12:10:58 winnie kernel: Call Trace: [] [] [] [] [] Feb 14 12:10:58 winnie kernel: [svc_process+664/1328] [nfsd+369/768] [kernel_thread+35/48] Feb 14 12:10:58 winnie kernel: [] [] [] Feb 14 12:10:58 winnie kernel: Feb 14 12:10:58 winnie kernel: Code: Bad EIP value. The oops appears at different points during the dump, that's not reproducible. The previous messages on this topic indicate that it's a problem with nfsd and xfsdump 'stomping' on each others resources, which would suggest that the timing would be random, but for large drives, probably inevitable. We've had this same problem with all the versions of the kernel (2.4.2, 2.4.5, 2.4.14), xfs (1.0.0, 1.0.1, 1.0.2), and xfsdump that we've had installed. Any suggestions or ideas? Thanks, Scott -- Scott McMillan - smcmilla@northwestern.edu Institute for Environmental Catalysis Department of Chemical Engineering, Northwestern University http://broadbelt.chem-eng.northwestern.edu/~scott/ From owner-linux-xfs@oss.sgi.com Tue Feb 19 14:40:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JMekA28052 for linux-xfs-outgoing; Tue, 19 Feb 2002 14:40:46 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JMeh928030 for ; Tue, 19 Feb 2002 14:40:43 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1JLebtm002614 for ; Tue, 19 Feb 2002 13:40:37 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA49491 for ; Tue, 19 Feb 2002 15:39:22 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA90482 for ; Tue, 19 Feb 2002 15:39:22 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1JLbCf11213; Tue, 19 Feb 2002 15:37:12 -0600 Message-Id: <200202192137.g1JLbCf11213@jen.americas.sgi.com> Date: Tue, 19 Feb 2002 15:37:12 -0600 Subject: TAKE - fix memory leak in O_DIRECT read path Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Leak introduced in the last direct I/O change Date: Tue Feb 19 13:38:06 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112081a linux/fs/xfs/pagebuf/page_buf_io.c - 1.11 - Remove extra hold added by last direct I/O fix, it was causing a memory leak. linux/fs/xfs/pagebuf/page_buf.c - 1.7 - Remove the rele call from pagebuf_iostart, the only caller who could get into this was direct I/O which does its own rele. From owner-linux-xfs@oss.sgi.com Tue Feb 19 17:17:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K1HcI32764 for linux-xfs-outgoing; Tue, 19 Feb 2002 17:17:38 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K1HZ932741 for ; Tue, 19 Feb 2002 17:17:35 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1K1HTxV004024 for ; Tue, 19 Feb 2002 17:17:30 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02383; Wed, 20 Feb 2002 11:16:11 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA68888; Wed, 20 Feb 2002 11:16:10 +1100 (AEDT) Date: Wed, 20 Feb 2002 11:16:10 +1100 From: Nathan Scott To: "Ralf G. R. Bergs" , Tim Shimmin Cc: linux-xfs@oss.sgi.com Subject: Re: Failed check 064?! Message-ID: <20020220111610.H165312@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rabe@RWTH-Aachen.DE on Tue, Feb 19, 2002 at 01:53:45PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 19, 2002 at 01:53:45PM +0100, Ralf G. R. Bergs wrote: > Hi there, > > what does it mean if my machine fails in check 064? I could not detect > anything in the log file that could give me a hint... > > I've re-run 064, and this time there wasn't any error.... > > Ok, I've yet again re-run it, and this time there ARE comparison errors again: > This is a known issue (though for some reason the test always passes on our main QA machine) and it's on Tims TODO list. Its not clear if its a real failure or just a test failure at this stage. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 20 13:33:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KLX0t26429 for linux-xfs-outgoing; Wed, 20 Feb 2002 13:33:00 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KLWq926407 for ; Wed, 20 Feb 2002 13:32:53 -0800 Received: (qmail 11825 invoked from network); 20 Feb 2002 20:34:08 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 20 Feb 2002 20:34:08 -0000 Subject: Re: TAKE - quota patch From: Shawn Starr To: xfs In-Reply-To: <200202182226.JAA04619@snort.melbourne.sgi.com> References: <200202182226.JAA04619@snort.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 20 Feb 2002 15:36:13 -0500 Message-Id: <1014237401.8812.11.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk asmlinkage long sys_quotactl(int cmd, const char *special, int id, caddr_t addr) asmlinkage long sys_quotactl(int cmd, const char *special, qid_t id, __kernel_caddr_t addr) redefinition of qid_t in quota.h /fs.h These two system calls are conflicting and are different. quota.c and dquot.c contain sys_quotactl functions. this is with 2.4.18-rc2 + 2.4.18-pre3-ac-quota patch + 2.4.18-rc2-ac1 + XFS + rmap12f. Shawn. On Mon, 2002-02-18 at 17:26, Nathan Scott wrote: > > Date: Mon Feb 18 14:22:14 PST 2002 > Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: xfs-cmds:slinx:111999a > cmd/xfsmisc/README - 1.5 > cmd/xfsmisc/2.4.18-pre3-ac2-quotactl.patch - 1.1 > - Patch (against Alan Cox's tree, with 32-bit UID VFS quota) that > integrates XFS quota with the new quota interfaces. Experimental, > now being reworked with the 32-bit UID VFS quota being reworked > also (to allow both old and new VFS formats to co-exist), but it > might still be useful to folks merging XFS with the current 32bit > UID quota (ac) patches. > > > From owner-linux-xfs@oss.sgi.com Wed Feb 20 13:27:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KLRW726242 for linux-xfs-outgoing; Wed, 20 Feb 2002 13:27:32 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KLRS926220 for ; Wed, 20 Feb 2002 13:27:28 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07455 for ; Wed, 20 Feb 2002 12:27:26 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA61218 for ; Wed, 20 Feb 2002 14:26:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA75638 for ; Wed, 20 Feb 2002 14:26:10 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1KKNon17124; Wed, 20 Feb 2002 14:23:50 -0600 Message-Id: <200202202023.g1KKNon17124@jen.americas.sgi.com> Date: Wed, 20 Feb 2002 14:23:50 -0600 Subject: TAKE - more pagebuf cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Feb 20 12:21:39 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112208a linux/fs/xfs/pagebuf/page_buf_io.c - 1.12 - Fix an error path in the direct I/O path and place the contents of a function inline in the one place it is used. linux/fs/xfs/pagebuf/page_buf.c - 1.8 - fix the code to deal with freeing a non-locking pagebuf correctly in all cases. From owner-linux-xfs@oss.sgi.com Wed Feb 20 14:06:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KM6Rs27394 for linux-xfs-outgoing; Wed, 20 Feb 2002 14:06:27 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KM6H927372 for ; Wed, 20 Feb 2002 14:06:17 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA05327 for ; Wed, 20 Feb 2002 13:06:15 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA08309; Thu, 21 Feb 2002 08:04:56 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA70742; Thu, 21 Feb 2002 08:04:55 +1100 (AEDT) Date: Thu, 21 Feb 2002 08:04:55 +1100 From: Nathan Scott To: Shawn Starr Cc: xfs Subject: Re: TAKE - quota patch Message-ID: <20020221080454.A170349@wobbly.melbourne.sgi.com> References: <200202182226.JAA04619@snort.melbourne.sgi.com> <1014237401.8812.11.camel@unaropia> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014237401.8812.11.camel@unaropia>; from spstarr@sh0n.net on Wed, Feb 20, 2002 at 03:36:13PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Shawn, On Wed, Feb 20, 2002 at 03:36:13PM -0500, Shawn Starr wrote: > asmlinkage long sys_quotactl(int cmd, const char > *special, int > id, caddr_t addr) > asmlinkage long sys_quotactl(int cmd, const char > *special, > qid_t id, __kernel_caddr_t addr) > > > redefinition of qid_t in quota.h /fs.h > > These two system calls are conflicting and are different. > > quota.c and dquot.c contain sys_quotactl functions. > > this is with 2.4.18-rc2 + 2.4.18-pre3-ac-quota patch + 2.4.18-rc2-ac1 + > XFS + rmap12f. > OK, is this the order you applied the patches? If so, this is probably the problem (the order). The order should instead be: 2.4.18-rc2 + 2.4.18-rc2-ac1 + 2.4.18-pre3-ac2-quotactl + XFS + rmap12f. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (ie. the patch I put in CVS must be applied to the new quota from -ac, and not to the old quota from base) Let me know where that gets you. I'm not sure about the redefinition of qid_t issue, but perhaps that will resolve itself by correcting the patch order. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 20 14:25:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KMPgl29921 for linux-xfs-outgoing; Wed, 20 Feb 2002 14:25:42 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KMOJ929882 for ; Wed, 20 Feb 2002 14:24:20 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA211576 for ; Wed, 20 Feb 2002 22:24:50 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA62138 for ; Wed, 20 Feb 2002 15:22:52 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA42882 for ; Wed, 20 Feb 2002 15:22:52 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1KLKWF17911; Wed, 20 Feb 2002 15:20:32 -0600 Message-Id: <200202202120.g1KLKWF17911@jen.americas.sgi.com> Date: Wed, 20 Feb 2002 15:20:32 -0600 Subject: TAKE - merge up to 2.5.5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Looks like Linus is sneaking all the changes in via bitkeeper instead of doing pre patches now. Date: Wed Feb 20 13:17:26 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:112223a linux/include/asm-ppc64/hardirq.h - 1.1 linux/include/asm-ppc64/time.h - 1.1 linux/include/asm-ppc64/floppy.h - 1.1 linux/arch/ppc64/mm/fault.c - 1.1 linux/include/asm-ppc64/iSeries/mf.h - 1.1 linux/arch/ppc64/mm/init.c - 1.1 linux/include/asm-ppc64/fcntl.h - 1.1 linux/include/asm-ppc64/iSeries/mf_proc.h - 1.1 linux/drivers/video/matrox/g450_pll.h - 1.1 linux/include/asm-ppc64/errno.h - 1.1 linux/include/asm-ppc64/elf.h - 1.1 linux/include/asm-ppc64/eeh.h - 1.1 linux/include/asm-ppc64/dma.h - 1.1 linux/include/asm-ppc64/div64.h - 1.1 linux/include/asm-ppc64/delay.h - 1.1 linux/drivers/video/matrox/g450_pll.c - 1.1 linux/include/asm-ppc64/current.h - 1.1 linux/include/asm-ppc64/checksum.h - 1.1 linux/include/asm-ppc64/cache.h - 1.1 linux/include/asm-ppc64/byteorder.h - 1.1 linux/include/asm-ppc64/bugs.h - 1.1 linux/include/asm-ppc64/iSeries/veth-proc.h - 1.1 linux/include/asm-ppc64/iSeries/iSeries_proc.h - 1.1 linux/include/asm-ppc64/ide.h - 1.1 linux/include/asm-ppc64/bootinfo.h - 1.1 linux/include/asm-ppc64/init.h - 1.1 linux/include/asm-ppc64/bitops.h - 1.1 linux/include/asm-ppc64/io.h - 1.1 linux/include/asm-ppc64/ioctl.h - 1.1 linux/include/asm-ppc64/ioctls.h - 1.1 linux/include/asm-ppc64/atomic.h - 1.1 linux/include/asm-ppc64/abs_addr.h - 1.1 linux/include/asm-ppc64/a.out.h - 1.1 linux/include/asm-ppc64/Paca.h - 1.1 linux/include/asm-ppc64/Naca.h - 1.1 linux/include/asm-ppc64/ipc.h - 1.1 linux/include/asm-ppc64/hdreg.h - 1.1 linux/include/asm-ppc64/ipcbuf.h - 1.1 linux/include/asm-ppc64/irq.h - 1.1 linux/include/asm-ppc64/iSeries/iSeries_pci.h - 1.1 linux/include/asm-ppc64/keyboard.h - 1.1 linux/arch/ppc64/Makefile - 1.1 linux/arch/ppc64/boot/Makefile - 1.1 linux/arch/ppc64/boot/addRamDisk.c - 1.1 linux/arch/ppc64/boot/addSystemMap.c - 1.1 linux/arch/ppc64/boot/addnote.c - 1.1 linux/arch/ppc64/boot/crt0.S - 1.1 linux/arch/ppc64/boot/main.c - 1.1 linux/arch/ppc64/boot/mknote.c - 1.1 linux/arch/ppc64/boot/no_initrd.c - 1.1 linux/arch/ppc64/boot/piggyback.c - 1.1 linux/arch/ppc64/boot/start.c - 1.1 linux/arch/ppc64/boot/zImage.lds - 1.1 linux/arch/ppc64/boot/zlib.c - 1.1 linux/arch/ppc64/boot/zlib.h - 1.1 linux/arch/ppc64/config.in - 1.1 linux/arch/ppc64/defconfig - 1.1 linux/arch/ppc64/kernel/HvCall.c - 1.1 linux/arch/ppc64/kernel/HvLpConfig.c - 1.1 linux/arch/ppc64/kernel/HvLpEvent.c - 1.1 linux/arch/ppc64/kernel/ItLpQueue.c - 1.1 linux/arch/ppc64/kernel/LparData.c - 1.1 linux/arch/ppc64/kernel/Makefile - 1.1 linux/arch/ppc64/kernel/XmPciLpEvent.c - 1.1 linux/arch/ppc64/kernel/align.c - 1.1 linux/arch/ppc64/kernel/binfmt_elf32.c - 1.1 linux/arch/ppc64/kernel/bitops.c - 1.1 linux/arch/ppc64/kernel/chrp_setup.c - 1.1 linux/arch/ppc64/kernel/eeh.c - 1.1 linux/arch/ppc64/kernel/entry.S - 1.1 linux/arch/ppc64/kernel/head.S - 1.1 linux/arch/ppc64/kernel/htab.c - 1.1 linux/arch/ppc64/kernel/hvCall.S - 1.1 linux/arch/ppc64/kernel/i8259.c - 1.1 linux/arch/ppc64/kernel/i8259.h - 1.1 linux/arch/ppc64/kernel/iSeries_IoMmTable.c - 1.1 linux/arch/ppc64/kernel/iSeries_IoMmTable.h - 1.1 linux/arch/ppc64/kernel/iSeries_VpdInfo.c - 1.1 linux/arch/ppc64/kernel/iSeries_irq.c - 1.1 linux/arch/ppc64/kernel/iSeries_pci.c - 1.1 linux/arch/ppc64/kernel/iSeries_pci_reset.c - 1.1 linux/arch/ppc64/kernel/iSeries_proc.c - 1.1 linux/arch/ppc64/kernel/iSeries_setup.c - 1.1 linux/arch/ppc64/kernel/iSeries_setup.h - 1.1 linux/arch/ppc64/kernel/idle.c - 1.1 linux/arch/ppc64/kernel/init_task.c - 1.1 linux/arch/ppc64/kernel/ioctl32.c - 1.1 linux/arch/ppc64/kernel/irq.c - 1.1 linux/arch/ppc64/kernel/lmb.c - 1.1 linux/arch/ppc64/kernel/local_irq.h - 1.1 linux/arch/ppc64/kernel/mf.c - 1.1 linux/arch/ppc64/kernel/mf_proc.c - 1.1 linux/arch/ppc64/kernel/misc.S - 1.1 linux/arch/ppc64/kernel/mk_defs.c - 1.1 linux/arch/ppc64/kernel/open_pic.c - 1.1 linux/arch/ppc64/kernel/open_pic.h - 1.1 linux/arch/ppc64/kernel/open_pic_defs.h - 1.1 linux/arch/ppc64/kernel/pSeries_hvCall.S - 1.1 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.1 linux/arch/ppc64/kernel/pSeries_pci.c - 1.1 linux/arch/ppc64/kernel/pacaData.c - 1.1 linux/arch/ppc64/kernel/pci.c - 1.1 linux/arch/ppc64/kernel/pci.h - 1.1 linux/arch/ppc64/kernel/pci_dma.c - 1.1 linux/arch/ppc64/kernel/pci_dn.c - 1.1 linux/arch/ppc64/kernel/pmac_nvram.c - 1.1 linux/arch/ppc64/kernel/pmc.c - 1.1 linux/arch/ppc64/kernel/ppc-stub.c - 1.1 linux/arch/ppc64/kernel/ppc_asm.h - 1.1 linux/arch/ppc64/kernel/ppc_asm.tmpl - 1.1 linux/arch/ppc64/kernel/ppc_defs.head - 1.1 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.1 linux/arch/ppc64/kernel/proc_pmc.c - 1.1 linux/arch/ppc64/kernel/process.c - 1.1 linux/arch/ppc64/kernel/prom.c - 1.1 linux/arch/ppc64/kernel/ptrace.c - 1.1 linux/arch/ppc64/kernel/ptrace32.c - 1.1 linux/arch/ppc64/kernel/ras.c - 1.1 linux/arch/ppc64/kernel/rtas-proc.c - 1.1 linux/arch/ppc64/kernel/rtas.c - 1.1 linux/arch/ppc64/kernel/rtasd.c - 1.1 linux/arch/ppc64/kernel/rtc.c - 1.1 linux/arch/ppc64/kernel/semaphore.c - 1.1 linux/arch/ppc64/kernel/setup.c - 1.1 linux/arch/ppc64/kernel/signal.c - 1.1 linux/arch/ppc64/kernel/signal32.c - 1.1 linux/arch/ppc64/kernel/smp.c - 1.1 linux/arch/ppc64/kernel/stab.c - 1.1 linux/arch/ppc64/kernel/sys32.S - 1.1 linux/arch/ppc64/kernel/sys_ppc32.c - 1.1 linux/arch/ppc64/kernel/syscalls.c - 1.1 linux/arch/ppc64/kernel/time.c - 1.1 linux/arch/ppc64/kernel/traps.c - 1.1 linux/arch/ppc64/kernel/udbg.c - 1.1 linux/arch/ppc64/kernel/xics.c - 1.1 linux/arch/ppc64/kernel/xics.h - 1.1 linux/arch/ppc64/lib/Makefile - 1.1 linux/arch/ppc64/lib/checksum.S - 1.1 linux/arch/ppc64/lib/dec_and_lock.c - 1.1 linux/arch/ppc64/lib/strcase.c - 1.1 linux/arch/ppc64/lib/string.S - 1.1 linux/arch/ppc64/mm/Makefile - 1.1 linux/arch/ppc64/mm/extable.c - 1.1 linux/include/asm-ppc64/ucontext.h - 1.1 linux/arch/ppc64/mm/imalloc.c - 1.1 linux/include/asm-ppc64/kgdb.h - 1.1 linux/arch/ppc64/vmlinux.lds - 1.1 linux/arch/ppc64/xmon/Makefile - 1.1 linux/arch/ppc64/xmon/ansidecl.h - 1.1 linux/arch/ppc64/xmon/nonstdio.h - 1.1 linux/arch/ppc64/xmon/ppc-dis.c - 1.1 linux/arch/ppc64/xmon/ppc-opc.c - 1.1 linux/arch/ppc64/xmon/ppc.h - 1.1 linux/arch/ppc64/xmon/privinst.h - 1.1 linux/arch/ppc64/xmon/setjmp.c - 1.1 linux/arch/ppc64/xmon/start.c - 1.1 linux/arch/ppc64/xmon/subr_prf.c - 1.1 linux/arch/ppc64/xmon/xmon.c - 1.1 linux/include/asm-ppc64/linux_logo.h - 1.1 linux/include/asm-ppc64/lmb.h - 1.1 linux/include/asm-ppc64/machdep.h - 1.1 linux/include/asm-ppc64/mc146818rtc.h - 1.1 linux/include/asm-ppc64/md.h - 1.1 linux/include/asm-ppc64/memory.h - 1.1 linux/include/asm-ppc64/hw_irq.h - 1.1 linux/include/asm-ppc64/iSeries/HvCall.h - 1.1 linux/include/asm-ppc64/mman.h - 1.1 linux/include/asm-ppc64/mmu.h - 1.1 linux/include/asm-ppc64/mmu_context.h - 1.1 linux/include/asm-ppc64/iSeries/HvCallCfg.h - 1.1 linux/include/asm-ppc64/iSeries/HvCallEvent.h - 1.1 linux/include/asm-ppc64/iSeries/HvCallHpt.h - 1.1 linux/include/asm-ppc64/iSeries/HvCallPci.h - 1.1 linux/include/asm-ppc64/iSeries/HvCallSc.h - 1.1 linux/include/asm-ppc64/iSeries/HvCallSm.h - 1.1 linux/include/asm-ppc64/iSeries/HvCallXm.h - 1.1 linux/include/asm-ppc64/module.h - 1.1 linux/include/asm-ppc64/iSeries/HvLpConfig.h - 1.1 linux/include/asm-ppc64/iSeries/HvLpEvent.h - 1.1 linux/include/asm-ppc64/iSeries/HvReleaseData.h - 1.1 linux/include/asm-ppc64/iSeries/HvTypes.h - 1.1 linux/include/asm-ppc64/iSeries/IoHriMainStore.h - 1.1 linux/include/asm-ppc64/iSeries/IoHriProcessorVpd.h - 1.1 linux/include/asm-ppc64/iSeries/ItIplParmsReal.h - 1.1 linux/include/asm-ppc64/iSeries/ItLpNaca.h - 1.1 linux/include/asm-ppc64/iSeries/ItLpPaca.h - 1.1 linux/include/asm-ppc64/iSeries/ItLpQueue.h - 1.1 linux/include/asm-ppc64/msgbuf.h - 1.1 linux/include/asm-ppc64/xor.h - 1.1 linux/include/asm-ppc64/vga.h - 1.1 linux/include/asm-ppc64/vc_ioctl.h - 1.1 linux/include/asm-ppc64/user.h - 1.1 linux/include/asm-ppc64/unistd.h - 1.1 linux/include/asm-ppc64/unaligned.h - 1.1 linux/include/asm-ppc64/udbg.h - 1.1 linux/include/asm-ppc64/thread_info.h - 1.1 linux/include/asm-ppc64/uaccess.h - 1.1 linux/include/asm-ppc64/types.h - 1.1 linux/include/asm-ppc64/tlb.h - 1.1 linux/include/asm-ppc64/timex.h - 1.1 linux/include/asm-ppc64/iSeries/ItLpRegSave.h - 1.1 linux/include/asm-ppc64/rwsem.h - 1.1 linux/include/asm-ppc64/termios.h - 1.1 linux/include/asm-ppc64/termbits.h - 1.1 linux/include/asm-ppc64/system.h - 1.1 linux/include/asm-ppc64/string.h - 1.1 linux/include/asm-ppc64/statfs.h - 1.1 linux/include/asm-ppc64/stat.h - 1.1 linux/include/asm-ppc64/spinlock.h - 1.1 linux/include/asm-ppc64/softirq.h - 1.1 linux/include/asm-ppc64/sockios.h - 1.1 linux/include/asm-ppc64/socket.h - 1.1 linux/include/asm-ppc64/smplock.h - 1.1 linux/include/asm-ppc64/iSeries/ItSpCommArea.h - 1.1 linux/include/asm-ppc64/iSeries/ItVpdAreas.h - 1.1 linux/include/asm-ppc64/smp.h - 1.1 linux/include/asm-ppc64/signal.h - 1.1 linux/include/asm-ppc64/siginfo.h - 1.1 linux/include/asm-ppc64/sigcontext.h - 1.1 linux/include/asm-ppc64/shmparam.h - 1.1 linux/include/asm-ppc64/shmbuf.h - 1.1 linux/include/asm-ppc64/setup.h - 1.1 linux/include/asm-ppc64/serial.h - 1.1 linux/include/asm-ppc64/sembuf.h - 1.1 linux/include/asm-ppc64/semaphore.h - 1.1 linux/include/asm-ppc64/segment.h - 1.1 linux/include/asm-ppc64/scatterlist.h - 1.1 linux/include/asm-ppc64/iSeries/LparData.h - 1.1 linux/include/asm-ppc64/rtas.h - 1.1 linux/include/asm-ppc64/resource.h - 1.1 linux/include/asm-ppc64/ppc32.h - 1.1 linux/include/asm-ppc64/ptrace.h - 1.1 linux/include/asm-ppc64/prom.h - 1.1 linux/include/asm-ppc64/processor.h - 1.1 linux/include/asm-ppc64/iSeries/LparMap.h - 1.1 linux/include/asm-ppc64/iSeries/XmPciLpEvent.h - 1.1 linux/include/asm-ppc64/iSeries/iSeries_VpdInfo.h - 1.1 linux/include/asm-ppc64/iSeries/iSeries_dma.h - 1.1 linux/include/asm-ppc64/iSeries/iSeries_fixup.h - 1.1 linux/include/asm-ppc64/proc_pmc.h - 1.1 linux/include/asm-ppc64/iSeries/iSeries_io.h - 1.1 linux/include/asm-ppc64/proc_fs.h - 1.1 linux/include/asm-ppc64/ppcdebug.h - 1.1 linux/include/asm-ppc64/posix_types.h - 1.1 linux/include/asm-ppc64/namei.h - 1.1 linux/include/asm-ppc64/poll.h - 1.1 linux/include/asm-ppc64/pmc.h - 1.1 linux/include/asm-ppc64/pgtable.h - 1.1 linux/include/asm-ppc64/pgalloc.h - 1.1 linux/include/asm-ppc64/pci_dma.h - 1.1 linux/include/asm-ppc64/iSeries/iSeries_irq.h - 1.1 linux/include/asm-ppc64/pci.h - 1.1 linux/include/asm-ppc64/pci-bridge.h - 1.1 linux/include/asm-ppc64/parport.h - 1.1 linux/include/asm-ppc64/param.h - 1.1 linux/include/asm-ppc64/page.h - 1.1 linux/include/asm-ppc64/nvram.h - 1.1 linux/net/socket.c - 1.32 linux/net/ipx/af_ipx.c - 1.26 linux/mm/vmscan.c - 1.94 linux/mm/vmalloc.c - 1.34 linux/mm/swapfile.c - 1.52 linux/mm/page_alloc.c - 1.73 linux/mm/mremap.c - 1.28 linux/mm/mprotect.c - 1.23 linux/mm/memory.c - 1.76 linux/mm/filemap.c - 1.110 linux/mm/Makefile - 1.12 linux/kernel/sysctl.c - 1.49 linux/kernel/sched.c - 1.60 linux/kernel/ksyms.c - 1.135 linux/kernel/fork.c - 1.50 linux/include/linux/pagemap.h - 1.39 linux/include/linux/mm.h - 1.80 linux/include/linux/hfs_fs.h - 1.10 linux/include/linux/fs.h - 1.151 linux/include/linux/blkdev.h - 1.53 linux/include/asm-sparc64/pgtable.h - 1.32 linux/include/asm-sparc64/page.h - 1.15 linux/include/asm-sparc/pgtable.h - 1.24 linux/include/asm-ppc/unistd.h - 1.18 linux/include/asm-ppc/system.h - 1.21 linux/include/asm-ppc/spinlock.h - 1.13 linux/include/asm-ppc/smp.h - 1.15 linux/include/asm-ppc/processor.h - 1.31 linux/include/asm-ppc/pgtable.h - 1.31 linux/include/asm-ppc/mmu_context.h - 1.14 linux/include/asm-ppc/bitops.h - 1.12 linux/include/asm-mips/pgtable.h - 1.17 linux/include/asm-i386/processor.h - 1.34 linux/include/asm-i386/pgtable.h - 1.30 linux/include/asm-i386/page.h - 1.25 linux/include/asm-arm/pgtable.h - 1.23 linux/include/asm-alpha/pgtable.h - 1.32 linux/fs/vfat/namei.c - 1.27 linux/fs/ufs/namei.c - 1.15 linux/fs/sysv/namei.c - 1.16 linux/fs/sysv/dir.c - 1.14 linux/fs/smbfs/proc.c - 1.15 linux/fs/smbfs/dir.c - 1.19 linux/fs/readdir.c - 1.14 linux/fs/read_write.c - 1.18 linux/fs/qnx4/namei.c - 1.14 linux/fs/proc/generic.c - 1.28 linux/fs/proc/base.c - 1.35 linux/fs/proc/array.c - 1.39 linux/fs/ntfs/fs.c - 1.40 linux/fs/nfsd/vfs.c - 1.46 linux/fs/nfsd/nfsfh.c - 1.35 linux/fs/nfsd/nfsctl.c - 1.26 linux/fs/nfsd/nfs3proc.c - 1.12 linux/fs/nfsd/export.c - 1.27 linux/fs/nfs/file.c - 1.30 linux/fs/nfs/dir.c - 1.35 linux/fs/ncpfs/symlink.c - 1.15 linux/fs/ncpfs/dir.c - 1.28 linux/fs/namei.c - 1.48 linux/fs/msdos/namei.c - 1.27 linux/fs/minix/namei.c - 1.17 linux/fs/minix/dir.c - 1.9 linux/fs/isofs/dir.c - 1.14 linux/fs/hfs/file_hdr.c - 1.14 linux/fs/hfs/file.c - 1.17 linux/fs/hfs/dir_nat.c - 1.11 linux/fs/hfs/dir_dbl.c - 1.11 linux/fs/hfs/dir.c - 1.9 linux/fs/filesystems.c - 1.20 linux/fs/fat/inode.c - 1.38 linux/fs/fat/dir.c - 1.18 linux/fs/ext2/namei.c - 1.23 linux/fs/ext2/inode.c - 1.43 linux/fs/ext2/dir.c - 1.19 linux/fs/exec.c - 1.53 linux/fs/dquot.c - 1.50 linux/fs/coda/dir.c - 1.23 linux/fs/buffer.c - 1.112 linux/fs/block_dev.c - 1.41 linux/fs/autofs/root.c - 1.18 linux/fs/attr.c - 1.14 linux/fs/affs/namei.c - 1.17 linux/fs/affs/dir.c - 1.12 linux/drivers/video/Config.in - 1.33 linux/drivers/usb/usb.c - 1.70 linux/drivers/usb/hub.c - 1.44 linux/drivers/usb/audio.c - 1.40 linux/drivers/sgi/char/graphics.c - 1.19 linux/drivers/scsi/sr_ioctl.c - 1.22 linux/drivers/scsi/sr.c - 1.38 linux/drivers/scsi/sd.c - 1.56 linux/drivers/scsi/ide-scsi.c - 1.26 linux/drivers/pci/proc.c - 1.24 linux/drivers/isdn/hisax/netjet.c - 1.19 linux/drivers/isdn/hisax/hisax.h - 1.27 linux/drivers/cdrom/sonycd535.c - 1.17 linux/drivers/cdrom/sjcd.c - 1.14 linux/drivers/cdrom/sbpcd.c - 1.19 linux/drivers/cdrom/optcd.c - 1.15 linux/drivers/cdrom/mcdx.c - 1.12 linux/drivers/cdrom/mcd.c - 1.15 linux/drivers/cdrom/gscd.c - 1.14 linux/drivers/cdrom/cm206.c - 1.16 linux/drivers/cdrom/cdu31a.c - 1.13 linux/drivers/cdrom/aztcd.c - 1.16 linux/drivers/block/xd.c - 1.32 linux/drivers/block/ps2esdi.c - 1.34 linux/drivers/block/paride/pf.c - 1.21 linux/drivers/block/paride/pd.c - 1.26 linux/drivers/block/paride/pcd.c - 1.17 linux/drivers/block/ll_rw_blk.c - 1.93 linux/drivers/block/floppy.c - 1.35 linux/drivers/block/ataflop.c - 1.18 linux/drivers/block/acsi.c - 1.24 linux/drivers/acorn/block/mfmhd.c - 1.18 linux/arch/sparc64/kernel/ioctl32.c - 1.50 linux/arch/ppc/vmlinux.lds - 1.14 linux/arch/ppc/mm/init.c - 1.39 linux/arch/ppc/lib/locks.c - 1.10 linux/arch/ppc/kernel/smp.c - 1.33 linux/arch/ppc/kernel/signal.c - 1.15 linux/arch/ppc/kernel/setup.c - 1.42 linux/arch/ppc/kernel/process.c - 1.35 linux/arch/ppc/kernel/mk_defs.c - 1.16 linux/arch/ppc/kernel/misc.S - 1.35 linux/arch/ppc/kernel/irq.c - 1.34 linux/arch/ppc/kernel/head.S - 1.31 linux/arch/ppc/config.in - 1.45 linux/arch/i386/mm/ioremap.c - 1.10 linux/arch/i386/mm/init.c - 1.33 linux/arch/i386/mm/fault.c - 1.22 linux/arch/i386/kernel/vm86.c - 1.13 linux/arch/i386/kernel/traps.c - 1.48 linux/arch/i386/kernel/setup.c - 1.69 linux/arch/i386/kernel/process.c - 1.46 linux/arch/i386/kernel/i386_ksyms.c - 1.46 linux/arch/i386/kernel/entry.S - 1.49 linux/arch/i386/defconfig - 1.98 linux/arch/i386/config.in - 1.74 linux/Makefile - 1.186 linux/Documentation/fb/matroxfb.txt - 1.9 linux/Documentation/cdrom/sbpcd - 1.3 linux/CREDITS - 1.73 linux/include/linux/ide.h - 1.39 linux/fs/hpfs/namei.c - 1.14 linux/drivers/block/blkpg.c - 1.17 linux/drivers/block/cpqarray.c - 1.42 linux/drivers/isdn/hisax/hfc_pci.h - 1.7 linux/drivers/isdn/hisax/hfc_pci.c - 1.22 linux/arch/ppc/kernel/head_8xx.S - 1.16 linux/arch/ppc/kernel/entry.S - 1.25 linux/drivers/block/DAC960.c - 1.43 linux/include/asm-sh/pgtable.h - 1.24 linux/include/asm-i386/kmap_types.h - 1.7 linux/fs/udf/namei.c - 1.21 linux/arch/i386/kernel/smpboot.c - 1.33 linux/mm/highmem.c - 1.37 linux/include/linux/highmem.h - 1.19 linux/include/asm-i386/highmem.h - 1.10 linux/fs/bfs/dir.c - 1.19 linux/include/asm-i386/pgalloc.h - 1.16 linux/arch/ppc/kernel/head_4xx.S - 1.7 linux/include/linux/mmzone.h - 1.18 linux/drivers/char/agp/agpgart_be.c - 1.32 linux/drivers/usb/dabusb.c - 1.18 linux/fs/openpromfs/inode.c - 1.18 linux/drivers/usb/scanner.c - 1.31 linux/drivers/usb/usbmouse.c - 1.18 linux/drivers/usb/usbkbd.c - 1.24 linux/drivers/usb/ov511.c - 1.32 linux/drivers/usb/devio.c - 1.28 linux/drivers/usb/inode.c - 1.23 linux/drivers/ieee1394/pcilynx.c - 1.18 linux/fs/autofs4/root.c - 1.14 linux/include/asm-ia64/pgtable.h - 1.14 linux/fs/devfs/base.c - 1.34 linux/drivers/video/matrox/matroxfb_misc.h - 1.2 linux/drivers/video/matrox/matroxfb_misc.c - 1.5 linux/drivers/video/matrox/matroxfb_maven.c - 1.5 linux/drivers/video/matrox/matroxfb_crtc2.c - 1.7 linux/drivers/video/matrox/matroxfb_base.h - 1.11 linux/drivers/video/matrox/matroxfb_base.c - 1.15 linux/drivers/video/matrox/matroxfb_Ti3026.c - 1.6 linux/drivers/video/matrox/matroxfb_DAC1064.h - 1.5 linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.10 linux/drivers/video/matrox/Makefile - 1.4 linux/include/asm-mips64/pgtable.h - 1.12 linux/arch/mips64/kernel/linux32.c - 1.12 linux/drivers/usb/wacom.c - 1.18 linux/drivers/usb/pegasus.c - 1.28 linux/include/linux/usb.h - 1.31 linux/drivers/ide/pdc4030.c - 1.9 linux/drivers/ide/ide.c - 1.44 linux/drivers/ide/ide-tape.c - 1.19 linux/drivers/ide/ide-proc.c - 1.12 linux/drivers/ide/ide-probe.c - 1.24 linux/drivers/ide/ide-floppy.c - 1.16 linux/drivers/ide/ide-dma.c - 1.19 linux/drivers/ide/ide-disk.c - 1.25 linux/drivers/ide/ide-cd.c - 1.26 linux/drivers/ide/icside.c - 1.11 linux/drivers/ide/hd.c - 1.17 linux/drivers/ide/Makefile - 1.15 linux/drivers/net/wan/comx.c - 1.16 linux/drivers/usb/mdc800.c - 1.18 linux/fs/ramfs/inode.c - 1.18 linux/drivers/usb/serial/usbserial.c - 1.30 linux/drivers/usb/serial/visor.h - 1.8 linux/drivers/usb/serial/visor.c - 1.30 linux/drivers/s390/block/dasd.c - 1.20 linux/include/asm-s390/pgtable.h - 1.11 linux/arch/mips64/kernel/ioctl32.c - 1.9 linux/kdb/modules/kdbm_pg.c - 1.52 linux/Documentation/filesystems/Locking - 1.7 linux/drivers/char/drm/i810_dma.c - 1.10 linux/drivers/usb/storage/usb.c - 1.19 linux/drivers/usb/serial/keyspan.c - 1.22 linux/drivers/usb/microtek.c - 1.17 linux/drivers/usb/bluetooth.c - 1.23 linux/fs/jffs/inode-v23.c - 1.21 linux/drivers/ieee1394/video1394.c - 1.17 linux/include/linux/nfsd/interface.h - 1.2 linux/drivers/media/video/cpia_usb.c - 1.10 linux/drivers/media/video/cpia.c - 1.11 linux/drivers/media/video/bttv-driver.c - 1.17 linux/drivers/isdn/hisax/nj_u.c - 1.9 linux/drivers/isdn/hisax/nj_s.c - 1.9 linux/drivers/md/lvm.c - 1.28 linux/drivers/block/cciss.c - 1.30 linux/drivers/md/lvm-snap.c - 1.14 linux/drivers/md/md.c - 1.39 linux/include/linux/dnotify.h - 1.3 linux/include/asm-parisc/pgtable.h - 1.4 linux/drivers/usb/serial/empeg.c - 1.19 linux/drivers/video/matrox/matroxfb_g450.c - 1.4 linux/mm/shmem.c - 1.30 linux/fs/reiserfs/namei.c - 1.20 linux/include/asm-s390x/pgtable.h - 1.7 linux/arch/s390x/kernel/linux32.c - 1.10 linux/arch/cris/drivers/ide.c - 1.7 linux/drivers/s390/char/tapeblock.c - 1.7 linux/drivers/s390/block/xpram.c - 1.11 linux/include/asm-cris/pgtable.h - 1.8 linux/drivers/md/lvm-fs.c - 1.6 linux/drivers/usb/serial/io_edgeport.c - 1.21 linux/arch/cris/drivers/eeprom.c - 1.6 linux/drivers/usb/pwc-if.c - 1.12 linux/drivers/bluetooth/hci_usb.c - 1.7 linux/drivers/usb/catc.c - 1.9 linux/drivers/usb/se401.c - 1.9 linux/arch/ppc/mm/hashtable.S - 1.4 linux/drivers/media/video/meye.h - 1.3 linux/drivers/media/video/meye.c - 1.6 linux/drivers/usb/usb-skeleton.c - 1.8 linux/drivers/char/drm/drm_vm.h - 1.10 linux/drivers/char/drm/drm_scatter.h - 1.4 linux/drivers/char/drm/drm_proc.h - 1.3 linux/drivers/usb/CDCEther.c - 1.8 linux/drivers/usb/kaweth.c - 1.13 linux/drivers/usb/usbnet.c - 1.12 linux/drivers/usb/usbvideo.h - 1.7 linux/drivers/usb/usbvideo.c - 1.8 linux/drivers/isdn/hisax/st5481_usb.c - 1.9 linux/drivers/usb/hid-core.c - 1.8 linux/fs/jffs2/dir.c - 1.7 linux/drivers/ide/ataraid.c - 1.6 linux/drivers/usb/hpusbscsi.h - 1.4 linux/drivers/usb/hpusbscsi.c - 1.7 linux/drivers/message/i2o/i2o_block.c - 1.10 linux/fs/ext3/namei.c - 1.5 linux/drivers/hotplug/pci_hotplug_core.c - 1.5 linux/fs/sysv/ChangeLog - 1.7 linux/fs/driverfs/inode.c - 1.9 linux/include/linux/driverfs_fs.h - 1.3 linux/include/linux/device.h - 1.6 linux/drivers/usb/serial/kl5kusb105.c - 1.3 linux/drivers/usb/stv680.c - 1.5 linux/drivers/usb/vicam.c - 1.6 linux/drivers/usb/auerswald.c - 1.6 linux/fs/xfs/pagebuf/page_buf.c - 1.9 linux/drivers/ide/ide-taskfile.c - 1.4 linux/drivers/ieee1394/dv1394.c - 1.2 linux/drivers/usb/hcd/ohci-hcd.c - 1.4 linux/drivers/video/neofb.c - 1.3 linux/drivers/video/Config.help - 1.2 linux/drivers/base/interface.c - 1.5 linux/drivers/pci/pci-driver.c - 1.2 linux/fs/xattr.c - 1.2 linux/drivers/input/joystick/iforce.c - 1.2 linux/sound/synth/util_mem.c - 1.2 linux/sound/synth/emux/soundfont.c - 1.2 linux/Documentation/filesystems/directory-locking - 1.2 linux/Documentation/filesystems/porting - 1.2 linux/sound/synth/emux/emux_voice.h - 1.2 linux/sound/synth/emux/emux_synth.c - 1.2 linux/sound/synth/emux/emux_seq.c - 1.2 linux/sound/synth/emux/emux_proc.c - 1.2 linux/sound/synth/emux/emux_effect.c - 1.2 linux/sound/synth/emux/emux.c - 1.2 linux/sound/ppc/tumbler.c - 1.2 linux/sound/ppc/pmac.c - 1.2 linux/sound/ppc/awacs.c - 1.2 linux/sound/ppc/Config.in - 1.2 linux/sound/pci/ymfpci/ymfpci_main.c - 1.2 linux/sound/pci/ymfpci/ymfpci.c - 1.2 linux/sound/pci/via8233.c - 1.2 linux/sound/pci/via686.c - 1.2 linux/sound/pci/trident/trident_synth.c - 1.2 linux/sound/pci/trident/trident_memory.c - 1.2 linux/sound/pci/trident/trident_main.c - 1.2 linux/sound/pci/trident/trident.c - 1.2 linux/sound/pci/sonicvibes.c - 1.2 linux/sound/pci/rme9652/rme9652.c - 1.2 linux/sound/pci/rme96.c - 1.2 linux/sound/pci/nm256/nm256.c - 1.2 linux/sound/pci/maestro3.c - 1.2 linux/sound/pci/korg1212/korg1212.c - 1.2 linux/sound/pci/intel8x0.c - 1.2 linux/sound/pci/ice1712.c - 1.2 linux/arch/ppc/4xx_io/Config.in - 1.2 linux/sound/pci/fm801.c - 1.2 linux/sound/pci/es1968.c - 1.2 linux/sound/pci/es1938.c - 1.2 linux/sound/pci/ens1370.c - 1.2 linux/sound/pci/emu10k1/voice.c - 1.2 linux/sound/pci/emu10k1/memory.c - 1.2 linux/sound/pci/emu10k1/irq.c - 1.2 linux/sound/pci/emu10k1/io.c - 1.2 linux/sound/pci/emu10k1/emuproc.c - 1.2 linux/sound/pci/emu10k1/emupcm.c - 1.2 linux/sound/pci/emu10k1/emumpu401.c - 1.2 linux/sound/pci/emu10k1/emumixer.c - 1.2 linux/sound/pci/emu10k1/emufx.c - 1.2 linux/sound/pci/emu10k1/emu10k1_synth_local.h - 1.2 linux/sound/pci/emu10k1/emu10k1_main.c - 1.2 linux/sound/pci/emu10k1/emu10k1_callback.c - 1.2 linux/sound/pci/emu10k1/emu10k1.c - 1.2 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.2 linux/sound/pci/cs46xx/cs46xx.c - 1.2 linux/sound/pci/cs4281.c - 1.2 linux/sound/pci/cmipci.c - 1.2 linux/sound/pci/als4000.c - 1.2 linux/sound/pci/ali5451/ali5451.c - 1.2 linux/sound/pci/ac97/ak4531_codec.c - 1.2 linux/sound/pci/ac97/ac97_codec.c - 1.2 linux/sound/pci/ac97/Makefile - 1.2 linux/sound/pci/Config.in - 1.2 linux/arch/ppc/kernel/iSeries_head.S - 1.2 linux/sound/oss/i810_audio.c - 1.2 linux/arch/x86_64/config.in - 1.2 linux/sound/last.c - 1.2 linux/sound/isa/wavefront/wavefront_synth.c - 1.2 linux/sound/isa/wavefront/wavefront_midi.c - 1.2 linux/sound/isa/wavefront/wavefront_fx.c - 1.2 linux/sound/isa/wavefront/wavefront.c - 1.2 linux/sound/isa/sgalaxy.c - 1.2 linux/sound/isa/sb/sb_mixer.c - 1.2 linux/sound/isa/sb/sb_common.c - 1.2 linux/sound/isa/sb/sb8_midi.c - 1.2 linux/sound/isa/sb/sb8_main.c - 1.2 linux/sound/isa/sb/sb8.c - 1.2 linux/sound/isa/sb/sb16_main.c - 1.2 linux/sound/isa/sb/sb16_csp.c - 1.2 linux/sound/isa/sb/sb16.c - 1.2 linux/sound/isa/sb/es968.c - 1.2 linux/sound/isa/sb/emu8000_local.h - 1.2 linux/sound/isa/sb/emu8000.c - 1.2 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.2 linux/sound/isa/opl3sa2.c - 1.2 linux/sound/isa/gus/interwave.c - 1.2 linux/sound/isa/gus/gusmax.c - 1.2 linux/sound/isa/gus/gusextreme.c - 1.2 linux/sound/isa/gus/gusclassic.c - 1.2 linux/sound/isa/gus/gus_volume.c - 1.2 linux/sound/isa/gus/gus_uart.c - 1.2 linux/sound/isa/gus/gus_timer.c - 1.2 linux/sound/isa/gus/gus_synth.c - 1.2 linux/sound/isa/gus/gus_simple.c - 1.2 linux/sound/isa/gus/gus_sample.c - 1.2 linux/sound/isa/gus/gus_reset.c - 1.2 linux/sound/isa/gus/gus_pcm.c - 1.2 linux/sound/isa/gus/gus_mixer.c - 1.2 linux/sound/isa/gus/gus_mem_proc.c - 1.2 linux/sound/isa/gus/gus_mem.c - 1.2 linux/sound/isa/gus/gus_main.c - 1.2 linux/sound/isa/gus/gus_io.c - 1.2 linux/sound/isa/gus/gus_instr.c - 1.2 linux/sound/isa/gus/gus_dram.c - 1.2 linux/sound/isa/gus/gus_dma.c - 1.2 linux/sound/isa/es18xx.c - 1.2 linux/sound/isa/es1688/es1688_lib.c - 1.2 linux/sound/isa/es1688/es1688.c - 1.2 linux/sound/isa/dt0197h.c - 1.2 linux/sound/isa/cs423x/cs4236_lib.c - 1.2 linux/sound/isa/cs423x/cs4236.c - 1.2 linux/sound/isa/cs423x/cs4231_lib.c - 1.2 linux/sound/isa/cs423x/cs4231.c - 1.2 linux/sound/isa/cmi8330.c - 1.2 linux/sound/isa/azt2320.c - 1.2 linux/sound/isa/als100.c - 1.2 linux/sound/isa/ad1848/ad1848_lib.c - 1.2 linux/sound/isa/ad1848/ad1848.c - 1.2 linux/sound/isa/ad1816a/ad1816a_lib.c - 1.2 linux/sound/isa/ad1816a/ad1816a.c - 1.2 linux/sound/isa/Config.in - 1.2 linux/sound/i2c/tea6330t.c - 1.2 linux/sound/i2c/i2c.c - 1.2 linux/sound/i2c/cs8427.c - 1.2 linux/sound/drivers/virmidi.c - 1.2 linux/sound/drivers/serial-u16550.c - 1.2 linux/sound/drivers/opl3/opl3_oss.c - 1.2 linux/sound/drivers/opl3/opl3_lib.c - 1.2 linux/sound/drivers/mtpav.c - 1.2 linux/sound/drivers/mpu401/mpu401_uart.c - 1.2 linux/sound/drivers/mpu401/mpu401.c - 1.2 linux/sound/drivers/dummy.c - 1.2 linux/sound/drivers/Config.in - 1.2 linux/sound/core/timer.c - 1.2 linux/sound/core/sound_oss.c - 1.2 linux/sound/core/sound.c - 1.2 linux/sound/core/seq/seq_virmidi.c - 1.2 linux/sound/core/seq/seq_timer.c - 1.2 linux/sound/core/seq/seq_queue.c - 1.2 linux/sound/core/seq/seq_prioq.c - 1.2 linux/sound/core/seq/seq_ports.c - 1.2 linux/sound/core/seq/seq_midi_event.c - 1.2 linux/sound/core/seq/seq_midi_emul.c - 1.2 linux/sound/core/seq/seq_midi.c - 1.2 linux/sound/core/seq/seq_memory.c - 1.2 linux/sound/core/seq/seq_lock.h - 1.2 linux/sound/core/seq/seq_instr.c - 1.2 linux/sound/core/seq/seq_fifo.c - 1.2 linux/sound/core/seq/seq_device.c - 1.2 linux/sound/core/seq/seq_clientmgr.c - 1.2 linux/sound/core/seq/oss/seq_oss_device.h - 1.2 linux/sound/core/seq/instr/ainstr_simple.c - 1.2 linux/sound/core/seq/instr/ainstr_iw.c - 1.2 linux/sound/core/seq/instr/ainstr_gf1.c - 1.2 linux/sound/core/seq/instr/ainstr_fm.c - 1.2 linux/sound/core/rtctimer.c - 1.2 linux/sound/core/rawmidi.c - 1.2 linux/sound/core/pcm_timer.c - 1.2 linux/sound/core/pcm_native.c - 1.2 linux/sound/core/pcm_misc.c - 1.2 linux/sound/core/pcm_memory.c - 1.2 linux/sound/core/pcm_lib.c - 1.2 linux/sound/core/pcm.c - 1.2 linux/sound/core/oss/route.c - 1.2 linux/sound/core/oss/rate.c - 1.2 linux/sound/core/oss/pcm_plugin.c - 1.2 linux/sound/core/oss/pcm_oss.c - 1.2 linux/sound/core/oss/mulaw.c - 1.2 linux/sound/core/oss/mixer_oss.c - 1.2 linux/sound/core/oss/linear.c - 1.2 linux/sound/core/oss/io.c - 1.2 linux/sound/core/oss/copy.c - 1.2 linux/sound/core/misc.c - 1.2 linux/sound/core/memory.c - 1.2 linux/sound/core/isadma.c - 1.2 linux/sound/core/init.c - 1.2 linux/sound/core/info_oss.c - 1.2 linux/sound/core/info.c - 1.2 linux/sound/core/hwdep.c - 1.2 linux/sound/core/device.c - 1.2 linux/sound/core/control.c - 1.2 linux/sound/core/Config.in - 1.2 linux/sound/Makefile - 1.2 linux/sound/Config.in - 1.2 linux/include/asm-x86_64/pgtable.h - 1.2 linux/drivers/usb/konicawc.c - 1.2 linux/include/sound/ymfpci.h - 1.2 linux/include/sound/wavefront.h - 1.2 linux/include/sound/version.h - 1.2 linux/include/sound/trident.h - 1.2 linux/include/sound/seq_kernel.h - 1.2 linux/include/sound/pcm_params.h - 1.2 linux/include/sound/emux_synth.h - 1.2 linux/include/sound/pcm.h - 1.2 linux/include/sound/opl3.h - 1.2 linux/include/sound/gus.h - 1.2 linux/include/sound/emu8000.h - 1.2 linux/include/sound/cs46xx.h - 1.2 linux/include/sound/core.h - 1.2 linux/include/sound/asound.h - 1.2 linux/include/asm-ppc/thread_info.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Feb 20 14:34:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KMYtb31093 for linux-xfs-outgoing; Wed, 20 Feb 2002 14:34:55 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KMYp931064 for ; Wed, 20 Feb 2002 14:34:51 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1KMYkFH010707 for ; Wed, 20 Feb 2002 14:34:46 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA62179 for ; Wed, 20 Feb 2002 15:33:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA08961 for ; Wed, 20 Feb 2002 15:33:29 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1KLXTr20480; Wed, 20 Feb 2002 15:33:29 -0600 Message-Id: <200202202133.g1KLXTr20480@stout.americas.sgi.com> Date: Wed, 20 Feb 2002 15:33:29 -0600 From: Eric Sandeen Subject: TAKE - pagebuf_iozero Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk pagebuf_iozero handles zeroing for xfs_zero_eof and xfs_zero_last_block (both deal with zeroing unwritten portions when a write extends filesize). But pagebuf_iozero wasn't setting up pages correctly, it was calling pagebuf_commit_write_core w/o first setting up buffers on pages with __pb_block_prepare_write_async. xfs_zero_eof and xfs_zero_last_block were also forcing writes on these pagebufs, which was probably causing double i/o... Date: Wed Feb 20 13:27:57 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112227a linux/fs/xfs/linux/xfs_lrw.c - 1.123 - Prepare pagebuf bmap to pass to pagebuf_iozero Don't force writing the pagebuf linux/fs/xfs/pagebuf/page_buf_io.c - 1.13 - do a __pb_block_prepare_write_async before pagebuf_commit_write_core linux/fs/xfs/pagebuf/page_buf.h - 1.4 - Add pb_bmap_t to pagebuf_iozero arguments From owner-linux-xfs@oss.sgi.com Thu Feb 21 01:56:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L9uXA12919 for linux-xfs-outgoing; Thu, 21 Feb 2002 01:56:33 -0800 Received: from mail.vavel.net (vavel-pc1.avacom.net [213.169.135.178]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L9uR912896 for ; Thu, 21 Feb 2002 01:56:27 -0800 Received: from bandit (bandit.vavel.local [192.168.0.27]) by mail.vavel.net (Postfix) with SMTP id 235A920A0A for ; Thu, 21 Feb 2002 10:56:25 +0200 (EET) Message-ID: <002801c1bab5$a445a880$1b00a8c0@vavel.local> From: "Mihai Marusca" To: Subject: kernel upgrade Date: Thu, 21 Feb 2002 10:56:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello I tried to update my kernel to kernel-smp-2.4.9-12SGI_XFS_1.0.2.i686.rpm on a dual PIII with AIC 7896 SCSI controller. Until now it ran 2.4.3-SGI_XFS_1.0.1smp (since I installed RedHat 7.1 with XFS 1.0.1 in July 2001) without any problem. What I did: - upgraded xfsprogs to 1.3.13 (from /projects/xfs/download/latest/cmd_rpms/i386/) - installed kernel-smp-2.4.9-12SGI_XFS_1.0.2.i686.rpm (from /projects/xfs/download/latest/kernel_rpms/i386/2.4.9-12-RH7.1/) - added a new entry in /etc/lilo.conf, including 'initrd=...' line - ran succesfully lilo -v What I got: [...] Mounting root file system XFS mounting file system sd(8,2) pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2 Freeing unused kernel memory: 240K freed Kernel panic: No init found. Try passing init= option to kernel I even created myself initrd image (using mkinitrd) but nothing changed. And that's the end of it. I'm running (for now) 2.4.3 kernel, but I really like to get rid of it. Any help, hint, hunch would be appreciated. Thanks Mihai From owner-linux-xfs@oss.sgi.com Thu Feb 21 02:38:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LAcUi13922 for linux-xfs-outgoing; Thu, 21 Feb 2002 02:38:30 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LAcQ913900 for ; Thu, 21 Feb 2002 02:38:26 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16dpgG-0007qj-00; Thu, 21 Feb 2002 04:38:24 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g1L9cMC30458; Thu, 21 Feb 2002 04:38:22 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Mihai Marusca" Cc: Subject: Re: kernel upgrade From: "Martin K. Petersen" Organization: SGI XFS Team References: <002801c1bab5$a445a880$1b00a8c0@vavel.local> Date: 21 Feb 2002 04:38:22 -0500 In-Reply-To: <002801c1bab5$a445a880$1b00a8c0@vavel.local> Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Mihai" == Mihai Marusca writes: Mihai> What I got: Mihai> [...] Mounting root file system XFS mounting file system Mihai> sd(8,2) pivotroot: pivot_root(/sysroot,/sysroot/initrd) Mihai> failed: 2 Freeing unused kernel memory: 240K freed Kernel Mihai> panic: No init found. Try passing init= option to kernel Mihai> I even created myself initrd image (using mkinitrd) but nothing Mihai> changed. Check that you have a /initrd directory... -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Feb 21 02:57:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LAveW14702 for linux-xfs-outgoing; Thu, 21 Feb 2002 02:57:40 -0800 Received: from mail.vavel.net (vavel-pc1.avacom.net [213.169.135.178]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LAvX914679; Thu, 21 Feb 2002 02:57:34 -0800 Received: from bandit (bandit.vavel.local [192.168.0.27]) by mail.vavel.net (Postfix) with SMTP id 506FC20A0B; Thu, 21 Feb 2002 11:57:30 +0200 (EET) Message-ID: <001001c1babe$2ced0d10$1b00a8c0@vavel.local> From: "Mihai Marusca" To: "Martin K. Petersen" Cc: References: <002801c1bab5$a445a880$1b00a8c0@vavel.local> Subject: Re: kernel upgrade Date: Thu, 21 Feb 2002 11:57:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From: "Martin K. Petersen" > Check that you have a /initrd directory... I didn't. Now I have and it works :) It was there and I deleted it sometime? I checked other two computers (RH 7.1 XFS 1.0.1 and RH7.2 XFS 1.0.2) and both have /initrd. This one was the only ane actually using an initial ramdisk, didn't have a /initrd directory but this didn't prevent it from booting linux-2.4.3. Is there an explanation for this? Thanks again, I'm glad it works. Mihai From owner-linux-xfs@oss.sgi.com Thu Feb 21 03:03:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LB3as15051 for linux-xfs-outgoing; Thu, 21 Feb 2002 03:03:36 -0800 Received: from sol.alphadiz.local (sol.alphadiz.com [193.108.48.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LB3T915017 for ; Thu, 21 Feb 2002 03:03:30 -0800 Received: from there (localhost.localdomain [127.0.0.1]) by sol.alphadiz.local (8.11.6/8.11.6) with SMTP id g1LA3Pg18273 for ; Thu, 21 Feb 2002 12:03:25 +0200 Message-Id: <200202211003.g1LA3Pg18273@sol.alphadiz.local> Content-Type: text/plain; charset="us-ascii" From: Eugene Onischenko To: Subject: Deleting the file securely Date: Thu, 21 Feb 2002 12:03:24 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1LB3X915029 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, There is shred utility for deleting files securely but in shred manual is written: "The following are examples of filesystems on which shred is not effective: * log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, etc.) ^^^ Is there a tool for deleting the file securely on xfs? -- Best regards, person: Eugene Onischenko nic-hdl: EO1030-RIPE From owner-linux-xfs@oss.sgi.com Thu Feb 21 08:42:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LGgIr07096 for linux-xfs-outgoing; Thu, 21 Feb 2002 08:42:18 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LGg9907074 for ; Thu, 21 Feb 2002 08:42:09 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1LGg4FH012019 for ; Thu, 21 Feb 2002 08:42:04 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA69219; Thu, 21 Feb 2002 09:40:47 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA29043; Thu, 21 Feb 2002 09:40:47 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1LFcJj28239; Thu, 21 Feb 2002 09:38:19 -0600 Subject: Re: Deleting the file securely From: Steve Lord To: Eugene Onischenko Cc: linux-xfs@oss.sgi.com In-Reply-To: <200202211003.g1LA3Pg18273@sol.alphadiz.local> References: <200202211003.g1LA3Pg18273@sol.alphadiz.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Feb 2002 09:38:19 -0600 Message-Id: <1014305899.27700.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-21 at 04:03, Eugene Onischenko wrote: > Hello, > > There is shred utility for deleting files securely but in shred manual is > written: > "The following are examples of filesystems on which shred is not effective: > * log-structured or journaled filesystems, such as those supplied with > AIX and Solaris (and JFS, ReiserFS, XFS, etc.) > ^^^ > > Is there a tool for deleting the file securely on xfs? The shred man page says this: CAUTION: Note that shred relies on a very important assump- tion: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The fol- lowing are examples of filesystems on which shred is not effective: XFS does overwrite data in place, so, as long as you are not worried about people with special hardware reading overwritten data, shred probably does the job. Steve > > -- > Best regards, > person: Eugene Onischenko > nic-hdl: EO1030-RIPE -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 21 11:59:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LJxdI10483 for linux-xfs-outgoing; Thu, 21 Feb 2002 11:59:39 -0800 Received: from grumpy.ekky.org (kbl-tnz3291.zeelandnet.nl [62.238.44.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LJxY910461 for ; Thu, 21 Feb 2002 11:59:35 -0800 Received: from zeelandnet.nl (dopey.ekky.org [192.168.1.101]) by grumpy.ekky.org (8.11.6/8.11.6) with ESMTP id g1LIxRQ29491 for ; Thu, 21 Feb 2002 19:59:27 +0100 Message-ID: <3C754390.A25E0B83@zeelandnet.nl> Date: Thu, 21 Feb 2002 19:59:28 +0100 From: "P. Ekkebus" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: nl, nl-BE, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: mirror Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sir, My ISp have a lot of linux mirror's and so I ask them of they want to mirror http://oss.sgi.com/projects/xfs/ if that is possible and allowed by SGI. So is it possible and allowed to mirror the SGI linux site? My ISP is www.zeelandnet.nl and the linux mirror by my ISP are located by zappa.zeelandnet.nl Thanks P. Ekkebus From owner-linux-xfs@oss.sgi.com Thu Feb 21 12:04:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LK4HY10718 for linux-xfs-outgoing; Thu, 21 Feb 2002 12:04:17 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LK4D910696 for ; Thu, 21 Feb 2002 12:04:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA283699 for ; Thu, 21 Feb 2002 20:05:02 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA71877; Thu, 21 Feb 2002 13:02:55 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA44158; Thu, 21 Feb 2002 13:02:54 -0600 (CST) Subject: Re: mirror From: Eric Sandeen To: "P. Ekkebus" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C754390.A25E0B83@zeelandnet.nl> References: <3C754390.A25E0B83@zeelandnet.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Feb 2002 13:02:49 -0600 Message-Id: <1014318174.2743.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sure, another mirror would be great. Just let me know when it's set up, and I'll add it to the list on the web pages. Thanks, -Eric On Thu, 2002-02-21 at 12:59, P. Ekkebus wrote: > My ISp have a lot of linux mirror's and so I ask them > of they want to mirror http://oss.sgi.com/projects/xfs/ if > that is possible and allowed by SGI. > So is it possible and allowed to mirror the SGI linux site? > My ISP is www.zeelandnet.nl and the linux mirror by my ISP > are located by zappa.zeelandnet.nl -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 21 17:08:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M18Ua16802 for linux-xfs-outgoing; Thu, 21 Feb 2002 17:08:30 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M18L916780 for ; Thu, 21 Feb 2002 17:08:21 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1M18GFH006454 for ; Thu, 21 Feb 2002 17:08:16 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA75210; Thu, 21 Feb 2002 18:07:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id SAA42287; Thu, 21 Feb 2002 18:06:59 -0600 (CST) Subject: Re: Testing XFS cvs snaptshots at sparc64 From: Eric Sandeen To: root@lucy.ulatina.ac.cr Cc: linux-xfs@oss.sgi.com In-Reply-To: <200202220056.g1M0uwl16580@oss.sgi.com> References: <200202220056.g1M0uwl16580@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Feb 2002 18:06:59 -0600 Message-Id: <1014336420.2047.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi. > > I intend to test XFS for a while on a couple of ultra boxes and then use > it on production servers. > > Because I counld't found a "stable" patch that wasn't only for ia(32|64) > archs, I downloaded the cvs snapshot 2002-02-17. > > While compiling the kernel, at the final link I got the following error. > > ld -m elf64_sparc -T arch/sparc64/vmlinux.lds arch/sparc64/kernel/head.o > arch/sparc64/kernel/init_task.o init/main.o init/version.o --start-group > arch/sparc64/kernel/kernel.o arch/sparc64/mm/mm.o kernel/kernel.o > mm/mm.o fs/fs.o ipc/ipc.o arch/sparc64/math-emu/math-emu.o > drivers/char/char.o drivers/block/block.o drivers/misc/misc.o > drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o > drivers/cdrom/driver.o drivers/pci/driver.o drivers/sbus/sbus_all.o > drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o > drivers/md/mddev.o net/network.o /usr/src/linux/lib/lib.a > /usr/src/linux/lib/lib.a /usr/src/linux/arch/sparc64/prom/promlib.a > /usr/src/linux/arch/sparc64/lib/lib.a --end-group -o vmlinux > fs/fs.o: In function `pagebuf_target_blocksize': > fs/fs.o(.text+0xa1d28): undefined reference to `generic_ffs' > make[1]: *** [kallsyms] Error 1 "generic_ffs" is defined in include/linux/bitops.h, I'm not sure why sparc can't find it. > PS. I read at the changelog of the latest stable release, that you guys > need sparc64 testers. Well, once I have it running what do I have to do? Use it and see what breaks. :) You can also run the tests in cmd/xfstests by editing common.config for your hostname, then running ./check 0?? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Feb 21 17:18:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M1IUA17082 for linux-xfs-outgoing; Thu, 21 Feb 2002 17:18:30 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M1IS917060 for ; Thu, 21 Feb 2002 17:18:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA19310 for ; Thu, 21 Feb 2002 16:13:56 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA40465 for linux-xfs@oss.sgi.com; Fri, 22 Feb 2002 11:16:58 +1100 (EST) Date: Fri, 22 Feb 2002 11:16:58 +1100 (EST) From: Nathan Scott Message-Id: <200202220016.LAA40465@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bitops.h for sparc64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Feb 21 16:16:14 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112387a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.4 - add explicit include of linux/bitops.h - some architectures don't seem to pick this up though the existing set of includes. From owner-linux-xfs@oss.sgi.com Thu Feb 21 22:52:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M6qpY22317 for linux-xfs-outgoing; Thu, 21 Feb 2002 22:52:51 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M6qe922289 for ; Thu, 21 Feb 2002 22:52:40 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA05884 for ; Thu, 21 Feb 2002 21:54:03 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA53133; Fri, 22 Feb 2002 16:51:15 +1100 (AEDT) Date: Fri, 22 Feb 2002 16:51:15 +1100 From: Timothy Shimmin To: unruh@acm.org Cc: Simon Matter , linux-xfs@oss.sgi.com, hlady@cs.usask.ca Subject: Re: xfsrestore fails: assertion failure in do_next_mark Message-ID: <20020222165115.D2733461@boing.melbourne.sgi.com> References: <3C58FAB9.D940E9B8@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from unruh@acm.org on Thu, Jan 31, 2002 at 07:58:02PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys, On Thu, Jan 31, 2002 at 07:58:02PM +0100, unruh@acm.org wrote: > On 31-Jan-2002 Simon Matter wrote: > > > IIRC I got the same error some months ago when trying to restore from a > > DDS2 DAT drive. On the same system restoring from DLT was okay. I didn't > > try again but I guess this bug is still not fixed :-( > > After some reading of the mailing list archives, I added the following at > line 1481 in drive_scsitape.c (version 1.5): > > rechdrp->first_mark_offset = > INT_GET(rechdrp->first_mark_offset,ARCH_CONVERT); > > > The patched xfsrestore can read the damaged backup, > but will probably be unable > to read backups from newer versions of xfsdump. > > Thanks for the suggestion Daniel. Problem ------- Yes this problem was fixed in xfsdump: xfsdump-1.1.10 (10 December 2001) - fix xfsdump to endian convert all of the record header fields properly just prior to writing the header out (in particular first_mark_offset). This caused do_next_mark() assertion failures at some sites. The problem was that the dump record headers were endian converted too early. The "first_mark_offset" field was then overwritten after the conversion prior to being written out to tape. The endian conversion is now (since xfsdump-1.1.10) being done just prior to being written out. So in old dumps, it means that "first_mark_offset" will not be endian converted. And on restore it _will_ be endian converted which will stuff it up. (I haven't looked into why this problem didn't occur for everyone) Restoring old bad dumps ----------------------- So for people with trouble restoring old dumps with the first_mark_offset assertion failure, they need to hack xfsrestore to NOT endian convert first_mark_offset. (Daniel's method would endian convert twice I think and achieve the same result - once in getrec() and then again after that) In drive_scsitape.c, tape records are read in by this call sequence... getrec()->read_record()->record_hdr_validate()->xlate_rec_hdr() So as an alternative to Daniel's suggestion, one could modify arch_xlate.c/xlate_rec_hdr() and take out the first_mark_offset translation: IXLATE(rh1, rh2, first_mark_offset); One could test that the translation looks sane by running xfsrestore with -v4 and looking for msgs of the form "xlate_rec_hdr: pre-xlate\n" and "xlate_rec_hdr: post-xlate\n", and check that what is coming from the tape looks sane and nothing is changing after translation for this field. (Note: the initial conversion of first_mark_offset in the old xfsdump, was done on first_mark_offset's initial value of -1. And if first_mark_offset was never set after that then it would still have a value of -1. And -1 byte-swapped is -1.) ------------------------------ Jason - let me know how you go. --Tim From owner-linux-xfs@oss.sgi.com Fri Feb 22 00:44:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M8iaO25535 for linux-xfs-outgoing; Fri, 22 Feb 2002 00:44:36 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M8iW925512 for ; Fri, 22 Feb 2002 00:44:32 -0800 Received: by monkeyiq.dnsalias.org id g1M7jP631499 ; Fri, 22 Feb 2002 17:45:25 +1000 Date: Fri, 22 Feb 2002 17:45:25 +1000 Message-Id: <200202220745.g1M7jP631499@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com Subject: lvm and segmentation From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have been reading about lvm of late and was thinking of a possilbe drawback to its use. It strikes me that a filesystem no longer knows about a contiguoius disk the lvm and so if I define a preallocated 15Gb file then there is no real say, even if xfs_bmap reports a single extent, that I can be sure that there is a contiguious 15Gb block ready for my data. Just wondering if I am correct in this thought? -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Fri Feb 22 01:13:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M9DAw26258 for linux-xfs-outgoing; Fri, 22 Feb 2002 01:13:10 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M9D3926235 for ; Fri, 22 Feb 2002 01:13:03 -0800 Received: by monkeyiq.dnsalias.org id g1M8DwF01105 ; Fri, 22 Feb 2002 18:13:58 +1000 Date: Fri, 22 Feb 2002 18:13:58 +1000 Message-Id: <200202220813.g1M8DwF01105@monkeyiq.dnsalias.org> To: linux-xfs@oss.sgi.com cc: monkeyiq@users.sourceforge.net Subject: bmv_oflags not being set From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I emailed this a few weeks ago, but now took a little more of an aggresive attack on the problem and found that from what I can tell BMV_OF_PREALLOC is never set from the linux/fs/xfs kernel calls. Indeed a xfs]$ find . -type f -exec grep BMV_OF_PREALLOC {} \; fails to see anything in the kernel code using that value. in /usr/include/xfs_fs.h #line:133 /* bmv_oflags values - returned for for each non-header segment */ #define BMV_OF_PREALLOC 0x1 /* segment = unwritten pre-allocation */ and I had monstered my private xfs_bmap to output the printf(" bmv_oflags=\"%lld\" ", map[i+1].bmv_oflags); which are always == 0; It seems that from line 5759 in fs/xfs/xfs_bmap.c if ( prealloced && map[i].br_startblock == HOLESTARTBLOCK && out.bmv_offset + out.bmv_length == bmvend) { /* * came to hole at end of file */ goto unlock_and_return; } else { that just before the goto maybe if( interface & BMV_IF_PREALLOC ) bmv->bmv_oflags |= BMV_OF_PREALLOC; though I have not looked very deeply at the code, it definately seems to be a bug that the oflags are not being set. -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Fri Feb 22 01:40:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M9evQ26863 for linux-xfs-outgoing; Fri, 22 Feb 2002 01:40:57 -0800 Received: from zork.zork.net (zork.zork.net [66.92.188.166]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M9er926840 for ; Fri, 22 Feb 2002 01:40:53 -0800 Received: from sneakums by zork.zork.net with local (Exim 3.34 #1 (Debian)) id 16eBG9-0005U5-00; Fri, 22 Feb 2002 00:40:53 -0800 To: Linux XFS Subject: Re: lvm and segmentation References: <200202220745.g1M7jP631499@monkeyiq.dnsalias.org> From: Sean Neakums X-Message-Flag: Message text advisory: EXCRETORY SPEECH, SALACIOUS IMAGININGS X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 22 Feb 2002 08:40:53 +0000 In-Reply-To: <200202220745.g1M7jP631499@monkeyiq.dnsalias.org> (monkeyiq's message of "Fri, 22 Feb 2002 17:45:25 +1000") Message-ID: <6ud6yxucx6.fsf@zork.zork.net> Lines: 19 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk commence monkeyiq quotation: > I have been reading about lvm of late and was thinking of a possilbe > drawback to its use. > > It strikes me that a filesystem no longer knows about a contiguoius > disk the lvm and so if I define a preallocated 15Gb file then there > is no real say, even if xfs_bmap reports a single extent, that I can > be sure that there is a contiguious 15Gb block ready for my > data. Just wondering if I am correct in this thought? Sounds about right to me. If it *really* matters where your data ends up on disk (or even which disk it ends up on), you probably shouldn't be using LVM in the first place. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Feb 22 02:06:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MA63527582 for linux-xfs-outgoing; Fri, 22 Feb 2002 02:06:03 -0800 Received: from netfinity.realnet.co.sz (swazi.realnet.co.sz [196.28.7.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MA5l927533 for ; Fri, 22 Feb 2002 02:05:52 -0800 Received: by netfinity.realnet.co.sz (Postfix, from userid 502) id 7C576FA54; Fri, 22 Feb 2002 10:54:37 +0200 (SAST) Received: from localhost (localhost [127.0.0.1]) by netfinity.realnet.co.sz (Postfix) with ESMTP id 79F8665486; Fri, 22 Feb 2002 10:54:37 +0200 (SAST) Date: Fri, 22 Feb 2002 10:54:37 +0200 (SAST) From: Zwane Mwaikambo X-X-Sender: zwane@netfinity.realnet.co.sz To: svetljo Cc: linux-kernel@vger.kernel.org, Subject: Re: linux-2.5.5-dj1 + xfs-cvs --- kernel bug at elevator.c : 237! In-Reply-To: <3C7607A7.2020804@st-peter.stw.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Feb 2002, svetljo wrote: > i tried to get patch-2.5.5dj1 in linux-2.5.5-xfs-cvs > but thats what i got > ##################################### > Activating swap partitions: OK > Finding modules dependancies: OK > Kernel Bug at elevator.c : 237! > Invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010002 > eax: def5dd04 ebx: c0415540 ecx: c0415540 edx: df69501c > esi: c148ac40 edi: 00000000 ebp: 00000202 ecp: c0373e88 > ds: 0018 es: 0018 ss: 0018 > Process swapper(pid: 0, threadinfo=c0372000 task=c0359040) > Stack: c0415540 c0415540 00000002 c027b2cb c0415540 df69501c c0415540 > dfff1980 > 00000000 00000001 c0373ec0 c0373ec0 00000000 00000001 > c0373ec0 c0373ec0 > c0415540 df69501c df69400c c0415540 c0a3f5f2 c0415540 > df69501c 00000002 > Call Trace: [] [] [] [] [] > [] [] [] [] [] > [] > [] [] [] > > Code: 0f 01 ed 00 43 ad 33 c0 8b 42 1c a9 04 00 00 00 75 06 83 e0 > <0> Kernel panic: Aiee,killing interrupt handler ! > In interrupt handler -- not syncing A backtrace would be more handy here, have you searched the archives on wether someone has hit this particular bug with 2.4.x+XFS? Regards, Zwane Mwaikambo From owner-linux-xfs@oss.sgi.com Fri Feb 22 02:08:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MA8YW27727 for linux-xfs-outgoing; Fri, 22 Feb 2002 02:08:34 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MA5w927557 for ; Fri, 22 Feb 2002 02:05:58 -0800 Received: from voyager.st-peter.stw.uni-erlangen.de (voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) 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 BAA09452 for ; Fri, 22 Feb 2002 01:05:55 -0800 (PST) mail_from (galia@st-peter.stw.uni-erlangen.de) Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 16eBUT-0004nX-00; Fri, 22 Feb 2002 09:55:41 +0100 Message-ID: <3C7607A7.2020804@st-peter.stw.uni-erlangen.de> Date: Fri, 22 Feb 2002 09:56:07 +0100 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: linux-2.5.5-dj1 + xfs-cvs --- kernel bug at elevator.c : 237! Content-Type: multipart/mixed; boundary="------------020300060208020203000505" X-Scanner: exiscan *16eBUT-0004nX-00*sgWsE2/58dk* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------020300060208020203000505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit i tried to get patch-2.5.5dj1 in linux-2.5.5-xfs-cvs but thats what i got ##################################### Activating swap partitions: OK Finding modules dependancies: OK Kernel Bug at elevator.c : 237! Invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010002 eax: def5dd04 ebx: c0415540 ecx: c0415540 edx: df69501c esi: c148ac40 edi: 00000000 ebp: 00000202 ecp: c0373e88 ds: 0018 es: 0018 ss: 0018 Process swapper(pid: 0, threadinfo=c0372000 task=c0359040) Stack: c0415540 c0415540 00000002 c027b2cb c0415540 df69501c c0415540 dfff1980 00000000 00000001 c0373ec0 c0373ec0 00000000 00000001 c0373ec0 c0373ec0 c0415540 df69501c df69400c c0415540 c0a3f5f2 c0415540 df69501c 00000002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 01 ed 00 43 ad 33 c0 8b 42 1c a9 04 00 00 00 75 06 83 e0 <0> Kernel panic: Aiee,killing interrupt handler ! In interrupt handler -- not syncing ################################### my .config is attached --------------020300060208020203000505 Content-Type: text/plain; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=".config" # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_PPRO_FENCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM4G_HIGHPTE is not set # CONFIG_HIGHMEM64G is not set # CONFIG_HIGHMEM64G_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_PREEMPT=y # CONFIG_MULTIQUAD is not set CONFIG_HAVE_DEC_LOCK=y # # General options # CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_EISA=y # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y CONFIG_I82092=y CONFIG_I82365=y CONFIG_TCIC=y # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_COMPAQ=m CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_PARTITIONS is not set # CONFIG_MTD_REDBOOT_PARTS is not set CONFIG_MTD_CHAR=m # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set # CONFIG_MTD_GEN_PROBE is not set # CONFIG_MTD_CFI_INTELEXT is not set # CONFIG_MTD_CFI_AMDSTD is not set CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # CONFIG_MTD_AMDSTD is not set # CONFIG_MTD_SHARP is not set # CONFIG_MTD_JEDEC is not set # # Mapping drivers for chip access # # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PNC2000 is not set # CONFIG_MTD_SC520CDP is not set # CONFIG_MTD_NETSC520 is not set # CONFIG_MTD_SBC_GXX is not set # CONFIG_MTD_ELAN_104NC is not set # CONFIG_MTD_MIXMEM is not set # CONFIG_MTD_OCTAGON is not set # CONFIG_MTD_VMAX is not set # CONFIG_MTD_L440GX is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set CONFIG_MTD_SLRAM=m # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set # CONFIG_MTD_DOC1000 is not set # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOCPROBE is not set # # NAND Flash Device Drivers # # CONFIG_MTD_NAND is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set CONFIG_PARPORT_OTHER=y CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=18000 CONFIG_BLK_DEV_INITRD=y # # Enterprise Volume Management System # # CONFIG_EVMS is not set # CONFIG_EVMS_LOCAL_DEV_MGR_PLUGIN is not set # CONFIG_EVMS_DOS_PARTITION_PLUGIN is not set # CONFIG_EVMS_SNAPSHOT_PLUGIN is not set # CONFIG_EVMS_DRIVELINK_PLUGIN is not set # CONFIG_EVMS_BBR_PLUGIN is not set # CONFIG_EVMS_LVM_PLUGIN is not set # CONFIG_EVMS_MD_PLUGIN is not set # CONFIG_EVMS_MD_LINEAR_PERS is not set # CONFIG_EVMS_MD_RAID0_PERS is not set # CONFIG_EVMS_MD_RAID1_PERS is not set # CONFIG_EVMS_MD_RAID5_PERS is not set # CONFIG_EVMS_AIX_PLUGIN is not set # CONFIG_EVMS_OS2_PLUGIN is not set # CONFIG_EVMS_ECR_PLUGIN is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set CONFIG_BLK_DEV_LVM=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_LARGE_TABLES=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_ARPD=y CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_COMPAT_IPFWADM=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IPV6=m # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_QUEUE is not set CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_KHTTPD=m CONFIG_ATM=y CONFIG_ATM_CLIP=y CONFIG_ATM_CLIP_NO_ICMP=y CONFIG_ATM_LANE=m CONFIG_ATM_MPOA=m CONFIG_VLAN_8021Q=m # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set CONFIG_BRIDGE=m CONFIG_X25=m # CONFIG_LAPB is not set CONFIG_LLC=y CONFIG_NET_DIVERT=y # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_ATM=y CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_IDEDISK_STROKE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m CONFIG_IDE_TASK_IOCTL=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_PCI_WIP=y CONFIG_BLK_DEV_IDEDMA_TIMEOUT=y CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set CONFIG_BLK_DEV_HPT366=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC_ADMA is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_PDC202XX_FORCE is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # # SCSI support # CONFIG_SCSI=m CONFIG_BLK_DEV_SD=m CONFIG_SD_EXTRA_DEVS=40 # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=4 CONFIG_CHR_DEV_SG=m # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set CONFIG_SCSI_SYM53C8XX=m CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 # CONFIG_SCSI_NCR53C8XX_PROFILE is not set # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set # CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set # CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_SCSI_PCMCIA is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # CONFIG_I2O=m CONFIG_I2O_PCI=m # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set CONFIG_I2O_PROC=m # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m CONFIG_ETHERTAP=m # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_DE2104X is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set CONFIG_8139TOO=m CONFIG_8139TOO_PIO=y CONFIG_8139TOO_TUNE_TWISTER=y # CONFIG_8139TOO_8129 is not set # CONFIG_8139_NEW_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m CONFIG_PPPOATM=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_PCMCIA_PCNET=m # CONFIG_PCMCIA_AXNET is not set # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_ARCNET_COM20020_CS is not set # CONFIG_PCMCIA_IBMTR is not set # CONFIG_PCMCIA_XIRCOM is not set # CONFIG_PCMCIA_XIRTULIP is not set CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_RAYCS=m # CONFIG_AIRONET4500_CS is not set # # ATM drivers # CONFIG_ATM_TCP=m # CONFIG_ATM_LANAI is not set # CONFIG_ATM_ENI is not set # CONFIG_ATM_FIRESTREAM is not set # CONFIG_ATM_ZATM is not set # CONFIG_ATM_NICSTAR is not set # CONFIG_ATM_IDT77252 is not set # CONFIG_ATM_AMBASSADOR is not set # CONFIG_ATM_HORIZON is not set # CONFIG_ATM_IA is not set # CONFIG_ATM_FORE200E_MAYBE is not set # # Amateur Radio support # CONFIG_HAMRADIO=y CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m # # AX.25 network device drivers # # CONFIG_MKISS is not set # CONFIG_6PACK is not set # CONFIG_BPQETHER is not set # CONFIG_DMASCC is not set # CONFIG_SCC is not set # CONFIG_BAYCOM_SER_FDX is not set # CONFIG_BAYCOM_SER_HDX is not set # CONFIG_BAYCOM_PAR is not set # CONFIG_BAYCOM_EPP is not set # CONFIG_SOUNDMODEM is not set # CONFIG_YAM is not set # # IrDA (infrared) support # CONFIG_IRDA=m # CONFIG_IRLAN is not set # CONFIG_IRNET is not set CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # CONFIG_IRTTY_SIR=m CONFIG_IRPORT_SIR=m # CONFIG_DONGLE is not set CONFIG_USB_IRDA=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_KEYBDEV is not set CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_GAMEPORT_VORTEX is not set # CONFIG_GAMEPORT_FM801 is not set # CONFIG_GAMEPORT_CS461x is not set CONFIG_SERIO=y CONFIG_SERIO_I8042=m CONFIG_I8042_REG_BASE=60 CONFIG_I8042_KBD_IRQ=1 CONFIG_I8042_AUX_IRQ=12 # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set CONFIG_KEYBOARD_PS2SERKBD=m CONFIG_KEYBOARD_XTKBD=m CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_SERIAL=m # CONFIG_MOUSE_GUNZE is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_JOYSTICK_ANALOG is not set # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE_USB is not set # CONFIG_JOYSTICK_IFORCE_232 is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDDLER is not set # CONFIG_JOYSTICK_DB9 is not set # CONFIG_JOYSTICK_GAMECON is not set # CONFIG_JOYSTICK_TURBOGRAFX is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=m # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m # # I2C support # CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_PHILIPSPAR=m CONFIG_I2C_ELV=m CONFIG_I2C_VELLEMAN=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ELEKTOR=m CONFIG_I2C_CHARDEV=m CONFIG_I2C_PROC=m # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set CONFIG_SOFT_WATCHDOG=m # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_PCWATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_I810_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_60XX_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_INTEL_RNG is not set CONFIG_NVRAM=m CONFIG_RTC=m # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_INTEL=y # CONFIG_AGP_I810 is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_ALI is not set # CONFIG_AGP_SWORKS is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set CONFIG_DRM_R128=m # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m # # PCMCIA character devices # # CONFIG_PCMCIA_SERIAL_CS is not set # CONFIG_MWAVE is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # CONFIG_VIDEO_PROC_FS=y CONFIG_I2C_PARPORT=m CONFIG_VIDEO_BT848=m # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZORAN_BUZ is not set # CONFIG_VIDEO_ZORAN_DC10 is not set # CONFIG_VIDEO_ZORAN_LML33 is not set # CONFIG_VIDEO_ZR36120 is not set # CONFIG_VIDEO_MEYE is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_MIROPCM20 is not set # CONFIG_RADIO_MIROPCM20_RDS is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # File systems # CONFIG_QUOTA=y CONFIG_FS_POSIX_ACL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_JFS_FS=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_MINIX_FS=m CONFIG_VXFS_FS=m CONFIG_NTFS_FS=m CONFIG_NTFS_RW=y CONFIG_HPFS_FS=m CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVFS_DEBUG=y CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y CONFIG_SYSV_FS=m CONFIG_UDF_FS=m CONFIG_UDF_RW=y CONFIG_UFS_FS=m CONFIG_UFS_FS_WRITE=y CONFIG_XFS_FS=y CONFIG_XFS_RT=y CONFIG_XFS_QUOTA=y CONFIG_HAVE_ATTRCTL=y CONFIG_XFS_DMAPI=y CONFIG_HAVE_XFS_DMAPI=y # # Network File Systems # CONFIG_CODA_FS=m # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set CONFIG_ZISOFS_FS=y # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set CONFIG_NLS_CODEPAGE_1251=m # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set CONFIG_NLS_ISO8859_5=m # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y CONFIG_FB_RIVA=m CONFIG_FB_CLGEN=m CONFIG_FB_PM2=m CONFIG_FB_PM2_FIFO_DISCONNECT=y CONFIG_FB_PM2_PCI=y CONFIG_FB_CYBER2000=m # CONFIG_FB_VESA is not set CONFIG_FB_VGA16=m # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G100=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_G450=m CONFIG_FB_MATROX_MULTIHEAD=y CONFIG_FB_ATY=m CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_CT=y CONFIG_FB_RADEON=m CONFIG_FB_ATY128=m CONFIG_FB_SIS=m CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y # CONFIG_FB_NEOMAGIC is not set CONFIG_FB_3DFX=m CONFIG_FB_VOODOO1=m # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set CONFIG_FBCON_ADVANCED=y CONFIG_FBCON_MFB=m # CONFIG_FBCON_CFB2 is not set # CONFIG_FBCON_CFB4 is not set CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y # CONFIG_FBCON_AFB is not set # CONFIG_FBCON_ILBM is not set # CONFIG_FBCON_IPLAN2P2 is not set # CONFIG_FBCON_IPLAN2P4 is not set # CONFIG_FBCON_IPLAN2P8 is not set # CONFIG_FBCON_MAC is not set CONFIG_FBCON_VGA_PLANES=m CONFIG_FBCON_VGA=m # CONFIG_FBCON_HGA is not set # CONFIG_FBCON_FONTWIDTH8_ONLY is not set CONFIG_FBCON_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_6x11 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # # Sound # CONFIG_SOUND=m # # Open Sound System # CONFIG_SOUND_PRIME=m CONFIG_SOUND_BT878=m # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_MIDI_VIA82CXXX is not set # CONFIG_SOUND_YMFPCI is not set # CONFIG_SOUND_YMFPCI_LEGACY is not set # CONFIG_SOUND_OSS is not set CONFIG_SOUND_TVMIXER=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_RTCTIMER=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=m # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # ISA devices # # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_DT0197H is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_TRIDENT is not set CONFIG_SND_YMFPCI=m # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA686 is not set # CONFIG_SND_VIA8233 is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y CONFIG_USB_LONG_TIMEOUT=y CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI=m CONFIG_USB_UHCI_ALT=m CONFIG_USB_OHCI=m CONFIG_USB_AUDIO=m CONFIG_USB_BLUETOOTH=m # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_HID=m CONFIG_USB_HIDDEV=y CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_WACOM=m # CONFIG_USB_POWERMATE is not set CONFIG_USB_DC2XX=m CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # CONFIG_USB_IBMCAM is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set CONFIG_USB_USBNET=m # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_AUERSWALD is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_OBSOLETE is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_486_STRING is not set # CONFIG_KDB is not set # CONFIG_KDB_MODULES is not set # CONFIG_KALLSYMS is not set # CONFIG_FRAME_POINTER is not set # # Library routines # CONFIG_CRC32=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m --------------020300060208020203000505-- From owner-linux-xfs@oss.sgi.com Fri Feb 22 02:12:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MAC5b28170 for linux-xfs-outgoing; Fri, 22 Feb 2002 02:12:05 -0800 Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MAC0928148 for ; Fri, 22 Feb 2002 02:12:01 -0800 Received: from burns.home.kernel.dk ([192.168.0.2] ident=mail) by virtualhost.dk with esmtp (Exim 3.34 #1) id 16eBfG-0004He-00; Fri, 22 Feb 2002 10:06:50 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.34 #1) id 16eBdN-0000eD-00; Fri, 22 Feb 2002 10:04:53 +0100 Date: Fri, 22 Feb 2002 10:04:53 +0100 From: Jens Axboe To: svetljo Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: linux-2.5.5-dj1 + xfs-cvs --- kernel bug at elevator.c : 237! Message-ID: <20020222090453.GI1427@suse.de> References: <3C7607A7.2020804@st-peter.stw.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7607A7.2020804@st-peter.stw.uni-erlangen.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 22 2002, svetljo wrote: > i tried to get patch-2.5.5dj1 in linux-2.5.5-xfs-cvs > but thats what i got > ##################################### > Activating swap partitions: OK > Finding modules dependancies: OK > Kernel Bug at elevator.c : 237! > Invalid operand: 0000 known problem, disable ide floppy support for now. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Fri Feb 22 02:41:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MAfMv29205 for linux-xfs-outgoing; Fri, 22 Feb 2002 02:41:22 -0800 Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MAfG929182 for ; Fri, 22 Feb 2002 02:41:16 -0800 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 16eCCP-00054R-00; Fri, 22 Feb 2002 10:41:05 +0100 Message-ID: <3C76124D.50505@st-peter.stw.uni-erlangen.de> Date: Fri, 22 Feb 2002 10:41:33 +0100 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Jens Axboe CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: linux-2.5.5-dj1 + xfs-cvs --- kernel bug at elevator.c : 237! References: <3C7607A7.2020804@st-peter.stw.uni-erlangen.de> <20020222090453.GI1427@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16eCCP-00054R-00*KJS843Qu.5c* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > >>i tried to get patch-2.5.5dj1 in linux-2.5.5-xfs-cvs >>but thats what i got >>##################################### >>Activating swap partitions: OK >>Finding modules dependancies: OK >>Kernel Bug at elevator.c : 237! >>Invalid operand: 0000 >> > >known problem, disable ide floppy support for now. > thanks that fixed it i have to only figure it out , how to get keyboard(PS2) and mices(PS2 and USB) working From owner-linux-xfs@oss.sgi.com Fri Feb 22 04:36:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MCadX03833 for linux-xfs-outgoing; Fri, 22 Feb 2002 04:36:39 -0800 Received: from papadoc.bayour.com (qmailr@papadoc.bayour.com [195.163.1.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MCaX903811 for ; Fri, 22 Feb 2002 04:36:34 -0800 Received: (qmail-ldap/ctrl 9285 invoked by uid 1000); 22 Feb 2002 11:36:31 -0000 To: linux-xfs@oss.sgi.com Subject: Kickstarting and XFSInstaller 1.0.2a X-PGP-Fingerprint: B7 92 93 0E 06 94 D6 22 98 1F 0B 5B FE 33 A1 0B X-PGP-Key-ID: 0x788CD1A9 X-URL: http://www.nocrew.org/~turbo/ From: Turbo Fredriksson Organization: Bah! X-Yow: What UNIVERSE is this, please?? Date: 22 Feb 2002 12:36:30 +0100 Message-ID: <87n0y14ukh.fsf@papadoc.bayour.com> Lines: 7 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Where there any problems with this? I can't seem to get this to work. Everything worked on the previous release... supercomputer spy counter-intelligence Qaddafi World Trade Center [Hello to all my fans in domestic surveillance] Marxist NSA Panama colonel FBI subway Ft. Meade smuggle genetic [See http://www.aclu.org/echelonwatch/index.html for more about this] From owner-linux-xfs@oss.sgi.com Fri Feb 22 06:38:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MEcOq11252 for linux-xfs-outgoing; Fri, 22 Feb 2002 06:38:24 -0800 Received: from papadoc.bayour.com (qmailr@papadoc.bayour.com [195.163.1.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MEcE911230 for ; Fri, 22 Feb 2002 06:38:14 -0800 Received: (qmail-ldap/ctrl 12482 invoked by uid 1000); 22 Feb 2002 13:38:11 -0000 To: linux-xfs@oss.sgi.com Subject: Re: Kickstarting and XFSInstaller 1.0.2a References: <87n0y14ukh.fsf@papadoc.bayour.com> X-PGP-Fingerprint: B7 92 93 0E 06 94 D6 22 98 1F 0B 5B FE 33 A1 0B X-PGP-Key-ID: 0x788CD1A9 X-URL: http://www.nocrew.org/~turbo/ From: Turbo Fredriksson Organization: Bah! X-Yow: Is something VIOLENT going to happen to a GARBAGE CAN? Date: 22 Feb 2002 14:38:11 +0100 In-Reply-To: <87n0y14ukh.fsf@papadoc.bayour.com> Message-ID: <87heo94oxo.fsf@papadoc.bayour.com> Lines: 50 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Turbo" == Turbo Fredriksson writes: Turbo> Where there any problems with this? I can't seem to get Turbo> this to work. Everything worked on the previous release... Never mind that, I forgot to copy my kickstart config file onto the initrd image... Now I get another error... Error mounting device sda5 as /: No such device Switching to terminal 2, and using the shell there: sh-2.04# mkfs.xfs -f /tmp/sda5 mkfs.xfs: warning - cannot set blocksize on block device /tmp/sda5: Invalid argument But the disk is getting 'formated' with XFS... Trying to mount it: sh-2.04# mount -t xfs /tmp/sda5 /mnt/sysimage/ mount failed: No such device Checking the output on tty5, I see the warnings from mkfs.xfs on ALL the devices I try to use... The devices: sh-2.04# ls -l /tmp/sda* brw------- 1 root 0 8, 0 Feb 22 05:24 //tmp/sda brw------- 1 root 0 8, 1 Feb 22 05:24 //tmp/sda1 brw------- 1 root 0 8, 5 Feb 22 05:24 //tmp/sda5 brw------- 1 root 0 8, 6 Feb 22 05:24 //tmp/sda6 The output from fdisk looks good (to cumbersome to 'rewrite' here :). Part of my ks.cfg file: zerombr yes clearpart --all part /boot --size 100 part /tmp --size 200 part swap --size 133 part / --size 500 --grow install FBI arrangements Clinton cracking FSF pits BATF security Delta Force critical Ortega nitrate Serbian Treasury strategic [See http://www.aclu.org/echelonwatch/index.html for more about this] From owner-linux-xfs@oss.sgi.com Fri Feb 22 07:29:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MFToq12346 for linux-xfs-outgoing; Fri, 22 Feb 2002 07:29:50 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MFTj912323 for ; Fri, 22 Feb 2002 07:29:45 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16eGhh-0004Er-00; Fri, 22 Feb 2002 09:29:42 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g1METe404645; Fri, 22 Feb 2002 09:29:40 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: monkeyiq Cc: linux-xfs@oss.sgi.com Subject: Re: lvm and segmentation From: "Martin K. Petersen" Organization: Linuxcare, Inc. References: <200202220745.g1M7jP631499@monkeyiq.dnsalias.org> Date: 22 Feb 2002 09:29:40 -0500 In-Reply-To: <200202220745.g1M7jP631499@monkeyiq.dnsalias.org> Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "monkeyiq" == monkeyiq writes: monkeyiq> It strikes me that a filesystem no longer knows about a monkeyiq> contiguoius disk the lvm and so if I define a preallocated monkeyiq> 15Gb file then there is no real say, even if xfs_bmap monkeyiq> reports a single extent, that I can be sure that there is a monkeyiq> contiguious 15Gb block ready for my data. Just wondering if monkeyiq> I am correct in this thought? In theory, yes. LVM allocates space in big fixed-size blocks (called extents in LVM, but they are not arbitrarily sized like ours). By default these are 4MB each. See the -s option to vgcreate. So worst case your file will be chopped into discontiguous chunks of 4MB each (plus fluff for misalignment at the beginning and end). On top of that you can tell lvcreate to try and allocate contiguous space (-C) when you create a volume. If you don't pvmove or grow the volume often, chances are your data will be mostly contiguous. You can check the physical mapping using lvdisplay. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Feb 22 08:09:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MG9HI14530 for linux-xfs-outgoing; Fri, 22 Feb 2002 08:09:17 -0800 Received: from papadoc.bayour.com (qmailr@papadoc.bayour.com [195.163.1.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MG9C914507 for ; Fri, 22 Feb 2002 08:09:12 -0800 Received: (qmail-ldap/ctrl 17466 invoked by uid 1000); 22 Feb 2002 15:09:09 -0000 To: linux-xfs@oss.sgi.com Subject: Re: Kickstarting and XFSInstaller 1.0.2a References: <87n0y14ukh.fsf@papadoc.bayour.com> <87heo94oxo.fsf@papadoc.bayour.com> X-PGP-Fingerprint: B7 92 93 0E 06 94 D6 22 98 1F 0B 5B FE 33 A1 0B X-PGP-Key-ID: 0x788CD1A9 X-URL: http://www.nocrew.org/~turbo/ From: Turbo Fredriksson Organization: Bah! X-Yow: An air of FRENCH FRIES permeates my nostrils!! Date: 22 Feb 2002 16:09:09 +0100 In-Reply-To: <87heo94oxo.fsf@papadoc.bayour.com> Message-ID: <87d6yx4kq2.fsf@papadoc.bayour.com> Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry yet again... This time I had forgotten to update the RedHat/base/*.img files... *blush* Sorry about the wasted bandwidth. Albanian KGB arrangements Treasury jihad Qaddafi radar North Korea CIA 747 toluene class struggle Rule Psix subway NSA [See http://www.aclu.org/echelonwatch/index.html for more about this] From owner-linux-xfs@oss.sgi.com Fri Feb 22 08:20:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MGKk114791 for linux-xfs-outgoing; Fri, 22 Feb 2002 08:20:46 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MGKd914769 for ; Fri, 22 Feb 2002 08:20:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 HAA12842 for ; Fri, 22 Feb 2002 07:16:13 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA78916; Fri, 22 Feb 2002 09:19:23 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA78793; Fri, 22 Feb 2002 09:19:23 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1MFGjF02978; Fri, 22 Feb 2002 09:16:45 -0600 Subject: Re: bmv_oflags not being set From: Steve Lord To: monkeyiq Cc: linux-xfs@oss.sgi.com In-Reply-To: <200202220813.g1M8DwF01105@monkeyiq.dnsalias.org> References: <200202220813.g1M8DwF01105@monkeyiq.dnsalias.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Feb 2002 09:16:45 -0600 Message-Id: <1014391005.2895.75.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yep, this flag is never set to anything but zero - even Irix looks that way. The question is what should the flag mean - that we are in an extent which goes beyond the end of file, it looks like that is the intent. Steve On Fri, 2002-02-22 at 02:13, monkeyiq wrote: > Hi, > I emailed this a few weeks ago, but now took a little more > of an aggresive attack on the problem and found that from what I > can tell BMV_OF_PREALLOC is never set from the linux/fs/xfs kernel > calls. Indeed a > xfs]$ find . -type f -exec grep BMV_OF_PREALLOC {} \; > fails to see anything in the kernel code using that value. > > > in /usr/include/xfs_fs.h #line:133 > /* bmv_oflags values - returned for for each non-header segment */ > #define BMV_OF_PREALLOC 0x1 /* segment = unwritten pre-allocation */ > > and I had monstered my private xfs_bmap to output the > printf(" bmv_oflags=\"%lld\" ", map[i+1].bmv_oflags); > which are always == 0; > > It seems that from line 5759 in fs/xfs/xfs_bmap.c > if ( prealloced > && map[i].br_startblock == HOLESTARTBLOCK > && out.bmv_offset + out.bmv_length == bmvend) { > /* > * came to hole at end of file > */ > goto unlock_and_return; > } else { > that just before the goto maybe > if( interface & BMV_IF_PREALLOC ) > bmv->bmv_oflags |= BMV_OF_PREALLOC; > > though I have not looked very deeply at the code, it definately > seems to be a bug that the oflags are not being set. > > -- > ----------------------------------------------------- > http://witme.sourceforge.net/libferris.web/ -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 22 10:28:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MISZ217113 for linux-xfs-outgoing; Fri, 22 Feb 2002 10:28:35 -0800 Received: from imf07bis.bellsouth.net (mail307.mail.bellsouth.net [205.152.58.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MISS917091 for ; Fri, 22 Feb 2002 10:28:28 -0800 Received: from taz ([66.156.33.27]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020222172943.MNSK6900.imf07bis.bellsouth.net@taz> for ; Fri, 22 Feb 2002 12:29:43 -0500 Date: Fri, 22 Feb 2002 12:24:51 -0500 From: Greg Freemyer Subject: Current Status ?? To: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020222172943.MNSK6900.imf07bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1MIST917092 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just gotten interested in XFS because of its ACL support in the metadata and via xfsdump/xfsrestore. I'm trying to figure out what its current status is, and what is likely to happen over the next few months. Does the below sound correct: Current release (XFS v1.0.2): fairly stable, appears to be production quality Supports ACLs on disk and with xfsdump/xfsrestore. With xfsrestore a single file can be restored complete with its associated ACL metadata. Uses a XFS specific interface to the kernel from userland to manipulate ACL. Has trouble with LVM snapshots (maybe this is CVS code only). XFS v2.0: Will be released when the new Linus approved EA interface is added to the kernel. (I can't tell if this is 2.4.18, or 2.5.x) The filesystem layout itself will not change, but the userland tools from V2.0 will not be compatible with a V1.0 kernel and vice-versa. Questions: Is the new EA API coming out in 2.4.18 the same as the one in 2.5.x? If so, how long after 2.4.18 is released do you expect XFS V2.0 to be released? (days, weeks, months??) The first release of V2.0 will be what quality? (alpha, beta, production??) Is the 2.4.18 kernel likely to be of production quality? I have read about a lot of problems in the whole 2.4.x series of kernels, but it sounds like it is all coming together in the most recent kernels. Because the of the new standard EA interface, will V2.0 userland ACL tools will be able to control both XFS and ext3 with the acl.bestbits.at extensions. Is star (http://acl.bestbits.at/backup.html) able to support XFS complete with ACLs by using the Posix ACL interface. If not now, what about with XFS V2.0? What about xfsdump/xfsrestore and ext3 with ACL support? Does Amanda work well with xfsdump/xfsrestore? star? In general, do you think XFS or ext3 with ACL extensions is a more production ready environment. (I know your biased, but I would still appreciate an answer.) Thanks for any answers you can give me. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Fri Feb 22 11:33:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MJXAg18014 for linux-xfs-outgoing; Fri, 22 Feb 2002 11:33:10 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MJWt917992 for ; Fri, 22 Feb 2002 11:32:55 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA360832 for ; Fri, 22 Feb 2002 19:33:59 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA82051; Fri, 22 Feb 2002 12:31:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA89365; Fri, 22 Feb 2002 12:31:32 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1MISr110410; Fri, 22 Feb 2002 12:28:53 -0600 Subject: Re: Current Status ?? From: Steve Lord To: Greg Freemyer Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020222172943.MNSK6900.imf07bis.bellsouth.net@taz> References: <20020222172943.MNSK6900.imf07bis.bellsouth.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Feb 2002 12:28:53 -0600 Message-Id: <1014402533.2929.162.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-22 at 11:24, Greg Freemyer wrote: > > I've just gotten interested in XFS because of its ACL support in the metadata and via xfsdump/xfsrestore. > > I'm trying to figure out what its current status is, and what is likely to happen over the next few months. > > Does the below sound correct: > > Current release (XFS v1.0.2): > fairly stable, appears to be production quality > Supports ACLs on disk and with xfsdump/xfsrestore. > With xfsrestore a single file can be restored complete with its associated ACL metadata. > Uses a XFS specific interface to the kernel from userland to manipulate ACL. > Has trouble with LVM snapshots (maybe this is CVS code only). CVS and the kernel patches have come a long way since 1.02 was released, a lot of bugs have been fixed in the kernel and user space code which are not in the original rpms. LVM snapshots do appear to have some issues still, although I am not sure what the current status really is on this one. > > XFS v2.0: > Will be released when the new Linus approved EA interface is added to the kernel. > (I can't tell if this is 2.4.18, or 2.5.x) > The filesystem layout itself will not change, but the userland tools from V2.0 will not be compatible with a V1.0 kernel and vice-versa. > They will be compatible in all areas except acls and extended attributes. > Questions: > Is the new EA API coming out in 2.4.18 the same as the one in 2.5.x? yes. > > If so, how long after 2.4.18 is released do you expect XFS V2.0 to be released? (days, weeks, months??) Days - we have rc3 in a tree now, rc4 just came out and is really small. > > The first release of V2.0 will be what quality? (alpha, beta, production??) Well, in theory things keep getting better as we go along, so cvs should be 'better' than the 1.02 release rpms. Regressions do happen, but in general I would say we should be at or higher than the reliability level of the original 1.02 release. I do not think there will be much 'extra' testing going into this version if that is what you are asking. > > Is the 2.4.18 kernel likely to be of production quality? I have read about a lot of problems in the whole 2.4.x series of kernels, but it sounds like it is all coming together in the most recent kernels. > Things do seem to be getting better. For general linux things you pretty much have to look at linux-kernel and judge for yourself. > Because the of the new standard EA interface, will V2.0 userland ACL tools will be able to control both XFS and ext3 with the acl.bestbits.at extensions. That is the theory. > > Is star (http://acl.bestbits.at/backup.html) able to support XFS complete with ACLs by using the Posix ACL interface. If not now, what about with XFS V2.0? > I have no idea - it all depends on how star extracts data from the filesystem, does it run on a live filesystem, or does it use the block interface. If the former then it may work, if the latter then no it will not work. > What about xfsdump/xfsrestore and ext3 with ACL support? xfsdump will not work on filesystems other than xfs - since it uses xfs specific extensions to scan the filesystem. Restore should be able to restore an xfs filesystem with acls to another acl enabled filesystem type - I think. > > Does Amanda work well with xfsdump/xfsrestore? star? > Amanda works with xfsdump/restore, I cannot speak for star. > In general, do you think XFS or ext3 with ACL extensions is a more production ready environment. (I know your biased, but I would still appreciate an answer.) > I will leave the answer to that to external people, all I can say is that xfs has had more production time than ext3, but ext3 comes from an existing linux filesystem which has had way more linux time than xfs has. I actually use both filesystems - since when testing radical xfs things I want to be able to isolate things down to one filesystem and not have to reinstall if things go bad. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 22 11:52:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MJq0n18395 for linux-xfs-outgoing; Fri, 22 Feb 2002 11:52:00 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-174.qld.bigpond.net.au [203.45.214.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MJpj918373 for ; Fri, 22 Feb 2002 11:51:45 -0800 Received: by monkeyiq.dnsalias.org id g1MIqNM13923 ; Sat, 23 Feb 2002 04:52:23 +1000 Date: Sat, 23 Feb 2002 04:52:23 +1000 Message-Id: <200202221852.g1MIqNM13923@monkeyiq.dnsalias.org> To: Steve Lord Cc: monkeyiq , linux-xfs@oss.sgi.com Subject: Re: bmv_oflags not being set From: monkeyiq MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord writes: > Yep, this flag is never set to anything but zero - even Irix looks that > way. The question is what should the flag mean - that we are in an > extent which goes beyond the end of file, it looks like that is the > intent. Firstly, my rationale for wanting this flag: I want to allow a nice easy way for people to add and trim preallocation at the end of file in libferris. I could assume that if the final extent is a hole then it is preallocation, but I would really like to know for sure so that I can issue a XFS_IOC_UNRESVSP64 with a relative feeling that it will work (given that displaying the size of the unused preallocation at eof and the user deciding to "trim" it may be seperated by a little time). I admit that it would be rare for an application to write files that have a hole at the end that is not left over preallocation, but if the flag is there to tell if an extent is prealloc then I can know for sure :) BTW ferriscreate already has support for making files with preallocation, this final loop will be handy for ferrisclients to be able to trim back preallocation that they have not used. Now some other thoughts: A quick play around with mkfile and bmap show an interesting thing [tmp]$ cat dropbyte.c #include #include #include #include int main( int argc, char** argv ) { int fd = open("test", O_WRONLY); printf(" fd:%ld\n", fd ); lseek(fd, 5000, SEEK_SET ); write( fd, "hello", 5 ); close(fd); } [tmp]$ /usr/sbin/xfs_mkfile -n -p 128k test [tmp]$ /usr/sbin/xfs_bmap -vp test test: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..247]: hole 248 1: [248..255]: 1533656..1533663 1 (764552..764559) 8 [tmp]$ ./dropbyte fd:3 [tmp]$ /usr/sbin/xfs_bmap -vp test test: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: hole 8 1: [8..15]: 1186760..1186767 1 (417656..417663) 8 2: [16..247]: hole 232 3: [248..255]: 1533656..1533663 1 (764552..764559) 8 I was always thinking that the "preallocate" flag was an indicator to tell if that extent was a hole that was there on purpose or if the hole was part of preallocated space and not really there by application design. One does land on strange ground in with the last command because there are two "preallocation" sections, one at the prefix and one suffix preallocation. This is way I assumed the XFS_IOC_UNRESVSP64 command took a xfs_flock64_t typedef struct xfs_flock64 { __s16 l_type; __s16 l_whence; __s64 l_start; __s64 l_len; /* len == 0 means until end of file */ __s32 l_sysid; pid_t l_pid; __s32 l_pad[4]; /* reserve area */ } xfs_flock64_t; So that one could round up these pesky preallocations that remained only due to an application seeking and writing. > > Steve > > > On Fri, 2002-02-22 at 02:13, monkeyiq wrote: > > Hi, > > I emailed this a few weeks ago, but now took a little more > > of an aggresive attack on the problem and found that from what I > > can tell BMV_OF_PREALLOC is never set from the linux/fs/xfs kernel > > calls. Indeed a > > xfs]$ find . -type f -exec grep BMV_OF_PREALLOC {} \; > > fails to see anything in the kernel code using that value. > > > > > > in /usr/include/xfs_fs.h #line:133 > > /* bmv_oflags values - returned for for each non-header segment */ > > #define BMV_OF_PREALLOC 0x1 /* segment = unwritten pre-allocation */ > > > > and I had monstered my private xfs_bmap to output the > > printf(" bmv_oflags=\"%lld\" ", map[i+1].bmv_oflags); > > which are always == 0; > > > > It seems that from line 5759 in fs/xfs/xfs_bmap.c > > if ( prealloced > > && map[i].br_startblock == HOLESTARTBLOCK > > && out.bmv_offset + out.bmv_length == bmvend) { > > /* > > * came to hole at end of file > > */ > > goto unlock_and_return; > > } else { > > that just before the goto maybe > > if( interface & BMV_IF_PREALLOC ) > > bmv->bmv_oflags |= BMV_OF_PREALLOC; > > > > though I have not looked very deeply at the code, it definately > > seems to be a bug that the oflags are not being set. > > > > -- > > ----------------------------------------------------- > > http://witme.sourceforge.net/libferris.web/ > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Fri Feb 22 12:00:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MK0FR18696 for linux-xfs-outgoing; Fri, 22 Feb 2002 12:00:15 -0800 Received: from imf13bis.bellsouth.net (mail213.mail.bellsouth.net [205.152.58.153]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MJxv918641 for ; Fri, 22 Feb 2002 11:59:57 -0800 Received: from taz ([66.156.33.27]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020222190112.MIFP27846.imf13bis.bellsouth.net@taz>; Fri, 22 Feb 2002 14:01:12 -0500 Date: Fri, 22 Feb 2002 13:56:32 -0500 From: Greg Freemyer Subject: re[2]: Current Status ?? To: Steve Lord cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020222190112.MIFP27846.imf13bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1MJxw918642 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Thanks for the feedback. As to what I was thinking about relating to XFS 2.0's quality. Given that the EA/ACL interface has obviously been changed at both the userland-kernel interface and at the kernel-xfs driver interface, I am curious if this is likely to introduce any instabilities in the first release, or if you believe you have performed enough regression testing to be comfortable with the changes. (Obviously I need to click on that "QA" link on your website. I'm off to do that now. Thanks Again, Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com >> On Fri, 2002-02-22 at 11:24, Greg Freemyer wrote: >> > >> > I've just gotten interested in XFS because of its ACL support in the >> metadata and via xfsdump/xfsrestore. >> > >> > I'm trying to figure out what its current status is, and what is likely >> to happen over the next few months. >> > >> > Does the below sound correct: >> > >> > Current release (XFS v1.0.2): >> > fairly stable, appears to be production quality >> > Supports ACLs on disk and with xfsdump/xfsrestore. >> > With xfsrestore a single file can be restored complete with its >> associated ACL metadata. >> > Uses a XFS specific interface to the kernel from userland to >> manipulate ACL. >> > Has trouble with LVM snapshots (maybe this is CVS code only). >> CVS and the kernel patches have come a long way since 1.02 was released, >> a lot of bugs have been fixed in the kernel and user space code which are >> not in the original rpms. >> LVM snapshots do appear to have some issues still, although I am >> not sure what the current status really is on this one. >> > >> > XFS v2.0: >> > Will be released when the new Linus approved EA interface is added >> to the kernel. >> > (I can't tell if this is 2.4.18, or 2.5.x) >> > The filesystem layout itself will not change, but the userland tools >> from V2.0 will not be compatible with a V1.0 kernel and vice-versa. >> > >> They will be compatible in all areas except acls and extended >> attributes. >> > Questions: >> > Is the new EA API coming out in 2.4.18 the same as the one in 2.5.x? >> yes. >> > >> > If so, how long after 2.4.18 is released do you expect XFS V2.0 to be >> released? (days, weeks, months??) >> Days - we have rc3 in a tree now, rc4 just came out and is really small. >> > >> > The first release of V2.0 will be what quality? (alpha, beta, >> production??) >> Well, in theory things keep getting better as we go along, so cvs should >> be 'better' than the 1.02 release rpms. Regressions do happen, but in >> general I would say we should be at or higher than the reliability level >> of the original 1.02 release. I do not think there will be much 'extra' >> testing going into this version if that is what you are asking. >> > >> > Is the 2.4.18 kernel likely to be of production quality? I have read >> about a lot of problems in the whole 2.4.x series of kernels, but it >> sounds like it is all coming together in the most recent kernels. >> > >> Things do seem to be getting better. For general linux things you pretty >> much have to look at linux-kernel and judge for yourself. >> >> > Because the of the new standard EA interface, will V2.0 userland ACL >> tools will be able to control both XFS and ext3 with the acl.bestbits.at >> extensions. >> That is the theory. >> > >> > Is star (http://acl.bestbits.at/backup.html) able to support XFS >> complete with ACLs by using the Posix ACL interface. If not now, what >> about with XFS V2.0? >> > >> I have no idea - it all depends on how star extracts data from the >> filesystem, does it run on a live filesystem, or does it use the >> block interface. If the former then it may work, if the latter then >> no it will not work. >> > What about xfsdump/xfsrestore and ext3 with ACL support? >> xfsdump will not work on filesystems other than xfs - since it uses xfs >> specific extensions to scan the filesystem. Restore should be able to >> restore an xfs filesystem with acls to another acl enabled filesystem >> type - I think. >> > >> > Does Amanda work well with xfsdump/xfsrestore? star? >> > >> Amanda works with xfsdump/restore, I cannot speak for star. >> > In general, do you think XFS or ext3 with ACL extensions is a more >> production ready environment. (I know your biased, but I would still >> appreciate an answer.) >> > >> I will leave the answer to that to external people, all I can say is >> that xfs has had more production time than ext3, but ext3 comes from >> an existing linux filesystem which has had way more linux time >> than xfs has. >> I actually use both filesystems - since when testing radical xfs things >> I want to be able to isolate things down to one filesystem and not have >> to reinstall if things go bad. >> Steve >> -- >> Steve Lord voice: +1-651-683-3511 >> Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Feb 22 12:07:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MK7xK18921 for linux-xfs-outgoing; Fri, 22 Feb 2002 12:07:59 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MK7s918899 for ; Fri, 22 Feb 2002 12:07:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1MJ7nhd021129 for ; Fri, 22 Feb 2002 11:07:49 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA82770; Fri, 22 Feb 2002 13:06:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA10221; Fri, 22 Feb 2002 13:06:34 -0600 (CST) Subject: Re: re[2]: Current Status ?? From: Eric Sandeen To: Greg Freemyer Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <20020222190112.MIFP27846.imf13bis.bellsouth.net@taz> References: <20020222190112.MIFP27846.imf13bis.bellsouth.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Feb 2002 13:06:33 -0600 Message-Id: <1014404794.8790.13.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-22 at 12:56, Greg Freemyer wrote: > Steve, > > Thanks for the feedback. > > As to what I was thinking about relating to XFS 2.0's quality. Given that the EA/ACL interface has obviously been changed at both the userland-kernel interface and at the kernel-xfs driver interface, I am curious if this is likely to introduce any instabilities in the first release, or if you believe you have performed enough regression testing to be comfortable with the changes. Before we go to far, it's not going to be called "XFS 2.0" :) re: quality, it's not even released yet, so it will be hard to say. The first thing available will be a snapshot, with all the (lack of) guarantees that come along with that. We will eventually do another "official" release, which will be much more rigorously tested at SGI before it's done. And of course, as the GPL says, there won't be any guarantees with that either. :) We can do QA all day long, but in the end you should still test it in your environment before you put it into production. -Eric > > (Obviously I need to click on that "QA" link on your website. I'm off to do that now. > > Thanks Again, > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > The Norcross Group > www.NorcrossGroup.com > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Feb 22 12:23:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MKNRI19244 for linux-xfs-outgoing; Fri, 22 Feb 2002 12:23:27 -0800 Received: from imf15bis.bellsouth.net (mail315.mail.bellsouth.net [205.152.58.175]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MKNK919222 for ; Fri, 22 Feb 2002 12:23:20 -0800 Received: from taz ([66.156.33.27]) by imf15bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020222192435.OHZA3299.imf15bis.bellsouth.net@taz>; Fri, 22 Feb 2002 14:24:35 -0500 Date: Fri, 22 Feb 2002 14:19:59 -0500 From: Greg Freemyer Subject: re[4]: Current Status ?? To: Eric Sandeen cc: Steve Lord , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020222192435.OHZA3299.imf15bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1MKNL919223 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> On Fri, 2002-02-22 at 12:56, Greg Freemyer wrote: >> > Steve, >> > >> > Thanks for the feedback. >> > >> > As to what I was thinking about relating to XFS 2.0's quality. Given >> that the EA/ACL interface has obviously been changed at both the >> userland-kernel interface and at the kernel-xfs driver interface, I am >> curious if this is likely to introduce any instabilities in the first >> release, or if you believe you have performed enough regression testing >> to be comfortable with the changes. >> Before we go to far, it's not going to be called "XFS 2.0" :) My mistake. I thought I read that in a previous e-mail. >> re: quality, it's not even released yet, so it will be hard to say. The >> first thing available will be a snapshot, with all the (lack of) >> guarantees that come along with that. I assume it is this snapshot that will hopefully come out a few days after 2.4.18. >> We will eventually do another >> "official" release, which will be much more rigorously tested at SGI >> before it's done. Any idea on the timing. I really prefer to work with "released" code in preference to snapshots. >> And of course, as the GPL says, there won't be any >> guarantees with that either. :) We can do QA all day long, but in the >> end you should still test it in your environment before you put it into >> production. Understood. As a matter of fact I ordered hardware yesterday to setup a test environment on. >> -Eric >> > >> > (Obviously I need to click on that "QA" link on your website. I'm off >> to do that now. >> > Is there a QA testing write-up on the website? I thought I had seen a link to that effect, but now I can't find it. >> -- >> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >> sandeen@sgi.com SGI, Inc. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Fri Feb 22 12:41:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MKfRQ19671 for linux-xfs-outgoing; Fri, 22 Feb 2002 12:41:27 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MKfM919649 for ; Fri, 22 Feb 2002 12:41:22 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 LAA13486 for ; Fri, 22 Feb 2002 11:36:55 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA83448; Fri, 22 Feb 2002 13:40:04 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA90569; Fri, 22 Feb 2002 13:40:04 -0600 (CST) Subject: Re: re[4]: Current Status ?? From: Eric Sandeen To: Greg Freemyer Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <20020222192435.OHZA3299.imf15bis.bellsouth.net@taz> References: <20020222192435.OHZA3299.imf15bis.bellsouth.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Feb 2002 13:40:04 -0600 Message-Id: <1014406804.8790.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-02-22 at 13:19, Greg Freemyer wrote: > >> On Fri, 2002-02-22 at 12:56, Greg Freemyer wrote: > >> Before we go to far, it's not going to be called "XFS 2.0" :) > > My mistake. I thought I read that in a previous e-mail. I think maybe some of the userspace will have a "2.0" tag on it, but probably not the kernel code. (they don't track like that) > I assume it is this snapshot that will hopefully come out a few days after 2.4.18. Yep. > Any idea on the timing. I really prefer to work with "released" code in preference to snapshots. The next formal release is slated for this quarter, and we only have about a month left, so... :) > Is there a QA testing write-up on the website? I thought I had seen a link to that effect, but now I can't find it. > http://oss.sgi.com/projects/xfs/102_qa.html -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Feb 22 13:38:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MLcKp20768 for linux-xfs-outgoing; Fri, 22 Feb 2002 13:38:20 -0800 Received: from imf03bis.bellsouth.net (mail203.mail.bellsouth.net [205.152.58.143]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MLcD920746 for ; Fri, 22 Feb 2002 13:38:13 -0800 Received: from taz ([66.156.33.27]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020222203928.PDNC8189.imf03bis.bellsouth.net@taz>; Fri, 22 Feb 2002 15:39:28 -0500 Date: Fri, 22 Feb 2002 15:34:45 -0500 From: Greg Freemyer Subject: re[6]: Current Status ?? To: Eric Sandeen cc: Steve Lord , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020222203928.PDNC8189.imf03bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1MLcE920747 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> The next formal release is slated for this quarter, and we only have >> about a month left, so... :) That sounds very good to me. >> > Is there a QA testing write-up on the website? I thought I had seen a >> link to that effect, but now I can't find it. >> > >> http://oss.sgi.com/projects/xfs/102_qa.html I just looked at that and I have 2 questions. 1) Do you test with IDE drives and/or IDE Raid controllers. I was thinking they might be useful in a low-end solution. Especially now that there are IDE Hardware Raid controllers available for a reasonable price. Some even support hot-swap capabilities. The test server I just ordered has a IDE hardware Raid controller in it. My hope is that it will be relatively fast, and that the Raid controller with a 1 + 0 setup will read data 4 times the speed of a single drive. I know that IDE has problems, but I am trying to setup a low-end Samba server, so I'm hoping that it will work okay. 2) Do you do any testing with Samba? I am going to install Mandrake 8.1 because it already has XFS and Samba with ACL support preconfigured. I know I will still likely want to get the latest versions of both, but it seems smart to start with a working environment. Thanks, Greg >> -Eric >> -- >> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >> sandeen@sgi.com SGI, Inc. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Fri Feb 22 14:33:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MMXtb21837 for linux-xfs-outgoing; Fri, 22 Feb 2002 14:33:55 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MMXU921814 for ; Fri, 22 Feb 2002 14:33:31 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKVQ79>; Fri, 22 Feb 2002 13:35:57 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0BC@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'linux-xfs@oss.sgi.com'" Cc: "'linux-lvm@sistina.com'" Subject: oops umounting full LVM snapshots Date: Fri, 22 Feb 2002 13:35:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have recreated my oops umounting full LVM snapshots of an XFS filesystem. I updated to use a more recent system: xfs CVS tree from Feb 20th LVM 1.0.3 (just released) linux-2.4.11-VFS-lock.patch compiled with kgcc. Scenario: make two snapshots of xfs filesystem. Mount them both ro, nouuid, norecovery. Add files to filesystem until the snapshots are full (invalidated -- any further access should just return an I/O error). Umount the first snapshot, then the second snapshot. I get log entries complaining about the I/O error in each umount, and the second one also oopses. I performed the same sequence of events twice with two snapshots of an ext2 filesystem. No oops, no errors, no complaints in the log. Here are the log messages preceding the oops: <6> Feb 22 14:20:47 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 on /dev/volgr0/lvol1: out of space <6> Feb 22 14:20:47 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 on /dev/volgr0/lvol2: out of space <6> Feb 22 14:21:00 CROND[1106]: (root) CMD (/bin/snapsched) <1> Feb 22 14:21:35 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol1 <1> Feb 22 14:21:35 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol1 <4> Feb 22 14:21:35 kernel: I/O error in filesystem ("lvm(58,1)") meta-data dev 0x3a01 block 0x1400020 <4> Feb 22 14:21:35 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 22 14:21:35 kernel: xfs_force_shutdown(lvm(58,1),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01b495e <4> Feb 22 14:21:35 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,1) <4> Feb 22 14:21:35 kernel: Please umount the filesystem, and rectify the problem(s) <1> Feb 22 14:21:40 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol2 <1> Feb 22 14:21:40 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol2 <4> Feb 22 14:21:40 kernel: I/O error in filesystem ("lvm(58,2)") meta-data dev 0x3a02 block 0x1400020 <4> Feb 22 14:21:40 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 22 14:21:40 kernel: xfs_force_shutdown(lvm(58,2),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01b495e <4> Feb 22 14:21:40 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,2) <4> Feb 22 14:21:40 kernel: Please umount the filesystem, and rectify the problem(s) The oops follows in the log at 14:21:40. I ran it through ksymoops on my build machine using a copy of /proc/ksyms: ksymoops 2.4.0 on i686 2.4.9-2buildsmp. Options used -V (default) -k ksyms (specified) -L (specified) -O (specified) -M (specified) Error (expand_objects): cannot stat(/lib/modules/2.4.17-1snap/kernel/net/appletalk/appletalk.o) for appletalk Error (expand_objects): cannot stat(/lib/modules/2.4.17-1snap/kernel/drivers/net/eepro100.o) for eepro100 Unable to handle kernel NULL pointer dereference at virtual address 00000020 c012ea13 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 00000000 ebx: 00000000 ecx: 00003a02 edx: 00003a02 esi: 00000006 edi: 00000000 ebp: 00000000 esp: c1615e8c ds: 0018 es: 0018 ss: 0018 Process umount (pid: 1118, stackpage=c1615000) Stack: c3e3e460 c3c99800 c3b8b360 00000000 3a020168 00000000 c012eaf8 c3e3e460 00000001 c3756220 c01d2270 00003a02 00000001 c3c99800 c01bc7d7 c3756220 00000000 c3c99800 c01c3e61 c3c99800 00000001 c03485c0 00000000 c3c99800 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 53 20 89 54 24 14 0f b7 54 24 12 66 39 53 0c 75 7b 83 7b >>EIP; c012ea13 <===== Trace; c012eaf8 <__invalidate_buffers+20/7c> Trace; c01d2270 Trace; c01bc7d7 Trace; c01c3e61 Trace; c01d2c9a Trace; c01da79c Trace; c0131eb8 Trace; c014090e <__mntput+1e/3fc> Trace; c013579f Trace; c0140f61 Trace; c01204f5 Trace; c0140f7c Trace; c0106d7b <__up_wakeup+1057/2274> Code; c012ea13 00000000 <_EIP>: Code; c012ea13 <===== 0: 8b 53 20 mov 0x20(%ebx),%edx <===== Code; c012ea16 3: 89 54 24 14 mov %edx,0x14(%esp,1) Code; c012ea1a 7: 0f b7 54 24 12 movzwl 0x12(%esp,1),%edx Code; c012ea1f c: 66 39 53 0c cmp %dx,0xc(%ebx) Code; c012ea23 10: 75 7b jne 8d <_EIP+0x8d> c012eaa0 Code; c012ea25 12: 83 7b 00 00 cmpl $0x0,0x0(%ebx) 2 errors issued. Results may not be reliable. I have also generated an oops with the same build by filling a single snapshot of an xfs file system, umounting it, and doing an lvscan. Again, the same procedure is not a problem with ext2. Here's the log and oops from that sequence. <6> Feb 21 14:35:14 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 on /dev/volgr0/lvol4: out of space <1> Feb 21 14:50:25 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol4 <1> Feb 21 14:50:25 kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/volgr0/lvol4 <4> Feb 21 14:50:25 kernel: I/O error in filesystem ("lvm(58,4)") meta-data dev 0x3a04 block 0x1400020 <4> Feb 21 14:50:25 kernel: ("xlog_iodone") error 5 buf count 1024 <4> Feb 21 14:50:25 kernel: xfs_force_shutdown(lvm(58,4),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01b495e <4> Feb 21 14:50:25 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,4) <4> Feb 21 14:50:25 kernel: Please umount the filesystem, and rectify the problem(s) The oops occured shortly thereafter when I ran lvscan. I ran it through ksymoops on my build machine using a copy of /proc/ksyms: ksymoops 2.4.0 on i686 2.4.9-2buildsmp. Options used -V (default) -k ksyms (specified) -L (specified) -O (specified) -M (specified) Error (expand_objects): cannot stat(/lib/modules/2.4.17-1snap/kernel/net/appletalk/appletalk.o) for appletalk Error (expand_objects): cannot stat(/lib/modules/2.4.17-1snap/kernel/drivers/net/eepro100.o) for eepro100 Unable to handle kernel NULL pointer dereference at virtual address 00000020 c012ea13 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00001600 esi: 00000191 edi: 00000000 ebp: 00000000 esp: c26e9f28 ds: 0018 es: 0018 ss: 0018 Process lvscan (pid: 1409, stackpage=c26e9000) Stack: c3e3e420 c24f62a0 c3e3e43c 00000000 16006350 00000000 c0132225 c3e3e420 00000001 c3e3e420 c0132d75 c3e3e420 c21ce2c0 c1c4dc20 c3ea52a0 c3ccf7e0 c0132dde c3e3e420 00000000 c012e014 c1c4dc20 c21ce2c0 c21ce2c0 00000000 Call Trace: [] [] [] [] [] [] [] Code: 8b 53 20 89 54 24 14 0f b7 54 24 12 66 39 53 0c 75 7b 83 7b >>EIP; c012ea13 <===== Trace; c0132225 Trace; c0132d75 Trace; c0132dde Trace; c012e014 Trace; c012d0ec Trace; c012d137 Trace; c0106d7b <__up_wakeup+1057/2274> Code; c012ea13 00000000 <_EIP>: Code; c012ea13 <===== 0: 8b 53 20 mov 0x20(%ebx),%edx <===== Code; c012ea16 3: 89 54 24 14 mov %edx,0x14(%esp,1) Code; c012ea1a 7: 0f b7 54 24 12 movzwl 0x12(%esp,1),%edx Code; c012ea1f c: 66 39 53 0c cmp %dx,0xc(%ebx) Code; c012ea23 10: 75 7b jne 8d <_EIP+0x8d> c012eaa0 Code; c012ea25 12: 83 7b 00 00 cmpl $0x0,0x0(%ebx) 2 errors issued. Results may not be reliable. I would appreciate any insights. Is anyone else using xfs with lvm and seeing this behavior (or not seeing this behavior)? Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Fri Feb 22 17:03:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1N13hI28064 for linux-xfs-outgoing; Fri, 22 Feb 2002 17:03:43 -0800 Received: from angelina.sl.pt (isengard.sl.pt [212.55.140.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1N13c928041 for ; Fri, 22 Feb 2002 17:03:38 -0800 Received: from localhost (nmr@localhost) by angelina.sl.pt (8.11.3/8.11.3) with ESMTP id g1N070s46846 for ; Sat, 23 Feb 2002 00:07:00 GMT (envelope-from nmr@co.sapo.pt) Date: Sat, 23 Feb 2002 00:07:00 +0000 (WET) From: Nuno Miguel Rodrigues X-X-Sender: To: Subject: mkfs on an unpartitioned disk Message-ID: <20020222235643.R46537-100000@angelina.sl.pt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, The system is Linux 2.4.16-xfs on PC hardware. I've run mkfs on an unpartitioned disk block device (eg, /dev/hda). The case is that I've been experiencing random hangs (uninterruptible sleep state) on I/O system calls. Can anyone antecipate problems due to the usage of the referred block device? TIA, -- Nuno M. Rodrigues Systems Administrator SAPO - Servico de Apontadores Portugueses http://www.sapo.pt/ "Pentiums melt in your PC, not in your hand." -Anon. From owner-linux-xfs@oss.sgi.com Sat Feb 23 09:01:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NH1Xx08549 for linux-xfs-outgoing; Sat, 23 Feb 2002 09:01:33 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NH1R908527 for ; Sat, 23 Feb 2002 09:01:28 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g1NG0dc10483; Sat, 23 Feb 2002 10:00:39 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: More "undefineded references" on CVS-sparc64 From: Alvaro Figueroa To: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 23 Feb 2002 10:00:39 -0600 Message-Id: <1014480039.10454.0.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Again, at the final link, I get drivers/input/inputdrv.o: In function `emulate_raw': drivers/input/inputdrv.o(.text+0xae0): undefined reference to `handle_scancode' drivers/input/inputdrv.o(.text+0xaf0): undefined reference to `handle_scancode' drivers/input/inputdrv.o(.text+0xafc): undefined reference to `handle_scancode' drivers/input/inputdrv.o(.text+0xb28): undefined reference to `handle_scancode' drivers/input/inputdrv.o(.text+0xb78): undefined reference to `handle_scancode' drivers/input/inputdrv.o(.text+0xb8c): more undefined references to `handle_scancode' follow drivers/input/inputdrv.o: In function `keybdev_init': drivers/input/inputdrv.o(.text.init+0x9c): undefined reference to `kbd_ledfunc' drivers/input/inputdrv.o(.text.init+0xac): undefined reference to `kbd_ledfunc' BTW, thanks a lot for the other fix. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Sat Feb 23 09:45:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NHjcq09197 for linux-xfs-outgoing; Sat, 23 Feb 2002 09:45:38 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NHjY909172 for ; Sat, 23 Feb 2002 09:45:34 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1NHjUFH008990 for ; Sat, 23 Feb 2002 09:45:30 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA91714; Sat, 23 Feb 2002 08:44:54 -0800 (PST) Date: Sat, 23 Feb 2002 10:44:53 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Alvaro Figueroa cc: XFS to linux port mailing list Subject: Re: More "undefineded references" on CVS-sparc64 In-Reply-To: <1014480039.10454.0.camel@lucy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Alvaro - As a quick fix, you could turn kdb off to work around these, I'll take a look and see what's missing for sparc so that these are not getting defined. -Eric On 23 Feb 2002, Alvaro Figueroa wrote: > > Again, at the final link, I get > > drivers/input/inputdrv.o: In function `emulate_raw': > drivers/input/inputdrv.o(.text+0xae0): undefined reference to > `handle_scancode' From owner-linux-xfs@oss.sgi.com Sat Feb 23 10:31:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NIVZR09714 for linux-xfs-outgoing; Sat, 23 Feb 2002 10:31:35 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NIVW909692 for ; Sat, 23 Feb 2002 10:31:32 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA26858 for ; Sat, 23 Feb 2002 09:27:05 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA61717; Sat, 23 Feb 2002 09:30:57 -0800 (PST) Date: Sat, 23 Feb 2002 11:30:56 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Alvaro Figueroa cc: XFS to linux port mailing list Subject: Re: More "undefineded references" on CVS-sparc64 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Whoops, I misread "kbd" for "kdb" - kdb might not have anything to do with it, sorry. :) -Eric On Sat, 23 Feb 2002, Eric Sandeen wrote: > Hi Alvaro - > > As a quick fix, you could turn kdb off to work around these, I'll take a > look and see what's missing for sparc so that these are not getting > defined. From owner-linux-xfs@oss.sgi.com Sat Feb 23 10:55:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NItex10063 for linux-xfs-outgoing; Sat, 23 Feb 2002 10:55:40 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NIt7910022 for ; Sat, 23 Feb 2002 10:55:07 -0800 Received: (from root@localhost) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g1NHt3M21707 for linux-xfs@oss.sgi.com.KAV; Sat, 23 Feb 2002 18:55:03 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g1NHt1X21683; Sat, 23 Feb 2002 18:55:01 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g1NHr3a30982; Sat, 23 Feb 2002 18:53:04 +0100 Date: Sat, 23 Feb 2002 18:53:02 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Cc: jra@samba.org Subject: DACLs patch for linux with XFS filesystem (EXPERIMENTAL) Message-ID: <20020223185302.A4576@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_BXVAT5kNtrzKuD" Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 291 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=_BXVAT5kNtrzKuD Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Hi, I want DACLs to be honoured by samba. So my idea is, if we create directory or file in directory which has default ACLs (DACLs), to let system set permissions on them. If somebody wants to test it on another platform, he should fill a function in /lib/sysacls.c for it. Function is: BOOL sys_acl_has_dacl(const char *path); This function takes as parameter parent directory of created object. By now, for other platforms it always returns False, so there is no impact for them at all. Also, if you don't have DACLs on your directories, samba will behave in old way. If it works as you want, I'll add parameter for smb.conf (per share). Oh, I have to find how, first ;) Side effects: The hidden,system,archive mapping will be probably affected. I think, that the only right resolution for this, is to put them in EA, on filesystems which support EA. I mould like Jeremy Allison to look at it, and tell if it is OK. And if it is, I would like to add an option eg. honour dacls = yes/no to smb.conf And to have it in 2.2.4 :) Regards, Olaf Fraczyk --=_BXVAT5kNtrzKuD Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="2.2.3a-dacl.patch" diff -r -c samba-2.2.3a/source/include/proto.h samba-2.2.3a-dacl/source/include/proto.h *** samba-2.2.3a/source/include/proto.h Sun Feb 3 01:46:40 2002 --- samba-2.2.3a-dacl/source/include/proto.h Sat Feb 23 17:27:03 2002 *************** *** 937,942 **** --- 937,943 ---- int sys_acl_delete_def_file(const char *name); int sys_acl_free_acl(SMB_ACL_T the_acl) ; int sys_acl_free_qualifier(void *qual, SMB_ACL_TAG_T tagtype); + BOOL sys_acl_has_dacl(const char *path); /*The following definitions come from lib/system.c */ diff -r -c samba-2.2.3a/source/lib/sysacls.c samba-2.2.3a-dacl/source/lib/sysacls.c *** samba-2.2.3a/source/lib/sysacls.c Sun Feb 3 01:46:42 2002 --- samba-2.2.3a-dacl/source/lib/sysacls.c Sat Feb 23 17:34:20 2002 *************** *** 189,194 **** --- 189,209 ---- return acl_free(qual); } + BOOL sys_acl_has_dacl(const char *path) + { + struct acl *test_acl; + test_acl=acl_get_file(path,ACL_TYPE_DEFAULT); + if(!test_acl) { + return False; + } + if(test_acl->acl_cnt>0) { + acl_free(test_acl); + return True; + } + acl_free(test_acl); + return False; + } + #elif defined(HAVE_TRU64_ACLS) /* * The interface to DEC/Compaq Tru64 UNIX ACLs *************** *** 345,350 **** --- 360,371 ---- return acl_free_qualifier(qual, tagtype); } + BOOL sys_acl_has_dacl(const char *path) + { + errno = ENOSYS; + return False; + } + #elif defined(HAVE_UNIXWARE_ACLS) || defined(HAVE_SOLARIS_ACLS) /* *************** *** 977,982 **** --- 998,1009 ---- return 0; } + BOOL sys_acl_has_dacl(const char *path) + { + errno = ENOSYS; + return False; + } + #elif defined(HAVE_HPUX_ACLS) #include *************** *** 1932,1937 **** --- 1959,1970 ---- return 0; } + BOOL sys_acl_has_dacl(const char *path) + { + errno = ENOSYS; + return False; + } + #elif defined(HAVE_IRIX_ACLS) int sys_acl_get_entry(SMB_ACL_T acl_d, int entry_id, SMB_ACL_ENTRY_T *entry_p) *************** *** 2187,2192 **** --- 2220,2237 ---- return 0; } + BOOL sys_acl_has_dacl(const char *path) + { + errno = ENOSYS; + return False; + } + + BOOL sys_acl_has_dacl(const char *path) + { + errno = ENOSYS; + return False; + } + #elif defined(HAVE_AIX_ACLS) /* Donated by Medha Date, mdate@austin.ibm.com, for IBM */ *************** *** 3206,3209 **** --- 3251,3260 ---- return -1; } + BOOL sys_acl_has_dacl(const char *path) + { + errno = ENOSYS; + return False; + } + #endif /* No ACLs. */ diff -r -c samba-2.2.3a/source/smbd/open.c samba-2.2.3a-dacl/source/smbd/open.c *** samba-2.2.3a/source/smbd/open.c Sun Feb 3 01:46:56 2002 --- samba-2.2.3a-dacl/source/smbd/open.c Sat Feb 23 18:24:48 2002 *************** *** 34,45 **** --- 34,54 ---- int flags, mode_t mode) { int fd; + int saved_errno; + BOOL has_dacl; #ifdef O_NOFOLLOW if (!lp_symlinks(SNUM(conn))) flags |= O_NOFOLLOW; #endif + saved_errno=errno; /* We may get ENOSYS here */ + has_dacl=sys_acl_has_dacl(parent_dirname(fname)); + errno=saved_errno; + if(has_dacl) { + mode=0777; + } + fd = conn->vfs_ops.open(conn,dos_to_unix(fname,False),flags,mode); /* Fix for files ending in '.' */ *************** *** 633,638 **** --- 642,649 ---- files_struct *fsp = NULL; int open_mode=0; uint16 port = 0; + int saved_errno; + BOOL has_dacl; if (conn->printer) { /* printers are handled completely differently. Most *************** *** 925,932 **** * Take care of inherited ACLs on created files. JRA. */ ! if (!file_existed && (conn->vfs_ops.fchmod_acl != NULL)) { ! int saved_errno = errno; /* We might get ENOSYS in the next call.. */ if (conn->vfs_ops.fchmod_acl(fsp, fsp->fd, mode) == -1 && errno == ENOSYS) errno = saved_errno; /* Ignore ENOSYS */ } --- 936,947 ---- * Take care of inherited ACLs on created files. JRA. */ ! saved_errno = errno; /* We might get ENOSYS in the next call.. */ ! has_dacl = sys_acl_has_dacl(parent_dirname(fname)); ! errno=saved_errno; ! ! if (!file_existed && (conn->vfs_ops.fchmod_acl != NULL) && !has_dacl) { ! saved_errno = errno; /* We might get ENOSYS in the next call.. */ if (conn->vfs_ops.fchmod_acl(fsp, fsp->fd, mode) == -1 && errno == ENOSYS) errno = saved_errno; /* Ignore ENOSYS */ } diff -r -c samba-2.2.3a/source/smbd/vfs-wrap.c samba-2.2.3a-dacl/source/smbd/vfs-wrap.c *** samba-2.2.3a/source/smbd/vfs-wrap.c Sun Feb 3 01:46:57 2002 --- samba-2.2.3a-dacl/source/smbd/vfs-wrap.c Sat Feb 23 17:41:35 2002 *************** *** 96,101 **** --- 96,103 ---- int vfswrap_mkdir(connection_struct *conn, char *path, mode_t mode) { int result; + BOOL have_dacl; + int saved_errno; START_PROFILE(syscall_mkdir); *************** *** 104,124 **** smb_panic("NULL pointer passed to vfswrap_mkdir()\n"); } #endif ! ! result = mkdir(path, mode); ! ! if (result == 0) { ! /* ! * We need to do this as the default behavior of POSIX ACLs ! * is to set the mask to be the requested group permission ! * bits, not the group permission bits to be the requested ! * group permission bits. This is not what we want, as it will ! * mess up any inherited ACL bits that were set. JRA. ! */ ! int saved_errno = errno; /* We may get ENOSYS */ ! if (conn->vfs_ops.chmod_acl != NULL) { ! if ((conn->vfs_ops.chmod_acl(conn, path, mode) == -1) && (errno == ENOSYS)) ! errno = saved_errno; } } --- 106,132 ---- smb_panic("NULL pointer passed to vfswrap_mkdir()\n"); } #endif ! saved_errno = errno; /* We may get ENOSYS */ ! have_dacl = sys_acl_has_dacl(parent_dirname(path)); ! errno = saved_errno; ! if(have_dacl) { ! result = mkdir(path,0777); ! } ! else { ! result = mkdir(path, mode); ! if (result == 0) { ! /* ! * We need to do this as the default behavior of POSIX ACLs ! * is to set the mask to be the requested group permission ! * bits, not the group permission bits to be the requested ! * group permission bits. This is not what we want, as it will ! * mess up any inherited ACL bits that were set. JRA. ! */ ! saved_errno = errno; /* We may get ENOSYS */ ! if (conn->vfs_ops.chmod_acl != NULL) { ! if ((conn->vfs_ops.chmod_acl(conn, path, mode) == -1) && (errno == ENOSYS)) ! errno = saved_errno; ! } } } --=_BXVAT5kNtrzKuD-- From owner-linux-xfs@oss.sgi.com Sat Feb 23 11:10:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NJA9x10472 for linux-xfs-outgoing; Sat, 23 Feb 2002 11:10:09 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NJA4910450 for ; Sat, 23 Feb 2002 11:10:06 -0800 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g1NIA1Y22901 for linux-xfs@oss.sgi.com.KAV; Sat, 23 Feb 2002 19:10:01 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g1NIA1X22885; Sat, 23 Feb 2002 19:10:01 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g1NI8Fa31189; Sat, 23 Feb 2002 19:08:15 +0100 Date: Sat, 23 Feb 2002 19:08:15 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Cc: jra@samba.org Subject: Re: DACLs patch for linux with XFS filesystem (EXPERIMENTAL) Message-ID: <20020223190815.C4576@venus.local.navi.pl> References: <20020223185302.A4576@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 In-Reply-To: <20020223185302.A4576@venus.local.navi.pl>; from olaf@cbk.poznan.pl on Sat, Feb 23, 2002 at 18:53:02 +0100 X-Mailer: Balsa 1.2.4 Lines: 7 X-MIME-Autoconverted: from 8bit to quoted-printable by goliath.sylaba.poznan.pl id g1NIA1Y22901 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1NJA7910451 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 2002.02.23 18:53:02 +0100 Olaf Fr±czyk wrote: I forgot to add: This patch is for samba 2.2.3a, of course. Regards, Olaf From owner-linux-xfs@oss.sgi.com Sat Feb 23 13:36:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NLaaF12502 for linux-xfs-outgoing; Sat, 23 Feb 2002 13:36:36 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NLaP912478 for ; Sat, 23 Feb 2002 13:36:25 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05825 for ; Sat, 23 Feb 2002 12:37:52 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA67021; Sat, 23 Feb 2002 14:35:08 -0600 (CST) Received: from sgi.com (SMtZaymprMoRSm3msGZ3NHvuZJWbe8ai@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA01731; Sat, 23 Feb 2002 14:35:07 -0600 (CST) Message-ID: <3C77FD46.5010008@sgi.com> Date: Sat, 23 Feb 2002 14:36:22 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: "Stephenson, Dale" CC: "'linux-xfs@oss.sgi.com'" , "'linux-lvm@sistina.com'" Subject: Re: Oops unmounting snapshot of xfs filesystem References: <2D0AFEFEE711D611923E009027D39F2B02F0AF@cdserv.meridian-data.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephenson, Dale wrote: >Klaus Strebel's suggestion to use 2.91.66 (kgcc) for the kernel did solve >the oops from snapshot umounting, in ordinary circumstances. Thanks! > >However, I still have similar behavior, from umounting an invalid >(filled-up) snapshot. I took three snapshots of a single xfs logical >volume, mounted the snapshots, and ran I-O on the source until the snapshots >were invalidated. I then umounted two of the snapshots. I saw >xfs_force_shutdown messages in syslog for each umount, and the second umount >oopsed. > >Here's the syslog entries: > ><6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 >on /dev/volgr0/lvol1: out of space ><6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 >on /dev/volgr0/lvol2: out of space ><6> Feb 14 15:24:11 kernel: lvm -- giving up to snapshot /dev/volgr0/lvol0 >on /dev/volgr0/lvol3: out of space ><1> Feb 14 15:24:43 kernel: lvm - lvm_map: ll_rw_blk for inactive LV >/dev/volgr0/lvol1 ><1> Feb 14 15:24:43 kernel: lvm - lvm_map: ll_rw_blk for inactive LV >/dev/volgr0/lvol1 ><4> Feb 14 15:24:43 kernel: I/O error in filesystem ("lvm(58,1)") meta-data >dev 0x3a01 block 0xa00020 ><4> Feb 14 15:24:43 kernel: ("xlog_iodone") error 5 buf count 1024 ><4> Feb 14 15:24:43 kernel: xfs_force_shutdown(lvm(58,1),0x2) called from >line 939 of file xfs_log.c. Return address = 0xc01b934e ><4> Feb 14 15:24:43 kernel: Log I/O Error Detected. Shutting down >filesystem: lvm(58,1) ><4> Feb 14 15:24:43 kernel: Please umount the filesystem, and rectify the >problem(s) ><1> Feb 14 15:24:48 kernel: lvm - lvm_map: ll_rw_blk for inactive LV >/dev/volgr0/lvol2 ><1> Feb 14 15:24:48 kernel: lvm - lvm_map: ll_rw_blk for inactive LV >/dev/volgr0/lvol2 ><4> Feb 14 15:24:48 kernel: I/O error in filesystem ("lvm(58,2)") meta-data >dev 0x3a02 block 0xa00020 ><4> Feb 14 15:24:48 kernel: ("xlog_iodone") error 5 buf count 1024 ><4> Feb 14 15:24:48 kernel: xfs_force_shutdown(lvm(58,2),0x2) called from >line 939 of file xfs_log.c. Return address = 0xc01b934e ><4> Feb 14 15:24:48 kernel: Log I/O Error Detected. Shutting down >filesystem: lvm(58,2) ><4> Feb 14 15:24:48 kernel: Please umount the filesystem, and rectify the >problem(s) ><1> Feb 14 15:24:48 kernel: Unable to handle kernel NULL pointer dereference >at virtual address 00000020 >[oops snipped, but output of ksymoops attached to message] > >System details: >Celeron with 512 MB of RAM and WD 45GB harddrives. >128 MB swap, one vg consisting of a one-drive RAID 0. >Kernel 2.4.16 with 12/14/01 xfs CVS. >LVM CVS of 1/21/02 (functionally identical to 1.0.2, I believe). >LVM's linux-2.4.11-VFS-lock.patch. >xfs_fs_freeze() patch posted by Eric Sandeen. >Anselm Kruis' writable snapshot patch. > >Snapshots were mounted ro,nouuid,norecovery. The only action taken to the >snapshots was mounting. > >I hope to try it soon with 2.4.17, as Adrian Head suggested. > >Has anyone else run this case with xfs snapshots? > >Why does umount result in I/O activity to a read-only, norecovery file >system? > >Thanks, >Dale Stephenson >steph@snapserver.com > This is definitely odd, xlog_iodone is the I/O completion function for a log write. What I would suspect is that xfs is not actually seeing the read only state somewhere. I have mounted a regular filesystem with these options and set break points in various spots during unmount which would do writes, none of them trigger. Can you build with kdb, run the same test with a breakpoint in xfs_forced_shutdown, and then when it trips do a backtrace for the unmount process. Thanks Steve > From owner-linux-xfs@oss.sgi.com Sun Feb 24 12:33:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OKXOY04953 for linux-xfs-outgoing; Sun, 24 Feb 2002 12:33:24 -0800 Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OKXG904928 for ; Sun, 24 Feb 2002 12:33:16 -0800 Received: from fwd01.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16f4OY-0006iQ-04; Sun, 24 Feb 2002 20:33:14 +0100 Received: from tower (340024412816-0001@[80.145.124.230]) by fwd01.sul.t-online.com with esmtp id 16f4OJ-11zigSC; Sun, 24 Feb 2002 20:32:59 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Hasch@t-online.de (Juergen Hasch) To: linux-xfs@oss.sgi.com Subject: xfsrestore not restoring Date: Sun, 24 Feb 2002 20:34:41 +0100 X-Mailer: KMail [version 1.3.9] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200202242034.41581.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I try to restore a backup from DAT tape but xfsrestore won't let me get my files back. I know the backup set is working because it is the one I used to report an assertion failure some time ago. All I get now are empty directories, but no files at all. Looking at the output of the "-v trace" option or strace gives no error messages. I am running Suse 7.3 and Kernel 2.4.17-XFS from CVS (date January 13.) The destination at /mnt is in XFS format. Any hints for me where to start looking ? This is the output of xfsrestore: tower:/mnt # xfsrestore -f /dev/st0 /mnt xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: version 3.0 - Running single-threaded xfsrestore: searching media for dump xfsrestore: preparing drive xfsrestore: tape drive /dev/st0 is not ready (0x10000): retrying ... xfsrestore: examining media file 0 =========================== dump selection dialog ============================ the following dump has been found on drive 0 hostname: tower mount point: /local volume: /dev/lfw_a/local session time: Sat Dec 1 20:58:18 2001 level: 0 session label: "Backup Windows" media label: "DAT2" file system id: cf935d4d-f79c-4ed1-8527-76f9e9d25d19 session id: 568e4825-bdba-48eb-8c10-fefc8faf2d8f media id: afcf7ecc-23dd-45ea-af65-578ca530739d restore this dump? 1: skip 2: restore (default) -> 2 this dump selected for restoral --------------------------------- end dialog --------------------------------- xfsrestore: using online session inventory xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 4141 directories and 55768 entries processed xfsrestore: directory post-processing xfsrestore: restore complete: 19 seconds elapsed xfsrestore: Restore Status: SUCCESS From owner-linux-xfs@oss.sgi.com Sun Feb 24 12:43:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OKhXT05170 for linux-xfs-outgoing; Sun, 24 Feb 2002 12:43:33 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OKhP905147 for ; Sun, 24 Feb 2002 12:43:25 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id E4B01401841; Sun, 24 Feb 2002 14:44:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id D4BFAC00EEA; Sun, 24 Feb 2002 14:44:23 -0500 (EST) Date: Sun, 24 Feb 2002 14:44:23 -0500 (EST) From: Mike Burger To: Juergen Hasch Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore not restoring In-Reply-To: <200202242034.41581.hasch@t-online.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What was the actual xfsrestore command line that you used? On Sun, 24 Feb 2002, Juergen Hasch wrote: > Hi, > > I try to restore a backup from DAT tape but xfsrestore won't let me > get my files back. > I know the backup set is working because it is the one I used to > report an assertion failure some time ago. > All I get now are empty directories, but no files at all. Looking > at the output of the "-v trace" option or strace gives no error > messages. > I am running Suse 7.3 and Kernel 2.4.17-XFS from CVS (date January 13.) > The destination at /mnt is in XFS format. > Any hints for me where to start looking ? > > This is the output of xfsrestore: > > tower:/mnt # xfsrestore -f /dev/st0 /mnt > xfsrestore: using scsi tape (drive_scsitape) strategy > xfsrestore: version 3.0 - Running single-threaded > xfsrestore: searching media for dump > xfsrestore: preparing drive > xfsrestore: tape drive /dev/st0 is not ready (0x10000): retrying ... > xfsrestore: examining media file 0 > > =========================== dump selection dialog ============================ > > the following dump has been found on drive 0 > > hostname: tower > mount point: /local > volume: /dev/lfw_a/local > session time: Sat Dec 1 20:58:18 2001 > level: 0 > session label: "Backup Windows" > media label: "DAT2" > file system id: cf935d4d-f79c-4ed1-8527-76f9e9d25d19 > session id: 568e4825-bdba-48eb-8c10-fefc8faf2d8f > media id: afcf7ecc-23dd-45ea-af65-578ca530739d > > restore this dump? > 1: skip > 2: restore (default) > -> 2 > this dump selected for restoral > > --------------------------------- end dialog --------------------------------- > > xfsrestore: using online session inventory > xfsrestore: searching media for directory dump > xfsrestore: reading directories > xfsrestore: 4141 directories and 55768 entries processed > xfsrestore: directory post-processing > xfsrestore: restore complete: 19 seconds elapsed > xfsrestore: Restore Status: SUCCESS > > > From owner-linux-xfs@oss.sgi.com Sun Feb 24 12:51:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OKpGo05530 for linux-xfs-outgoing; Sun, 24 Feb 2002 12:51:16 -0800 Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OKpD905504 for ; Sun, 24 Feb 2002 12:51:13 -0800 Received: from fwd06.sul.t-online.de by mailout04.sul.t-online.com with smtp id 16f4fr-0006KH-03; Sun, 24 Feb 2002 20:51:07 +0100 Received: from tower (340024412816-0001@[80.145.124.230]) by fwd06.sul.t-online.com with esmtp id 16f4ff-10dqlcC; Sun, 24 Feb 2002 20:50:55 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Mike Burger Subject: Re: xfsrestore not restoring Date: Sun, 24 Feb 2002 20:52:36 +0100 X-Mailer: KMail [version 1.3.9] Cc: linux-xfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200202242052.36431.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Mike, Am Sonntag, 24. Februar 2002 20:44 schrieb Mike Burger: > What was the actual xfsrestore command line that you used? It was simply: > > tower:/mnt # xfsrestore -f /dev/st0 /mnt This worked before. I also tried xfsrestore interactively (-i option). All files are marked, but none gets restored... ...Juergen From owner-linux-xfs@oss.sgi.com Sun Feb 24 13:23:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OLNbg06138 for linux-xfs-outgoing; Sun, 24 Feb 2002 13:23:37 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OLNS906116 for ; Sun, 24 Feb 2002 13:23:28 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id VAA523752 for ; Sun, 24 Feb 2002 21:25:03 +0100 (CET) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA02858; Mon, 25 Feb 2002 07:22:05 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id HAA72108; Mon, 25 Feb 2002 07:22:04 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 25 Feb 2002 07:22:04 +1100 From: Ivan Rayner X-X-Sender: ivanr@omen.melbourne.sgi.com To: Juergen Hasch cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore not restoring In-Reply-To: <200202242034.41581.hasch@t-online.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Feb 2002, Juergen Hasch wrote: > Hi, > > I try to restore a backup from DAT tape but xfsrestore won't let me > get my files back. Could you run xfsrestore with -v5 for verbose output? Also, could you try xfsrestore -t to get a table-of-contents? Thanks, Ivan > I know the backup set is working because it is the one I used to > report an assertion failure some time ago. > All I get now are empty directories, but no files at all. Looking > at the output of the "-v trace" option or strace gives no error > messages. > I am running Suse 7.3 and Kernel 2.4.17-XFS from CVS (date January 13.) > The destination at /mnt is in XFS format. > Any hints for me where to start looking ? > > This is the output of xfsrestore: > > tower:/mnt # xfsrestore -f /dev/st0 /mnt > xfsrestore: using scsi tape (drive_scsitape) strategy > xfsrestore: version 3.0 - Running single-threaded > xfsrestore: searching media for dump > xfsrestore: preparing drive > xfsrestore: tape drive /dev/st0 is not ready (0x10000): retrying ... > xfsrestore: examining media file 0 > > =========================== dump selection dialog ============================ > > the following dump has been found on drive 0 > > hostname: tower > mount point: /local > volume: /dev/lfw_a/local > session time: Sat Dec 1 20:58:18 2001 > level: 0 > session label: "Backup Windows" > media label: "DAT2" > file system id: cf935d4d-f79c-4ed1-8527-76f9e9d25d19 > session id: 568e4825-bdba-48eb-8c10-fefc8faf2d8f > media id: afcf7ecc-23dd-45ea-af65-578ca530739d > > restore this dump? > 1: skip > 2: restore (default) > -> 2 > this dump selected for restoral > > --------------------------------- end dialog --------------------------------- > > xfsrestore: using online session inventory > xfsrestore: searching media for directory dump > xfsrestore: reading directories > xfsrestore: 4141 directories and 55768 entries processed > xfsrestore: directory post-processing > xfsrestore: restore complete: 19 seconds elapsed > xfsrestore: Restore Status: SUCCESS > > > -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Feb 24 14:11:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OMBrH06862 for linux-xfs-outgoing; Sun, 24 Feb 2002 14:11:53 -0800 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OMBW906837 for ; Sun, 24 Feb 2002 14:11:32 -0800 Received: from fwd10.sul.t-online.de by mailout03.sul.t-online.com with smtp id 16f5bc-0000DL-01; Sun, 24 Feb 2002 21:50:48 +0100 Received: from tower (340024412816-0001@[80.145.124.230]) by fwd10.sul.t-online.com with esmtp id 16f5bb-2Hef3IC; Sun, 24 Feb 2002 21:50:47 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Ivan Rayner Subject: Re: xfsrestore not restoring Date: Sun, 24 Feb 2002 21:52:29 +0100 X-Mailer: KMail [version 1.3.9] Cc: linux-xfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200202242152.29668.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Ivan, Am Sonntag, 24. Februar 2002 21:22 schrieb Ivan Rayner: > On Sun, 24 Feb 2002, Juergen Hasch wrote: > > Hi, > > > > I try to restore a backup from DAT tape but xfsrestore won't let me > > get my files back. > > Could you run xfsrestore with -v5 for verbose output? This generates a lot of output :-) Below are the first 200 lines, I didn't dare to send more to the list. If you really want the 40MB logfile I can put it somewhere for you to download. I can start looking for myself, I just thought it may be a good idea to ask for some input. > Also, could you try xfsrestore -t to get a table-of-contents? This doesn't show anything. But I can see all files when using the interactive option -i. ...Juergen xfsrestore: RLIMIT_AS org cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_STACK org cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: lowering stack size soft limit from 0xffffffffffffffff to 0x8000000 xfsrestore: RLIMIT_STACK new cur 0x8000000 max 0xffffffffffffffff xfsrestore: RLIMIT_DATA org cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_FSIZE org cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_FSIZE now cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_CPU cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_CPU now cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: INTGENMAX == 2147483647 (0x7fffffff) xfsrestore: UINTGENMAX == 4294967295 (0xffffffff) xfsrestore: OFF64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsrestore: OFFMAX == -1 (0x7fffffff) xfsrestore: SIZEMAX == 4294967295 (0xffffffff) xfsrestore: INOMAX == 4294967295 (0xffffffff) xfsrestore: TIMEMAX == 2147483647 (0x7fffffff) xfsrestore: SIZE64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: INO64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: UINT64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: INT64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsrestore: UINT32MAX == 4294967295 (0xffffffff) xfsrestore: INT32MAX == 2147483647 (0x7fffffff) xfsrestore: INT16MAX == 32767 (0x7fff) xfsrestore: UINT16MAX == 65535 (0xffff) xfsrestore: getpagesize( ) returns 4096 xfsrestore: parent pid is 9009 xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: tty fd: 0; terminal interrupt character: (03) xfsrestore: version 3.0 - Running single-threaded xfsrestore: sizeof( pers_desc_t ) == 328, pgsz == 4096, perssz == 20480 ::::::::::: persistent inventory media file tree at initialization ::::::::::: session inventory unknown ...................... end persistent inventory display ...................... xfsrestore: drive op: init xfsrestore: drive op: sync xfsrestore: Media_create xfsrestore: checking and validating command line dump id/label xfsrestore: searching media for dump xfsrestore: Media_mfile_next: purp==0 pos==0 xfsrestore: drive op: begin read xfsrestore: preparing drive xfsrestore: tape op: opening drive xfsrestore: tape op: get status xfsrestore: tape status = bot onl xfsrestore: tape op: get block size info xfsrestore: max=1048576 cur=1048576 xfsrestore: fixed block size tape drive at /dev/st0 xfsrestore: tape op: get block size info xfsrestore: max=1048576 cur=1048576 xfsrestore: recommended tape media file size set to 0x10000000 bytes xfsrestore: recommended tape media mark separation set to 0x1000000 bytes xfsrestore: determining tape record size: trying 1048576 (0x100000) bytes xfsrestore: setting fixed block size to 1048576 xfsrestore: tape op: closing drive xfsrestore: tape op: opening drive xfsrestore: tape op: set block size 1048576 xfsrestore: tape op: get block size info xfsrestore: max=1048576 cur=1048576 xfsrestore: tape op: get status xfsrestore: tape status = bot onl xfsrestore: tape positioned at BOT: doing redundant rewind xfsrestore: tape op: rewind 0 xfsrestore: tape op: get status xfsrestore: tape status = bot onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op read of 1048576 bytes successful xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: nread == selected blocksize on fixed blocksize drive indicates correct blocksize found xfsrestore: validating media file header xfsrestore: validate_media_file_hdr gh_magic xFSdump0 gh_version 33554432 gh_checksum 510229823 gh_timestamp 1513490748 gh_ipaddr 1337727693881344 gh_hostname tower gh_dumplabel Backup Windows xfsrestore: xlate_global_hdr: pre-xlate gh_magic xFSdump0 gh_version 33554432 gh_checksum 510229823 gh_timestamp 1513490748 gh_ipaddr 1337727693881344 gh_hostname tower gh_dumplabel Backup Windows xfsrestore: xlate_global_hdr: post-xlate gh_magic xFSdump0 gh_version 2 gh_checksum 1065183518 gh_timestamp 1007236698 gh_ipaddr 2831156224 gh_hostname tower gh_dumplabel Backup Windows xfsrestore: xlate_drive_hdr: pre-xlate dh_drivecnt 16777216 dh_driveix 0 dh_strategyid 0 dh_pad1 dh_specific W›ßFŠÎ dh_upper DAT2 xfsrestore: xlate_drive_hdr: post-xlate dh_drivecnt 1 dh_driveix 0 dh_strategyid 0 dh_pad1 dh_specific W›ßFŠÎ dh_upper DAT2 xfsrestore: xlate_media_hdr xfsrestore: xlate_content_hdr xfsrestore: xlate_content_inode_hdr xfsrestore: xlate_startpt xfsrestore: xlate_startpt xfsrestore: xlate_rec_hdr xfsrestore: xlate_rec_hdr: pre-xlate magic 14882784896754603795 version 16777216 blksize 4096 recsize 4096 capability 2010185728 file_offset 0 first_mark_offset 0 rec_used 0 checksum 0 ischecksum 0 xfsrestore: xlate_rec_hdr: post-xlate magic 1393753991812647630 version 1 blksize 1048576 recsize 1048576 capability 53623 file_offset 0 first_mark_offset 0 rec_used 0 checksum 0 ischecksum 0 xfsrestore: media file header valid: media file ix 0 xfsrestore: tape record size set to header's record size = 1048576 xfsrestore: read first record of first media file encountered on media: recsz == 1048576 xfsrestore: examining media file 0 xfsrestore: file 0 in object 1 of stream 0 xfsrestore: file 10 in stream, file 0 of dump 0 on object xfsrestore: dump found: checking From owner-linux-xfs@oss.sgi.com Sun Feb 24 15:16:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ONGDb07666 for linux-xfs-outgoing; Sun, 24 Feb 2002 15:16:13 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ONFq907629 for ; Sun, 24 Feb 2002 15:15:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id OAA00214 for ; Sun, 24 Feb 2002 14:17:19 -0800 (PST) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA03221; Mon, 25 Feb 2002 09:14:32 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA77013; Mon, 25 Feb 2002 09:14:32 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 25 Feb 2002 09:14:32 +1100 From: Ivan Rayner X-X-Sender: ivanr@omen.melbourne.sgi.com To: Juergen Hasch cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore not restoring In-Reply-To: <200202242152.29668.hasch@t-online.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id g1ONFq907630 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Feb 2002, Juergen Hasch wrote: > Hello Ivan, > > Am Sonntag, 24. Februar 2002 21:22 schrieb Ivan Rayner: > > On Sun, 24 Feb 2002, Juergen Hasch wrote: > > > Hi, > > > > > > I try to restore a backup from DAT tape but xfsrestore won't let me > > > get my files back. > > > > Could you run xfsrestore with -v5 for verbose output? > This generates a lot of output :-) > Below are the first 200 lines, I didn't dare to send more to > the list. The last 20 lines or so would also be interesting. Ivan > If you really want the 40MB logfile I can put it somewhere > for you to download. > I can start looking for myself, I just thought it may be a good idea > to ask for some input. > > > Also, could you try xfsrestore -t to get a table-of-contents? > This doesn't show anything. But I can see all files when using > the interactive option -i. > > ...Juergen > > xfsrestore: RLIMIT_AS org cur 0xffffffffffffffff max 0xffffffffffffffff > xfsrestore: RLIMIT_STACK org cur 0xffffffffffffffff max 0xffffffffffffffff > xfsrestore: lowering stack size soft limit from 0xffffffffffffffff to > 0x8000000 > xfsrestore: RLIMIT_STACK new cur 0x8000000 max 0xffffffffffffffff > xfsrestore: RLIMIT_DATA org cur 0xffffffffffffffff max 0xffffffffffffffff > xfsrestore: RLIMIT_FSIZE org cur 0xffffffffffffffff max 0xffffffffffffffff > xfsrestore: RLIMIT_FSIZE now cur 0xffffffffffffffff max 0xffffffffffffffff > xfsrestore: RLIMIT_CPU cur 0xffffffffffffffff max 0xffffffffffffffff > xfsrestore: RLIMIT_CPU now cur 0xffffffffffffffff max 0xffffffffffffffff > xfsrestore: INTGENMAX == 2147483647 (0x7fffffff) > xfsrestore: UINTGENMAX == 4294967295 (0xffffffff) > xfsrestore: OFF64MAX == 9223372036854775807 (0x7fffffffffffffff) > xfsrestore: OFFMAX == -1 (0x7fffffff) > xfsrestore: SIZEMAX == 4294967295 (0xffffffff) > xfsrestore: INOMAX == 4294967295 (0xffffffff) > xfsrestore: TIMEMAX == 2147483647 (0x7fffffff) > xfsrestore: SIZE64MAX == 18446744073709551615 (0xffffffffffffffff) > xfsrestore: INO64MAX == 18446744073709551615 (0xffffffffffffffff) > xfsrestore: UINT64MAX == 18446744073709551615 (0xffffffffffffffff) > xfsrestore: INT64MAX == 9223372036854775807 (0x7fffffffffffffff) > xfsrestore: UINT32MAX == 4294967295 (0xffffffff) > xfsrestore: INT32MAX == 2147483647 (0x7fffffff) > xfsrestore: INT16MAX == 32767 (0x7fff) > xfsrestore: UINT16MAX == 65535 (0xffff) > xfsrestore: getpagesize( ) returns 4096 > xfsrestore: parent pid is 9009 > xfsrestore: using scsi tape (drive_scsitape) strategy > xfsrestore: tty fd: 0; terminal interrupt character: (03) > xfsrestore: version 3.0 - Running single-threaded > xfsrestore: sizeof( pers_desc_t ) == 328, pgsz == 4096, perssz == 20480 > > ::::::::::: persistent inventory media file tree at initialization > ::::::::::: > > session inventory unknown > > ...................... end persistent inventory display > ...................... > > xfsrestore: drive op: init > xfsrestore: drive op: sync > xfsrestore: Media_create > xfsrestore: checking and validating command line dump id/label > xfsrestore: searching media for dump > xfsrestore: Media_mfile_next: purp==0 pos==0 > xfsrestore: drive op: begin read > xfsrestore: preparing drive > xfsrestore: tape op: opening drive > xfsrestore: tape op: get status > xfsrestore: tape status = bot onl > xfsrestore: tape op: get block size info > xfsrestore: max=1048576 cur=1048576 > xfsrestore: fixed block size tape drive at /dev/st0 > xfsrestore: tape op: get block size info > xfsrestore: max=1048576 cur=1048576 > xfsrestore: recommended tape media file size set to 0x10000000 bytes > xfsrestore: recommended tape media mark separation set to 0x1000000 bytes > xfsrestore: determining tape record size: trying 1048576 (0x100000) bytes > xfsrestore: setting fixed block size to 1048576 > xfsrestore: tape op: closing drive > xfsrestore: tape op: opening drive > xfsrestore: tape op: set block size 1048576 > xfsrestore: tape op: get block size info > xfsrestore: max=1048576 cur=1048576 > xfsrestore: tape op: get status > xfsrestore: tape status = bot onl > xfsrestore: tape positioned at BOT: doing redundant rewind > xfsrestore: tape op: rewind 0 > xfsrestore: tape op: get status > xfsrestore: tape status = bot onl > xfsrestore: tape op: reading 1048576 bytes > xfsrestore: tape op read of 1048576 bytes successful > xfsrestore: tape op: get status > xfsrestore: tape status = onl > xfsrestore: nread == selected blocksize on fixed blocksize drive indicates > correct blocksize found > xfsrestore: validating media file header > xfsrestore: validate_media_file_hdr > gh_magic xFSdump0 > gh_version 33554432 > gh_checksum 510229823 > gh_timestamp 1513490748 > gh_ipaddr 1337727693881344 > gh_hostname tower > gh_dumplabel Backup Windows > xfsrestore: xlate_global_hdr: pre-xlate > gh_magic xFSdump0 > gh_version 33554432 > gh_checksum 510229823 > gh_timestamp 1513490748 > gh_ipaddr 1337727693881344 > gh_hostname tower > gh_dumplabel Backup Windows > xfsrestore: xlate_global_hdr: post-xlate > gh_magic xFSdump0 > gh_version 2 > gh_checksum 1065183518 > gh_timestamp 1007236698 > gh_ipaddr 2831156224 > gh_hostname tower > gh_dumplabel Backup Windows > xfsrestore: xlate_drive_hdr: pre-xlate > dh_drivecnt 16777216 > dh_driveix 0 > dh_strategyid 0 > dh_pad1 > dh_specific W›ßFŠÎ > dh_upper DAT2 > xfsrestore: xlate_drive_hdr: post-xlate > dh_drivecnt 1 > dh_driveix 0 > dh_strategyid 0 > dh_pad1 > dh_specific W›ßFŠÎ > dh_upper DAT2 > xfsrestore: xlate_media_hdr > xfsrestore: xlate_content_hdr > xfsrestore: xlate_content_inode_hdr > xfsrestore: xlate_startpt > xfsrestore: xlate_startpt > xfsrestore: xlate_rec_hdr > xfsrestore: xlate_rec_hdr: pre-xlate > magic 14882784896754603795 > version 16777216 > blksize 4096 > recsize 4096 > capability 2010185728 > file_offset 0 > first_mark_offset 0 > rec_used 0 > checksum 0 > ischecksum 0 > xfsrestore: xlate_rec_hdr: post-xlate > magic 1393753991812647630 > version 1 > blksize 1048576 > recsize 1048576 > capability 53623 > file_offset 0 > first_mark_offset 0 > rec_used 0 > checksum 0 > ischecksum 0 > xfsrestore: media file header valid: media file ix 0 > xfsrestore: tape record size set to header's record size = 1048576 > xfsrestore: read first record of first media file encountered on media: recsz > == 1048576 > xfsrestore: examining media file 0 > xfsrestore: file 0 in object 1 of stream 0 > xfsrestore: file 10 in stream, file 0 of dump 0 on object > xfsrestore: dump found: checking > > -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Feb 24 23:37:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1P7bQX21229 for linux-xfs-outgoing; Sun, 24 Feb 2002 23:37:26 -0800 Received: from mail.iinet.net.au (symphony-06.iinet.net.au [203.59.3.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1P7bI921177 for ; Sun, 24 Feb 2002 23:37:19 -0800 Received: (qmail 23085 invoked by uid 666); 25 Feb 2002 06:37:11 -0000 Received: from unknown (HELO compaq) (203.59.111.106) by mail.iinet.net.au with SMTP; 25 Feb 2002 06:37:11 -0000 Message-ID: <000c01c1bdc8$7f8647a0$6a6f3bcb@cole> Reply-To: "Catherine Cole" From: "Catherine Cole" To: Subject: XFS 1.0.2a Installer CD/Image Problem Date: Mon, 25 Feb 2002 14:48:55 +0800 Organization: Peter Cole & Associates Pty Ltd MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have just downloaded RH7.2-SGI-XFS-1.0.2a.iso and burn it to a cd. I boot the cd and went through the installation options. But when it went to install the packages to the hard drive it asked for Red Hat Cd 1, i inserted it, but it would not accept it. The Cd is Red Hat Linux 7.2 Disk 1. What can I do, is there any way to force the installation to use this Cd. From, Jason Cole. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Feb 25 00:21:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1P8L0c31579 for linux-xfs-outgoing; Mon, 25 Feb 2002 00:21:00 -0800 Received: from mel-rto1.wanadoo.fr (smtp-out-1.wanadoo.fr [193.252.19.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1P8Kv931545 for ; Mon, 25 Feb 2002 00:20:57 -0800 Received: from mel-rta4.wanadoo.fr (193.252.19.58) by mel-rto1.wanadoo.fr; 25 Feb 2002 08:20:50 +0100 Received: from mail-web8 (193.252.19.71) by mel-rta4.wanadoo.fr; 25 Feb 2002 08:20:43 +0100 Received: from '193.251.61.154' by www.wanadoo.fr with HTTP; Mon, 25 Feb 2002 08:20:43 +0100 (MET) Message-ID: <3c79e5cb3d272d0e@mel-rta4.wanadoo.fr> (added by mel-rta4.wanadoo.fr) Date: Mon, 25 Feb 2002 08:20:43 +0100 (MET) From: "Jean-Yves LENHOF" To: Cc: Subject: Re : XFS 1.0.2a Installer CD/Image Problem MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1P8Kv931549 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, In order to make the installer recognise the first CD of RedHat 7.2 you needs to have a .disc1-i386 on it. In this file there's a number which needs to be the same that the one in the .disc3-i386 of the SGI disc. Regards, JYL From owner-linux-xfs@oss.sgi.com Mon Feb 25 00:41:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1P8fJJ03548 for linux-xfs-outgoing; Mon, 25 Feb 2002 00:41:19 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1P8fE903510 for ; Mon, 25 Feb 2002 00:41:15 -0800 Received: from lizard.webland.de (www.schweitzer.de [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx03)) with ESMTP id C47CB6535; Mon, 25 Feb 2002 08:41:07 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA17387; Mon, 25 Feb 2002 08:41:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C859657306; Mon, 25 Feb 2002 08:40:52 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2608025835; Mon, 25 Feb 2002 08:40:52 +0100 (CET) Message-ID: <3C79EA84.6A8DF810@ch.sauter-bc.com> Date: Mon, 25 Feb 2002 08:40:52 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Catherine Cole Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.0.2a Installer CD/Image Problem References: <000c01c1bdc8$7f8647a0$6a6f3bcb@cole> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Catherine Cole schrieb: > > Hi, > > I have just downloaded RH7.2-SGI-XFS-1.0.2a.iso and burn it to a cd. I boot the cd and went through the installation options. But when it went to install the packages to the hard drive it asked for Red Hat Cd 1, i inserted it, but it would not accept it. The Cd is Red Hat Linux 7.2 Disk 1. There are several RH 7.2 CDs out there which are modified by vendors like DELL. IIRC the XFS installer does not work with them. -Simon > > What can I do, is there any way to force the installation to use this Cd. > > From, > Jason Cole. > > [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Feb 25 01:51:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1P9pLR18925 for linux-xfs-outgoing; Mon, 25 Feb 2002 01:51:21 -0800 Received: from lifesci.ucsb.edu (root@lifesci.lscf.ucsb.edu [128.111.226.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1P9p7918864 for ; Mon, 25 Feb 2002 01:51:07 -0800 Received: from lifesci.ucsb.edu (sour.lscf.ucsb.edu [128.111.226.35]) by lifesci.ucsb.edu (8.11.4/8.11.4) with ESMTP id g1P8p3K08890; Mon, 25 Feb 2002 00:51:03 -0800 (PST) Message-ID: <3C79FAEF.4020201@lifesci.ucsb.edu> Date: Mon, 25 Feb 2002 00:50:55 -0800 From: Christopher Jones User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: ivanr@sgi.com CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump, xfsrestore segmentation faults References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Passed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ivan, Thank you very much for the reply, and the suggestion. I've been out of town, and couldn't reply earlier, however, I can't reproduce the behavior, which is great. Getting the latest code from CVS worked very well. I wish I knew why there were so many orphaned inodes, but for now, things seem stable so I'll just go with it. Again, thanks the advice. Chris ivanr@sgi.com wrote: > On Fri, 8 Feb 2002, Christopher Jones wrote: > > >>Hi everyone, >> >>I'm experiencing some problems with XFS on a Redhat 7.2 installation >>using the SGI supplied installer, and was hoping that someone might be >>able to provide some advice. >> > > Could you try reproducing the core dump with the latest xfsdump version, > and then send me the core file and xfsdump binary? > > I'll take a look at them next week. > > Thanks, > Ivan > > > >>I've had the system up for 2 months now, but in the last 2 weeks, have >>fould that both xfsdump and xfsrestore will crash the system. I had >>consistently been doing backups just fine, until around January 28th, >>during a dump, the system load peaked up in the 40's as reported by top >>(although cpu and memory were fine). >> >>My typical dump would look like (sans the escapes): >> >>/sbin/xfsdump -F -o -l 9 -L session091 \ >> -M tue-2002-02-08 \ >> -f /dev/nst0 /home >> >>and a restore: >> >>xfsrestore -if /dev/nst0 /home >> >>I have two LVM volumes (home and /scratch01): >> >>Filesystem Size Used Avail Use% Mounted on >>/dev/sda1 1.9G 368M 1.5G 19% / >>/dev/sda6 97M 4.8M 92M 5% /boot >>/dev/sda7 9.8G 4.9G 4.9G 50% /usr >>/dev/sda8 3.9G 243M 3.6G 7% /var >>/dev/sda10 55G 18G 36G 33% /d01 >>none 753M 0 753M 0% /dev/shm >>/dev/vg03/lv03 98G 64G 33G 66% /home >>/dev/vg00/lv00 78G 70G 8.7G 89% /scratch01 >> >>Sytem software: >> >>Linux 2.4.9-13SGI_XFS_1.0.2smp i686 >> >>lvm_1.0.1-rc4 >>xfsdump-1.1.12-0 >>xfsprogs-1.3.16-0 >>xfsprogs-devel-1.3.16-0 >> >>After the first time the dump seg faulted, I did an xfs_repair, which >>found many orphaned inodes, and placed them in lost+found (on the order >>of 200). >> >>Here's the output from one of the failed dumps: >> >>[root@mistral log]# /sbin/xfsdump -F -o -l 0 -L session087 -M >>tue-2002-02-08 -f >>/dev/nst0 / >>/sbin/xfsdump: using scsi tape (drive_scsitape) strategy >>/sbin/xfsdump: version 3.0 - Running single-threaded >>/sbin/xfsdump: level 0 dump of mistral:/ >>/sbin/xfsdump: dump date: Fri Feb 8 03:35:18 2002 >>/sbin/xfsdump: session id: e04d9485-3601-4d5b-86f0-1a946c5f117f >>/sbin/xfsdump: session label: "session087" >>/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) >>/sbin/xfsdump: ino map phase 2: constructing initial dump list >>/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary) >>/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2) >>/sbin/xfsdump: ino map phase 5: skipping (only one dump stream) >>/sbin/xfsdump: ino map construction complete >>/sbin/xfsdump: estimated dump size: 382444928 bytes >>/sbin/xfsdump: preparing drive >>/sbin/xfsdump: WARNING: media may contain data. Overwrite option specified >>Segmentation fault >> >>I've tried the -v trace, but don't get any different output. >> >>Is anyone else having problems with these cominations? >> >>Can anyone suggest a next step in troubleshooting? >> >>Thanks very much in advance, >> >>Chris >> >> >> > -- _________________________________________________________________ christopher jones cjones@lifesci.ucsb.edu (805) 893-5144 marine science institute university of california, santa barbara _________________________________________________________________ From owner-linux-xfs@oss.sgi.com Mon Feb 25 04:29:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PCTc002157 for linux-xfs-outgoing; Mon, 25 Feb 2002 04:29:38 -0800 Received: from ifaedi.insa-lyon.fr (ifaedi.insa-lyon.fr [134.214.104.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PCTC902032 for ; Mon, 25 Feb 2002 04:29:13 -0800 Received: from there (C524.resC.insa-lyon.fr [134.214.170.86]) by ifaedi.insa-lyon.fr (Postfix) with SMTP id A77C7E026 for ; Mon, 25 Feb 2002 12:25:22 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Maciek Borowka To: linux-xfs@oss.sgi.com Subject: bad clientid during mount, xfs_repair doesn't work Date: Mon, 25 Feb 2002 12:30:53 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020225112522.A77C7E026@ifaedi.insa-lyon.fr> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, This problem was already reported to the list, but searching the archive, I haven't found any solution. I am using Gentoo Linux with 2.4.17 kernel on a VIA chipset motherboard (Athlon processor) and a two disc RAID 0 array (Promise chip on the mainboard). I set up a XFS partition, I am able to use it (I am really delighted with the results of the performance tests by bonnie++ :+)), but if I unmount it, I am no longer able to remount it. The log shows : ********************* XFS mounting filesystem ataraid(114,3) Starting XFS recovery on filesystem: ataraid(114,3) (dev: 114/3) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed ********************* When I do xfs_repair /dev/ataraid/disc0/part3 I get : ********************* xfs_repair: warning - cannot set blocksize on block device /dev/ataraid/disc0/part3: Invalid argument Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. ********************* But when I try xfs_repair -L /dev/ataraid/disc0/part3 : ********************* xfs_repair: warning - cannot set blocksize on block device /dev/ataraid/disc0/part3: Invalid argument Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 [snip] - agno = 39 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 [snip] - agno = 4 entry ".." at block 0 offset 32 in directory inode 16777344 references free inode 162 clearing inode number in entry at offset 32... no .. entry for directory 16777344 - agno = 5 [snip] - agno = 39 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... rebuilding directory inode 16777344 - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 16777344, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 16777344 nlinks from 5 to 4 done ********************* And everything works without any problems - until next unmount/mount... I am pretty sure I didn't screw up anything in my kernel configuration, the hard disks are 2 new 40GB Maxtor 6L040J2. I am confused. /Maciek -- If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargill, C++ Journal, Fall 1990 From owner-linux-xfs@oss.sgi.com Mon Feb 25 04:53:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PCrqu08985 for linux-xfs-outgoing; Mon, 25 Feb 2002 04:53:52 -0800 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PCrj908906 for ; Mon, 25 Feb 2002 04:53:45 -0800 Received: from fwd09.sul.t-online.de by mailout02.sul.t-online.com with smtp id 16fJhA-0008Ah-0D; Mon, 25 Feb 2002 12:53:28 +0100 Received: from tower (340024412816-0001@[80.145.95.222]) by fwd09.sul.t-online.com with esmtp id 16fJh5-0VSiwqC; Mon, 25 Feb 2002 12:53:23 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Ivan Rayner Subject: Re: xfsrestore not restoring Date: Mon, 25 Feb 2002 12:55:05 +0100 X-Mailer: KMail [version 1.3.9] Cc: linux-xfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200202251255.05679.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Sonntag, 24. Februar 2002 23:14 schrieb Ivan Rayner: > On Sun, 24 Feb 2002, Juergen Hasch wrote: > > Hello Ivan, > > > > Am Sonntag, 24. Februar 2002 21:22 schrieb Ivan Rayner: > > > On Sun, 24 Feb 2002, Juergen Hasch wrote: > > > > Hi, > > > > > > > > I try to restore a backup from DAT tape but xfsrestore won't let me > > > > get my files back. > > > > > > Could you run xfsrestore with -v5 for verbose output? > > > > This generates a lot of output :-) > > Below are the first 200 lines, I didn't dare to send more to > > the list. > > The last 20 lines or so would also be interesting. These are the last few lines: xfsrestore: mkdir win/mo2/alt/DSP56K/DISTRIB/BERT xfsrestore: mkdir win/mo2/alt/DSP56K/CTEST xfsrestore: mkdir win/mo2/alt/DSP56K/CTEST/T xfsrestore: mkdir win/mo2/alt/DSP56K/CLDTOOLS xfsrestore: mkdir win/mo2/alt/DSP56K/BIN xfsrestore: mkdir win/mo2/alt/DSP56K/BERT xfsrestore: mkdir win/mo2/alt/DSP56K/BERT/1K2 xfsrestore: mkdir dvd xfsrestore: mkdir dvb xfsrestore: mkdir dl xfsrestore: mkdir sun xfsrestore: mkdir sun/forte xfsrestore: getting next media file for non-dir restore xfsrestore: Media_mfile_next: purp==2 pos==3 xfsrestore: drive op: end read xfsrestore: tree finalize xfsrestore: restore complete: 23 seconds elapsed xfsrestore: main.c: 630: mlog_exit called: exit_code: SUCCESS return: OK (success) xfsrestore: Restore Status: SUCCESS I created a new backup with xfsdump and it works. Could it be that xfsrestore doesn't like the fact that I changed my root partition without saving /var/lib/xfsdump ? ...Juergen From owner-linux-xfs@oss.sgi.com Mon Feb 25 09:44:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PHiUj22177 for linux-xfs-outgoing; Mon, 25 Feb 2002 09:44:30 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PHiJ922155 for ; Mon, 25 Feb 2002 09:44:19 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA24011 for ; Mon, 25 Feb 2002 08:39:51 -0800 (PST) mail_from (dstephenson@snapserver.com) Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKVW6P>; Mon, 25 Feb 2002 08:44:55 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0BD@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'Keith Owens'" , "'linux-xfs@oss.sgi.com'" Subject: RE: oops umounting full LVM snapshots Date: Mon, 25 Feb 2002 08:44:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At Keith Owens' suggestion, I've rerun the oops output using the System Map and a more recent ksymoops. This oops was generated by filling two mounted LVM snapshots of an XFS filesystem, and then umounting them both. Both umounts resulted in I/O errors and xfs_force_shutdown calls, and the second umount oopsed. The snapshots are a read only device, and they were mounted ro,nouuid,norecovery. ---oops start--- ksymoops 2.4.3 on i686 2.4.17-1snap. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17-1snap/ (default) -m /boot/System.map-2.4.17-1snap (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c024ed90, System.map says c014bde0. Ignoring ksyms_base entry Unable to handle kernel NULL pointer dereference at virtual address 00000020 c012ea13 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 00000000 ebx: 00000000 ecx: 00003a02 edx: 00003a02 esi: 00000006 edi: 00000000 ebp: 00000000 esp: c1615e8c ds: 0018 es: 0018 ss: 0018 Process umount (pid: 1118, stackpage=c1615000) Stack: c3e3e460 c3c99800 c3b8b360 00000000 3a020168 00000000 c012eaf8 c3e3e460 00000001 c3756220 c01d2270 00003a02 00000001 c3c99800 c01bc7d7 c3756220 00000000 c3c99800 c01c3e61 c3c99800 00000001 c03485c0 00000000 c3c99800 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 53 20 89 54 24 14 0f b7 54 24 12 66 39 53 0c 75 7b 83 7b >>EIP; c012ea12 <===== Trace; c012eaf8 <__invalidate_buffers+20/2c> Trace; c01d2270 Trace; c01bc7d6 Trace; c01c3e60 Trace; c01d2c9a Trace; c01da79c Trace; c0131eb8 Trace; c014090e <__mntput+1e/24> Trace; c013579e Trace; c0140f60 Trace; c01204f4 Trace; c0140f7c Trace; c0106d7a Code; c012ea12 00000000 <_EIP>: Code; c012ea12 <===== 0: 8b 53 20 mov 0x20(%ebx),%edx <===== Code; c012ea14 3: 89 54 24 14 mov %edx,0x14(%esp,1) Code; c012ea18 7: 0f b7 54 24 12 movzwl 0x12(%esp,1),%edx Code; c012ea1e c: 66 39 53 0c cmp %dx,0xc(%ebx) Code; c012ea22 10: 75 7b jne 8d <_EIP+0x8d> c012ea9e Code; c012ea24 12: 83 7b 00 00 cmpl $0x0,0x0(%ebx) 2 warnings issued. Results may not be reliable. ---oops end--- Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Mon Feb 25 10:56:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PIuwr25481 for linux-xfs-outgoing; Mon, 25 Feb 2002 10:56:58 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PIun925459 for ; Mon, 25 Feb 2002 10:56:50 -0800 Received: from sebastian ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g1PCsbW05485 for ; Mon, 25 Feb 2002 12:54:37 GMT Message-ID: <012601c1be25$cc6b8370$4902a8c0@consensys.com> From: "Sebastian Kun" To: Subject: Inode cache uses a lot of memory Date: Mon, 25 Feb 2002 12:56:49 -0500 Organization: Consensys Corp. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've been doing some SPEC SFS97 (http://www.spec.org/osg/sfs97r1/) testing for my company. SFS is a benchmark for evaluating NFS performance, measuring both throughput (NFS ops/sec), and latency (ORT, overall response time). In our case, the benchmark created a 50GB fileset, consisting of 2 million files and 65000 directories. During the test, approximately 10% of the fileset was accessed (read, write, getattr, lookup, etc.). I have some questions about some unusual behaviour I've noticed under XFS. There seems to be a problem with freeing up memory used for the inode cache. During the test run, I periodically checked the amount of free memory using the top command: Mem: 2063220K av, 2050000K used, 13220K free, 0K shrd, 640K buff 138420K cached There's a lot of memory unaccounted for (even taking into account userspace apps). I ran 'cat /proc/slabinfo' which came up with the following entries of interest: xfs_ili 505795 505848 136 18066 18066 xfs_inode 1433589 1501336 468 187667 187667 inode_cache 1188597 1279404 512 182772 182772 (The format of these entries is [name] [active_obj] [total_obj] [obj_size] [active_pages] [total_pages]) As you can see, the xfs_inode cache takes up over 180,000 pages, or around 750MB of memory. The inode_cache takes up another 700MB. Even after doing several gigabytes of I/O to another filesystem (reiserfs), the memory used by the inode caches was still around 1GB. This memory is only freed when the filesystem is unmounted. Question 1: Is this behaviour normal for XFS? Question 2: Is there any way to limit the amount of memory used by the inode cache? System stats are: Running on a dual 1GHz Intel STL2, 2GB RAM, 14-disk 1TB RAID0 array. Kernel version: 2.4.16 SMP, 4GB Highmem, 2GB/2GB split XFS patch: xfs-2.4.16-all-i386 (december 3), compiled into the kernel mkfs.xfs -f -d agsize=1g,sunit=128,swidth=1792 /dev/rze1 mount /dev/rze1 /sfs -o defaults,noatime,sunit=128,swidth=1792,logbufs=8 Thank you, Sebastian Kun Consensys Corp. http://www.consensys.com/ From owner-linux-xfs@oss.sgi.com Mon Feb 25 11:08:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PJ8aW25854 for linux-xfs-outgoing; Mon, 25 Feb 2002 11:08:36 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PJ8O925831 for ; Mon, 25 Feb 2002 11:08:24 -0800 Received: (qmail 3000 invoked by uid 500); 25 Feb 2002 18:07:49 -0000 Subject: Re: Inode cache uses a lot of memory From: Austin Gonyou To: Sebastian Kun Cc: linux-xfs@oss.sgi.com In-Reply-To: <012601c1be25$cc6b8370$4902a8c0@consensys.com> References: <012601c1be25$cc6b8370$4902a8c0@consensys.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Feb 2002 12:07:49 -0600 Message-Id: <1014660469.30034.11.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I also see similar things as well. On the system most everything is fine except for indoe_cache and xfs_inode. They are orders of magnitude larger. I *am* using logbufs=8, I assume that's part of it, or will that just be for fs_cache and files_cache? inode_cache 112628 112752 480 14094 14094 1 : 124 62 xfs_chashlist 4040 4040 16 20 20 1 : 252 126 xfs_ili 868 868 136 31 31 1 : 252 126 xfs_ifork 0 0 56 0 0 1 : 252 126 xfs_efi_item 180 180 260 12 12 1 : 124 62 xfs_efd_item 180 180 260 12 12 1 : 124 62 xfs_buf_item 364 364 148 14 14 1 : 252 126 xfs_dabuf 404 404 16 2 2 1 : 252 126 xfs_da_state 44 44 340 4 4 1 : 124 62 xfs_trans 272 396 320 30 33 1 : 124 62 xfs_inode 112360 112360 468 14045 14045 1 : 124 62 xfs_btree_cur 112 112 140 4 4 1 : 252 126 xfs_bmap_free_item 404 404 16 2 2 1 : 252 126 On Mon, 2002-02-25 at 11:56, Sebastian Kun wrote: > Hi, > > I've been doing some SPEC SFS97 (http://www.spec.org/osg/sfs97r1/) > testing > for my company. SFS is a benchmark > for evaluating NFS performance, measuring both throughput (NFS ops/sec), > and > latency (ORT, overall response time). In our case, the benchmark > created a > 50GB fileset, consisting of 2 million files and 65000 directories. > During > the test, approximately 10% of the fileset was accessed (read, write, > getattr, lookup, etc.). > > I have some questions about some unusual behaviour I've noticed under > XFS. > There seems to be a problem with freeing up memory used for the inode > cache. > During the test run, I periodically checked the amount of free memory > using > the top command: > > Mem: 2063220K av, 2050000K used, 13220K free, 0K shrd, 640K buff > 138420K > cached > > There's a lot of memory unaccounted for (even taking into account > userspace > apps). I ran 'cat /proc/slabinfo' which came up with the following > entries > of interest: > > xfs_ili 505795 505848 136 18066 18066 > xfs_inode 1433589 1501336 468 187667 187667 > inode_cache 1188597 1279404 512 182772 182772 > > (The format of these entries is [name] [active_obj] [total_obj] > [obj_size] > [active_pages] [total_pages]) > > As you can see, the xfs_inode cache takes up over 180,000 pages, or > around > 750MB of memory. The inode_cache takes up another 700MB. Even after > doing > several gigabytes of I/O to another filesystem (reiserfs), the memory > used > by the inode caches was still around 1GB. This memory is only freed > when > the filesystem is unmounted. > > Question 1: Is this behaviour normal for XFS? > Question 2: Is there any way to limit the amount of memory used by the > inode > cache? > > System stats are: > > Running on a dual 1GHz Intel STL2, 2GB RAM, 14-disk 1TB RAID0 array. > Kernel version: 2.4.16 SMP, 4GB Highmem, 2GB/2GB split > XFS patch: xfs-2.4.16-all-i386 (december 3), compiled into the kernel > mkfs.xfs -f -d agsize=1g,sunit=128,swidth=1792 /dev/rze1 > mount /dev/rze1 /sfs -o defaults,noatime,sunit=128,swidth=1792,logbufs=8 > > Thank you, > > Sebastian Kun > Consensys Corp. > http://www.consensys.com/ > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Feb 25 11:30:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PJU8h27147 for linux-xfs-outgoing; Mon, 25 Feb 2002 11:30:08 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PJU0927123 for ; Mon, 25 Feb 2002 11:30:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA02525 for ; Mon, 25 Feb 2002 10:29:59 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA07210; Mon, 25 Feb 2002 12:28:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA37792; Mon, 25 Feb 2002 12:28:43 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: "Stephenson, Dale" Cc: "'Keith Owens'" , "'linux-xfs@oss.sgi.com'" In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F0BD@cdserv.meridian-data.com> References: <2D0AFEFEE711D611923E009027D39F2B02F0BD@cdserv.meridian-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Feb 2002 12:28:43 -0600 Message-Id: <1014661724.14762.77.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Dale - a quick try at reproducing this here was unsuccessful. This is what I did: Create volume group & logical volume: vgcreate volgroup /dev/sda2 /dev/sda3 lvcreate -L 100M -n logicalvol volgroup mkfs and mount it: mkfs.xfs -f /dev/volgroup/logicalvol mount /dev/volgroup/logicalvol /mnt/lvm/logicalvol Make a couple snapshots and mount them: lvcreate --size 16m --snapshot --name snap1 /dev/volgroup/logicalvol lvcreate --size 16m --snapshot --name snap2 /dev/volgroup/logicalvol mount -o nouuid,ro,norecovery /dev/volgroup/snap1 /mnt/lvm/snap1 mount -o nouuid,ro,norecovery /dev/volgroup/snap2 /mnt/lvm/snap2 Overflow the snapshots: cp -vaR /usr/src/linux-2.4.9-13SGI_XFS_1.0.2/ . Unmount the snapshots: umount /mnt/lvm/snap1/ umount /mnt/lvm/snap2/ I got no I/O errors or oopses... This is with a fresh CVS checkout from today. -Eric On Mon, 2002-02-25 at 10:44, Stephenson, Dale wrote: > At Keith Owens' suggestion, I've rerun the oops output using the System Map > and a more recent ksymoops. > This oops was generated by filling two mounted LVM snapshots of an XFS > filesystem, and then umounting them both. Both umounts resulted in I/O > errors and xfs_force_shutdown calls, and the second umount oopsed. The > snapshots are a read only device, and they were mounted > ro,nouuid,norecovery. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Feb 25 13:16:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PLGh729258 for linux-xfs-outgoing; Mon, 25 Feb 2002 13:16:43 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PLGX929233 for ; Mon, 25 Feb 2002 13:16:33 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKVYNM>; Mon, 25 Feb 2002 12:19:07 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0BE@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'Eric Sandeen'" , "Stephenson, Dale" Cc: "'Keith Owens'" , "'linux-xfs@oss.sgi.com'" Subject: RE: oops umounting full LVM snapshots Date: Mon, 25 Feb 2002 12:19:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, I followed your steps and did not get the oops. It seems that the mount options on the original xfs source volume matter. I was able to recreate the oops with the same steps by mounting with quota support. mount -o quota /dev/volgroup/logicalvol /mnt/lvm/logicalvol or mount -o usrquota,grpquota,quota /dev/volgroup/logicalvol /mnt/lvm/logicalvol I also found (accidentally) that after the first snapshot umount goes through xfs_force_shutdown(), an oops can be triggered by umounting the original source volume--not just umounting its other snapshot. It doesn't xfs_force_shutdown the source volume, but oops in the same spot just the same. Dale Stephenson steph@snapserver.com Eric Sandeen wrote: > Hi Dale - a quick try at reproducing this here was unsuccessful. This > is what I did: > > Create volume group & logical volume: > > vgcreate volgroup /dev/sda2 /dev/sda3 > lvcreate -L 100M -n logicalvol volgroup > > mkfs and mount it: > > mkfs.xfs -f /dev/volgroup/logicalvol > mount /dev/volgroup/logicalvol /mnt/lvm/logicalvol > > Make a couple snapshots and mount them: > > lvcreate --size 16m --snapshot --name snap1 /dev/volgroup/logicalvol > lvcreate --size 16m --snapshot --name snap2 /dev/volgroup/logicalvol > mount -o nouuid,ro,norecovery /dev/volgroup/snap1 /mnt/lvm/snap1 > mount -o nouuid,ro,norecovery /dev/volgroup/snap2 /mnt/lvm/snap2 > > Overflow the snapshots: > > cp -vaR /usr/src/linux-2.4.9-13SGI_XFS_1.0.2/ . > > Unmount the snapshots: > > umount /mnt/lvm/snap1/ > umount /mnt/lvm/snap2/ > > I got no I/O errors or oopses... This is with a fresh CVS > checkout from > today. > > -Eric > > > On Mon, 2002-02-25 at 10:44, Stephenson, Dale wrote: > > At Keith Owens' suggestion, I've rerun the oops output > using the System Map > > and a more recent ksymoops. > > This oops was generated by filling two mounted LVM > snapshots of an XFS > > filesystem, and then umounting them both. Both umounts > resulted in I/O > > errors and xfs_force_shutdown calls, and the second umount > oopsed. The > > snapshots are a read only device, and they were mounted > > ro,nouuid,norecovery. > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Mon Feb 25 13:47:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PLlYV30060 for linux-xfs-outgoing; Mon, 25 Feb 2002 13:47:34 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PLlQ930037 for ; Mon, 25 Feb 2002 13:47:26 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1PLlKFH005837 for ; Mon, 25 Feb 2002 13:47:20 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA09878; Mon, 25 Feb 2002 14:46:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA83137; Mon, 25 Feb 2002 14:46:02 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1PKgr922228; Mon, 25 Feb 2002 14:42:53 -0600 Subject: Re: Inode cache uses a lot of memory From: Steve Lord To: Sebastian Kun Cc: linux-xfs@oss.sgi.com In-Reply-To: <012601c1be25$cc6b8370$4902a8c0@consensys.com> References: <012601c1be25$cc6b8370$4902a8c0@consensys.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Feb 2002 14:42:53 -0600 Message-Id: <1014669773.9227.442.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-02-25 at 11:56, Sebastian Kun wrote: > Hi, > > I've been doing some SPEC SFS97 (http://www.spec.org/osg/sfs97r1/) testing > for my company. SFS is a benchmark > for evaluating NFS performance, measuring both throughput (NFS ops/sec), and > latency (ORT, overall response time). In our case, the benchmark created a > 50GB fileset, consisting of 2 million files and 65000 directories. During > the test, approximately 10% of the fileset was accessed (read, write, > getattr, lookup, etc.). > > I have some questions about some unusual behaviour I've noticed under XFS. > There seems to be a problem with freeing up memory used for the inode cache. > During the test run, I periodically checked the amount of free memory using > the top command: > > Mem: 2063220K av, 2050000K used, 13220K free, 0K shrd, 640K buff 138420K > cached > > There's a lot of memory unaccounted for (even taking into account userspace > apps). I ran 'cat /proc/slabinfo' which came up with the following entries > of interest: > > xfs_ili 505795 505848 136 18066 18066 > xfs_inode 1433589 1501336 468 187667 187667 > inode_cache 1188597 1279404 512 182772 182772 > > (The format of these entries is [name] [active_obj] [total_obj] [obj_size] > [active_pages] [total_pages]) > > As you can see, the xfs_inode cache takes up over 180,000 pages, or around > 750MB of memory. The inode_cache takes up another 700MB. Even after doing > several gigabytes of I/O to another filesystem (reiserfs), the memory used > by the inode caches was still around 1GB. This memory is only freed when > the filesystem is unmounted. > > Question 1: Is this behaviour normal for XFS? > Question 2: Is there any way to limit the amount of memory used by the inode > cache? > Well, the xfs inode cache is pretty much controlled via the inode cache, which is only shrunk if you get into the cache pruning code if you run short of memory. I can easily prune out my inode cache without doing unmounts, but my memory size is a lot smaller than yours. I presume you do not see this issue with other filesystems? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Feb 25 14:39:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PMdYE31393 for linux-xfs-outgoing; Mon, 25 Feb 2002 14:39:34 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PMdR931370 for ; Mon, 25 Feb 2002 14:39:28 -0800 Received: (qmail 21038 invoked by uid 500); 25 Feb 2002 21:38:58 -0000 Subject: Re: Inode cache uses a lot of memory From: Austin Gonyou To: Steve Lord Cc: Sebastian Kun , linux-xfs@oss.sgi.com In-Reply-To: <1014669773.9227.442.camel@jen.americas.sgi.com> References: <1014669773.9227.442.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Feb 2002 15:38:58 -0600 Message-Id: <1014673138.18590.4.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To date I don't, but my only other system, not XFS is not the same configuration either. As a matter of fact, I've only got 1 system like the one which is shown here. Of note though, *my* stats are very different from Sebastian's. I'm using XFS-2.4.17 patched with -aarc2. So, my system may be as maxed as I can get in the way that it works. On Mon, 2002-02-25 at 14:42, Steve Lord wrote: ... > Well, the xfs inode cache is pretty much controlled via the inode cache, > which is only shrunk if you get into the cache pruning code if you run > short of memory. > > I can easily prune out my inode cache without doing unmounts, but my > memory size is a lot smaller than yours. > > I presume you do not see this issue with other filesystems? > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Feb 25 15:38:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PNcI000450 for linux-xfs-outgoing; Mon, 25 Feb 2002 15:38:18 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PNcF900422 for ; Mon, 25 Feb 2002 15:38:15 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA663003 for ; Mon, 25 Feb 2002 23:40:09 +0100 (CET) mail_from (roehrich@sgi.com) Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA10850 for ; Mon, 25 Feb 2002 16:36:57 -0600 (CST) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA85411 for ; Mon, 25 Feb 2002 16:36:57 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id QAA82709 for linux-xfs@oss.sgi.com; Mon, 25 Feb 2002 16:36:57 -0600 (CST) Date: Mon, 25 Feb 2002 16:36:57 -0600 (CST) From: Dean Roehrich Message-Id: <200202252236.QAA82709@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - allow dmapi test get_fileattr to take the text form of a filehandle Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Feb 25 14:36:32 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:112694a src/suite1/cmd/get_fileattr.c - 1.5 - allow it to accept the text form of a file handle From owner-linux-xfs@oss.sgi.com Mon Feb 25 17:31:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q1VTQ02889 for linux-xfs-outgoing; Mon, 25 Feb 2002 17:31:29 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q1VM902865 for ; Mon, 25 Feb 2002 17:31:22 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1Q1VFFH017043 for ; Mon, 25 Feb 2002 17:31:16 -0800 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11246; Tue, 26 Feb 2002 11:29:58 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA02888; Tue, 26 Feb 2002 11:29:58 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 26 Feb 2002 11:29:57 +1100 From: Ivan Rayner X-X-Sender: ivanr@omen.melbourne.sgi.com To: Juergen Hasch cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore not restoring In-Reply-To: <200202251255.05679.hasch@t-online.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Feb 2002, Juergen Hasch wrote: > > The last 20 lines or so would also be interesting. > > These are the last few lines: > xfsrestore: mkdir win/mo2/alt/DSP56K/DISTRIB/BERT > xfsrestore: mkdir win/mo2/alt/DSP56K/CTEST > xfsrestore: mkdir win/mo2/alt/DSP56K/CTEST/T > xfsrestore: mkdir win/mo2/alt/DSP56K/CLDTOOLS > xfsrestore: mkdir win/mo2/alt/DSP56K/BIN > xfsrestore: mkdir win/mo2/alt/DSP56K/BERT > xfsrestore: mkdir win/mo2/alt/DSP56K/BERT/1K2 > xfsrestore: mkdir dvd > xfsrestore: mkdir dvb > xfsrestore: mkdir dl > xfsrestore: mkdir sun > xfsrestore: mkdir sun/forte > xfsrestore: getting next media file for non-dir restore > xfsrestore: Media_mfile_next: purp==2 pos==3 > xfsrestore: drive op: end read > xfsrestore: tree finalize > xfsrestore: restore complete: 23 seconds elapsed > xfsrestore: main.c: 630: mlog_exit called: exit_code: SUCCESS return: OK > (success) > xfsrestore: Restore Status: SUCCESS > > I created a new backup with xfsdump and it works. > Could it be that xfsrestore doesn't like the fact that I changed my root > partition without saving /var/lib/xfsdump ? You shouldn't need the contents of /var/lib/xfsdump to do a restore (but it does help). To be honest, I don't know what caused this problem, but we will look into it. It looks like it might have something to do with the inventory. It'd be helpful if you could tell us the exact sequence of events that led to the problem so that we could try reproducing it here. Thanks, Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Mon Feb 25 17:45:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q1j6103153 for linux-xfs-outgoing; Mon, 25 Feb 2002 17:45:06 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q1it903122 for ; Mon, 25 Feb 2002 17:44:55 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA06299 for ; Mon, 25 Feb 2002 16:40:25 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11345; Tue, 26 Feb 2002 11:43:27 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA93010; Tue, 26 Feb 2002 11:43:26 +1100 (AEDT) Date: Tue, 26 Feb 2002 11:43:24 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Cc: Andreas Gruenbacher Message-ID: <20020226114324.J193798@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi folks, The merge to 2.4.18 is complete, the new bits should be arriving in CVS shortly. This merge includes the switch to the new extended attributes and ACL interfaces in the kernel, and hence userspace packages are all updated. Before building new tools, you should do a "make realclean" to get rid of any existing configure'd state. The new packages contain new checks for installed bits, and this forces autoconf/configure to be re-run. Let us know of any issues. Remember - version 2.0.0+ tools must be used with 2.4.18+ kernels, and should not be used with earlier kernels. I will do a merge to the current 2.5.x tree shortly, and same versioning rules will apply there. We expect to remove the ACL utilities from CVS in the future, once we are completely in sync with the ext2/ext3 project (very close), and will mostly likely just keep mirror copies of Andreas' ACL packages in the XFS ftp area on oss.sgi.com. In addition to the new EA/ACL interfaces, xfsprogs tools will now use the BLKGETSIZE64 ioctl (instead of BLKGETSIZE) to retrieve the size of the underlying device (this ioctl was incorrect in kernels before 2.4.18). Also, a few XFS ioctls (related to the old way of doing EAs, & related to unused "biosize" code in XFS) have been deprecated. Finally, there's a few remaining work items if anyone is keen to help with some of these... - glibc should export the new syscalls - strace(1) should be updated to recognise the new syscalls - syscall numbers for remaining architectures - currently, we have assigned numbers on these platforms: i386, ia64, sparc, sparc64, powerpc, and x86_64. Have fun. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 25 18:41:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q2fXW04372 for linux-xfs-outgoing; Mon, 25 Feb 2002 18:41:33 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q2fT904349 for ; Mon, 25 Feb 2002 18:41:29 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA683267 for ; Tue, 26 Feb 2002 02:43:24 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA42141 for linux-xfs@oss.sgi.com; Tue, 26 Feb 2002 12:40:08 +1100 (EST) Date: Tue, 26 Feb 2002 12:40:08 +1100 (EST) From: Nathan Scott Message-Id: <200202260140.MAA42141@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - binfmt_elf.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Feb 25 17:39:42 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112724a linux/fs/binfmt_elf.c - 1.39 - fix problem from 2.4.18-final (fix from 2.4.19-rc1). From owner-linux-xfs@oss.sgi.com Mon Feb 25 19:17:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q3H8p05058 for linux-xfs-outgoing; Mon, 25 Feb 2002 19:17:08 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q3Gv905034 for ; Mon, 25 Feb 2002 19:16:58 -0800 Received: from idcomm.com (IDENT:XFZNhAY7Ks2vYMFnx2G/y47ejlEPPsbp@k56-pip86.idcomm.com [209.60.72.213] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g1Q2PmY09198 for ; Mon, 25 Feb 2002 19:25:49 -0700 Message-ID: <3C7AF03F.8384BF25@idcomm.com> Date: Mon, 25 Feb 2002 19:17:35 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Was: untitled. Now: 2.4.18 update details References: <20020226114324.J193798@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since this release is different than other releases (it requires different tools), I'd like to ask what the recommended update procedure is? Imagine we have multiple booting with older kernels as well, and we want to make both old kernel and this new kernel remain bootable...at least until it has had time to be tested...what would be the way to go about this and not end up with an unmanageable machine should the tool update and new kernel not go in exactly as expected? D. Stimits, stimits@idcomm.com Nathan Scott wrote: > > hi folks, > > The merge to 2.4.18 is complete, the new bits should be arriving > in CVS shortly. This merge includes the switch to the new extended > attributes and ACL interfaces in the kernel, and hence userspace > packages are all updated. > > Before building new tools, you should do a "make realclean" to get > rid of any existing configure'd state. The new packages contain > new checks for installed bits, and this forces autoconf/configure > to be re-run. > > Let us know of any issues. Remember - version 2.0.0+ tools must > be used with 2.4.18+ kernels, and should not be used with earlier > kernels. I will do a merge to the current 2.5.x tree shortly, and > same versioning rules will apply there. > > We expect to remove the ACL utilities from CVS in the future, once > we are completely in sync with the ext2/ext3 project (very close), > and will mostly likely just keep mirror copies of Andreas' ACL > packages in the XFS ftp area on oss.sgi.com. > > In addition to the new EA/ACL interfaces, xfsprogs tools will now > use the BLKGETSIZE64 ioctl (instead of BLKGETSIZE) to retrieve > the size of the underlying device (this ioctl was incorrect in > kernels before 2.4.18). Also, a few XFS ioctls (related to the > old way of doing EAs, & related to unused "biosize" code in XFS) > have been deprecated. > > Finally, there's a few remaining work items if anyone is keen to > help with some of these... > - glibc should export the new syscalls > - strace(1) should be updated to recognise the new syscalls > - syscall numbers for remaining architectures - currently, we have > assigned numbers on these platforms: i386, ia64, sparc, sparc64, > powerpc, and x86_64. > > Have fun. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 25 19:31:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q3V8505329 for linux-xfs-outgoing; Mon, 25 Feb 2002 19:31:08 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q3V0905306 for ; Mon, 25 Feb 2002 19:31:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA01597 for ; Mon, 25 Feb 2002 18:26:32 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11992; Tue, 26 Feb 2002 13:29:42 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA92116; Tue, 26 Feb 2002 13:29:41 +1100 (AEDT) Date: Tue, 26 Feb 2002 13:29:40 +1100 From: Nathan Scott To: "D. Stimits" Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: 2.4.18 update details Message-ID: <20020226132940.K193798@wobbly.melbourne.sgi.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C7AF03F.8384BF25@idcomm.com>; from stimits@idcomm.com on Mon, Feb 25, 2002 at 07:17:35PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Feb 25, 2002 at 07:17:35PM -0700, D. Stimits wrote: > Since this release is different than other releases (it requires > different tools), I'd like to ask what the recommended update procedure > is? Imagine we have multiple booting with older kernels as well, and we > want to make both old kernel and this new kernel remain bootable...at Both the new and the old kernels do remain bootable. Boot the new kernel, install the new tools, and you're done. Or, installing the new tools then booting the new kernel would also work fine. > least until it has had time to be tested...what would be the way to go > about this and not end up with an unmanageable machine should the tool > update and new kernel not go in exactly as expected? I can't see any way you could possibly end up with an unmanageable machine because of this change. [ no, thats not a dare ;) ] Iff you have mismatched kernels and tools, you would be unable to do things like view/change EAs or ACLs, or restore dumps which have EAs (because xfsrestore uses new/old syscalls, depending on its version). There are no on-disk (fs) or on-tape (dump) format changes here, so as long as you align your versions, everything should be fine. And if you don't, the consequences wouldn't be catastrophic. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 25 19:36:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q3ahl05620 for linux-xfs-outgoing; Mon, 25 Feb 2002 19:36:43 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q3ad905598 for ; Mon, 25 Feb 2002 19:36:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1Q2aXhd032622 for ; Mon, 25 Feb 2002 18:36:34 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA19408; Tue, 26 Feb 2002 13:35:16 +1100 (EST) Date: Tue, 26 Feb 2002 13:35:16 +1100 (EST) From: Nathan Scott Message-Id: <200202260235.NAA19408@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - attr userspace docs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Feb 25 18:32:48 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:112727a cmd/attr/doc/ea-conv/Makefile - 1.1 cmd/attr/doc/ea-conv/ea-conv - 1.1 cmd/attr/doc/ea-conv/README - 1.1 - add Andreas' ea-conv script for ext2/ext3 users with backups in the old "aget" format. cmd/attr/VERSION - 1.12 cmd/attr/doc/CHANGES - 1.13 cmd/attr/doc/Makefile - 1.5 cmd/attr/debian/changelog - 1.13 - bump to 2.0.1, we should now be completely sync'd with Andreas for "attr" code. cmd/attr/man/man1/setfattr.1 - 1.4 cmd/attr/man/man1/getfattr.1 - 1.5 - incorporate several updates from Andreas, nothing major. From owner-linux-xfs@oss.sgi.com Mon Feb 25 19:41:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q3fxL05973 for linux-xfs-outgoing; Mon, 25 Feb 2002 19:41:59 -0800 Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q3ft905950 for ; Mon, 25 Feb 2002 19:41:55 -0800 Received: from user-2inia5l.dialup.mindspring.com ([165.121.40.181] helo=waltsathlon.localhost.net) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16fXYw-0001tJ-00 for linux-xfs@oss.sgi.com; Mon, 25 Feb 2002 21:41:54 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id E479C817A97; Mon, 25 Feb 2002 18:41:12 -0800 (PST) Message-ID: <3C7AF5C8.7090900@mindspring.com> Date: Mon, 25 Feb 2002 18:41:12 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - binfmt_elf.c References: <200202260140.MAA42141@snort.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks. You answered my next question :) -Walt Nathan Scott wrote: > Date: Mon Feb 25 17:39:42 PST 2002 > Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:112724a > linux/fs/binfmt_elf.c - 1.39 > - fix problem from 2.4.18-final (fix from 2.4.19-rc1). > > > From owner-linux-xfs@oss.sgi.com Mon Feb 25 21:09:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q59Dt07802 for linux-xfs-outgoing; Mon, 25 Feb 2002 21:09:13 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q597907780 for ; Mon, 25 Feb 2002 21:09:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA08801 for ; Mon, 25 Feb 2002 20:04:37 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA19933 for linux-xfs@oss.sgi.com; Tue, 26 Feb 2002 15:07:44 +1100 (EST) Date: Tue, 26 Feb 2002 15:07:44 +1100 (EST) From: Nathan Scott Message-Id: <200202260407.PAA19933@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 2.5 merge, ia64 fixup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The 2.5 merge is also done now. There was a minor stuff up with the IA64 syscall numbering - despite the patch I sent to the maintainer (which was accepted too), another syscall has slipped in ahead of the xattr ones. With any luck that wont happen again but there's not much I can do about it.. cheers. Date: Mon Feb 25 19:26:55 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:112729a cmd/attr/libattr/syscalls.c - 1.5 - slide ia64 xattr syscalls down one slot, tkill has appeared in 2.5/IA64 where we were supposed to be (according to the maintainer anyway). Modid: 2.4.x-xfs:slinx:112729b linux/arch/ia64/kernel/entry.S - 1.19 linux/include/asm-ia64/unistd.h - 1.15 - slide ia64 xattr syscalls down one slot, tkill has appeared in 2.5/IA64 where we were supposed to be (according to the maintainer anyway). Date: Mon Feb 25 20:01:43 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:112731a cmd/attr/doc/CHANGES - 1.14 - fix IA64 syscall numbering. From owner-linux-xfs@oss.sgi.com Mon Feb 25 23:05:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q75ea03473 for linux-xfs-outgoing; Mon, 25 Feb 2002 23:05:40 -0800 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q75X903426 for ; Mon, 25 Feb 2002 23:05:34 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g1Q65RXt023004 for ; Tue, 26 Feb 2002 17:05:27 +1100 (EST) Received: from jdc.local (ppp106.dyn134.pacific.net.au [210.23.134.106] (may be forged)) by wisma.pacific.net.au with ESMTP id RAA04514 for ; Tue, 26 Feb 2002 17:05:26 +1100 (EST) Received: from jdc.local (LOCALHOST [127.0.0.1]) by jdc.local (8.12.1/8.12.1/Debian -5) with ESMTP id g1Q65Onr002781 for ; Tue, 26 Feb 2002 17:05:24 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g1Q65NgQ002773; Tue, 26 Feb 2002 17:05:23 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15483.9635.101270.256294@jdc.local> Date: Tue, 26 Feb 2002 17:05:23 +1100 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details In-Reply-To: <20020226132940.K193798@wobbly.melbourne.sgi.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> X-Mailer: VM 7.01 under Emacs 20.7.2 Reply-To: jasonw@ariel.ucs.unimelb.edu.au Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am I correct in assuming that one can simply build the Debian ACL packages and they will cleanly replace the previous version, which in my case is already installed? I think I will wait a few weeks and observe the mailing list to find out whether any serious problems are reported with 2.4.18-xfs. If not, it will be time to upgrade. From owner-linux-xfs@oss.sgi.com Mon Feb 25 23:21:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q7LZk03895 for linux-xfs-outgoing; Mon, 25 Feb 2002 23:21:35 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q7LU903872 for ; Mon, 25 Feb 2002 23:21:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id WAA00986 for ; Mon, 25 Feb 2002 22:22:59 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13236; Tue, 26 Feb 2002 17:20:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA94117; Tue, 26 Feb 2002 17:20:11 +1100 (AEDT) Date: Tue, 26 Feb 2002 17:20:10 +1100 From: Nathan Scott To: Jason White Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details Message-ID: <20020226172010.M193798@wobbly.melbourne.sgi.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> <15483.9635.101270.256294@jdc.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15483.9635.101270.256294@jdc.local>; from jasonw@ariel.ucs.unimelb.edu.au on Tue, Feb 26, 2002 at 05:05:23PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 26, 2002 at 05:05:23PM +1100, Jason White wrote: > Am I correct in assuming that one can simply build the Debian ACL > packages and they will cleanly replace the previous version, which in > my case is already installed? There are no Debian ACL packages at the moment. I'll have to discuss this with the people involved first to see what comes of it. For now, you will have to build ACL from source. The rest of our userspace packages are all still Debian-ized. > I think I will wait a few weeks and observe the mailing list to find > out whether any serious problems are reported with 2.4.18-xfs. If not, > it will be time to upgrade. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 26 00:04:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1Q848H05015 for linux-xfs-outgoing; Tue, 26 Feb 2002 00:04:08 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1Q844904993 for ; Tue, 26 Feb 2002 00:04:04 -0800 Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) 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 XAA04881 for ; Mon, 25 Feb 2002 23:04:03 -0800 (PST) mail_from (rhowe@wiss.co.uk) Received: from os046.sta.man.ac.uk ([130.88.188.46] helo=xiao ident=mail) by curlew.cs.man.ac.uk with esmtp (Exim 2.05 #6) id 16fbWI-0000oG-00 for linux-xfs@oss.sgi.com; Tue, 26 Feb 2002 06:55:26 +0000 Received: from rhowe by xiao with local (Exim 3.34 #1 (Debian)) id 16fbWO-0002Fg-00 for ; Tue, 26 Feb 2002 06:55:32 +0000 Date: Tue, 26 Feb 2002 06:55:32 +0000 To: linux-xfs@oss.sgi.com Subject: Detection of empty files after filesystem recover Message-ID: <20020226065532.GA8629@xiao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline From: Russell Howe Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Apologies if this is an FAQ or documented all over the place... I have several files on my XFS partition which appear fine to ls, however stat reports 0 blocks allocated and du reports a size of 0. Is this just the result of the metadata being flushed to disk and the system crashing before the data made could follow it? (I've had problems lately with sporadic lockups, usually during IO operations, although only when X is running) I assume this is the FAQ "Why do I see binary NULLS in some files after recovery when I unplugged the power?" except that there aren't any NULLs in the file, just no blocks attributed to the file. So is it OK if I delete these files, since they reference no blocks, just an inode, right? -- Russell Howe rhowe@wiss.co.uk From owner-linux-xfs@oss.sgi.com Tue Feb 26 02:55:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QAtC011243 for linux-xfs-outgoing; Tue, 26 Feb 2002 02:55:12 -0800 Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QAt8911220 for ; Tue, 26 Feb 2002 02:55:08 -0800 Received: from pippin (pippin [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id g1Q9rZ314066 for ; Tue, 26 Feb 2002 10:53:36 +0100 Message-Id: <200202260953.g1Q9rZ314066@mail.loewe-komp.de> From: Peter =?ISO-8859-15?Q?W=E4chtler?= Subject: OFF-TOPIC: rqsall for Linux To: linux-xfs@oss.sgi.com Date: Tue, 26 Feb 2002 10:53:38 +0100 Lines: 20 Organization: LOEWE. Opta GmbH User-Agent: KNode/0.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, I know it's off topic. Anyway: Is there a way to ask SGI if they would provide/help in implementing something similar as "Quickstart" (rqsall) for Linux? With such a system the binaries are pre-relocated against ELF shared libraries improving startup time significant. Any hint of those nice SGI employees lurking here? ;-) Thanx Until now, I did not get the prelinking solution to work for me :-( http://sources.redhat.com/ml/binutils/2001-07/msg00057.html http://speakeasy.rpmfind.net/linux/RPM/ASP/i386/7.2/asplinux/contribs/RPMS/prelink-0.1.3-6.i386.html From owner-linux-xfs@oss.sgi.com Tue Feb 26 04:21:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QCLw013581 for linux-xfs-outgoing; Tue, 26 Feb 2002 04:21:58 -0800 Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QCLS913559 for ; Tue, 26 Feb 2002 04:21:29 -0800 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 16fffd-0000Nb-00; Tue, 26 Feb 2002 12:21:21 +0100 Message-ID: <3C7B6FDE.4090308@st-peter.stw.uni-erlangen.de> Date: Tue, 26 Feb 2002 12:22:06 +0100 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: linux-2.5.5-xfs-dj1 troubles (raid0_make_request bug) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16fffd-0000Nb-00*cdoHTTZfJsA* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi i'd like to ask you to CC me because i'm not subscribed to the lists i'm having some interesting troubles i have lvm over soft RAID-0 with LV's formated with XFS and JFS i can work with the JFS LV's, but i can not with the XFS one's, i can not mount them ( no troubles with XFS normal partitions) so i'd like to ask is this problem with XFS or with raid or lvm and is there a way to fix it thanks for your help here is what i found in dmesg ##################################################################################### id0: zone 2 raid0: checking ide/host2/bus0/target0/lun0/part8 ... contained as device 0 (2859456) is smallest!. raid0: checking ide/host3/bus0/target0/lun0/part10 ... nope. raid0: checking ide/host3/bus0/target1/lun0/part6 ... nope. raid0: zone->nb_dev: 1, size: 249024 raid0: current zone offset: 2859456 raid0: done. raid0 : md_size is 8064256 blocks. raid0 : conf->smallest->size is 32128 blocks. raid0 : nb_zone is 252. raid0 : Allocating 2016 bytes for hash. md: updating md0 RAID superblock on device md: ide/host3/bus0/target1/lun0/part6 [events: 000002f3]<6>(write) ide/host3/bus0/target1/lun0/part6's sb offset: 2610432 md: ide/host3/bus0/target0/lun0/part10 [events: 000002f3]<6>(write) ide/host3/bus0/target0/lun0/part10's sb offset: 2594368 md: ide/host2/bus0/target0/lun0/part8 [events: 000002f3]<6>(write) ide/host2/bus0/target0/lun0/part8's sb offset: 2859456 md: considering ide/host3/bus0/target1/lun0/part5 ... md: adding ide/host3/bus0/target1/lun0/part5 ... md: adding ide/host3/bus0/target0/lun0/part8 ... md: adding ide/host2/bus0/target0/lun0/part7 ... md: created md2 md: bind md: bind md: bind md: running: md: ide/host3/bus0/target1/lun0/part5's event counter: 0000031a md: ide/host3/bus0/target0/lun0/part8's event counter: 0000031a md: ide/host2/bus0/target0/lun0/part7's event counter: 0000031a md2: max total readahead window set to 744k md2: 3 data-disks, max readahead per data-disk: 248k raid0: looking at ide/host2/bus0/target0/lun0/part7 raid0: comparing ide/host2/bus0/target0/lun0/part7(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at ide/host3/bus0/target0/lun0/part8 raid0: comparing ide/host3/bus0/target0/lun0/part8(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: EQUAL raid0: looking at ide/host3/bus0/target1/lun0/part5 raid0: comparing ide/host3/bus0/target1/lun0/part5(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: EQUAL raid0: FINAL 1 zones raid0: zone 0 raid0: checking ide/host2/bus0/target0/lun0/part7 ... contained as device 0 (4096448) is smallest!. raid0: checking ide/host3/bus0/target0/lun0/part8 ... contained as device 1 raid0: checking ide/host3/bus0/target1/lun0/part5 ... contained as device 2 raid0: zone->nb_dev: 3, size: 12289344 raid0: current zone offset: 4096448 raid0: done. raid0 : md_size is 12289344 blocks. raid0 : conf->smallest->size is 12289344 blocks. raid0 : nb_zone is 1. raid0 : Allocating 8 bytes for hash. md: updating md2 RAID superblock on device md: ide/host3/bus0/target1/lun0/part5 [events: 0000031b]<6>(write) ide/host3/bus0/target1/lun0/part5's sb offset: 4096448 md: ide/host3/bus0/target0/lun0/part8 [events: 0000031b]<6>(write) ide/host3/bus0/target0/lun0/part8's sb offset: 4096448 md: ide/host2/bus0/target0/lun0/part7 [events: 0000031b]<6>(write) ide/host2/bus0/target0/lun0/part7's sb offset: 4096448 md: considering ide/host3/bus0/target0/lun0/part12 ... md: adding ide/host3/bus0/target0/lun0/part12 ... md: adding ide/host3/bus0/target0/lun0/part6 ... md: adding ide/host3/bus0/target0/lun0/part5 ... md: adding ide/host3/bus0/target0/lun0/part1 ... md: created md6 md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part5 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part1. True protection against single-disk failure might be compromised. md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part6 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part5. True protection against single-disk failure might be compromised. md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part12 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part6. True protection against single-disk failure might be compromised. md: bind md: running: md: ide/host3/bus0/target0/lun0/part12's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part6's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part5's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part1's event counter: 00000391 md6: max total readahead window set to 124k md6: 1 data-disks, max readahead per data-disk: 124k md: updating md6 RAID superblock on device md: ide/host3/bus0/target0/lun0/part12 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part12's sb offset: 9759360 md: ide/host3/bus0/target0/lun0/part6 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part6's sb offset: 513984 md: ide/host3/bus0/target0/lun0/part5 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part5's sb offset: 2088320 md: ide/host3/bus0/target0/lun0/part1 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part1's sb offset: 2048192 md: considering ide/host2/bus0/target0/lun0/part11 ... md: adding ide/host2/bus0/target0/lun0/part11 ... md: adding ide/host2/bus0/target0/lun0/part6 ... md: created md7 md: bind md7: WARNING: ide/host2/bus0/target0/lun0/part11 appears to be on the same physical disk as ide/host2/bus0/target0/lun0/part6. True protection against single-disk failure might be compromised. md: bind md: running: md: ide/host2/bus0/target0/lun0/part11's event counter: 000003bf md: ide/host2/bus0/target0/lun0/part6's event counter: 000003bf md7: max total readahead window set to 124k md7: 1 data-disks, max readahead per data-disk: 124k md: updating md7 RAID superblock on device md: ide/host2/bus0/target0/lun0/part11 [events: 000003c0]<6>(write) ide/host2/bus0/target0/lun0/part11's sb offset: 10514432 md: ide/host2/bus0/target0/lun0/part6 [events: 000003c0]<6>(write) ide/host2/bus0/target0/lun0/part6's sb offset: 3421696 md: ... autorun DONE. LVM version 1.0.1-rc4(ish)(03/10/2001) IEEE 802.2 LLC for Linux 2.1 (c) 1996 Tim Alpaerts NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 131072 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. found reiserfs format "3.6" with standard journal Reiserfs journal params: device 22:4b, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 reiserfs: checking transaction log (ide3(34,75)) for (ide3(34,75)) Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 256k freed Real Time Clock Driver v1.10e loop: loaded (max 32 devices) mice: PS/2 mouse device common for all mice cdrom: open failed. VFS: Disk change detected on device ide1(22,0) Adding Swap: 473876k swap-space (priority 1) Adding Swap: 457812k swap-space (priority 1) Adding Swap: 473876k swap-space (priority 1) XFS mounting filesystem lvm(58,2) raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323317 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323445 64 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x601f7d ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8324829 29 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x602565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,3) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: lvm(58,3) (dev: 58/3) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,1) raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610115 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610243 64 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa0218b ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23611101 29 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa02565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,2) raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323317 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323445 64 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x601f7d ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8324829 29 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x602565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,3) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: lvm(58,3) (dev: 58/3) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,1) raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610115 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610243 64 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa0218b ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23611101 29 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa02565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed From owner-linux-xfs@oss.sgi.com Tue Feb 26 07:10:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QFAAK22378 for linux-xfs-outgoing; Tue, 26 Feb 2002 07:10:10 -0800 Received: from fruit.eu.org (qmailr@34dyn21.com21.casema.net [212.64.15.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QFA5922352 for ; Tue, 26 Feb 2002 07:10:06 -0800 Received: (qmail 11958 invoked by uid 500); 26 Feb 2002 14:10:03 -0000 Date: Tue, 26 Feb 2002 15:10:03 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: your mail Message-ID: <20020226151002.A22191@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020226114324.J193798@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: <20020226114324.J193798@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Tue, Feb 26, 2002 at 11:43:24AM +1100 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 2002-02-26 11:43:24+1100, Nathan Scott wrote: > hi folks, > > The merge to 2.4.18 is complete, the new bits should be arriving > in CVS shortly. This merge includes the switch to the new extended > attributes and ACL interfaces in the kernel, and hence userspace > packages are all updated. There has been some confusion surrounding 2.4.18. It appears that the tarball on kernel.org is really -rc3 and that the -rc4 patches are missing. Is the XFS CVS tree based on rc3 or rc4? Regards, -- Wessel Dankers We're on Token Ring, and it looks like the token got loose. From owner-linux-xfs@oss.sgi.com Tue Feb 26 07:17:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QFHTK22646 for linux-xfs-outgoing; Tue, 26 Feb 2002 07:17:29 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QFHO922624 for ; Tue, 26 Feb 2002 07:17:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1QEHJhd018812 for ; Tue, 26 Feb 2002 06:17:19 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA16684; Tue, 26 Feb 2002 08:16:03 -0600 (CST) Received: from sgi.com (cRCEu8wI2S+oKjkEj++2wIxSNeLIZXyY@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA41044; Tue, 26 Feb 2002 08:16:03 -0600 (CST) Message-ID: <3C7B98FA.8060504@sgi.com> Date: Tue, 26 Feb 2002 08:17:30 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Wessel Dankers CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <20020226151002.A22191@fruit.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Wessel Dankers wrote: >On 2002-02-26 11:43:24+1100, Nathan Scott wrote: > >>hi folks, >> >>The merge to 2.4.18 is complete, the new bits should be arriving >>in CVS shortly. This merge includes the switch to the new extended >>attributes and ACL interfaces in the kernel, and hence userspace >>packages are all updated. >> > >There has been some confusion surrounding 2.4.18. It appears that the >tarball on kernel.org is really -rc3 and that the -rc4 patches are missing. >Is the XFS CVS tree based on rc3 or rc4? > >Regards, > >-- >Wessel Dankers > >We're on Token Ring, and it looks like the token got loose. > If I read it correctly, rc4 - i.e. we have the missing patch. Steve From owner-linux-xfs@oss.sgi.com Tue Feb 26 07:59:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QFxYR23876 for linux-xfs-outgoing; Tue, 26 Feb 2002 07:59:34 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QFxO923847 for ; Tue, 26 Feb 2002 07:59:29 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA715089 for ; Tue, 26 Feb 2002 16:01:28 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA32998; Tue, 26 Feb 2002 06:58:49 -0800 (PST) Date: Tue, 26 Feb 2002 08:58:48 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Nathan Scott cc: , Andreas Gruenbacher Subject: Re: 2.4.18 update In-Reply-To: <20020226114324.J193798@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk New userspace packages are now on OSS (tarballs, SRPMS, and i386 RPMS). -Eric On Tue, 26 Feb 2002, Nathan Scott wrote: > hi folks, > > The merge to 2.4.18 is complete, the new bits should be arriving > in CVS shortly. This merge includes the switch to the new extended > attributes and ACL interfaces in the kernel, and hence userspace > packages are all updated. > From owner-linux-xfs@oss.sgi.com Tue Feb 26 08:49:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QGnWv25568 for linux-xfs-outgoing; Tue, 26 Feb 2002 08:49:32 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QGnL925539 for ; Tue, 26 Feb 2002 08:49:21 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA07397 for ; Tue, 26 Feb 2002 07:49:17 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA17634; Tue, 26 Feb 2002 09:48:00 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA25316; Tue, 26 Feb 2002 09:47:59 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1QFigm09990; Tue, 26 Feb 2002 09:44:42 -0600 Subject: Re: linux-2.5.5-xfs-dj1 troubles (raid0_make_request bug) From: Steve Lord To: svetljo Cc: linux-xfs@oss.sgi.com, Linux Kernel , Jens Axboe In-Reply-To: <3C7B6FDE.4090308@st-peter.stw.uni-erlangen.de> References: <3C7B6FDE.4090308@st-peter.stw.uni-erlangen.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 09:44:42 -0600 Message-Id: <1014738282.5993.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 05:22, svetljo wrote: > Hi > i'd like to ask you to CC me because i'm not subscribed to the lists > > i'm having some interesting troubles > i have lvm over soft RAID-0 with LV's formated with XFS and JFS > i can work with the JFS LV's, > but i can not with the XFS one's, i can not mount them ( no troubles > with XFS normal partitions) > > so > i'd like to ask is this problem with XFS or with raid or lvm > and is there a way to fix it > > thanks for your help > > here is what i found in dmesg > > > XFS mounting filesystem lvm(58,2) > raid0_make_request bug: can't convert block across chunks or bigger than > 16k 8323317 64 > raid0_make_request bug: can't convert block across chunks or bigger than > 16k 8323445 64 > I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block > 0x601f7d > ("xlog_bread") error 5 buf count 131072 > raid0_make_request bug: can't convert block across chunks or bigger than > 16k 8324829 29 > I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block > 0x602565 > ("xlog_bread") error 5 buf count 30208 XFS is sending a 64K request down to the driver, and raid0 is bouncing it as too large. Jens, I thought you said requests which were too large for underlying layers would get chopped up? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 26 09:39:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QHd6N28833 for linux-xfs-outgoing; Tue, 26 Feb 2002 09:39:06 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QHcx928810 for ; Tue, 26 Feb 2002 09:38:59 -0800 Received: from sebastian ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g1QBaUW09228; Tue, 26 Feb 2002 11:36:30 GMT Message-ID: <016a01c1bee4$1192aa50$4902a8c0@consensys.com> From: "Sebastian Kun" To: "Steve Lord" Cc: References: <012601c1be25$cc6b8370$4902a8c0@consensys.com> <1014669773.9227.442.camel@jen.americas.sgi.com> Subject: Re: Inode cache uses a lot of memory Date: Tue, 26 Feb 2002 11:38:49 -0500 Organization: Consensys Corp. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Reiserfs behaves a bit differently. After running the same test: inode_cache 1190503 1883987 512 269141 269141 1 : 124 62 The inode_cache uses around 1GB of memory. This is a bit more than XFS, which used only 750MB, but then XFS also has the xfs_inode cache, which uses another 700MB. Also, after doing a few gigs of I/O to another filesystem, the memory was freed, and the inode cache shrunk to around 80MB: inode_cache 27043 135821 512 19403 19403 1 : 124 62 XFS before: xfs_ili 505795 505848 136 18066 18066 1 : 252 126 xfs_inode 1433589 1501336 468 187667 187667 1 : 124 62 inode_cache 1188597 1279404 512 182772 182772 1 : 124 62 XFS after: xfs_ili 114037 476924 136 17033 17033 1 : 252 126 xfs_inode 269159 753952 468 94244 94244 1 : 124 62 inode_cache 239429 577038 512 82434 82434 1 : 124 62 I haven't tried it on ext2 or anything else. Sebastian ----- Original Message ----- From: "Steve Lord" To: "Sebastian Kun" Cc: Sent: Monday, February 25, 2002 3:42 PM Subject: Re: Inode cache uses a lot of memory [...] > Well, the xfs inode cache is pretty much controlled via the inode cache, > which is only shrunk if you get into the cache pruning code if you run > short of memory. > > I can easily prune out my inode cache without doing unmounts, but my > memory size is a lot smaller than yours. > > I presume you do not see this issue with other filesystems? > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 26 10:38:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QIcbC31189 for linux-xfs-outgoing; Tue, 26 Feb 2002 10:38:37 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QIcT931165 for ; Tue, 26 Feb 2002 10:38:30 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA03941 for ; Tue, 26 Feb 2002 09:39:59 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA66081; Tue, 26 Feb 2002 11:37:13 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA22670; Tue, 26 Feb 2002 11:37:13 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: "Stephenson, Dale" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F0BE@cdserv.meridian-data.com> References: <2D0AFEFEE711D611923E009027D39F2B02F0BE@cdserv.meridian-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 11:37:13 -0600 Message-Id: <1014745033.9500.27.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, I tried adding quota to the mix, and it still doesn't fall down for me... Do you guys have some other XFS changes in the mix? -Eric # This works for me: # create logical volume vgcreate volgroup /dev/sda2 /dev/sda3 lvcreate -L 100M -n logicalvol volgroup # mkfs and mount it: umount /dev/volgroup/logicalvol mkfs.xfs -f /dev/volgroup/logicalvol mount -o quota /dev/volgroup/logicalvol /mnt/lvm/logicalvol # Make a couple snapshots and mount them: lvcreate --size 16m --snapshot --name snap1 /dev/volgroup/logicalvol lvcreate --size 16m --snapshot --name snap2 /dev/volgroup/logicalvol mount -o ro,nouuid,norecovery /dev/volgroup/snap1 /mnt/lvm/snap1 mount -o ro,nouuid,norecovery /dev/volgroup/snap2 /mnt/lvm/snap2 # Overflow the snapshots: cp -aR /usr/src/linux-2.4.9-13SGI_XFS_1.0.2/ /mnt/lvm/logicalvol # Unmount the snapshots: umount /mnt/lvm/snap1/ umount /mnt/lvm/snap2/ On Mon, 2002-02-25 at 14:19, Stephenson, Dale wrote: > Eric, > > I followed your steps and did not get the oops. It seems that the mount > options on the original xfs source volume matter. I was able to recreate > the oops with the same steps by mounting with quota support. > > mount -o quota /dev/volgroup/logicalvol /mnt/lvm/logicalvol > or > mount -o usrquota,grpquota,quota /dev/volgroup/logicalvol > /mnt/lvm/logicalvol > > I also found (accidentally) that after the first snapshot umount goes > through xfs_force_shutdown(), an oops can be triggered by umounting the > original source volume--not just umounting its other snapshot. It doesn't > xfs_force_shutdown the source volume, but oops in the same spot just the -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 26 11:04:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QJ4I131818 for linux-xfs-outgoing; Tue, 26 Feb 2002 11:04:18 -0800 Received: from angelina.sl.pt (isengard.sl.pt [212.55.140.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QJ4E931796 for ; Tue, 26 Feb 2002 11:04:14 -0800 Received: from localhost (nmr@localhost) by angelina.sl.pt (8.11.3/8.11.3) with ESMTP id g1QI91a05273 for ; Tue, 26 Feb 2002 18:09:01 GMT (envelope-from nmr@co.sapo.pt) Date: Tue, 26 Feb 2002 18:09:01 +0000 (WET) From: Nuno Miguel Rodrigues X-X-Sender: To: Subject: Direct I/O Message-ID: <20020226180708.D4305-100000@angelina.sl.pt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, Should one expect direct I/O support anyday soon now? Thanks, -- Nuno M. Rodrigues From owner-linux-xfs@oss.sgi.com Tue Feb 26 11:29:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QJTR132190 for linux-xfs-outgoing; Tue, 26 Feb 2002 11:29:27 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QJTK932168 for ; Tue, 26 Feb 2002 11:29:20 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA03933 for ; Tue, 26 Feb 2002 10:29:18 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA18058; Tue, 26 Feb 2002 12:28:03 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA87584; Tue, 26 Feb 2002 12:28:03 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1QIOie10139; Tue, 26 Feb 2002 12:24:44 -0600 Subject: Re: Direct I/O From: Steve Lord To: Nuno Miguel Rodrigues Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020226180708.D4305-100000@angelina.sl.pt> References: <20020226180708.D4305-100000@angelina.sl.pt> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 12:24:44 -0600 Message-Id: <1014747884.5993.48.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 12:09, Nuno Miguel Rodrigues wrote: > > Hello all, > > Should one expect direct I/O support anyday soon now? Been there for well over a year. You need to right cpp directive to get O_DIRECT defined. -D_GNU_SOURCE I think. Steve > > Thanks, > > > -- > Nuno M. Rodrigues -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 26 11:47:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QJl0W00939 for linux-xfs-outgoing; Tue, 26 Feb 2002 11:47:00 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QJk3900903 for ; Tue, 26 Feb 2002 11:46:04 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKV8RV>; Tue, 26 Feb 2002 10:48:39 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0C0@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: oops umounting full LVM snapshots Date: Tue, 26 Feb 2002 10:48:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BEF6.31D1CD70" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BEF6.31D1CD70 Content-Type: text/plain; charset="iso-8859-1" Eric Sandeen wrote: > > Ok, I tried adding quota to the mix, and it still doesn't > fall down for > me... Do you guys have some other XFS changes in the mix? > > -Eric > The only change to xfs in my build is the VFS lock patch and Danny Cox's extended ACLs patch. I've attached Danny's patch in case you want to look at it, but I pulled it out and rebuilt my kernel without it--didn't fix the problem. I followed the same steps as you, and I'm still getting an I/O error umounting the snapshot. The only difference remaining I can see from your test and my last test is that I made my volume group from a single IDE drive partition, not two scsi partitions. At this point, the only patches I'm applying that are anywhere in the test path are: 1) the LVM patch to upgrade to 1.0.3 2) the VFS lock patch 3) some miscellaneous IDE patches I wouldn't expect the IDE patches to matter, since a full snapshot shouldn't be letting any I/O through to the drive below. Just in case, I'm building a kernel now with just the LVM patch. Dale > # This works for me: > # create logical volume > > vgcreate volgroup /dev/sda2 /dev/sda3 > lvcreate -L 100M -n logicalvol volgroup > > # mkfs and mount it: > > umount /dev/volgroup/logicalvol > mkfs.xfs -f /dev/volgroup/logicalvol > mount -o quota /dev/volgroup/logicalvol /mnt/lvm/logicalvol > > # Make a couple snapshots and mount them: > > lvcreate --size 16m --snapshot --name snap1 /dev/volgroup/logicalvol > lvcreate --size 16m --snapshot --name snap2 /dev/volgroup/logicalvol > mount -o ro,nouuid,norecovery /dev/volgroup/snap1 /mnt/lvm/snap1 > mount -o ro,nouuid,norecovery /dev/volgroup/snap2 /mnt/lvm/snap2 > > # Overflow the snapshots: > > cp -aR /usr/src/linux-2.4.9-13SGI_XFS_1.0.2/ /mnt/lvm/logicalvol > > # Unmount the snapshots: > > umount /mnt/lvm/snap1/ > umount /mnt/lvm/snap2/ ------_=_NextPart_000_01C1BEF6.31D1CD70 Content-Type: application/octet-stream; name="ext_acl_2.4.16.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ext_acl_2.4.16.patch" diff -Nur linux/Documentation/Configure.help linux-hacked/linux/Documentati= on/Configure.help --- linux/Documentation/Configure.help Wed Nov 28 15:36:41 2001 +++ linux-hacked/linux/Documentation/Configure.help Thu Nov 29 15:11:03 2001 @@ -11769,6 +11769,21 @@ =20 If unsure, say N. =20 +Connex Extended Permissions +CONFIG_EXTENDED_PERMISSION + This option extends the normal permissions available with the + Access Control List of the XFS file system. If a file has no ACL, + then the default behaviour results. Three new permissions are added: + Delete, Chmod, and Chown. With Delete, a user must have Delete=20 + ACL permission to delete an object. If a user has Chmod permission, + the file permissions may be changed, and if a user has Chown + permission, the user can become the owner of the object. + This may break some programs! + + This option is also settable at mount time on a per-filesystem basis. + + If unsure, say N. + Memory Technology Device (MTD) support CONFIG_MTD Memory Technology Devices are flash, RAM and similar chips, often diff -Nur linux/fs/Config.in linux-hacked/linux/fs/Config.in --- linux/fs/Config.in Tue Nov 20 18:18:52 2001 +++ linux-hacked/linux/fs/Config.in Thu Nov 29 15:11:03 2001 @@ -6,6 +6,7 @@ =20 bool 'Quota support' CONFIG_QUOTA bool 'POSIX Access Control List support' CONFIG_FS_POSIX_ACL +dep_bool 'Connex Extended Permissions' CONFIG_EXTENDED_PERMISSION $CONFIG_= FS_POSIX_ACL tristate 'Kernel automounter support' CONFIG_AUTOFS_FS tristate 'Kernel automounter version 4 support (also supports v3)' CONFIG_= AUTOFS4_FS =20 diff -Nur linux/fs/attr.c linux-hacked/linux/fs/attr.c --- linux/fs/attr.c Thu Oct 11 23:31:28 2001 +++ linux-hacked/linux/fs/attr.c Thu Nov 29 15:11:03 2001 @@ -28,19 +28,40 @@ /* Make sure a caller can chown. */ if ((ia_valid & ATTR_UID) && (current->fsuid !=3D inode->i_uid || - attr->ia_uid !=3D inode->i_uid) && !capable(CAP_CHOWN)) + attr->ia_uid !=3D inode->i_uid) && !capable(CAP_CHOWN)) { +#if CONFIG_EXTENDED_PERMISSION + retval =3D permission (inode, MAY_CHMOD); + if (retval) + goto error; +#else goto error; +#endif + } =20 /* Make sure caller can chgrp. */ if ((ia_valid & ATTR_GID) && (!in_group_p(attr->ia_gid) && attr->ia_gid !=3D inode->i_gid) && - !capable(CAP_CHOWN)) + !capable(CAP_CHOWN)) { +#if CONFIG_EXTENDED_PERMISSION + retval =3D permission (inode, MAY_CHMOD); + if (retval) + goto error; +#else goto error; +#endif + } =20 /* Make sure a caller can chmod. */ if (ia_valid & ATTR_MODE) { - if ((current->fsuid !=3D inode->i_uid) && !capable(CAP_FOWNER)) + if ((current->fsuid !=3D inode->i_uid) && !capable(CAP_FOWNER)) { +#if CONFIG_EXTENDED_PERMISSION + retval =3D permission (inode, MAY_CHMOD); + if (retval) + goto error; +#else goto error; +#endif + } /* Also check the setgid bit! */ if (!in_group_p((ia_valid & ATTR_GID) ? attr->ia_gid : inode->i_gid) && !capable(CAP_FSETID)) diff -Nur linux/fs/namei.c linux-hacked/linux/fs/namei.c --- linux/fs/namei.c Thu Oct 18 23:53:48 2001 +++ linux-hacked/linux/fs/namei.c Thu Nov 29 15:11:03 2001 @@ -872,7 +872,17 @@ int error; if (!victim->d_inode || victim->d_parent->d_inode !=3D dir) return -ENOENT; +#if CONFIG_EXTENDED_PERMISSION + if (dir->i_sb->s_magic =3D=3D XFS_SUPER_MAGIC) { + error =3D permission(victim->d_inode,MAY_DELETE); + if (error =3D=3D -EAGAIN) + error =3D permission(dir,MAY_WRITE | MAY_EXEC); + } + else + error =3D permission(dir,MAY_WRITE | MAY_EXEC); +#else error =3D permission(dir,MAY_WRITE | MAY_EXEC); +#endif if (error) return error; if (IS_APPEND(dir)) diff -Nur linux/fs/xfs/linux/xfs_super.c linux-hacked/linux/fs/xfs/linux/xf= s_super.c --- linux/fs/xfs/linux/xfs_super.c Thu Oct 25 17:35:51 2001 +++ linux-hacked/linux/fs/xfs/linux/xfs_super.c Thu Nov 29 15:11:03 2001 @@ -120,6 +120,9 @@ #define MNTOPT_RO "ro" /* read only */ #define MNTOPT_RW "rw" /* read/write */ #define MNTOPT_NOUUID "nouuid" /* Ignore FS uuid */ +#if CONFIG_EXTENDED_PERMISSION +#define MNTOPT_EXTPERM "extperm" /* turn on extended permissions */ +#endif =20 STATIC int xfs_parseargs( @@ -234,6 +237,9 @@ args->flags |=3D MS_NOSUID; } else if (!strcmp(this_char, MNTOPT_NOUUID)) { args->flags |=3D XFSMNT_NOUUID;=20 + } else if (!strcmp(this_char, MNTOPT_EXTPERM)) { + extended_perm =3D 1; + printk ("XFS: extended permissions ON\n"); } else { printk("XFS: unknown mount option [%s].\n", this_char); return rval; diff -Nur linux/fs/xfs/xfs_acl.c linux-hacked/linux/fs/xfs/xfs_acl.c --- linux/fs/xfs/xfs_acl.c Tue Nov 20 18:18:55 2001 +++ linux-hacked/linux/fs/xfs/xfs_acl.c Fri Feb 15 15:22:11 2002 @@ -42,6 +42,11 @@ #define ACL_READ 0x04 #define ACL_WRITE 0x02 #define ACL_EXECUTE 0x01 +/* added for Connex Extended ACLs */ +#define ACL_CHOWN 0x20 +#define ACL_CHMOD 0x10 +#define ACL_DELETE 0x08 +#define EXTENDED_PERM_BITS (ACL_CHOWN|ACL_CHMOD|ACL_DELETE) =20 #define ACL_USER_OBJ 0x01 #define ACL_USER 0x02 @@ -57,6 +62,8 @@ STATIC int xfs_acl_invalid(xfs_acl_t *aclp); STATIC void xfs_acl_sync_mode(mode_t mode, xfs_acl_t *acl); =20 +int extended_perm; + int xfs_acl_iaccess( xfs_inode_t *ip, mode_t mode, cred_t *cr ) { @@ -97,6 +104,17 @@ return EACCES; if ((mode & ACL_EXECUTE) && !capable_cred(cr, CAP_DAC_OVERRIDE)) return EACCES; +#if CONFIG_EXTENDED_PERMISSION + if ((mode & ACL_DELETE) && !capable_cred(cr, CAP_DAC_OVERRIDE)) { + return EACCES; + } + if ((mode & ACL_CHMOD) && !capable_cred (cr, CAP_DAC_OVERRIDE)) { + return EACCES; + } + if ((mode & ACL_CHOWN) && !capable_cred (cr, CAP_DAC_OVERRIDE)) { + return EACCES; + } +#endif return 0; } =20 @@ -556,8 +574,14 @@ va.va_mask =3D AT_UID; VOP_GETATTR(vp, &va, 0, NULL, error); if (!error && va.va_uid !=3D current->fsuid && - !capable(CAP_FOWNER)) + !capable(CAP_FOWNER)) { +#if CONFIG_EXTENDED_PERMISSION + if (!extended_perm || xfs_acl_iaccess( + XFS_BHVTOI(vp->v_fbhv), MAY_CHMOD << 6,=20 + NULL) !=3D 0) +#endif error =3D EACCES; + } } if (!error && acl) /* Set the access ACL. */ error =3D xfs_acl_vset(vp, &kacl); @@ -676,25 +700,46 @@ for (ap =3D acl->acl_entry, i =3D 0; i < acl->acl_cnt; ap++, i++) { switch (ap->ae_tag) { case ACL_USER_OBJ: - ap->ae_perm =3D (mode >> 6) & 0x7; + ap->ae_perm =3D ((mode >> 6) & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ?=20 + (ap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; break; case ACL_GROUP_OBJ: gap =3D ap; break; case ACL_MASK: nomask =3D 0; - ap->ae_perm =3D (mode >> 3) & 0x7; + ap->ae_perm =3D ((mode >> 3) & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ? + (ap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; break; case ACL_OTHER: - ap->ae_perm =3D mode & 0x7; + ap->ae_perm =3D (mode & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ? + (ap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; break; default: break; } } /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm =3D (mode >> 3) & 0x7; + if (gap && nomask) { + gap->ae_perm =3D ((mode >> 3) & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ? + (gap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; + } } =20 /*=20 @@ -719,17 +764,32 @@ for (ap =3D acl->acl_entry, i =3D 0; i < acl->acl_cnt; ap++, i++) { switch (ap->ae_tag) { case ACL_USER_OBJ: - ap->ae_perm &=3D (mode >> 6) & 0x7; + ap->ae_perm &=3D ((mode >> 6) & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ?=20 + (ap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; break; case ACL_GROUP_OBJ: gap =3D ap; break; case ACL_MASK: nomask =3D 0; - ap->ae_perm &=3D (mode >> 3) & 0x7; + ap->ae_perm &=3D ((mode >> 3) & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ? + (ap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; break; case ACL_OTHER: - ap->ae_perm &=3D mode & 0x7; + ap->ae_perm &=3D (mode & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ? + (ap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; break; default: break; @@ -737,5 +797,10 @@ } /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ if (gap && nomask) - gap->ae_perm &=3D (mode >> 3) & 0x7; + gap->ae_perm &=3D ((mode >> 3) & 0x7) +#if CONFIG_EXTENDED_PERMISSION + | ((extended_perm) ? + (gap->ae_perm & EXTENDED_PERM_BITS) : 0) +#endif + ; } diff -Nur linux/fs/xfs/xfs_acl.h linux-hacked/linux/fs/xfs/xfs_acl.h --- linux/fs/xfs/xfs_acl.h Tue Nov 20 18:18:55 2001 +++ linux-hacked/linux/fs/xfs/xfs_acl.h Thu Nov 29 15:11:03 2001 @@ -42,6 +42,8 @@ extern int xfs_acl_set(struct vnode *, xfs_acl_t *, xfs_acl_t *); extern int xfs_acl_vtoacl(vnode_t *, xfs_acl_t *, xfs_acl_t *); =20 +extern int extended_perm; + #ifdef CONFIG_FS_POSIX_ACL #define _ACL_INHERIT(c,v,d) (xfs_acl_inherit(c,v,d)) #define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd)=3D=3D0) diff -Nur linux/fs/xfs/xfs_dinode.h linux-hacked/linux/fs/xfs/xfs_dinode.h --- linux/fs/xfs/xfs_dinode.h Tue Nov 14 18:40:34 2000 +++ linux-hacked/linux/fs/xfs/xfs_dinode.h Thu Nov 29 15:11:03 2001 @@ -448,6 +448,11 @@ #define ISUID 04000 /* set user id on execution */ #define ISGID 02000 /* set group id on execution */ #define ISVTX 01000 /* sticky directory */ +#if CONFIG_EXTENDED_PERMISSION +#define ICHOWN 04000 /* become owner */ +#define ICHMOD 02000 /* change permissions */ +#define IDELETE 01000 /* delete object */ +#endif #define IREAD 0400 /* read, write, execute permissions */ #define IWRITE 0200 #define IEXEC 0100 diff -Nur linux/fs/xfs/xfs_inode.c linux-hacked/linux/fs/xfs/xfs_inode.c --- linux/fs/xfs/xfs_inode.c Tue Oct 16 20:01:56 2001 +++ linux-hacked/linux/fs/xfs/xfs_inode.c Thu Nov 29 15:11:03 2001 @@ -32,6 +32,10 @@ =20 #include =20 +#define ACL_CHOWN 0x20 +#define ACL_CHMOD 0x10 +#define ACL_DELETE 0x08 +#define EXTENDED_PERM_BITS (ACL_CHOWN|ACL_CHMOD|ACL_DELETE) =20 xfs_zone_t *xfs_ifork_zone; xfs_zone_t *xfs_inode_zone; @@ -3474,6 +3478,16 @@ if ((error =3D _ACL_XFS_IACCESS(ip, mode, cr)) !=3D -1) return error ? XFS_ERROR(error) : 0; =20 +#if CONFIG_EXTENDED_PERMISSION + /* if we wish to delete an object, and the object has no ACL, + ** return EAGAIN, so we can try the normal semantics + */ + if ((mode & IDELETE) && error =3D=3D -1) + return EAGAIN; + + /* discard extended permission bits */ + mode &=3D ~(EXTENDED_PERM_BITS); +#endif if (current->fsuid !=3D ip->i_d.di_uid) { mode >>=3D 3; if (!in_group_p((gid_t)ip->i_d.di_gid)) diff -Nur linux/fs/xfs/xfs_vnodeops.c linux-hacked/linux/fs/xfs/xfs_vnodeop= s.c --- linux/fs/xfs/xfs_vnodeops.c Mon Nov 5 13:40:15 2001 +++ linux-hacked/linux/fs/xfs/xfs_vnodeops.c Thu Nov 29 15:11:03 2001 @@ -423,7 +423,13 @@ */ if (!file_owner && !capable(CAP_FOWNER)) { code =3D XFS_ERROR(EPERM); - goto error_return; +#if CONFIG_EXTENDED_PERMISSION + if (!extended_perm ||=20 + _ACL_XFS_IACCESS(ip, ICHMOD, credp) !=3D 0) + goto error_return; +#else + goto error_return; +#endif } =20 /* @@ -491,7 +497,13 @@ !in_group_p((gid_t)gid))) && !capable(CAP_CHOWN)) { code =3D XFS_ERROR(EPERM); +#if CONFIG_EXTENDED_PERMISSION + if (!extended_perm || uid !=3D current->fsuid || + _ACL_XFS_IACCESS(ip, ICHMOD, credp) !=3D 0) + goto error_return; +#else goto error_return; +#endif } /* * Do a quota reservation only if uid or gid is actually diff -Nur linux/include/linux/fs.h linux-hacked/linux/include/linux/fs.h --- linux/include/linux/fs.h Thu Nov 29 11:03:55 2001 +++ linux-hacked/linux/include/linux/fs.h Thu Nov 29 15:11:03 2001 @@ -70,6 +70,11 @@ #define MAY_EXEC 1 #define MAY_WRITE 2 #define MAY_READ 4 +#if CONFIG_EXTENDED_PERMISSION +#define MAY_DELETE 8 +#define MAY_CHMOD 16 +#define MAY_CHOWN 32 +#endif =20 #define FMODE_READ 1 #define FMODE_WRITE 2 ------_=_NextPart_000_01C1BEF6.31D1CD70-- From owner-linux-xfs@oss.sgi.com Tue Feb 26 12:09:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QK92K01413 for linux-xfs-outgoing; Tue, 26 Feb 2002 12:09:02 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QK8w901391 for ; Tue, 26 Feb 2002 12:08:58 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKV8YK>; Tue, 26 Feb 2002 11:11:33 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0C1@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: oops umounting full LVM snapshots Date: Tue, 26 Feb 2002 11:11:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I pulled the VFS lock patch and all the IDE patches, and I am still getting the same problem. The only patch left is the LVM 1.0.3 patch. Which version of LVM do you have? Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Tue Feb 26 12:12:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QKCQO01568 for linux-xfs-outgoing; Tue, 26 Feb 2002 12:12:26 -0800 Received: from mx01.uni-tuebingen.de (mx01.uni-tuebingen.de [134.2.3.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QKC7901546 for ; Tue, 26 Feb 2002 12:12:08 -0800 Received: from mailserv05.uni-tuebingen.de (mailserv05.uni-tuebingen.de [192.168.3.15]) by mx01.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id UAA28512 for ; Tue, 26 Feb 2002 20:12:06 +0100 Received: from chimaera (pool2149.studentenheim.uni-tuebingen.de [134.2.212.149]) by mailserv05.uni-tuebingen.de (8.9.3/8.9.3) with SMTP id UAA15300 for ; Tue, 26 Feb 2002 20:12:06 +0100 Message-ID: <000701c1bef9$7bb94c80$0a42a8c0@chimaera> From: "Simon Pabst" To: Subject: xfs/lvm problem, disappearing files Date: Tue, 26 Feb 2002 20:12:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I just experienced some problems with my xfs-lvm volume. This volume is mounted via samba and I noticed some files and directories were disappearing, a whole directory in which a task on the client machine was writing at this time appeared empty for ls -la (on the server of course). I umounted the volume and tried to mount it again, which did not work (mount did not return). After a reboot I was able to mount again, the files seemed to be fine, and I did a xfs_repair on the volume to asure this, which repaired some disconnected inodes. Running xfs_repair again produces the same output again and again, so my question is, is my filesystem safe or should I backup data and mkfs it again? system is redhat 7.1(roswell), kernel is 2.4.9-13SGI_XFS_PR1custom with lvm from this version (1.01rc4), running on an athlon 900, 512mb mount options: /dev/vg02/lvol1 /fs3 xfs defaults,noatime,nodiratime,logbufs=4 1 2 vg02/lvol1 is a 2-disk stripeset using 2 maxtor 80gb ide drives /var/log/messages did not show any xfs-related information output of xfs_repair: root@judicator:~ > xfs_repair /dev/vg02/lvol1 xfs_repair: warning - cannot set blocksize on block device /dev/vg02/lvol1: Inva lid argument Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 18376471, moving to lost+found disconnected dir inode 18800263, moving to lost+found disconnected dir inode 117385730, moving to lost+found disconnected inode 150995073, moving to lost+found disconnected inode 150995075, moving to lost+found disconnected inode 150995076, moving to lost+found disconnected inode 150995077, moving to lost+found disconnected inode 150995078, moving to lost+found disconnected dir inode 275899789, moving to lost+found disconnected dir inode 310212310, moving to lost+found disconnected dir inode 402676446, moving to lost+found disconnected dir inode 506154388, moving to lost+found disconnected inode 621161409, moving to lost+found disconnected inode 621161443, moving to lost+found disconnected inode 621161466, moving to lost+found Phase 7 - verify and correct link counts... done as mentioned above, running xfs_repair again produces the same output. thanks in advance -simon pabst From owner-linux-xfs@oss.sgi.com Tue Feb 26 12:22:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QKMoN01884 for linux-xfs-outgoing; Tue, 26 Feb 2002 12:22:50 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QKMg901862 for ; Tue, 26 Feb 2002 12:22:42 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1QKMbFH024737 for ; Tue, 26 Feb 2002 12:22:38 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA19124; Tue, 26 Feb 2002 13:21:21 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA89384; Tue, 26 Feb 2002 13:21:21 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1QJI2o12176; Tue, 26 Feb 2002 13:18:02 -0600 Subject: Re: xfs/lvm problem, disappearing files From: Steve Lord To: Simon Pabst Cc: linux-xfs@oss.sgi.com In-Reply-To: <000701c1bef9$7bb94c80$0a42a8c0@chimaera> References: <000701c1bef9$7bb94c80$0a42a8c0@chimaera> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 13:18:02 -0600 Message-Id: <1014751082.5993.107.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 13:12, Simon Pabst wrote: > Running xfs_repair again produces the same output again and again, so my > question is, > is my filesystem safe or should I backup data and mkfs it again? Repair will do this if you do not clean out lost+found between runs, during each run it deletes the directory, making the contents unlinked inodes again. > > system is redhat 7.1(roswell), kernel is 2.4.9-13SGI_XFS_PR1custom with lvm > from > this version (1.01rc4), running on an athlon 900, 512mb > mount options: /dev/vg02/lvol1 /fs3 xfs > defaults,noatime,nodiratime,logbufs=4 1 2 > vg02/lvol1 is a 2-disk stripeset using 2 maxtor 80gb ide drives > /var/log/messages did not show any xfs-related information > Ugh, ancient kernel. I am not sure what happened to your filesystem, the repair output could have been valid the first time, but we do not really know that - the files in lost+found could be recent or the may be old. Do they correspond with things from the directory which went missing? Nothing else rings a bell here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 26 12:23:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QKNEv01983 for linux-xfs-outgoing; Tue, 26 Feb 2002 12:23:14 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QKNB901961 for ; Tue, 26 Feb 2002 12:23:11 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1QKN6FH024758 for ; Tue, 26 Feb 2002 12:23:06 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA19967; Tue, 26 Feb 2002 13:21:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA00910; Tue, 26 Feb 2002 13:21:50 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: "Stephenson, Dale" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F0C1@cdserv.meridian-data.com> References: <2D0AFEFEE711D611923E009027D39F2B02F0C1@cdserv.meridian-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 13:21:49 -0600 Message-Id: <1014751310.9500.31.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 13:11, Stephenson, Dale wrote: > I pulled the VFS lock patch and all the IDE patches, and I am still getting > the same problem. The only patch left is the LVM 1.0.3 patch. Which > version of LVM do you have? LVM 1.0.3, with 1.0.3 userspace; this is on an updated RH7.2/XFS box. Feb 26 10:38:14 lite kernel: LVM version 1.0.3(19/02/2002) module loaded I can try it on IDE... What XFS options do you have enabled? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 26 12:34:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QKYpI02310 for linux-xfs-outgoing; Tue, 26 Feb 2002 12:34:51 -0800 Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.3.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QKYi902287 for ; Tue, 26 Feb 2002 12:34:44 -0800 Received: from mailserv05.uni-tuebingen.de (mailserv05.uni-tuebingen.de [192.168.3.15]) by mx03.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id UAA03306; Tue, 26 Feb 2002 20:34:42 +0100 Received: from chimaera (pool2149.studentenheim.uni-tuebingen.de [134.2.212.149]) by mailserv05.uni-tuebingen.de (8.9.3/8.9.3) with SMTP id UAA17121; Tue, 26 Feb 2002 20:34:42 +0100 Message-ID: <000b01c1befc$a41992e0$0a42a8c0@chimaera> From: "Simon Pabst" To: "Steve Lord" Cc: References: <000701c1bef9$7bb94c80$0a42a8c0@chimaera> <1014751082.5993.107.camel@jen.americas.sgi.com> Subject: Re: xfs/lvm problem, disappearing files Date: Tue, 26 Feb 2002 20:34:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Steve Lord" To: "Simon Pabst" Cc: Sent: Tuesday, February 26, 2002 8:18 PM Subject: Re: xfs/lvm problem, disappearing files > On Tue, 2002-02-26 at 13:12, Simon Pabst wrote: > > > Running xfs_repair again produces the same output again and again, so my > > question is, > > is my filesystem safe or should I backup data and mkfs it again? > > Repair will do this if you do not clean out lost+found between runs, > during each run it deletes the directory, making the contents unlinked > inodes again. > > > > > system is redhat 7.1(roswell), kernel is 2.4.9-13SGI_XFS_PR1custom with lvm > > from > > this version (1.01rc4), running on an athlon 900, 512mb > > mount options: /dev/vg02/lvol1 /fs3 xfs > > defaults,noatime,nodiratime,logbufs=4 1 2 > > vg02/lvol1 is a 2-disk stripeset using 2 maxtor 80gb ide drives > > /var/log/messages did not show any xfs-related information > > > > Ugh, ancient kernel. > > I am not sure what happened to your filesystem, the repair output > could have been valid the first time, but we do not really know > that - the files in lost+found could be recent or the may be old. > Do they correspond with things from the directory which went > missing? yes I was just able to identify them, they were from a different directory than the one with missing files. Looks like no data was lost at all, puuh. xfs_repair looks good now, I didn't know I had to clean lost+found first. 2.4.9-13 worked really great for me for a long time, but this sure looks like a good point for a kernel upgrade. thanks for the fast reply, and keep up the good work -simon pabst From owner-linux-xfs@oss.sgi.com Tue Feb 26 12:37:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QKbph02487 for linux-xfs-outgoing; Tue, 26 Feb 2002 12:37:51 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QKbk902464 for ; Tue, 26 Feb 2002 12:37:46 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKV80G>; Tue, 26 Feb 2002 11:40:22 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0C2@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: oops umounting full LVM snapshots Date: Tue, 26 Feb 2002 11:40:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > On Tue, 2002-02-26 at 13:11, Stephenson, Dale wrote: > > I pulled the VFS lock patch and all the IDE patches, and I > am still getting > > the same problem. The only patch left is the LVM 1.0.3 > patch. Which > > version of LVM do you have? > > LVM 1.0.3, with 1.0.3 userspace; this is on an updated RH7.2/XFS box. > I am using the same userspace/kernel, though I have LVM compiled into the kernel. > Feb 26 10:38:14 lite kernel: LVM version 1.0.3(19/02/2002) > module loaded > > I can try it on IDE... What XFS options do you have enabled? CONFIG_PAGE_BUF CONFIG_XFS_FS CONFIG_XFS_QUOTA CONFIG_HAVE_ATTRCTL # CONFIG_XFS_RT is not set # CONFIG_XFS_DMAPI is not set Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Tue Feb 26 12:43:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QKhrG03228 for linux-xfs-outgoing; Tue, 26 Feb 2002 12:43:53 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QKhn903204 for ; Tue, 26 Feb 2002 12:43:49 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA734381 for ; Tue, 26 Feb 2002 20:45:56 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA94316; Tue, 26 Feb 2002 13:42:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA93951; Tue, 26 Feb 2002 13:42:29 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: "Stephenson, Dale" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F0C0@cdserv.meridian-data.com> References: <2D0AFEFEE711D611923E009027D39F2B02F0C0@cdserv.meridian-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 13:42:28 -0600 Message-Id: <1014752549.9478.35.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 12:48, Stephenson, Dale wrote: > The only difference remaining I can see from your test and my last test is > that I made my volume group from a single IDE drive partition, not two scsi > partitions. ...and that was the crucial difference. Mine falls down now, too. Drat. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 26 13:00:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QL0OL03790 for linux-xfs-outgoing; Tue, 26 Feb 2002 13:00:24 -0800 Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QL0I903767 for ; Tue, 26 Feb 2002 13:00:18 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel13.hp.com (Postfix) with ESMTP id 81880400855; Tue, 26 Feb 2002 12:00:08 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 714D4E00092; Tue, 26 Feb 2002 12:00:08 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 12:00:08 -0800 Message-ID: From: "DICKENS,CARY (HP-Loveland,ex2)" To: "'Eric Sandeen'" Cc: "Xfs Mailing List (E-mail)" , "PATTERSON,ANDREW (HP-Loveland,ex2)" Subject: RE: oops umounting full LVM snapshots Date: Tue, 26 Feb 2002 12:00:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, I'm glad you reproduced the problem, because we are having the same problems here. We are on a 2.4.17 kernel with LVM version 1.0.2. We include the 2.4.11 vfs lock patch that was included in LVM 1.0.3. The disks are fibre. XFS is from 2/7/02 cvs and is built when the kernel. These are 4 way SMP machines with highmem enabled. We mount with quota,grpquota,noqenforce,nogqenforce,osyncisdsync and get a lockup when we unmount a snapshot that has overflowed. When we reboot, the LVM doesn't work. Without quotas we don't see the problem. I don't think IDE has anything to do with it here because we don't even have an IDE hard drive in the system. Let me know if there is any information we can provide or test we can do to help hunt this down. Cary > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Tuesday, February 26, 2002 12:42 PM > To: Stephenson, Dale > Cc: 'linux-xfs@oss.sgi.com' > Subject: RE: oops umounting full LVM snapshots > > > On Tue, 2002-02-26 at 12:48, Stephenson, Dale wrote: > > > The only difference remaining I can see from your test and > my last test is > > that I made my volume group from a single IDE drive > partition, not two scsi > > partitions. > > ...and that was the crucial difference. Mine falls down now, too. > Drat. :) > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Tue Feb 26 13:01:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QL1qq03955 for linux-xfs-outgoing; Tue, 26 Feb 2002 13:01:52 -0800 Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QL1k903933 for ; Tue, 26 Feb 2002 13:01:46 -0800 Received: from fwd03.sul.t-online.de by mailout11.sul.t-online.com with smtp id 16fnlZ-0005ux-00; Tue, 26 Feb 2002 21:00:01 +0100 Received: from tower (340024412816-0001@[80.145.99.249]) by fwd03.sul.t-online.com with esmtp id 16fnlL-11R4WOC; Tue, 26 Feb 2002 20:59:47 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Ivan Rayner Subject: Re: xfsrestore not restoring Date: Tue, 26 Feb 2002 20:59:45 +0100 X-Mailer: KMail [version 1.3.9] Cc: linux-xfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200202262059.45518.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Ivan, > To be honest, I don't know what caused this problem, but we will look into > it. It looks like it might have something to do with the inventory. These are the last lines of the xfsrestore output again: ./xfsrestore: mkdir sun ./xfsrestore: mkdir sun/forte ./xfsrestore: getting next media file for non-dir restore ./xfsrestore: Media_mfile_next: purp==2 pos==3 ./xfsrestore: drive op: end read ./xfsrestore: tree finalize ./xfsrestore: restore complete: 40 seconds elapsed ./xfsrestore: main.c: 630: mlog_exit called: exit_code: SUCCESS return: OK (success) ./xfsrestore: Restore Status: SUCCESS It looks like pi_neededobjs_nondir_alloc() returns NULL in pi_alldone() and xfsrestore exits without restoring any files. This doesn't happen with an newly created tape. > It'd be helpful if you could tell us the exact sequence of events that led > to the problem so that we could try reproducing it here. What I did was to upgrade my System from Suse 7.1 to Suse 7.3. The kernel and xfs tools remained the same. Today I upgraded to the most recent CVS version of the tools, no change. I will try to create a Suse 7.1 system where I can boot from to see if the tapes can be restored there. ...Juergen From owner-linux-xfs@oss.sgi.com Tue Feb 26 13:16:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QLGLe04315 for linux-xfs-outgoing; Tue, 26 Feb 2002 13:16:21 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QLGF904293 for ; Tue, 26 Feb 2002 13:16:15 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA03338 for ; Tue, 26 Feb 2002 12:17:45 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA20479; Tue, 26 Feb 2002 14:14:55 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA99094; Tue, 26 Feb 2002 14:14:55 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1QKBax17060; Tue, 26 Feb 2002 14:11:36 -0600 Subject: RE: oops umounting full LVM snapshots From: Steve Lord To: "DICKENS,CARY ""(HP-Loveland,ex2)" Cc: "'Eric Sandeen'" , Xfs "Mailing List (E-mail)" , "PATTERSON,ANDREW ""(HP-Loveland,ex2)" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 14:11:35 -0600 Message-Id: <1014754295.9994.140.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 14:00, DICKENS,CARY (HP-Loveland,ex2) wrote: > > Eric, > I'm glad you reproduced the problem, because we are having the same problems > here. We are on a 2.4.17 kernel with LVM version 1.0.2. We include the > 2.4.11 vfs lock patch that was included in LVM 1.0.3. The disks are fibre. > XFS is from 2/7/02 cvs and is built when the kernel. These are 4 way SMP > machines with highmem enabled. > > We mount with quota,grpquota,noqenforce,nogqenforce,osyncisdsync and get a > lockup when we unmount a snapshot that has overflowed. When we reboot, the > LVM doesn't work. Without quotas we don't see the problem. > > I don't think IDE has anything to do with it here because we don't even have > an IDE hard drive in the system. > > Let me know if there is any information we can provide or test we can do to > help hunt this down. > > Cary > If it is stack overflow as we suspect then different drivers may push it over the edge in different ways. What we need to do is catch it in the act and see if there isn't something we can push off the stack. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Feb 26 16:13:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R0DJn20015 for linux-xfs-outgoing; Tue, 26 Feb 2002 16:13:19 -0800 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R0DE919993 for ; Tue, 26 Feb 2002 16:13:15 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g1QNDDXt007134 for ; Wed, 27 Feb 2002 10:13:13 +1100 (EST) Received: from jdc.local (ppp30.dyn224.pacific.net.au [203.100.224.30]) by wisma.pacific.net.au with ESMTP id KAA15177 for ; Wed, 27 Feb 2002 10:13:10 +1100 (EST) Received: from jdc.local (LOCALHOST [127.0.0.1]) by jdc.local (8.12.1/8.12.1/Debian -5) with ESMTP id g1QND8fE001713 for ; Wed, 27 Feb 2002 10:13:08 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g1QND2FS001693; Wed, 27 Feb 2002 10:13:02 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.5757.823737.54107@jdc.local> Date: Wed, 27 Feb 2002 10:13:01 +1100 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details In-Reply-To: <20020226172010.M193798@wobbly.melbourne.sgi.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> <15483.9635.101270.256294@jdc.local> <20020226172010.M193798@wobbly.melbourne.sgi.com> X-Mailer: VM 7.01 under Emacs 20.7.2 Reply-To: jasonw@ariel.ucs.unimelb.edu.au Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott writes: > > There are no Debian ACL packages at the moment. I'll have to > discuss this with the people involved first to see what comes > of it. For now, you will have to build ACL from source. The > rest of our userspace packages are all still Debian-ized. I noticed that the Debian control file and installation scripts were included in the CVS source, but don't appear to have been updated recently. From owner-linux-xfs@oss.sgi.com Tue Feb 26 16:28:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R0S4920429 for linux-xfs-outgoing; Tue, 26 Feb 2002 16:28:04 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R0Rq920406 for ; Tue, 26 Feb 2002 16:27:53 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA08017 for ; Tue, 26 Feb 2002 15:23:25 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18697; Wed, 27 Feb 2002 10:26:34 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA98126; Wed, 27 Feb 2002 10:26:34 +1100 (AEDT) Date: Wed, 27 Feb 2002 10:26:33 +1100 From: Nathan Scott To: Jason White Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details Message-ID: <20020227102633.V193798@wobbly.melbourne.sgi.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> <15483.9635.101270.256294@jdc.local> <20020226172010.M193798@wobbly.melbourne.sgi.com> <15484.5757.823737.54107@jdc.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15484.5757.823737.54107@jdc.local>; from jasonw@ariel.ucs.unimelb.edu.au on Wed, Feb 27, 2002 at 10:13:01AM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 10:13:01AM +1100, Jason White wrote: > Nathan Scott writes: > > > > There are no Debian ACL packages at the moment. I'll have to > > discuss this with the people involved first to see what comes > > of it. For now, you will have to build ACL from source. The > > rest of our userspace packages are all still Debian-ized. > > I noticed that the Debian control file and installation scripts were > included in the CVS source, but don't appear to have been updated > recently. > I usually only update the Debian packaging stuff just prior to uploading to the Debian incoming directory. Since ACL has not ever been uploaded, it probably would have had bit rot at times. That (acl) situation will likely change now that syscalls exist. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 26 16:48:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R0mTO20848 for linux-xfs-outgoing; Tue, 26 Feb 2002 16:48:29 -0800 Received: from the-penguin.otak.com (mail@the-penguin.otak.com [216.122.56.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R0mI920822 for ; Tue, 26 Feb 2002 16:48:19 -0800 Received: from lawrence by the-penguin.otak.com with local (Exim 3.34 #1 (Debian)) id 16frJC-0000mC-00; Tue, 26 Feb 2002 15:46:58 -0800 Date: Tue, 26 Feb 2002 15:46:58 -0800 From: Lawrence Walton To: Nathan Scott Cc: Jason White , linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details Message-ID: <20020226234658.GA2544@the-penguin.otak.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> <15483.9635.101270.256294@jdc.local> <20020226172010.M193798@wobbly.melbourne.sgi.com> <15484.5757.823737.54107@jdc.local> <20020227102633.V193798@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020227102633.V193798@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.27i X-Operating-System: Linux 2.4.18-pre9-ac4 on an i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott [nathans@sgi.com] wrote: > On Wed, Feb 27, 2002 at 10:13:01AM +1100, Jason White wrote: > > Nathan Scott writes: > > > > > > There are no Debian ACL packages at the moment. I'll have to > > > discuss this with the people involved first to see what comes > > > of it. For now, you will have to build ACL from source. The > > > rest of our userspace packages are all still Debian-ized. > > > > I noticed that the Debian control file and installation scripts were > > included in the CVS source, but don't appear to have been updated > > recently. > > > > I usually only update the Debian packaging stuff just prior to > uploading to the Debian incoming directory. Since ACL has not > ever been uploaded, it probably would have had bit rot at times. > That (acl) situation will likely change now that syscalls exist. > > cheers. > > -- > Nathan > I for one would love to try to help with the Debian packages. At this point, I have deployed 5 servers that use Debian, XFS, and the CVS Debian ACL packages. Source is really not going to cut it, I expect to have additional servers in the pipe soon, and .deb makes it easy, supportable, scalable. Now call me stupid, but I could do my own packages, and just submit patches but would that be counter productive? Or am just insecure about my L33t developer skills. :) Personally; I think that the ACL packages should be uploaded to Debian proper, with some sort of dependency on the XFS kernel patches. Does that work? To be honest, I am not sure it does, but I hope so. :/ All else failing, having CVS/Deb support to the new ACL tools. The point is really, XFS and it's support for ACL's is really a amazing, wonderful thing, and I am grateful, and want to help. -- *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://www.otak-k.com/~lawrence/ -------------------------------------- - - - - - - O t a k i n c . - - - - - From owner-linux-xfs@oss.sgi.com Tue Feb 26 17:03:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R13pZ21232 for linux-xfs-outgoing; Tue, 26 Feb 2002 17:03:51 -0800 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R13m921208 for ; Tue, 26 Feb 2002 17:03:48 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g1R03lXt015032 for ; Wed, 27 Feb 2002 11:03:47 +1100 (EST) Received: from jdc.local (ppp30.dyn224.pacific.net.au [203.100.224.30]) by wisma.pacific.net.au with ESMTP id LAA27902 for ; Wed, 27 Feb 2002 11:03:45 +1100 (EST) Received: from jdc.local (LOCALHOST [127.0.0.1]) by jdc.local (8.12.1/8.12.1/Debian -5) with ESMTP id g1R03hfE002715 for ; Wed, 27 Feb 2002 11:03:43 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g1R03gRR002707; Wed, 27 Feb 2002 11:03:42 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.8798.263455.219288@jdc.local> Date: Wed, 27 Feb 2002 11:03:42 +1100 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details In-Reply-To: <20020226234658.GA2544@the-penguin.otak.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> <15483.9635.101270.256294@jdc.local> <20020226172010.M193798@wobbly.melbourne.sgi.com> <15484.5757.823737.54107@jdc.local> <20020227102633.V193798@wobbly.melbourne.sgi.com> <20020226234658.GA2544@the-penguin.otak.com> X-Mailer: VM 7.01 under Emacs 20.7.2 Reply-To: jasonw@ariel.ucs.unimelb.edu.au Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Now that ext3 and XFS use the same ACL interfaces, as I understand it, the plan is to have a single set of ACL tools which will be compatible with both filesystems. What this means on the packaging front is a single set of packages that will support ext3 and XFS. I may be wrong here, but this is what appears to be underway (based on mailing list discussion). Thus, once the common ACL tools are in place it would simply be a matter of updating the relevant package files. From owner-linux-xfs@oss.sgi.com Tue Feb 26 17:10:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R1AvF21442 for linux-xfs-outgoing; Tue, 26 Feb 2002 17:10:57 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R1Aq921419 for ; Tue, 26 Feb 2002 17:10:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA00051 for ; Tue, 26 Feb 2002 16:12:21 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19050; Wed, 27 Feb 2002 11:09:33 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA96454; Wed, 27 Feb 2002 11:09:32 +1100 (AEDT) Date: Wed, 27 Feb 2002 11:09:32 +1100 From: Nathan Scott To: Lawrence Walton Cc: Jason White , linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details Message-ID: <20020227110932.X193798@wobbly.melbourne.sgi.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> <15483.9635.101270.256294@jdc.local> <20020226172010.M193798@wobbly.melbourne.sgi.com> <15484.5757.823737.54107@jdc.local> <20020227102633.V193798@wobbly.melbourne.sgi.com> <20020226234658.GA2544@the-penguin.otak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020226234658.GA2544@the-penguin.otak.com>; from lawrence@the-penguin.otak.com on Tue, Feb 26, 2002 at 03:46:58PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 26, 2002 at 03:46:58PM -0800, Lawrence Walton wrote: > > I for one would love to try to help with the Debian packages. At this > point, I have deployed 5 servers that use Debian, XFS, and the CVS > Debian ACL packages. > > Source is really not going to cut it, I expect to have additional servers > in the pipe soon, and .deb makes it easy, supportable, scalable. > > Now call me stupid, but I could do my own packages, and just submit patches > but would that be counter productive? Or am just insecure about my L33t > developer skills. :) > > Personally; I think that the ACL packages should be uploaded to Debian > proper, with some sort of dependency on the XFS kernel patches. Does that > work? To be honest, I am not sure it does, but I hope so. :/ > > All else failing, having CVS/Deb support to the new ACL tools. > Since the attr and acl packages are so similar, I may as well just do this and prevent all the questions. It should appear in CVS later today, and the Debian upload should happen later in the week - along with the other v2 packages, before anyone asks about that. ;-) > The point is really, XFS and it's support for ACL's is really a amazing, > wonderful thing, and I am grateful, and want to help. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 26 17:12:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R1CHJ21557 for linux-xfs-outgoing; Tue, 26 Feb 2002 17:12:17 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R1CD921529 for ; Tue, 26 Feb 2002 17:12:13 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id BAA744729 for ; Wed, 27 Feb 2002 01:14:23 +0100 (CET) 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 LAA19059; Wed, 27 Feb 2002 11:10:53 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA79911; Wed, 27 Feb 2002 11:10:53 +1100 (AEDT) Date: Wed, 27 Feb 2002 11:10:53 +1100 From: Nathan Scott To: Jason White Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 update details Message-ID: <20020227111053.Y193798@wobbly.melbourne.sgi.com> References: <20020226114324.J193798@wobbly.melbourne.sgi.com> <3C7AF03F.8384BF25@idcomm.com> <20020226132940.K193798@wobbly.melbourne.sgi.com> <15483.9635.101270.256294@jdc.local> <20020226172010.M193798@wobbly.melbourne.sgi.com> <15484.5757.823737.54107@jdc.local> <20020227102633.V193798@wobbly.melbourne.sgi.com> <20020226234658.GA2544@the-penguin.otak.com> <15484.8798.263455.219288@jdc.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15484.8798.263455.219288@jdc.local>; from jasonw@ariel.ucs.unimelb.edu.au on Wed, Feb 27, 2002 at 11:03:42AM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 11:03:42AM +1100, Jason White wrote: > Now that ext3 and XFS use the same ACL interfaces, as I understand it, > the plan is to have a single set of ACL tools which will be compatible > with both filesystems. What this means on the packaging front is a > single set of packages that will support ext3 and XFS. > > I may be wrong here, but this is what appears to be underway (based on > mailing list discussion). correct. > Thus, once the common ACL tools are in place it would simply be a > matter of updating the relevant package files. yes, wont be long now. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 26 17:35:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R1ZSf22013 for linux-xfs-outgoing; Tue, 26 Feb 2002 17:35:28 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R1ZL921990 for ; Tue, 26 Feb 2002 17:35:21 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05184 for ; Tue, 26 Feb 2002 16:36:50 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA23087; Tue, 26 Feb 2002 18:33:58 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id SAA08940; Tue, 26 Feb 2002 18:33:58 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: Steve Lord Cc: "DICKENS,CARY ""(HP-Loveland,ex2)" , Xfs "Mailing List (E-mail)" , "PATTERSON,ANDREW ""(HP-Loveland,ex2)" In-Reply-To: <1014754295.9994.140.camel@jen.americas.sgi.com> References: <1014754295.9994.140.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 18:33:58 -0600 Message-Id: <1014770038.10231.91.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm starting to wonder, now... I patched the kernel to increase the stack by 100% and I still get the oops. The patch also allows me to see stack depth, and things look ok. FWIW, it's even simpler to show the problem, it's not necessary to overflow the snapshot or even copy anything to them. Just create a couple snapshot volumes, mount them, and unmount them. Unmounting the first snapshot does a forced shutdown, unmounting the second one does a force shutdown and then oopses. Just for kicks I created 2 dirty xfs filesystems and mounted them ro,norecovery, and unmounted - so at least that works. So it looks like maybe with lvm, xfs is trying to do more log flushing than it should on an ro filesystem, which generates the i/o error, which shuts us down - not sure about the oops yet. I'm sure Steve will pipe up if this theory is too far out of line. :) Still looking... -Eric On Tue, 2002-02-26 at 14:11, Steve Lord wrote: > If it is stack overflow as we suspect then different drivers may push it > over the edge in different ways. What we need to do is catch it in the > act and see if there isn't something we can push off the stack. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Feb 26 18:23:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R2NeV22745 for linux-xfs-outgoing; Tue, 26 Feb 2002 18:23:40 -0800 Received: from mta2-rme.xtra.co.nz (210-86-15-130.ipnets.xtra.co.nz [210.86.15.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R2Na922721 for ; Tue, 26 Feb 2002 18:23:36 -0800 Received: from localhost.localdomain ([210.86.52.163]) by mta2-rme.xtra.co.nz with ESMTP id <20020227012321.YGWE12697.mta2-rme.xtra.co.nz@localhost.localdomain> for ; Wed, 27 Feb 2002 14:23:21 +1300 Subject: XFS with a few patches From: mdew To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 02:36:20 +1300 Message-Id: <1014730581.4135.7.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone succesully used XFS 2.4.18 with AA+0(1) Scheduler+Preemptive? From owner-linux-xfs@oss.sgi.com Tue Feb 26 18:36:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R2avP23136 for linux-xfs-outgoing; Tue, 26 Feb 2002 18:36:57 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R2ar923113 for ; Tue, 26 Feb 2002 18:36:53 -0800 Received: from UberGeek (10.130.1.222 [10.130.1.222]) by ausmail.coremetrics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FW76H8LP; Tue, 26 Feb 2002 19:36:18 -0600 Received: (qmail 11423 invoked by uid 500); 27 Feb 2002 01:36:13 -0000 Subject: Re: XFS with a few patches From: Austin Gonyou To: mdew Cc: xfs In-Reply-To: <1014730581.4135.7.camel@mdew> References: <1014730581.4135.7.camel@mdew> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 19:36:13 -0600 Message-Id: <1014773773.14489.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'll try and get this patch created. I want to do somem DB testing with it. Is there an -AA *final* ? On Tue, 2002-02-26 at 07:36, mdew wrote: > > > Has anyone succesully used XFS 2.4.18 with AA + 0(1) Scheduler+Preemptive? > > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Tue Feb 26 18:50:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R2op923411 for linux-xfs-outgoing; Tue, 26 Feb 2002 18:50:51 -0800 Received: from mta4-rme.xtra.co.nz (210-86-15-132.ipnets.xtra.co.nz [210.86.15.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R2ol923386 for ; Tue, 26 Feb 2002 18:50:47 -0800 Received: from localhost.localdomain ([210.86.52.163]) by mta4-rme.xtra.co.nz with ESMTP id <20020227014922.KJXM18867.mta4-rme.xtra.co.nz@localhost.localdomain>; Wed, 27 Feb 2002 14:49:22 +1300 Subject: Re: XFS with a few patches From: mdew To: Austin Gonyou Cc: xfs In-Reply-To: <1014773773.14489.8.camel@UberGeek> References: <1014730581.4135.7.camel@mdew> <1014773773.14489.8.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 03:02:17 +1300 Message-Id: <1014732142.4135.13.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-27 at 14:36, Austin Gonyou wrote: > I'll try and get this patch created. I want to do somem DB testing with > it. Is there an -AA *final* ? only -rc4 which is 2.4.18. I'd prefer if AA stripped XFS from his patch...since its pointless to me. > On Tue, 2002-02-26 at 07:36, mdew wrote: > > > > > > Has anyone succesully used XFS 2.4.18 with AA + 0(1) Scheduler+Preemptive? > > > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb From owner-linux-xfs@oss.sgi.com Tue Feb 26 19:18:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R3Inl24011 for linux-xfs-outgoing; Tue, 26 Feb 2002 19:18:49 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R3Ik923989 for ; Tue, 26 Feb 2002 19:18:46 -0800 Received: (qmail 1329 invoked from network); 27 Feb 2002 02:19:49 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 27 Feb 2002 02:19:49 -0000 Date: Tue, 26 Feb 2002 21:19:49 -0500 (EST) From: Shawn Starr To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch In-Reply-To: <20020226172010.M193798@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, I got it to build but I can't mount the drive ;-) VFS panic's on trying to mount the disk. I suspect the struct super_block or so broke XFS? Shawn. From owner-linux-xfs@oss.sgi.com Tue Feb 26 20:33:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R4XDG25134 for linux-xfs-outgoing; Tue, 26 Feb 2002 20:33:13 -0800 Received: from localhost.localdomain (209-6-26-174.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com [209.6.26.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R4XA925112 for ; Tue, 26 Feb 2002 20:33:10 -0800 Received: (from jacob@localhost) by localhost.localdomain (8.11.6/8.11.6) id g1R3WrE01964; Tue, 26 Feb 2002 22:32:53 -0500 X-Authentication-Warning: localhost.localdomain: jacob set sender to jacob@ximian.com using -f Subject: Re: XFS with a few patches From: jacob berkman To: mdew Cc: xfs In-Reply-To: <1014730581.4135.7.camel@mdew> References: <1014730581.4135.7.camel@mdew> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 22:32:52 -0500 Message-Id: <1014780772.1669.1.camel@wet-pants> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 08:36, mdew wrote: > > > Has anyone succesully used XFS 2.4.18 with AA+0(1) Scheduler+Preemptive? i've been using these for a while and it's been quite nice so far. jacob -- From owner-linux-xfs@oss.sgi.com Tue Feb 26 20:35:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R4Z4b25225 for linux-xfs-outgoing; Tue, 26 Feb 2002 20:35:04 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R4Z0925203 for ; Tue, 26 Feb 2002 20:35:00 -0800 Received: (qmail 1613 invoked from network); 27 Feb 2002 03:36:02 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 27 Feb 2002 03:36:02 -0000 Date: Tue, 26 Feb 2002 22:36:02 -0500 (EST) From: Shawn Starr To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm told there's a suse patch with XFS + quota? ftp://ftp.suse.com/pub/people/mantel Im going to try this one out. Shawn. On Tue, 26 Feb 2002, Shawn Starr wrote: > > Well, I got it to build but I can't mount the drive ;-) > > VFS panic's on trying to mount the disk. I suspect the struct super_block > or so broke XFS? > > Shawn. > > > > > From owner-linux-xfs@oss.sgi.com Tue Feb 26 21:39:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R5d8L26282 for linux-xfs-outgoing; Tue, 26 Feb 2002 21:39:08 -0800 Received: from mta2-rme.xtra.co.nz (mta2-rme.xtra.co.nz [210.86.15.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R5d4926255 for ; Tue, 26 Feb 2002 21:39:05 -0800 Received: from localhost.localdomain ([210.86.52.163]) by mta2-rme.xtra.co.nz with ESMTP id <20020227043729.CRAZ12697.mta2-rme.xtra.co.nz@localhost.localdomain>; Wed, 27 Feb 2002 17:37:29 +1300 Subject: Re: XFS with a few patches From: mdew To: jacob berkman Cc: xfs In-Reply-To: <1014780772.1669.1.camel@wet-pants> References: <1014730581.4135.7.camel@mdew> <1014780772.1669.1.camel@wet-pants> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 05:50:29 +1300 Message-Id: <1014742229.4135.16.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-27 at 16:32, jacob berkman wrote: > On Tue, 2002-02-26 at 08:36, mdew wrote: > > > > > > Has anyone succesully used XFS 2.4.18 with AA+0(1) Scheduler+Preemptive? > > i've been using these for a while and it's been quite nice so far. > > jacob > -- In what order do you apply the patches? From owner-linux-xfs@oss.sgi.com Tue Feb 26 21:43:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R5hFO26445 for linux-xfs-outgoing; Tue, 26 Feb 2002 21:43:15 -0800 Received: from localhost.localdomain (209-6-26-174.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com [209.6.26.174]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R5hB926420 for ; Tue, 26 Feb 2002 21:43:11 -0800 Received: (from jacob@localhost) by localhost.localdomain (8.11.6/8.11.6) id g1R4h1N02278; Tue, 26 Feb 2002 23:43:01 -0500 X-Authentication-Warning: localhost.localdomain: jacob set sender to jacob@ximian.com using -f Subject: Re: XFS with a few patches From: jacob berkman To: mdew Cc: xfs In-Reply-To: <1014742229.4135.16.camel@mdew> References: <1014730581.4135.7.camel@mdew> <1014780772.1669.1.camel@wet-pants> <1014742229.4135.16.camel@mdew> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 23:43:00 -0500 Message-Id: <1014784980.1669.7.camel@wet-pants> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-02-26 at 11:50, mdew wrote: > On Wed, 2002-02-27 at 16:32, jacob berkman wrote: > > On Tue, 2002-02-26 at 08:36, mdew wrote: > > > > > > > > > Has anyone succesully used XFS 2.4.18 with AA+0(1) Scheduler+Preemptive? > > > > i've been using these for a while and it's been quite nice so far. > > In what order do you apply the patches? starting with 2.4.17: 2.4.18-pre9 -split-kernel -split-only acpi-20020214 sched-01 preempt-kernel although i don't really remember - it's been a couple of weeks. jacob -- From owner-linux-xfs@oss.sgi.com Tue Feb 26 21:59:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R5xMd26967 for linux-xfs-outgoing; Tue, 26 Feb 2002 21:59:22 -0800 Received: from mta2-rme.xtra.co.nz (210-86-15-130.ipnets.xtra.co.nz [210.86.15.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R5xD926944 for ; Tue, 26 Feb 2002 21:59:13 -0800 Received: from localhost.localdomain ([210.86.52.163]) by mta2-rme.xtra.co.nz with ESMTP id <20020227045739.DABR12697.mta2-rme.xtra.co.nz@localhost.localdomain>; Wed, 27 Feb 2002 17:57:39 +1300 Subject: Re: XFS with a few patches From: mdew To: jacob berkman Cc: xfs In-Reply-To: <1014784980.1669.7.camel@wet-pants> References: <1014730581.4135.7.camel@mdew> <1014780772.1669.1.camel@wet-pants> <1014742229.4135.16.camel@mdew> <1014784980.1669.7.camel@wet-pants> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 06:10:38 +1300 Message-Id: <1014743439.4136.23.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is from the (0)1 Scheduler.. Its not patching at all (obviously) ..used for pre8 ..no rc4 version --- linux/include/asm-i386/hw_irq.h.orig Tue Feb 5 13:51:40 2002 +++ linux/include/asm-i386/hw_irq.h Tue Feb 5 13:52:12 2002 @@ -41,7 +41,8 @@ #define ERROR_APIC_VECTOR 0xfe #define INVALIDATE_TLB_VECTOR 0xfd #define RESCHEDULE_VECTOR 0xfc -#define CALL_FUNCTION_VECTOR 0xfb +#define TASK_MIGRATION_VECTOR 0xfb +#define CALL_FUNCTION_VECTOR 0xfa Off 2.4-XFS (CVS) linux/include/asm-i386/hw_irq.h /* * Special IRQ vectors used by the SMP architecture, 0xf0-0xff * * some of the following vectors are 'rare', they are merged * into a single vector (CALL_FUNCTION_VECTOR) to save vector space. * TLB, reschedule and local APIC vectors are performance-critical. * * Vectors 0xf0-0xfa are free (reserved for future Linux use). */ #define SPURIOUS_APIC_VECTOR 0xff #define ERROR_APIC_VECTOR 0xfe #define INVALIDATE_TLB_VECTOR 0xfd #define RESCHEDULE_VECTOR 0xfc #define CALL_FUNCTION_VECTOR 0xfb #define KDB_VECTOR 0xfa Something must of happened between pre8->rc4..if I was gonna patch it by hand, what would I remove/add? Or just wait for Ingo's new patch? On Wed, 2002-02-27 at 17:43, jacob berkman wrote: > On Tue, 2002-02-26 at 11:50, mdew wrote: > > On Wed, 2002-02-27 at 16:32, jacob berkman wrote: > > > On Tue, 2002-02-26 at 08:36, mdew wrote: > > > > > > > > > > > > Has anyone succesully used XFS 2.4.18 with AA+0(1) Scheduler+Preemptive? > > > > > > i've been using these for a while and it's been quite nice so far. > > > > In what order do you apply the patches? > > starting with 2.4.17: > 2.4.18-pre9 > -split-kernel > -split-only > acpi-20020214 > sched-01 > preempt-kernel > > although i don't really remember - it's been a couple of weeks. > > jacob > -- From owner-linux-xfs@oss.sgi.com Tue Feb 26 22:11:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R6BUr27285 for linux-xfs-outgoing; Tue, 26 Feb 2002 22:11:30 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R6BO927260 for ; Tue, 26 Feb 2002 22:11:24 -0800 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 VAA07787 for ; Tue, 26 Feb 2002 21:06:57 -0800 (PST) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g1R5ALK32892419; Tue, 26 Feb 2002 21:10:22 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 1FE3C3000B8; Wed, 27 Feb 2002 15:10:19 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id D9E698E; Wed, 27 Feb 2002 16:10:19 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: mdew Cc: jacob berkman , xfs Subject: Re: XFS with a few patches In-reply-to: Your message of "27 Feb 2002 06:10:38 +1300." <1014743439.4136.23.camel@mdew> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Feb 2002 16:10:14 +1100 Message-ID: <5372.1014786614@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 27 Feb 2002 06:10:38 +1300, mdew wrote: >This is from the (0)1 Scheduler.. Its not patching at all (obviously) >..used for pre8 ..no rc4 version > >--- linux/include/asm-i386/hw_irq.h.orig Tue Feb 5 13:51:40 2002 >+++ linux/include/asm-i386/hw_irq.h Tue Feb 5 13:52:12 2002 >@@ -41,7 +41,8 @@ > #define ERROR_APIC_VECTOR 0xfe > #define INVALIDATE_TLB_VECTOR 0xfd > #define RESCHEDULE_VECTOR 0xfc >-#define CALL_FUNCTION_VECTOR 0xfb >+#define TASK_MIGRATION_VECTOR 0xfb >+#define CALL_FUNCTION_VECTOR 0xfa > >Off 2.4-XFS (CVS) linux/include/asm-i386/hw_irq.h > >/* > * Special IRQ vectors used by the SMP architecture, 0xf0-0xff > * > * some of the following vectors are 'rare', they are merged > * into a single vector (CALL_FUNCTION_VECTOR) to save vector space. > * TLB, reschedule and local APIC vectors are performance-critical. > * > * Vectors 0xf0-0xfa are free (reserved for future Linux use). > */ >#define SPURIOUS_APIC_VECTOR 0xff >#define ERROR_APIC_VECTOR 0xfe >#define INVALIDATE_TLB_VECTOR 0xfd >#define RESCHEDULE_VECTOR 0xfc >#define CALL_FUNCTION_VECTOR 0xfb >#define KDB_VECTOR 0xfa > >Something must of happened between pre8->rc4..if I was gonna patch it by >hand, what would I remove/add? Or just wait for Ingo's new patch? Both O(1) and kdb are patching the list of vectors and are in conflict. A composite list that looks like this should do the job. #define INVALIDATE_TLB_VECTOR 0xfd #define RESCHEDULE_VECTOR 0xfc #define TASK_MIGRATION_VECTOR 0xfb #define CALL_FUNCTION_VECTOR 0xfa #define KDB_VECTOR 0xf9 From owner-linux-xfs@oss.sgi.com Wed Feb 27 00:38:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R8chp29532 for linux-xfs-outgoing; Wed, 27 Feb 2002 00:38:43 -0800 Received: from ledzep.dyndns.org (12-237-133-3.client.attbi.com [12.237.133.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R8cX929509 for ; Wed, 27 Feb 2002 00:38:33 -0800 Received: from attbi.com (IDENT:mXac4yerXBwFhBbkCngr9Q76rs8EQ0FN@localhost [127.0.0.1]) by ledzep.dyndns.org (8.11.6/8.11.6) with ESMTP id g1R4RXB19837 for ; Tue, 26 Feb 2002 22:27:34 -0600 Message-ID: <3C7C6035.DA9B2D3@attbi.com> Date: Tue, 26 Feb 2002 22:27:33 -0600 From: Jordan Breeding Organization: University of Texas at Dallas - Student X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.5-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Problems using linux-2.5.6-pre1 with a current CVS pull... Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Today I decided to upgrade my XFS kernel up to the 2.5.6-pre1 patch when it came out. I created a tree with 2.5.6-pre1 first, then updated my xfs tree and then executed the following: ln -s linux-2.5-xfs/linux linux-2.5.5-xfs diff -urN linux-2.5.5-original linux-2.5.5-xfs | patch -p1 -d/usr/src/linux I only got around four rejects which were all very trivial excerpts which I fixed by hand. However, when I try and do a `make bzImage` here is the error I get: --begin snip-- gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char -DKBUILD_BASENAME=xfs_iget -c -o xfs_iget.o xfs_iget.c gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char -DKBUILD_BASENAME=xfs_inode -c -o xfs_inode.o xfs_inode.c gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char -DKBUILD_BASENAME=xfs_inode_item -c -o xfs_inode_item.o xfs_inode_item.c gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char -DKBUILD_BASENAME=xfs_iocore -c -o xfs_iocore.o xfs_iocore.c gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char -DKBUILD_BASENAME=xfs_itable -c -o xfs_itable.o xfs_itable.c gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char -DKBUILD_BASENAME=xfs_dfrag -c -o xfs_dfrag.o xfs_dfrag.c xfs_dfrag.c: In function `xfs_swapext': xfs_dfrag.c:226: invalid operands to binary != xfs_dfrag.c:226: invalid operands to binary != make[3]: *** [xfs_dfrag.o] Error 1 make[3]: Leaving directory `/usr/src/linux/fs/xfs' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux/fs' make: *** [_dir_fs] Error 2 --end snip-- And here is line 266 of fs/xfs/xfs_dfrag.c: --begin snip-- if (VN_MAPPED(vp)) { --end snip-- And VM_MAPPED can be found in fs/xfs/linux/xfs_vnode.h: --begin snip-- #define VN_MAPPED(vp) ((LINVFS_GET_IP(vp)->i_mapping->i_mmap != NULL) || \ (LINVFS_GET_IP(vp)->i_mapping->i_mmap_shared != NULL)) --end snip-- So....what is going on with the current CVS code, or is it just my kernel being incorrectly merged with xfs? Thanks for any help. Jordan P.S. - Please Cc: me on responses, thank you. From owner-linux-xfs@oss.sgi.com Wed Feb 27 01:59:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R9xn631804 for linux-xfs-outgoing; Wed, 27 Feb 2002 01:59:49 -0800 Received: from trouble.picotech.net (trouble.picotech.net [216.17.224.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1R9xi931778 for ; Wed, 27 Feb 2002 01:59:44 -0800 Received: (qmail 31680 invoked by uid 514); 27 Feb 2002 09:06:01 -0000 Received: from unknown (HELO jeffw) (192.168.100.2) by trouble.picotech.net with SMTP; 27 Feb 2002 09:06:01 -0000 From: "Jeffrey D. Means" To: "XFS" Subject: why does this not work?? Date: Wed, 27 Feb 2002 02:05:05 -0700 Message-ID: <006701c1bf6d$dbdc8f90$0264a8c0@jeffw> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [root@trouble www]# setfacl -s d:u::rwx,d:g::rx,d:o::---,d:u:scoth:rwx,d:u:meaje:rwx,d:mask:rwx paperstreet2 setfacl: paperstreet2: Resulting ACL `': Missing or wrong entry at entry 1 [root@trouble www]# I can not set default acls either by explicit command 'setfacl -s' I get the above message about being a wrong entry at 1, however if I enter the same command specifying the -m instead of -s it works, why?? ------------- Jeffrey D. Means CIO for PicoTech Ft. Collins, Colorado [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Feb 27 05:59:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RDxqL05041 for linux-xfs-outgoing; Wed, 27 Feb 2002 05:59:52 -0800 Received: from yog-sothoth.sgi.com ([192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RDsu904880 for ; Wed, 27 Feb 2002 05:56:42 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA763117 for ; Wed, 27 Feb 2002 13:55:16 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA00700; Wed, 27 Feb 2002 06:51:06 -0600 (CST) Received: from sgi.com (UTBoc9pLUQYiyxdzNwZOzdA+tJ6WJWMP@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA52845; Wed, 27 Feb 2002 06:51:05 -0600 (CST) Message-ID: <3C7CD695.2010902@sgi.com> Date: Wed, 27 Feb 2002 06:52:37 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Jordan Breeding CC: linux-xfs@oss.sgi.com Subject: Re: Problems using linux-2.5.6-pre1 with a current CVS pull... References: <3C7C6035.DA9B2D3@attbi.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jordan Breeding wrote: >Today I decided to upgrade my XFS kernel up to the 2.5.6-pre1 patch when >it came out. I created a tree with 2.5.6-pre1 first, then updated my >xfs tree and then executed the following: > >ln -s linux-2.5-xfs/linux linux-2.5.5-xfs >diff -urN linux-2.5.5-original linux-2.5.5-xfs | patch -p1 >-d/usr/src/linux > >I only got around four rejects which were all very trivial excerpts >which I fixed by hand. However, when I try and do a `make bzImage` here >is the error I get: > >--begin snip-- >gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer >-pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char >-DKBUILD_BASENAME=xfs_iget -c -o xfs_iget.o xfs_iget.c >gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer >-pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char >-DKBUILD_BASENAME=xfs_inode -c -o xfs_inode.o xfs_inode.c >gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer >-pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char >-DKBUILD_BASENAME=xfs_inode_item -c -o xfs_inode_item.o >xfs_inode_item.c >gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer >-pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char >-DKBUILD_BASENAME=xfs_iocore -c -o xfs_iocore.o xfs_iocore.c >gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer >-pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char >-DKBUILD_BASENAME=xfs_itable -c -o xfs_itable.o xfs_itable.c >gcc296 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer >-pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-redhat-linux7/2.96/include -I. -funsigned-char >-DKBUILD_BASENAME=xfs_dfrag -c -o xfs_dfrag.o xfs_dfrag.c >xfs_dfrag.c: In function `xfs_swapext': >xfs_dfrag.c:226: invalid operands to binary != >xfs_dfrag.c:226: invalid operands to binary != >make[3]: *** [xfs_dfrag.o] Error 1 >make[3]: Leaving directory `/usr/src/linux/fs/xfs' >make[2]: *** [first_rule] Error 2 >make[2]: Leaving directory `/usr/src/linux/fs/xfs' >make[1]: *** [_subdir_xfs] Error 2 >make[1]: Leaving directory `/usr/src/linux/fs' >make: *** [_dir_fs] Error 2 >--end snip-- > >And here is line 266 of fs/xfs/xfs_dfrag.c: > >--begin snip-- >if (VN_MAPPED(vp)) { >--end snip-- > >And VM_MAPPED can be found in fs/xfs/linux/xfs_vnode.h: > >--begin snip-- >#define VN_MAPPED(vp) ((LINVFS_GET_IP(vp)->i_mapping->i_mmap != NULL) >|| \ > (LINVFS_GET_IP(vp)->i_mapping->i_mmap_shared != >NULL)) >--end snip-- > >So....what is going on with the current CVS code, or is it just my >kernel being incorrectly merged with xfs? Thanks for any help. > >Jordan > >P.S. - Please Cc: me on responses, thank you. > I have done a merge and built a kernel, not had a chance to boot it yet, maybe today. This was the one build error, it needs to use list_empty to check if these lists have entries or not now: #define VN_MAPPED(vp) \ (!list_empty(&(LINVFS_GET_IP(vp)->i_mapping->i_mmap)) || \ (!list_empty(&(LINVFS_GET_IP(vp)->i_mapping->i_mmap_shared)))) Steve p.s. Did the 2.5 bitkeeper tree move - if so were is it now? From owner-linux-xfs@oss.sgi.com Wed Feb 27 08:51:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RGp7q08659 for linux-xfs-outgoing; Wed, 27 Feb 2002 08:51:07 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RGmX908611 for ; Wed, 27 Feb 2002 08:50:19 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 HAA29186 for ; Wed, 27 Feb 2002 07:44:06 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA28349 for ; Wed, 27 Feb 2002 09:47:17 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA13170 for ; Wed, 27 Feb 2002 09:47:17 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1RFhoF18333; Wed, 27 Feb 2002 09:43:50 -0600 Message-Id: <200202271543.g1RFhoF18333@jen.americas.sgi.com> Date: Wed, 27 Feb 2002 09:43:50 -0600 Subject: TAKE - merge up to 2.5.6-pre1 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Feb 27 07:42:15 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:112860a linux/drivers/net/e1000/e1000_phy.h - 1.1 linux/Documentation/arm/mem_alignment - 1.1 linux/drivers/net/e1000/e1000_main.c - 1.1 linux/drivers/net/e1000/LICENSE - 1.1 linux/Documentation/networking/3c359.txt - 1.1 linux/Documentation/networking/e1000.txt - 1.1 linux/drivers/net/e1000/Makefile - 1.1 linux/drivers/net/e1000/e1000_osdep.h - 1.1 linux/drivers/net/e1000/e1000.h - 1.1 linux/drivers/net/e1000/e1000_ethtool.c - 1.1 linux/drivers/net/e1000/e1000_mac.c - 1.1 linux/include/asm-arm/fpstate.h - 1.1 linux/drivers/net/e1000/e1000_mac.h - 1.1 linux/drivers/net/e1000/e1000_phy.c - 1.1 linux/drivers/isdn/hisax/hisax_hfcpci.c - 1.1 linux/drivers/net/tokenring/3c359_microcode.h - 1.1 linux/include/asm-arm/thread_info.h - 1.1 linux/drivers/net/tokenring/3c359.c - 1.1 linux/drivers/net/e1000/e1000_param.c - 1.1 linux/drivers/isdn/hisax/hisax_hfcpci.h - 1.1 linux/drivers/net/tokenring/3c359.h - 1.1 linux/drivers/net/e1000/e1000_proc.c - 1.1 linux/net/wanrouter/wanproc.c - 1.21 linux/net/wanrouter/wanmain.c - 1.16 linux/net/Makefile - 1.18 linux/mm/vmalloc.c - 1.35 linux/mm/mmap.c - 1.47 linux/mm/memory.c - 1.77 linux/mm/filemap.c - 1.111 linux/kernel/sched.c - 1.61 linux/kernel/ksyms.c - 1.136 linux/kernel/kmod.c - 1.19 linux/kernel/fork.c - 1.51 linux/kernel/exec_domain.c - 1.19 linux/init/main.c - 1.74 linux/include/linux/sched.h - 1.63 linux/include/linux/mm.h - 1.81 linux/include/linux/fs.h - 1.154 linux/include/linux/dcache.h - 1.22 linux/include/asm-i386/io.h - 1.24 linux/include/asm-i386/fixmap.h - 1.9 linux/include/asm-arm/unistd.h - 1.19 linux/include/asm-arm/uaccess.h - 1.10 linux/include/asm-arm/system.h - 1.16 linux/include/asm-arm/stat.h - 1.6 linux/include/asm-arm/softirq.h - 1.9 linux/include/asm-arm/smplock.h - 1.6 linux/include/asm-arm/processor.h - 1.22 linux/include/asm-arm/proc-armv/uaccess.h - 1.12 linux/include/asm-arm/proc-armv/processor.h - 1.9 linux/include/asm-arm/proc-armo/processor.h - 1.9 linux/include/asm-arm/mmu_context.h - 1.9 linux/include/asm-arm/hardirq.h - 1.11 linux/include/asm-arm/current.h - 1.6 linux/include/asm-arm/bitops.h - 1.10 linux/include/asm-arm/arch-ebsa285/keyboard.h - 1.6 linux/include/asm-alpha/system.h - 1.19 linux/include/asm-alpha/spinlock.h - 1.14 linux/include/asm-alpha/mmu_context.h - 1.13 linux/include/asm-alpha/bitops.h - 1.12 linux/fs/ufs/swab.h - 1.4 linux/fs/sysv/symlink.c - 1.9 linux/fs/super.c - 1.76 linux/fs/smbfs/proc.c - 1.16 linux/fs/smbfs/dir.c - 1.20 linux/fs/pipe.c - 1.27 linux/fs/nfsd/vfs.c - 1.47 linux/fs/nfsd/nfsfh.c - 1.36 linux/fs/nfsd/nfs3xdr.c - 1.25 linux/fs/nfsd/export.c - 1.28 linux/fs/nfs/dir.c - 1.36 linux/fs/ncpfs/dir.c - 1.29 linux/fs/locks.c - 1.23 linux/fs/inode.c - 1.66 linux/fs/fat/inode.c - 1.39 linux/fs/dcache.c - 1.33 linux/fs/bad_inode.c - 1.11 linux/fs/Makefile - 1.48 linux/drivers/video/imsttfb.c - 1.21 linux/drivers/usb/uhci.h - 1.27 linux/drivers/usb/uhci.c - 1.60 linux/drivers/usb/hub.c - 1.45 linux/drivers/scsi/u14-34f.h - 1.11 linux/drivers/scsi/u14-34f.c - 1.21 linux/drivers/scsi/sr.c - 1.39 linux/drivers/scsi/ppa.c - 1.14 linux/drivers/scsi/imm.c - 1.15 linux/drivers/scsi/eata.h - 1.10 linux/drivers/scsi/eata.c - 1.23 linux/drivers/scsi/NCR5380.h - 1.4 linux/drivers/scsi/NCR5380.c - 1.9 linux/drivers/scsi/Makefile - 1.34 linux/drivers/net/yellowfin.c - 1.31 linux/drivers/net/via-rhine.c - 1.34 linux/drivers/net/tlan.c - 1.25 linux/drivers/net/rcpci45.c - 1.22 linux/drivers/net/ne2k-pci.c - 1.23 linux/drivers/net/irda/Makefile - 1.16 linux/drivers/net/hamradio/Makefile - 1.9 linux/drivers/net/epic100.c - 1.28 linux/drivers/net/eepro100.c - 1.40 linux/drivers/net/defxx.c - 1.21 linux/drivers/net/Makefile - 1.54 linux/drivers/net/Config.in - 1.58 linux/drivers/net/3c59x.c - 1.33 linux/drivers/isdn/hisax/Makefile - 1.17 linux/drivers/isdn/avmb1/capi.c - 1.29 linux/drivers/isdn/Config.in - 1.23 linux/drivers/char/synclink.c - 1.22 linux/drivers/char/rtc.c - 1.26 linux/drivers/char/mem.c - 1.44 linux/drivers/char/Makefile - 1.55 linux/drivers/block/rd.c - 1.46 linux/drivers/block/ataflop.c - 1.19 linux/drivers/block/acsi.c - 1.25 linux/drivers/block/Makefile - 1.24 linux/drivers/acorn/net/ether3.c - 1.13 linux/drivers/acorn/net/ether1.c - 1.14 linux/drivers/acorn/block/mfmhd.c - 1.19 linux/drivers/Makefile - 1.30 linux/arch/i386/mm/ioremap.c - 1.11 linux/arch/i386/mm/init.c - 1.34 linux/arch/i386/kernel/traps.c - 1.49 linux/arch/i386/kernel/smp.c - 1.42 linux/arch/i386/kernel/setup.c - 1.70 linux/arch/i386/defconfig - 1.99 linux/arch/arm/kernel/traps.c - 1.24 linux/arch/arm/kernel/signal.c - 1.20 linux/arch/arm/kernel/setup.c - 1.25 linux/arch/arm/kernel/ptrace.c - 1.15 linux/arch/arm/kernel/process.c - 1.24 linux/arch/arm/kernel/init_task.c - 1.10 linux/arch/arm/kernel/entry-common.S - 1.19 linux/arch/arm/kernel/entry-armv.S - 1.24 linux/arch/arm/kernel/calls.S - 1.17 linux/arch/arm/kernel/armksyms.c - 1.22 linux/arch/arm/config.in - 1.34 linux/arch/alpha/kernel/proto.h - 1.18 linux/arch/alpha/kernel/process.c - 1.23 linux/arch/alpha/kernel/entry.S - 1.26 linux/arch/alpha/Makefile - 1.12 linux/Makefile - 1.187 linux/MAINTAINERS - 1.97 linux/Documentation/sound/AD1816 - 1.4 linux/Documentation/kbuild/config-language.txt - 1.9 linux/CREDITS - 1.74 linux/drivers/video/cyber2000fb.c - 1.28 linux/fs/file.c - 1.11 linux/include/asm-i386/hw_irq.h - 1.25 linux/drivers/pnp/isapnp.c - 1.26 linux/arch/i386/kernel/i8259.c - 1.26 linux/drivers/net/sis900.c - 1.31 linux/drivers/net/fc/Makefile - 1.4 linux/drivers/atm/eni.c - 1.14 linux/drivers/block/DAC960.h - 1.14 linux/drivers/scsi/ips.c - 1.24 linux/include/math-emu/op-4.h - 1.3 linux/fs/udf/dir.c - 1.17 linux/drivers/net/starfire.c - 1.24 linux/drivers/net/wan/Makefile - 1.13 linux/drivers/net/tokenring/olympic.c - 1.18 linux/drivers/net/tokenring/Makefile - 1.10 linux/drivers/net/tokenring/Config.in - 1.10 linux/include/linux/pci_ids.h - 1.59 linux/drivers/video/tdfxfb.c - 1.18 linux/drivers/pci/pci.ids - 1.42 linux/include/asm-arm/pgalloc.h - 1.8 linux/drivers/pcmcia/pci_socket.c - 1.10 linux/drivers/usb/ov511.h - 1.14 linux/drivers/usb/ov511.c - 1.33 linux/drivers/net/arcnet/com20020-pci.c - 1.11 linux/arch/arm/lib/csumpartial.S - 1.4 linux/arch/i386/kernel/apic.c - 1.27 linux/arch/arm/lib/strrchr.S - 1.5 linux/drivers/net/tokenring/tmspci.c - 1.7 linux/drivers/net/tokenring/abyss.c - 1.7 linux/drivers/usb/usb-uhci.c - 1.40 linux/drivers/usb/usb-ohci.c - 1.37 linux/arch/ia64/kernel/perfmon.c - 1.10 linux/include/linux/rtc.h - 1.6 linux/drivers/net/8139too.c - 1.36 linux/include/linux/lvm.h - 1.14 linux/drivers/net/ioc3-eth.c - 1.17 linux/drivers/video/riva/fbdev.c - 1.16 linux/drivers/ide/sl82c105.c - 1.6 linux/drivers/ide/hd.c - 1.18 linux/drivers/net/tokenring/lanstreamer.c - 1.10 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.21 linux/drivers/char/wdt_pci.c - 1.10 linux/include/asm-arm/arch-shark/keyboard.h - 1.6 linux/arch/alpha/kernel/core_titan.c - 1.5 linux/drivers/usb/storage/Makefile - 1.6 linux/arch/alpha/kernel/sys_titan.c - 1.4 linux/include/asm-arm/arch-sa1100/assabet.h - 1.8 linux/drivers/ieee1394/video1394.c - 1.18 linux/fs/xfs/linux/xfs_vnode.h - 1.28 linux/include/asm-arm/arch-sa1100/cerf.h - 1.4 linux/drivers/net/natsemi.c - 1.20 linux/drivers/media/video/zr36120.c - 1.13 linux/drivers/media/video/cpia.c - 1.12 linux/drivers/media/video/bttv-driver.c - 1.18 linux/Documentation/sound/NEWS - 1.2 linux/arch/arm/mach-sa1100/leds.c - 1.6 linux/drivers/block/cciss.c - 1.31 linux/drivers/net/hamachi.c - 1.14 linux/drivers/net/sundance.c - 1.15 linux/drivers/net/winbond-840.c - 1.16 linux/include/linux/dnotify.h - 1.4 linux/arch/i386/kernel/dmi_scan.c - 1.14 linux/mm/shmem.c - 1.31 linux/drivers/atm/firestream.c - 1.9 linux/fs/reiserfs/namei.c - 1.21 linux/fs/reiserfs/inode.c - 1.27 linux/arch/arm/boot/compressed/ofw-shark.c - 1.5 linux/include/asm-arm/arch-sa1100/pangolin.h - 1.3 linux/drivers/net/pci-skeleton.c - 1.11 linux/arch/arm/mach-integrator/pci_v3.c - 1.5 linux/arch/arm/tools/getconstants.c - 1.7 linux/drivers/net/sungem.c - 1.15 linux/drivers/media/radio/radio-maxiradio.c - 1.4 linux/drivers/net/fealnx.c - 1.12 linux/arch/arm/lib/csumpartialcopygeneric.S - 1.2 linux/drivers/usb/pwc-if.c - 1.13 linux/drivers/mtd/nftlcore.c - 1.10 linux/drivers/mtd/maps/sbc_gxx.c - 1.3 linux/drivers/mtd/maps/elan-104nc.c - 1.3 linux/drivers/net/wireless/airo.c - 1.13 linux/drivers/usb/se401.c - 1.10 linux/drivers/acorn/char/mouse_ps2.c - 1.3 linux/drivers/isdn/tpam/tpam_main.c - 1.5 linux/drivers/media/video/meye.c - 1.7 linux/drivers/parport/parport_serial.c - 1.6 linux/drivers/net/dl2k.c - 1.10 linux/drivers/media/radio/radio-gemtek-pci.c - 1.3 linux/drivers/char/drm/drm_vm.h - 1.11 linux/drivers/char/drm/drm_scatter.h - 1.5 linux/drivers/net/irda/vlsi_ir.c - 1.8 linux/drivers/net/wan/farsync.c - 1.5 linux/include/asm-arm/arch-anakin/ide.h - 1.2 linux/arch/arm/mach-sa1100/yopy.c - 1.3 linux/arch/arm/mach-sa1100/victor.c - 1.2 linux/arch/arm/mach-sa1100/simpad.c - 1.4 linux/arch/arm/mach-sa1100/sherman.c - 1.3 linux/arch/arm/mach-sa1100/sa1111-pcibuf.c - 1.3 linux/arch/arm/mach-sa1100/pleb.c - 1.2 linux/arch/arm/kernel/entry-header.S - 1.4 linux/arch/arm/mach-sa1100/pfs168.c - 1.4 linux/include/asm-arm/arch-anakin/uncompress.h - 1.2 linux/arch/arm/mach-sa1100/pangolin.c - 1.4 linux/arch/arm/mach-sa1100/omnimeter.c - 1.3 linux/arch/arm/mach-sa1100/nanoengine.c - 1.2 linux/arch/arm/mach-sa1100/leds-graphicsclient.c - 1.2 linux/arch/arm/mach-anakin/arch.c - 1.2 linux/arch/arm/mach-sa1100/irq.c - 1.3 linux/arch/arm/mach-sa1100/huw_webpanel.c - 1.3 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.5 linux/arch/arm/mach-sa1100/brutus.c - 1.2 linux/arch/arm/mach-sa1100/cerf.c - 1.4 linux/arch/arm/mach-sa1100/freebird.c - 1.4 linux/arch/arm/mach-sa1100/empeg.c - 1.2 linux/arch/arm/mach-sa1100/flexanet.c - 1.3 linux/drivers/video/radeonfb.c - 1.8 linux/drivers/usb/usbvideo.c - 1.9 linux/drivers/isdn/hisax/st5481_init.c - 1.3 linux/drivers/isdn/hisax/st5481_usb.c - 1.10 linux/drivers/net/ns83820.c - 1.9 linux/drivers/net/pcmcia/xircom_cb.c - 1.4 linux/drivers/ide/pdcraid.c - 1.8 linux/drivers/ide/hptraid.c - 1.7 linux/drivers/ide/ataraid.c - 1.7 linux/drivers/char/mwave/mwavedd.c - 1.4 linux/drivers/mtd/devices/blkmtd.c - 1.6 linux/drivers/net/wireless/orinoco_plx.c - 1.2 linux/arch/arm/mach-sa1100/leds-graphicsmaster.c - 1.2 linux/arch/arm/mach-sa1100/h3600.c - 1.4 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.4 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.3 linux/arch/arm/lib/putuser.S - 1.3 linux/arch/arm/lib/getuser.S - 1.3 linux/drivers/message/i2o/i2o_block.c - 1.11 linux/drivers/net/8139cp.c - 1.7 linux/arch/arm/mach-epxa10db/arch.c - 1.2 linux/arch/arm/mach-sa1100/leds-adsbitsy.c - 1.2 linux/include/asm-arm/arch-epxa10db/time.h - 1.3 linux/fs/intermezzo/kml_reint.c - 1.3 linux/fs/intermezzo/psdev.c - 1.6 linux/fs/sysv/ChangeLog - 1.8 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.4 linux/drivers/usb/stv680.c - 1.6 linux/drivers/usb/vicam.c - 1.7 linux/arch/arm/mach-iop310/arch.c - 1.2 linux/arch/arm/mm/alignment.c - 1.2 linux/arch/arm/mach-sa1100/system3.c - 1.2 linux/include/asm-arm/arch-adifcc/serial.h - 1.2 linux/arch/arm/mach-sa1100/leds-system3.c - 1.2 linux/include/asm-arm/arch-iop310/uncompress.h - 1.2 linux/include/asm-arm/arch-iop310/timex.h - 1.2 linux/include/asm-arm/arch-iop310/serial.h - 1.2 linux/include/asm-arm/arch-iop310/memory.h - 1.2 linux/arch/arm/mach-adifcc/arch.c - 1.2 linux/arch/arm/mach-adifcc/irq.c - 1.2 linux/arch/arm/mach-arc/arch.c - 1.2 linux/arch/arm/mach-clps711x/cdb89712.c - 1.2 linux/include/asm-arm/arch-iop310/irqs.h - 1.2 linux/arch/arm/mach-ftvpci/core.c - 1.2 linux/arch/arm/mach-iop310/iop310-irq.c - 1.2 linux/arch/arm/mach-iop310/iq80310-irq.c - 1.2 linux/arch/arm/mach-iop310/mm.c - 1.2 linux/arch/arm/mach-iop310/xs80200-irq.c - 1.2 linux/arch/arm/mach-l7200/core.c - 1.2 linux/include/asm-arm/arch-clps711x/memory.h - 1.2 linux/arch/arm/kernel/head.S - 1.2 linux/drivers/ieee1394/dv1394.c - 1.3 linux/drivers/net/wireless/netwave_cs.c - 1.2 linux/drivers/net/wireless/wavelan.c - 1.2 linux/drivers/net/wireless/wavelan.p.h - 1.2 linux/drivers/net/wireless/wavelan_cs.c - 1.3 linux/drivers/net/wireless/wavelan_cs.p.h - 1.2 linux/drivers/video/neofb.c - 1.4 linux/arch/arm/Config.help - 1.4 linux/drivers/usb/hcd/Config.help - 1.3 linux/drivers/isdn/Config.help - 1.3 linux/drivers/net/Config.help - 1.3 linux/drivers/net/pcmcia/Config.help - 1.3 linux/drivers/net/tokenring/Config.help - 1.2 linux/drivers/input/gameport/pcigame.c - 1.2 linux/drivers/input/gameport/emu10k1-gp.c - 1.2 linux/drivers/input/gameport/cs461x.c - 1.2 linux/Documentation/filesystems/porting - 1.3 linux/sound/synth/emux/emux_synth.c - 1.3 linux/sound/sound_core.c - 1.2 linux/sound/ppc/powermac.c - 1.2 linux/sound/ppc/keywest.c - 1.2 linux/sound/pci/ymfpci/ymfpci.c - 1.3 linux/sound/pci/via8233.c - 1.3 linux/sound/pci/via686.c - 1.3 linux/sound/pci/trident/trident.c - 1.3 linux/sound/pci/sonicvibes.c - 1.3 linux/sound/pci/rme9652/rme9652.c - 1.3 linux/sound/pci/rme96.c - 1.3 linux/sound/pci/nm256/nm256.c - 1.3 linux/sound/pci/maestro3.c - 1.3 linux/sound/pci/korg1212/korg1212.c - 1.3 linux/sound/pci/intel8x0.c - 1.3 linux/sound/pci/ice1712.c - 1.3 linux/sound/pci/fm801.c - 1.3 linux/sound/pci/es1968.c - 1.3 linux/sound/pci/es1938.c - 1.3 linux/sound/pci/ens1370.c - 1.3 linux/sound/pci/emu10k1/emuproc.c - 1.3 linux/sound/pci/emu10k1/emupcm.c - 1.3 linux/sound/pci/emu10k1/emumixer.c - 1.3 linux/sound/pci/emu10k1/emufx.c - 1.3 linux/sound/pci/emu10k1/emu10k1_main.c - 1.3 linux/sound/pci/emu10k1/emu10k1.c - 1.3 linux/sound/pci/cs46xx/cs46xx.c - 1.3 linux/sound/pci/cs4281.c - 1.3 linux/sound/pci/cmipci.c - 1.3 linux/sound/pci/als4000.c - 1.3 linux/sound/pci/ali5451/ali5451.c - 1.3 linux/sound/pci/ac97/ac97_codec.c - 1.3 linux/sound/oss/ymfpci.c - 1.2 linux/sound/oss/via82cxxx_audio.c - 1.2 linux/sound/oss/trident.c - 1.2 linux/sound/oss/sonicvibes.c - 1.2 linux/sound/oss/rme96xx.c - 1.2 linux/sound/oss/mpu401.c - 1.2 linux/sound/oss/i810_audio.c - 1.3 linux/sound/oss/emu10k1/main.c - 1.2 linux/sound/oss/cs4232.c - 1.2 linux/sound/oss/btaudio.c - 1.2 linux/sound/last.c - 1.3 linux/sound/isa/wavefront/wavefront.c - 1.3 linux/sound/isa/sgalaxy.c - 1.3 linux/sound/isa/sb/sb8.c - 1.3 linux/sound/isa/sb/sb16.c - 1.3 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.3 linux/sound/isa/opl3sa2.c - 1.3 linux/sound/isa/gus/interwave.c - 1.3 linux/sound/isa/gus/gusmax.c - 1.3 linux/sound/isa/gus/gusextreme.c - 1.3 linux/sound/isa/gus/gusclassic.c - 1.3 linux/sound/isa/es18xx.c - 1.3 linux/sound/isa/es1688/es1688.c - 1.3 linux/sound/isa/dt0197h.c - 1.3 linux/sound/isa/cs423x/cs4236.c - 1.3 linux/sound/isa/cs423x/cs4231_lib.c - 1.3 linux/sound/isa/cs423x/cs4231.c - 1.3 linux/sound/isa/cmi8330.c - 1.3 linux/sound/isa/azt2320.c - 1.3 linux/sound/isa/als100.c - 1.3 linux/sound/isa/ad1848/ad1848.c - 1.3 linux/sound/isa/ad1816a/ad1816a.c - 1.3 linux/sound/isa/Config.in - 1.3 linux/sound/drivers/virmidi.c - 1.3 linux/sound/drivers/serial-u16550.c - 1.3 linux/sound/drivers/mtpav.c - 1.3 linux/sound/drivers/mpu401/mpu401.c - 1.3 linux/sound/drivers/dummy.c - 1.3 linux/sound/core/timer.c - 1.3 linux/sound/core/sound.c - 1.3 linux/sound/core/seq/seq_virmidi.c - 1.3 linux/sound/core/seq/seq_timer.c - 1.3 linux/sound/core/seq/seq_ports.c - 1.3 linux/sound/core/seq/seq_memory.c - 1.3 linux/sound/core/seq/seq_lock.c - 1.2 linux/sound/core/seq/seq_instr.c - 1.3 linux/sound/core/seq/seq_dummy.c - 1.2 linux/sound/core/seq/seq_device.c - 1.3 linux/sound/core/seq/seq_clientmgr.c - 1.3 linux/sound/core/seq/oss/seq_oss_synth.c - 1.2 linux/sound/core/seq/oss/seq_oss_readq.c - 1.2 linux/sound/core/seq/oss/seq_oss_midi.c - 1.2 linux/sound/core/seq/oss/seq_oss_init.c - 1.2 linux/sound/core/seq/oss/seq_oss.c - 1.2 linux/sound/core/seq/instr/Makefile - 1.2 linux/sound/core/seq/Makefile - 1.2 linux/sound/core/rtctimer.c - 1.3 linux/sound/core/rawmidi.c - 1.3 linux/sound/core/pcm_native.c - 1.3 linux/sound/core/pcm_lib.c - 1.3 linux/sound/core/misc.c - 1.3 linux/sound/core/memory.c - 1.3 linux/sound/core/init.c - 1.3 linux/sound/core/info.c - 1.3 linux/sound/core/hwdep.c - 1.3 linux/sound/core/device.c - 1.3 linux/sound/core/control.c - 1.3 linux/sound/core/Makefile - 1.2 linux/sound/core/Config.in - 1.3 linux/sound/Makefile - 1.3 linux/include/sound/version.h - 1.3 linux/include/sound/emu10k1.h - 1.2 linux/include/sound/core.h - 1.3 linux/include/sound/asound.h - 1.3 linux/include/sound/ac97_codec.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:13:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHDbD09224 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:13:37 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHDU909201 for ; Wed, 27 Feb 2002 09:13:30 -0800 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 VAA07762 for ; Tue, 26 Feb 2002 21:06:11 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g1R59DK32924354 for ; Tue, 26 Feb 2002 21:09:13 -0800 (PST) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id GAA775316 for ; Wed, 27 Feb 2002 06:08:46 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA53975; Wed, 27 Feb 2002 16:05:03 +1100 (EST) Date: Wed, 27 Feb 2002 16:05:03 +1100 (EST) From: Nathan Scott Message-Id: <200202270505.QAA53975@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - Debian ACL packaging Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Feb 26 21:04:24 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:112845a acl/configure.in - 1.14 acl/Makefile - 1.8 acl/doc/CHANGES - 1.21 acl/debian/control - 1.6 acl/debian/Makefile - 1.5 acl/debian/copyright - 1.3 acl/debian/changelog - 1.11 acl/debian/rules - 1.7 - integrate the Debian packaging again. acl/libacl/acl_valid.c - 1.2 - fix a compiler warning - looks like the headers in several libacl source files suffer a similar problem, fix that up some other time. From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:17:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHHuG09504 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:17:56 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHHo909481 for ; Wed, 27 Feb 2002 09:17:50 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g1R2R2R16191; Tue, 26 Feb 2002 20:27:02 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: More "undefineded references" on CVS-sparc64 From: Alvaro Figueroa To: XFS to linux port mailing list Cc: Eric Sandeen Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 26 Feb 2002 20:27:02 -0600 Message-Id: <1014776822.15917.4.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hey guys, I've just solved the last undefined references on sparc64. The whole thing was, that this is a non-pci box, you at the second menu at "menuconfig", I take pci out of the picture. Since there are no sbus usb cards, the kernel automagically tries to take usb out, and therefore, the "input core" out. I read the .config file, and I found that the input core was still being defined. I've just recompile it and boot it and its ok. Tomorrow I'll deal with the userland tools and put some stress on it. Thanks for the help. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:33:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHXaF10027 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:33:36 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHXQ910004 for ; Wed, 27 Feb 2002 09:33:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1R4fSFH022588 for ; Tue, 26 Feb 2002 20:41:32 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20177; Wed, 27 Feb 2002 14:40:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA00011; Wed, 27 Feb 2002 14:40:11 +1100 (AEDT) Date: Wed, 27 Feb 2002 14:40:11 +1100 From: Nathan Scott To: Shawn Starr Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch Message-ID: <20020227144011.C193798@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spstarr@sh0n.net on Tue, Feb 26, 2002 at 10:36:02PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 26, 2002 at 10:36:02PM -0500, Shawn Starr wrote: > > I'm told there's a suse patch with XFS + quota? > ftp://ftp.suse.com/pub/people/mantel > > Im going to try this one out. > Shawn. > Ah - I didn't realise this was online somewhere. Yes, that should work - Hubert (Mantel), Jan and I were discussing this last week and he reported good success (showed me his merge & it looked fine). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:37:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHbM010195 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:37:22 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHb8910172 for ; Wed, 27 Feb 2002 09:37:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1R5YAFH023735 for ; Tue, 26 Feb 2002 21:34:12 -0800 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA24627; Wed, 27 Feb 2002 15:32:53 +1100 (EST) Date: Wed, 27 Feb 2002 15:32:53 +1100 (EST) From: Timothy Shimmin Message-Id: <200202270432.PAA24627@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@moses.parsec.at Subject: TAKE - cmd/acl-2.0.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Merging in most of Andreas' changes. Some more minor cleanup changes probably still to come. --Tim Date: Tue Feb 26 20:28:04 PST 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.18-xfs Modid: xfs-cmds-2.4.18:slinx:112840a cmd/acl/test/perm.test - 1.1 cmd/acl/examples/copy-acl.c - 1.1 cmd/acl/po/Makefile - 1.1 cmd/acl/test/asroot.test - 1.1 cmd/acl/examples/get-acl.c - 1.1 cmd/acl/test/fileutil.test - 1.1 cmd/acl/test/setfacl.test - 1.1 cmd/acl/examples/Makefile - 1.1 cmd/acl/examples/Makefile.examples - 1.1 cmd/acl/examples/README - 1.1 cmd/acl/examples/set-acl.c - 1.1 cmd/acl/test/misc.test - 1.1 cmd/acl/test/getfacl-noacl.test - 1.1 cmd/acl/test/setfacl-noacl.test - 1.1 cmd/acl/test/run - 1.1 cmd/acl/test/make-tree - 1.1 cmd/acl/test/mode - 1.1 cmd/acl/configure.in - 1.13 cmd/acl/install-sh - 1.7 cmd/acl/README - 1.5 cmd/acl/Makefile - 1.7 cmd/acl/VERSION - 1.18 cmd/acl/doc/CHANGES - 1.20 cmd/acl/man/man1/getfacl.1 - 1.4 cmd/acl/man/man1/setfacl.1 - 1.5 cmd/acl/man/man5/acl.5 - 1.9 cmd/acl/chacl/chacl.c - 1.10 cmd/acl/include/Makefile - 1.6 cmd/acl/include/libacl.h - 1.5 cmd/acl/include/acl.h - 1.12 cmd/acl/libacl/Makefile - 1.8 cmd/acl/test/stress/stress6 - 1.2 cmd/acl/test/stress/stress5 - 1.2 cmd/acl/test/stress/stress4 - 1.2 cmd/acl/test/stress/stress3 - 1.2 cmd/acl/test/stress/stress2 - 1.2 cmd/acl/test/stress/stress1 - 1.2 cmd/acl/test/stress/some.acl - 1.2 cmd/acl/test/stress/show - 1.2 cmd/acl/test/stress/lsloop - 1.2 cmd/acl/test/stress/loop6 - 1.2 cmd/acl/test/stress/loop5 - 1.2 cmd/acl/test/stress/loop4 - 1.2 cmd/acl/test/stress/loop3 - 1.2 cmd/acl/test/stress/loop2 - 1.2 cmd/acl/test/stress/loop1 - 1.2 cmd/acl/test/stress/do-n - 1.2 cmd/acl/test/src/setfacl.test - 1.2 cmd/acl/test/src/setfacl-noacl.test - 1.2 cmd/acl/test/src/run - 1.2 cmd/acl/test/src/prepare-tests - 1.2 cmd/acl/test/src/perm.test - 1.2 cmd/acl/test/src/mode - 1.2 cmd/acl/test/src/misc.test - 1.2 cmd/acl/test/src/getfacl-noacl.test - 1.2 cmd/acl/test/src/fileutil.test - 1.2 cmd/acl/test/src/echo_into - 1.2 cmd/acl/test/src/asroot.test - 1.2 cmd/acl/test/perf/make-tree - 1.2 cmd/acl/test/perf/TESTS - 1.2 cmd/acl/test/lib/text.c - 1.2 cmd/acl/test/lib/mem.expect - 1.2 cmd/acl/test/lib/mem.c - 1.2 cmd/acl/test/lib/check.h - 1.2 cmd/acl/test/lib/byteorder.c - 1.2 cmd/acl/test/block - 1.2 cmd/acl/test/acl.ea - 1.2 cmd/acl/setfacl/setfacl.c - 1.2 cmd/acl/setfacl/do_set.c - 1.2 cmd/acl/setfacl/Makefile - 1.3 cmd/acl/po/de.po - 1.2 cmd/acl/po/acl.pot - 1.2 cmd/acl/libacl/byteorder.h - 1.2 cmd/acl/libacl/acl_print.c - 1.3 cmd/acl/libacl/acl_from_text.c - 1.2 cmd/acl/libacl/acl_entry_to_any_str.c - 1.2 cmd/acl/libacl/acl_delete_def_file.c - 1.3 cmd/acl/getfacl/getfacl.c - 1.2 cmd/acl/include/config.h - 1.2 cmd/acl/include/acl_ea.h - 1.2 cmd/acl/getfacl/showacl - 1.2 cmd/acl/getfacl/Makefile - 1.3 cmd/acl/doc/CREDITS - 1.2 cmd/acl/test/Makefile - 1.2 cmd/acl/test/lib/Makefile - 1.2 cmd/acl/test/perf/Makefile - 1.2 cmd/acl/test/src/Makefile - 1.2 cmd/acl/test/stress/Makefile - 1.2 cmd/acl/libacl/acl_delete_acc_file.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:41:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHfak10399 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:41:36 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHfX910377 for ; Wed, 27 Feb 2002 09:41:33 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g1RGfGt01587; Wed, 27 Feb 2002 17:41:16 +0100 Date: Wed, 27 Feb 2002 17:41:16 +0100 From: Christoph Hellwig To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch Message-ID: <20020227174116.B944@caldera.de> References: <20020227144011.C193798@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: <20020227144011.C193798@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Feb 27, 2002 at 02:40:11PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 02:40:11PM +1100, Nathan Scott wrote: > On Tue, Feb 26, 2002 at 10:36:02PM -0500, Shawn Starr wrote: > > > > I'm told there's a suse patch with XFS + quota? > > ftp://ftp.suse.com/pub/people/mantel > > > > Im going to try this one out. > > Shawn. > > > > Ah - I didn't realise this was online somewhere. Yes, that should > work - Hubert (Mantel), Jan and I were discussing this last week and > he reported good success (showed me his merge & it looked fine). What about just including new-quota in the XFS tree? From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:50:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHoeZ10778 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:50:40 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHoa910756 for ; Wed, 27 Feb 2002 09:50:36 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1R2W5hd020230 for ; Tue, 26 Feb 2002 18:32:06 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19854; Wed, 27 Feb 2002 13:30:43 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA98678; Wed, 27 Feb 2002 13:30:42 +1100 (AEDT) Date: Wed, 27 Feb 2002 13:30:42 +1100 From: Nathan Scott To: Shawn Starr Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch Message-ID: <20020227133042.B193798@wobbly.melbourne.sgi.com> References: <20020226172010.M193798@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spstarr@sh0n.net on Tue, Feb 26, 2002 at 09:19:49PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Feb 26, 2002 at 09:19:49PM -0500, Shawn Starr wrote: > > Well, I got it to build but I can't mount the drive ;-) > > VFS panic's on trying to mount the disk. I suspect the struct super_block > or so broke XFS? send me your fs/dquot.c, fs/quota.c, & include/linux/fs.h. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:53:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHrlk11041 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:53:47 -0800 Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHrR911017 for ; Wed, 27 Feb 2002 09:53:27 -0800 Received: from there (pool2149.studentenheim.uni-tuebingen.de [134.2.212.149]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id PAA03827 for ; Wed, 27 Feb 2002 15:52:46 +0100 (MET) Message-Id: <200202271452.PAA03827@post.webmailer.de> Content-Type: text/plain; charset="iso-8859-1" From: Simon Pabst Reply-To: elros@numenor.de To: "linux-xfs@oss.sgi.com" Subject: again: xfs/lvm problem, disappearing files Date: Wed, 27 Feb 2002 15:51:35 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I got the problem I reportet yesterday again, while writing to a samba-mounted xfs-lvm volume (/fs3) (this time vmware-win2k, yesterday real win2k). I was writing files to /fs3/scr/dc which is now reported empty: root@judicator:/fs3/scr > ls -la /fs3/scr/dc total 0 the client process on windows is happily writing to this folder while I did the ls. Also in the parent directory /fs3/scr/ one of my backup-directories "chimaera_backups" is missing (didn't even touch it for days): root@judicator:/fs3/scr > ls -la /fs3/scr ls: /fs3/scr/chimaera_backups: No such file or directory total 16 drwxrwxrwt 7 root root 88 Feb 25 00:56 . drwxr-xr-x 5 root root 46 Feb 8 18:19 .. drwxrwx--- 11 thrawn thrawn 4096 Feb 27 13:54 dc drwxr-xr-x 6 root root 75 Feb 17 20:06 judicator_backups drwxrwx--- 7 thrawn thrawn 4096 Feb 26 15:50 old_dc drwxrwsrwt 3 thrawn admin 4096 Feb 27 13:20 upload I had this "no such file or directory" problem with reiserfs a year ago, while writing to nfs shares. Running xfs_repair -n after umount /fs3 gives me root@judicator:/ > xfs_repair -n /dev/vg02/lvol1 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ........................................................................................................... I abortet this and did a reboot. Now xfs_repair -n shows no errors at all, and root@judicator:/ > xfs_repair /dev/vg02/lvol1 xfs_repair: warning - cannot set blocksize on block device /dev/vg02/lvol1: Invalid argument Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 18376471, moving to lost+found disconnected dir inode 18800263, moving to lost+found disconnected dir inode 117385730, moving to lost+found disconnected dir inode 275899789, moving to lost+found disconnected dir inode 310212310, moving to lost+found disconnected dir inode 402676446, moving to lost+found disconnected dir inode 506154388, moving to lost+found Phase 7 - verify and correct link counts... done I get some empty folders in lost+found, and some files that were from completely different parts of the directory structure (not /fs3/scr/ where I was writing) apart from those files nothing in /fs3/scr seems to be missing, but the files that were written last seem to be corrupted. I'm afraid it is still the "ancient" RH-2.4.9-13 kernel, haven't had time to upgrade (BTW oss.sgi.com seems down for me). same as yesterday: athlon 900, 512mb mount options: /dev/vg02/lvol1 /fs3 xfs defaults,noatime,nodiratime,logbufs=4 1 2 vg02/lvol1 is a 2-disk stripeset using 2 maxtor 80gb ide drives /var/log/messages did not show any xfs-related information any clues would be highly appreciated thanks -simon pabst From owner-linux-xfs@oss.sgi.com Wed Feb 27 09:53:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RHrtR11162 for linux-xfs-outgoing; Wed, 27 Feb 2002 09:53:55 -0800 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RHri911040 for ; Wed, 27 Feb 2002 09:53:45 -0800 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id 61CCB2C1B7; Wed, 27 Feb 2002 19:53:28 +0300 (MSK) Received: from andy by an.local with local (Exim 3.34 #1 (Debian)) id 16g7Ka-0004gX-00; Wed, 27 Feb 2002 19:53:28 +0300 Date: Wed, 27 Feb 2002 19:53:28 +0300 From: Andrey Nekrasov To: Nathan Scott Cc: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: Re: TAKE - Debian ACL packaging Message-ID: <20020227165328.GA18007@an.local> Mail-Followup-To: Nathan Scott , linux-xfs@oss.sgi.com, ag@bestbits.at References: <200202270505.QAA53975@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200202270505.QAA53975@snort.melbourne.sgi.com> User-Agent: Mutt/1.3.27i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Nathan Scott, Debian Sid, gcc-2.95.4. ... gcc -O1 -g -DNDEBUG -funsigned-char -Wall -D_GNU_SOURCE -I../include -DVERSION=\"2.0.1\" -D_FILE_OFFSET_BITS=64 -D_REENTRANT -fno-strict-aliasing -c acl_valid.c -fPIC -DPIC -o .libs/acl_valid.lo In file included from acl_valid.c:23: ../include/acl/libacl.h:58: parse error before `*' acl_valid.c: In function `acl_valid': acl_valid.c:33: `NULL' undeclared (first use in this function) acl_valid.c:33: (Each undeclared identifier is reported only once acl_valid.c:33: for each function it appears in.) make[2]: *** [acl_valid.lo] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/cmd/acl' make: *** [built] Error 2 Once you wrote about "TAKE - Debian ACL packaging": > Date: Tue Feb 26 21:04:24 PST 2002 > Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/xfs-cmds > > > Modid: xfs-cmds:slinx:112845a > acl/configure.in - 1.14 > acl/Makefile - 1.8 > acl/doc/CHANGES - 1.21 > acl/debian/control - 1.6 > acl/debian/Makefile - 1.5 > acl/debian/copyright - 1.3 > acl/debian/changelog - 1.11 > acl/debian/rules - 1.7 > - integrate the Debian packaging again. > > acl/libacl/acl_valid.c - 1.2 > - fix a compiler warning - looks like the headers in several libacl > source files suffer a similar problem, fix that up some other time. > > -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Wed Feb 27 10:23:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RINu512067 for linux-xfs-outgoing; Wed, 27 Feb 2002 10:23:56 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RINr912045 for ; Wed, 27 Feb 2002 10:23:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAB04986 for ; Tue, 26 Feb 2002 20:44:37 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA16205 for linux-xfs@oss.sgi.com; Wed, 27 Feb 2002 15:43:16 +1100 (EST) Date: Wed, 27 Feb 2002 15:43:16 +1100 (EST) From: Nathan Scott Message-Id: <200202270443.PAA16205@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 2.4-xattr.patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Feb 26 20:42:08 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:112843a xfsmisc/README - 1.7 xfsmisc/2.4-xattr.patch - 1.1 - Patch (against 2.4.18) for Marcelo. We should wait a little while first so this code gets a beating in the XFS CVS tree, but several people have asked for this now, so here it is. From owner-linux-xfs@oss.sgi.com Wed Feb 27 11:28:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RJSrr13261 for linux-xfs-outgoing; Wed, 27 Feb 2002 11:28:53 -0800 Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RJSf913237 for ; Wed, 27 Feb 2002 11:28:41 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id 24D59C00436; Wed, 27 Feb 2002 10:28:36 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 1E164E0009B; Wed, 27 Feb 2002 10:28:36 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 10:28:35 -0800 Message-ID: From: "FORRESTER,JUSTIN (HP-Loveland,ex1)" To: "'Eric Sandeen'" , "'Steve Lord'" Cc: "DICKENS,CARY (HP-Loveland,ex2)" , "'Xfs \"Mailing List (E-mail)'" , "PATTERSON,ANDREW (HP-Loveland,ex2)" Subject: RE: oops umounting full LVM snapshots Date: Wed, 27 Feb 2002 10:28:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We were able to capture an oops yesterday (as opposed to the machine just locking up hard). Here's the oops that we got while umounting a full snapshot volume (lvm 1.0.2, kernel 2.4.17). Thanks, Justin invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 00000000 ebx: 00000002 ecx: f3bee6 edx: c03ff1ac esi: f3bee600 edi: c2defa00 ebp: f3c94080 esp: f2ecfd48 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 7235, stackpage=f4141000) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 3a 00 75 05 89 0a 89 49 24 8b 02 89 41 20 8b 02 8b >>EIP; c0135468 <__insert_into_lru_list+1c/5c> <===== Trace; c0135f5c <__refile_buffer+54/5c> Trace; c0135f7b Trace; c0135ebe <__mark_buffer_dirty+26/2c> Trace; c01da7eb Trace; c01dac0b <__pb_block_commit_write_async+47/4c> Trace; c01d9b80 Trace; c01dadc5 <__pagebuf_do_delwri+1b5/23c> Trace; c01daf87 <_pagebuf_file_write+13b/1f4> Trace; c01db103 Trace; c01dff8c Trace; c01e12c3 Trace; c01dff8c Trace; c01dc464 Trace; c0133f57 Trace; c0106d6f Code; c0135468 <__insert_into_lru_list+1c/5c> 00000000 <_EIP>: Code; c0135468 <__insert_into_lru_list+1c/5c> <===== 0: 0f 0b ud2a <===== Code; c013546a <__insert_into_lru_list+1e/5c> 2: 83 3a 00 cmpl $0x0,(%edx) Code; c013546d <__insert_into_lru_list+21/5c> 5: 75 05 jne c <_EIP+0xc> c0135474 <__insert_into_lru_list+28/5c> Code; c013546f <__insert_into_lru_list+23/5c> 7: 89 0a mov %ecx,(%edx) Code; c0135471 <__insert_into_lru_list+25/5c> 9: 89 49 24 mov %ecx,0x24(%ecx) Code; c0135474 <__insert_into_lru_list+28/5c> c: 8b 02 mov (%edx),%eax Code; c0135476 <__insert_into_lru_list+2a/5c> e: 89 41 20 mov %eax,0x20(%ecx) Code; c0135479 <__insert_into_lru_list+2d/5c> 11: 8b 02 mov (%edx),%eax Code; c013547b <__insert_into_lru_list+2f/5c> 13: 8b 00 mov (%eax),%eax > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Tuesday, February 26, 2002 5:34 PM > To: Steve Lord > Cc: DICKENS,CARY " "(HP-Loveland,ex2); Xfs "Mailing List (E-mail); > PATTERSON,ANDREW " "(HP-Loveland,ex2) > Subject: RE: oops umounting full LVM snapshots > > I'm starting to wonder, now... I patched the kernel to increase the > stack by 100% and I still get the oops. The patch also allows me to see > stack depth, and things look ok. > > FWIW, it's even simpler to show the problem, it's not necessary to > overflow the snapshot or even copy anything to them. Just create a > couple snapshot volumes, mount them, and unmount them. Unmounting the > first snapshot does a forced shutdown, unmounting the second one does a > force shutdown and then oopses. > > Just for kicks I created 2 dirty xfs filesystems and mounted them > ro,norecovery, and unmounted - so at least that works. > > So it looks like maybe with lvm, xfs is trying to do more log flushing > than it should on an ro filesystem, which generates the i/o error, which > shuts us down - not sure about the oops yet. I'm sure Steve will pipe > up if this theory is too far out of line. :) > > Still looking... > > -Eric > > > On Tue, 2002-02-26 at 14:11, Steve Lord wrote: > > > If it is stack overflow as we suspect then different drivers may push it > > over the edge in different ways. What we need to do is catch it in the > > act and see if there isn't something we can push off the stack. > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Feb 27 11:46:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RJkZa13660 for linux-xfs-outgoing; Wed, 27 Feb 2002 11:46:35 -0800 Received: from the-penguin.otak.com (mail@the-penguin.otak.com [216.122.56.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RJkU913638 for ; Wed, 27 Feb 2002 11:46:30 -0800 Received: from lawrence by the-penguin.otak.com with local (Exim 3.34 #1 (Debian)) id 16g94s-0000Cv-00; Wed, 27 Feb 2002 10:45:22 -0800 Date: Wed, 27 Feb 2002 10:45:22 -0800 From: Lawrence Walton To: "Jeffrey D. Means" Cc: XFS Subject: Re: why does this not work?? Message-ID: <20020227184522.GA4837@the-penguin.otak.com> References: <006701c1bf6d$dbdc8f90$0264a8c0@jeffw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006701c1bf6d$dbdc8f90$0264a8c0@jeffw> User-Agent: Mutt/1.3.27i X-Operating-System: Linux 2.4.18-pre9-ac4 on an i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jeffrey D. Means [meaje@picotech.net] wrote: > [root@trouble www]# setfacl -s > d:u::rwx,d:g::rx,d:o::---,d:u:scoth:rwx,d:u:meaje:rwx,d:mask:rwx > paperstreet2 > setfacl: paperstreet2: Resulting ACL `': Missing or wrong entry at entry > 1 > [root@trouble www]# I don't know why that syntax is different per se, but try this setfacl -dm u::rwx,g::r-x,o::---,u:scoth:rwx,u:meaje:rwx,m::rwx > > I can not set default acls either by explicit command 'setfacl -s' I get > the above message about being a wrong entry at 1, however if I enter the > same command specifying the -m instead of -s it works, why?? > > ------------- > Jeffrey D. Means > CIO for PicoTech > Ft. Collins, Colorado > > > > [[HTML alternate version deleted]] > -- *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://www.otak-k.com/~lawrence/ -------------------------------------- - - - - - - O t a k i n c . - - - - - From owner-linux-xfs@oss.sgi.com Wed Feb 27 12:22:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RKMYh16059 for linux-xfs-outgoing; Wed, 27 Feb 2002 12:22:34 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RKMU916037 for ; Wed, 27 Feb 2002 12:22:30 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id <13KKW1DR>; Wed, 27 Feb 2002 11:25:07 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F0C5@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'Eric Sandeen'" , Steve Lord Cc: "Xfs \"Mailing List (E-mail)" Subject: RE: oops umounting full LVM snapshots Date: Wed, 27 Feb 2002 11:25:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: [snip] > > FWIW, it's even simpler to show the problem, it's not necessary to > overflow the snapshot or even copy anything to them. Just create a > couple snapshot volumes, mount them, and unmount them. Unmounting the > first snapshot does a forced shutdown, unmounting the second > one does a > force shutdown and then oopses. > [snip] FWIW, I was able to oops by mounting/umounting snapshots using 2.4.16 with LVM 1.0.2. I was able to work around the problem by changing the snapshot to writeable (using a writeable snapshot patch)--that let the force shutdown do whatever it wanted to do to the "read only" file system, and no I/O error was returning. I was able to SOLVE the problem by using a different compiler. By compiling with kgcc instead of gcc 2.96, the mount/umount/mount/umount no longer created oops. The unmounting full LVM snapshot problem remained the same, however. With 2.4.17 and LVM 1.0.3 (and no other LVM/IDE/xfs patches), I can mount and unmount a snapshot ten times in succession without oops or forced shutdown--compiled with kgcc. I expect that with gcc I would see the behavior you describe. Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Wed Feb 27 13:30:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RLUCe17534 for linux-xfs-outgoing; Wed, 27 Feb 2002 13:30:12 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RLU8917512 for ; Wed, 27 Feb 2002 13:30:08 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08918 for ; Wed, 27 Feb 2002 12:31:39 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA32472; Wed, 27 Feb 2002 14:28:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA51433; Wed, 27 Feb 2002 14:28:51 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: "Stephenson, Dale" Cc: Steve Lord , "Xfs \ Mailing List (E-mail)" In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F0C5@cdserv.meridian-data.com> References: <2D0AFEFEE711D611923E009027D39F2B02F0C5@cdserv.meridian-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 14:28:51 -0600 Message-Id: <1014841731.31777.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-02-27 at 13:25, Stephenson, Dale wrote: > By compiling with kgcc instead of gcc 2.96, the > mount/umount/mount/umount no longer created oops. The unmounting full LVM > snapshot problem remained the same, however. I have a kgcc-compiled kernel that blows up on the snapshot mount/umount test... -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Feb 27 13:57:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RLvPF18145 for linux-xfs-outgoing; Wed, 27 Feb 2002 13:57:25 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RLtg918103 for ; Wed, 27 Feb 2002 13:55:42 -0800 Received: (qmail 3388 invoked from network); 27 Feb 2002 20:57:03 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 27 Feb 2002 20:57:03 -0000 Subject: Re: Quota & XFS patch From: Shawn Starr To: Shawn Starr Cc: Jan Kara , xfs In-Reply-To: <1014837395.3448.42.camel@unaropia> References: <20020227160938.GA22460@atrey.karlin.mff.cuni.cz> <1014837395.3448.42.camel@unaropia> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 27 Feb 2002 16:00:13 -0500 Message-Id: <1014843642.3529.45.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Why not merge into XFS CVS tree? On Wed, 2002-02-27 at 14:16, Shawn Starr wrote: > This is the latest one right? The one I see is 2.4.17-3 on the suse ftp > site. > > On Wed, 2002-02-27 at 11:09, Jan Kara wrote: > > Hello, > > > > I'm sending you Nathan's patch which implements things > > in quotactl interface needed for XFS. If you can remember > > the patch was already floating around some time > > ago and was generally accepted... Please apply (it will > > at least simplify patching of kernels for XFS). > > > > Honza > > ---- > > > > > diff -Naur 2.4.18-pre3-ac2/fs/Makefile 2.4.18-pre3-ac2-quotactl/fs/Makefile > > --- 2.4.18-pre3-ac2/fs/Makefile Tue Nov 13 04:34:16 2001 > > +++ 2.4.18-pre3-ac2-quotactl/fs/Makefile Wed Jan 23 14:31:36 2002 > > @@ -14,12 +14,10 @@ > > super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o \ > > fcntl.o ioctl.o readdir.o select.o fifo.o locks.o \ > > dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o \ > > - filesystems.o namespace.o seq_file.o > > + filesystems.o namespace.o seq_file.o quota.o > > > > ifeq ($(CONFIG_QUOTA),y) > > obj-y += dquot.o > > -else > > -obj-y += noquot.o > > endif > > > > subdir-$(CONFIG_PROC_FS) += proc > > diff -Naur 2.4.18-pre3-ac2/fs/dquot.c 2.4.18-pre3-ac2-quotactl/fs/dquot.c > > --- 2.4.18-pre3-ac2/fs/dquot.c Wed Jan 23 12:24:44 2002 > > +++ 2.4.18-pre3-ac2-quotactl/fs/dquot.c Wed Jan 23 14:25:17 2002 > > @@ -46,9 +46,12 @@ > > * Jan Kara 12/2000 > > * > > * New quotafile format > > - * Alocation units changed to bytes > > + * Allocation units changed to bytes > > * Jan Kara, , 2000 > > * > > + * Reworked the quotactl interface for filesystem-specific quota > > + * Nathan Scott and Jan Kara , 2001 > > + * > > * (C) Copyright 1994 - 1997 Marco van Wieringen > > */ > > > > @@ -65,6 +68,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -73,8 +77,6 @@ > > #define __DQUOT_NUM_VERSION__ (6*10000+5*100+0) > > #define __DQUOT_PARANOIA > > > > -int nr_dquots, nr_free_dquots; > > - > > static const char *quotatypes[] = INITQFNAMES; > > static const uint quota_magics[] = INITQMAGICS; > > static const uint quota_versions[] = INITQVERSIONS; > > @@ -1004,6 +1006,11 @@ > > return 0; > > } > > > > +static int quota_sync(struct super_block *sb, short type) > > +{ > > + return sync_dquots(sb->s_dev, type); > > +} > > + > > /* Free unused dquots from cache */ > > static void prune_dqcache(int count) > > { > > @@ -1466,35 +1473,30 @@ > > * Initialize a dquot-struct with new quota info. This is used by the > > * system call interface functions. > > */ > > -static int set_dqblk(struct super_block *sb, qid_t id, short type, int flags, struct mem_dqblk *dqblk) > > +static int set_dqblk(struct super_block *sb, short type, qid_t id, struct mem_dqblk *dqblk, int op) > > { > > struct dquot *dquot; > > - int error = -EFAULT; > > - struct mem_dqblk dq_dqblk; > > - > > - if (copy_from_user(&dq_dqblk, dqblk, sizeof(struct mem_dqblk))) > > - return error; > > > > - if (sb && (dquot = dqget(sb, id, type)) != NODQUOT) { > > + if ((dquot = dqget(sb, id, type)) != NODQUOT) { > > /* We can't block while changing quota structure... */ > > - if ((flags & SET_QUOTA) || (flags & SET_QLIMIT)) { > > - dquot->dq_bhardlimit = dq_dqblk.dqb_bhardlimit; > > - dquot->dq_bsoftlimit = dq_dqblk.dqb_bsoftlimit; > > - dquot->dq_ihardlimit = dq_dqblk.dqb_ihardlimit; > > - dquot->dq_isoftlimit = dq_dqblk.dqb_isoftlimit; > > + if (op == Q_SETQUOTA || op == Q_SETQLIM) { > > + dquot->dq_bhardlimit = dqblk->dqb_bhardlimit; > > + dquot->dq_bsoftlimit = dqblk->dqb_bsoftlimit; > > + dquot->dq_ihardlimit = dqblk->dqb_ihardlimit; > > + dquot->dq_isoftlimit = dqblk->dqb_isoftlimit; > > } > > > > - if ((flags & SET_QUOTA) || (flags & SET_USE)) { > > + if (op == Q_SETQUOTA || op == Q_SETUSE) { > > if (dquot->dq_isoftlimit && > > dquot->dq_curinodes < dquot->dq_isoftlimit && > > - dq_dqblk.dqb_curinodes >= dquot->dq_isoftlimit) > > + dqblk->dqb_curinodes >= dquot->dq_isoftlimit) > > dquot->dq_itime = CURRENT_TIME + (__kernel_time_t)(sb_dqopt(dquot->dq_sb)->info[type].dqi_igrace); > > - dquot->dq_curinodes = dq_dqblk.dqb_curinodes; > > + dquot->dq_curinodes = dqblk->dqb_curinodes; > > if (dquot->dq_bsoftlimit && > > toqb(dquot->dq_curspace) < dquot->dq_bsoftlimit && > > - toqb(dq_dqblk.dqb_curspace) >= dquot->dq_bsoftlimit) > > + toqb(dqblk->dqb_curspace) >= dquot->dq_bsoftlimit) > > dquot->dq_btime = CURRENT_TIME + (__kernel_time_t)(sb_dqopt(dquot->dq_sb)->info[type].dqi_bgrace); > > - dquot->dq_curspace = dq_dqblk.dqb_curspace; > > + dquot->dq_curspace = dqblk->dqb_curspace; > > } > > > > if (dquot->dq_curinodes < dquot->dq_isoftlimit || !dquot->dq_isoftlimit) { > > @@ -1506,8 +1508,8 @@ > > dquot->dq_flags &= ~DQ_BLKS; > > } > > > > - if (dq_dqblk.dqb_bhardlimit == 0 && dq_dqblk.dqb_bsoftlimit == 0 && > > - dq_dqblk.dqb_ihardlimit == 0 && dq_dqblk.dqb_isoftlimit == 0) > > + if (dqblk->dqb_bhardlimit == 0 && dqblk->dqb_bsoftlimit == 0 && > > + dqblk->dqb_ihardlimit == 0 && dqblk->dqb_isoftlimit == 0) > > dquot->dq_flags |= DQ_FAKE; > > else > > dquot->dq_flags &= ~DQ_FAKE; > > @@ -1518,79 +1520,86 @@ > > return 0; > > } > > > > -static int get_quota(struct super_block *sb, qid_t id, short type, struct mem_dqblk *dqblk) > > +static int get_dqblk(struct super_block *sb, short type, qid_t id, struct mem_dqblk *dqblk) > > { > > struct dquot *dquot; > > - struct mem_dqblk data; > > int error = -ESRCH; > > > > - if (!sb || !sb_has_quota_enabled(sb, type)) > > + if (!sb_has_quota_enabled(sb, type)) > > goto out; > > dquot = dqget(sb, id, type); > > if (dquot == NODQUOT) > > goto out; > > > > - memcpy(&data, &dquot->dq_dqb, sizeof(struct mem_dqblk)); /* We copy data to preserve them from changing */ > > + memcpy(dqblk, &dquot->dq_dqb, sizeof(struct mem_dqblk)); /* We copy data to preserve them from changing */ > > dqput(dquot); > > - error = -EFAULT; > > - if (dqblk && !copy_to_user(dqblk, &data, sizeof(struct mem_dqblk))) > > - error = 0; > > + error = 0; > > out: > > return error; > > } > > > > -static int get_stats(caddr_t addr) > > +#ifdef CONFIG_PROC_FS > > +static int read_stats(char *buffer, char **start, off_t offset, int count, int *eof, void *data) > > { > > - int error = -EFAULT; > > - struct dqstats stats; > > + int len; > > > > dqstats.allocated_dquots = nr_dquots; > > dqstats.free_dquots = nr_free_dquots; > > > > - /* make a copy, in case we page-fault in user space */ > > - memcpy(&stats, &dqstats, sizeof(struct dqstats)); > > - if (!copy_to_user(addr, &stats, sizeof(struct dqstats))) > > - error = 0; > > - return error; > > -} > > + len = sprintf(buffer, "Version %u\n", dqstats.version); > > + len += sprintf(buffer + len, "%u %u %u %u %u %u %u %u\n", > > + dqstats.lookups, dqstats.drops, > > + dqstats.reads, dqstats.writes, > > + dqstats.cache_hits, dqstats.allocated_dquots, > > + dqstats.free_dquots, dqstats.syncs); > > + > > + if (offset >= len) { > > + *start = buffer; > > + *eof = 1; > > + return 0; > > + } > > + *start = buffer + offset; > > + if ((len -= offset) > count) > > + return count; > > + *eof = 1; > > + > > + return len; > > +} > > +#define quota_proc_init() \ > > + create_proc_read_entry("fs/quota", 0, 0, read_stats, NULL); > > +#else > > +#define quota_proc_init() do { } while (0) > > +#endif > > > > -static int get_info(struct super_block *sb, short type, struct mem_dqinfo *pinfo) > > +static int get_info(struct super_block *sb, short type, struct mem_dqinfo *kinfo) > > { > > - struct mem_dqinfo kinfo; > > - > > - if (!sb || !sb_has_quota_enabled(sb, type)) > > + if (!sb_has_quota_enabled(sb, type)) > > return -ESRCH; > > /* Make our own copy so we can guarantee consistent structure */ > > - memcpy(&kinfo, sb_dqopt(sb)->info+type, sizeof(struct mem_dqinfo)); > > - kinfo.dqi_flags &= DQF_MASK; > > - if (copy_to_user(pinfo, &kinfo, sizeof(struct mem_dqinfo))) > > - return -EFAULT; > > + memcpy(kinfo, sb_dqopt(sb)->info+type, sizeof(struct mem_dqinfo)); > > + kinfo->dqi_flags &= DQF_MASK; > > return 0; > > } > > > > -static int set_info(int op, struct super_block *sb, short type, struct mem_dqinfo *pinfo) > > +static int set_info(struct super_block *sb, short type, struct mem_dqinfo *pinfo, int op) > > { > > - struct mem_dqinfo info; > > struct quota_info *dqopt = sb_dqopt(sb); > > > > - if (!sb || !sb_has_quota_enabled(sb, type)) > > + if (!sb_has_quota_enabled(sb, type)) > > return -ESRCH; > > > > - if (copy_from_user(&info, pinfo, sizeof(struct mem_dqinfo))) > > - return -EFAULT; > > - > > switch (op) { > > - case ISET_FLAGS: > > + case Q_SETFLAGS: > > dqopt->info[type].dqi_flags = (dqopt->info[type].dqi_flags & ~DQF_MASK) > > - | (info.dqi_flags & DQF_MASK); > > + | (pinfo->dqi_flags & DQF_MASK); > > break; > > - case ISET_GRACE: > > - dqopt->info[type].dqi_bgrace = info.dqi_bgrace; > > - dqopt->info[type].dqi_igrace = info.dqi_igrace; > > + case Q_SETGRACE: > > + dqopt->info[type].dqi_bgrace = pinfo->dqi_bgrace; > > + dqopt->info[type].dqi_igrace = pinfo->dqi_igrace; > > break; > > - case ISET_ALL: > > - info.dqi_flags &= ~DQF_MASK; > > - memcpy(dqopt->info + type, &info, sizeof(struct mem_dqinfo)); > > + case Q_SETINFO: > > + pinfo->dqi_flags &= ~DQF_MASK; > > + memcpy(dqopt->info + type, pinfo, sizeof(struct mem_dqinfo)); > > break; > > } > > mark_quotafile_info_dirty(dqopt->info + type); > > @@ -1875,6 +1884,7 @@ > > INIT_LIST_HEAD(dquot_hash + i); > > dqstats.version = __DQUOT_NUM_VERSION__; > > printk(KERN_NOTICE "VFS: Diskquotas version %s initialized\n", __DQUOT_VERSION__); > > + quota_proc_init(); > > return 0; > > } > > __initcall(dquot_init); > > @@ -1929,8 +1939,6 @@ > > struct quota_info *dqopt = sb_dqopt(sb); > > > > lock_kernel(); > > - if (!sb) > > - goto out; > > > > /* We need to serialize quota_off() for device */ > > down(&dqopt->dqoff_sem); > > @@ -1953,7 +1961,6 @@ > > fput(filp); > > } > > up(&dqopt->dqoff_sem); > > -out: > > unlock_kernel(); > > return 0; > > } > > @@ -2035,117 +2042,14 @@ > > } > > > > /* > > - * This is the system call interface. This communicates with > > - * the user-level programs. Currently this only supports diskquota > > - * calls. Maybe we need to add the process quotas etc. in the future, > > - * but we probably should use rlimits for that. > > + * Definitions of quota operations accessible through quotactl(2). > > */ > > -asmlinkage long sys_quotactl(int cmd, const char *special, qid_t id, __kernel_caddr_t addr) > > -{ > > - int cmds = 0, type = 0, flags = 0; > > - kdev_t dev; > > - struct super_block *sb = NULL; > > - int ret = -EINVAL; > > - > > - lock_kernel(); > > - cmds = cmd >> SUBCMDSHIFT; > > - type = cmd & SUBCMDMASK; > > - > > - if ((u_int) type >= MAXQUOTAS) > > - goto out; > > - if (id & ~0xFFFF) > > - goto out; > > - if ((uint) type >= MAXQUOTAS || cmds > 0x1100 || cmds < 0x100 || cmds == 0x0300 || > > - cmds == 0x0400 || cmds == 0x0500 || cmds == 0x1000) > > - goto out; > > - > > - ret = -EPERM; > > - switch (cmds) { > > - case Q_SYNC: > > - case Q_GETSTATS: > > - case Q_GETINFO: > > - break; > > - case Q_GETQUOTA: > > - if (((type == USRQUOTA && current->euid != id) || > > - (type == GRPQUOTA && !in_egroup_p(id))) && > > - !capable(CAP_SYS_ADMIN)) > > - goto out; > > - break; > > - default: > > - if (!capable(CAP_SYS_ADMIN)) > > - goto out; > > - } > > - > > - dev = NODEV; > > - if (special != NULL || (cmds != Q_SYNC && cmds != Q_GETSTATS)) { > > - mode_t mode; > > - struct nameidata nd; > > - > > - ret = user_path_walk(special, &nd); > > - if (ret) > > - goto out; > > - > > - dev = nd.dentry->d_inode->i_rdev; > > - mode = nd.dentry->d_inode->i_mode; > > - path_release(&nd); > > - > > - ret = -ENOTBLK; > > - if (!S_ISBLK(mode)) > > - goto out; > > - ret = -ENODEV; > > - sb = get_super(dev); > > - if (!sb) > > - goto out; > > - } > > - > > - ret = -EINVAL; > > - switch (cmds) { > > - case Q_QUOTAON: > > - ret = quota_on(sb, type, (char *) addr); > > - goto out; > > - case Q_QUOTAOFF: > > - ret = quota_off(sb, type); > > - goto out; > > - case Q_GETQUOTA: > > - ret = get_quota(sb, id, type, (struct mem_dqblk *) addr); > > - goto out; > > - case Q_SETQUOTA: > > - flags |= SET_QUOTA; > > - break; > > - case Q_SETUSE: > > - flags |= SET_USE; > > - break; > > - case Q_SETQLIM: > > - flags |= SET_QLIMIT; > > - break; > > - case Q_SYNC: > > - ret = sync_dquots(dev, type); > > - goto out; > > - case Q_GETSTATS: > > - ret = get_stats(addr); > > - goto out; > > - case Q_GETINFO: > > - ret = get_info(sb, type, (struct mem_dqinfo *) addr); > > - goto out; > > - case Q_SETFLAGS: > > - ret = set_info(ISET_FLAGS, sb, type, (struct mem_dqinfo *)addr); > > - goto out; > > - case Q_SETGRACE: > > - ret = set_info(ISET_GRACE, sb, type, (struct mem_dqinfo *)addr); > > - goto out; > > - case Q_SETINFO: > > - ret = set_info(ISET_ALL, sb, type, (struct mem_dqinfo *)addr); > > - goto out; > > - default: > > - goto out; > > - } > > - > > - ret = -NODEV; > > - if (sb && sb_has_quota_enabled(sb, type)) > > - ret = set_dqblk(sb, id, type, flags, (struct mem_dqblk *) addr); > > -out: > > - if (sb) > > - drop_super(sb); > > - unlock_kernel(); > > - return ret; > > -} > > +struct quota_operations generic_quota_ops = { > > + quotaon: quota_on, > > + quotaoff: quota_off, > > + quotasync: quota_sync, > > + getinfo: get_info, > > + setinfo: set_info, > > + getdqblk: get_dqblk, > > + setdqblk: set_dqblk, > > +}; > > diff -Naur 2.4.18-pre3-ac2/fs/noquot.c 2.4.18-pre3-ac2-quotactl/fs/noquot.c > > --- 2.4.18-pre3-ac2/fs/noquot.c Sat May 13 04:21:20 2000 > > +++ 2.4.18-pre3-ac2-quotactl/fs/noquot.c Thu Jan 1 10:00:00 1970 > > @@ -1,15 +0,0 @@ > > -/* noquot.c: Quota stubs necessary for when quotas are not > > - * compiled into the kernel. > > - */ > > - > > -#include > > -#include > > -#include > > - > > -int nr_dquots, nr_free_dquots; > > -int max_dquots; > > - > > -asmlinkage long sys_quotactl(int cmd, const char *special, int id, caddr_t addr) > > -{ > > - return(-ENOSYS); > > -} > > diff -Naur 2.4.18-pre3-ac2/fs/quota.c 2.4.18-pre3-ac2-quotactl/fs/quota.c > > --- 2.4.18-pre3-ac2/fs/quota.c Thu Jan 1 10:00:00 1970 > > +++ 2.4.18-pre3-ac2-quotactl/fs/quota.c Wed Jan 23 15:08:49 2002 > > @@ -0,0 +1,204 @@ > > +/* > > + * Quota code necessary even when VFS quota support is not compiled > > + * into the kernel. The interesting stuff is over in dquot.c, here > > + * we have symbols for initial quotactl(2) handling, the sysctl(2) > > + * variables, etc - things needed even when quota support disabled. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +int nr_dquots, nr_free_dquots; > > + > > +static struct super_block * > > +validate_quotactl(int cmd, int type, const char *special, qid_t id) > > +{ > > + int ret; > > + kdev_t dev; > > + mode_t mode; > > + struct nameidata nd; > > + struct super_block *sb; > > + > > + ret = -ENOSYS; > > + if (cmd == 0x0800 || cmd == 0x1100) /* both were Q_GETSTATS */ > > + goto error; > > + > > + /* version/compatibility stuff - needs to be early on in the piece */ > > + ret = -EINVAL; > > + if (cmd == 0x0300 || cmd == 0x0400 || cmd == 0x0500 || cmd == 0x1000 > > + || cmd < 0x100) > > + goto error; > > + if (type >= MAXQUOTAS) > > + goto error; > > + > > + ret = -EPERM; > > + switch (cmd) { > > + case Q_SYNC: > > + case Q_GETINFO: > > + case Q_XGETQSTAT: > > + break; > > + > > + case Q_GETQUOTA: > > + case Q_XGETQUOTA: > > + if (((type == USRQUOTA && current->euid != id) || > > + (type == GRPQUOTA && !in_egroup_p(id))) && > > + !capable(CAP_SYS_ADMIN)) > > + goto error; > > + > > + default: > > + if (!capable(CAP_SYS_ADMIN)) > > + goto error; > > + } > > + > > + ret = -ENODEV; > > + if (!special) > > + goto error; > > + ret = user_path_walk(special, &nd); > > + if (ret) > > + goto error; > > + > > + dev = nd.dentry->d_inode->i_rdev; > > + mode = nd.dentry->d_inode->i_mode; > > + path_release(&nd); > > + > > + ret = -ENOTBLK; > > + if (!S_ISBLK(mode)) > > + goto error; > > + > > + ret = -ENODEV; > > + sb = get_super(dev); > > + if (!sb) > > + goto error; > > + > > + ret = -ENOSYS; > > + if (!sb->s_qop) { > > + drop_super(sb); > > + goto error; > > + } > > + > > + return sb; > > +error: > > + return ERR_PTR(ret); > > +} > > + > > +asmlinkage long > > +sys_quotactl(int cmd, const char *special, qid_t id, __kernel_caddr_t addr) > > +{ > > + int ret, cmds, type; > > + struct super_block *sb; > > + union { > > + char *pathname; > > + unsigned int flags; > > + struct mem_dqblk mdq; > > + struct mem_dqinfo info; > > + struct fs_disk_quota fdq; > > + struct fs_quota_stat fqs; > > + } u; /* qualifies valid uses of "addr" */ > > + > > + lock_kernel(); > > + cmds = cmd >> SUBCMDSHIFT; > > + type = cmd & SUBCMDMASK; > > + > > + sb = validate_quotactl(cmds, type, special, id); > > + if (IS_ERR(sb)) { > > + unlock_kernel(); > > + return PTR_ERR(sb); > > + } > > + > > + ret = -EINVAL; > > + switch (cmds) { > > + case Q_QUOTAON: > > + u.pathname = (char *)addr; > > + if (sb->s_qop->quotaon) > > + ret = sb->s_qop->quotaon(sb, type, u.pathname); > > + break; > > + > > + case Q_QUOTAOFF: > > + if (sb->s_qop->quotaoff) > > + ret = sb->s_qop->quotaoff(sb, type); > > + break; > > + > > + case Q_SYNC: > > + if (sb->s_qop->quotasync) > > + ret = sb->s_qop->quotasync(sb, type); > > + break; > > + > > + case Q_GETINFO: > > + if (sb->s_qop->getinfo) > > + ret = sb->s_qop->getinfo(sb, type, &u.info); > > + if (!ret && copy_to_user(addr, &u.info, sizeof(u.info))) > > + ret = -EFAULT; > > + break; > > + > > + case Q_SETINFO: > > + case Q_SETFLAGS: > > + case Q_SETGRACE: > > + if (!sb->s_qop->setinfo) > > + break; > > + ret = -EFAULT; > > + if (copy_from_user(&u.info, addr, sizeof(u.info))) > > + break; > > + ret = sb->s_qop->setinfo(sb, type, &u.info, cmds); > > + break; > > + > > + case Q_GETQUOTA: > > + if (sb->s_qop->getdqblk) > > + ret = sb->s_qop->getdqblk(sb, type, id, &u.mdq); > > + if (!ret && copy_to_user(addr, &u.mdq, sizeof(u.mdq))) > > + ret = -EFAULT; > > + break; > > + > > + case Q_SETUSE: > > + case Q_SETQLIM: > > + case Q_SETQUOTA: > > + if (!sb->s_qop->setdqblk) > > + break; > > + ret = -EFAULT; > > + if (copy_from_user(&u.mdq, addr, sizeof(u.mdq))) > > + break; > > + ret = sb->s_qop->setdqblk(sb, type, id, &u.mdq, cmds); > > + break; > > + > > + case Q_XQUOTAON: > > + case Q_XQUOTAOFF: > > + case Q_XQUOTARM: > > + if (!sb->s_qop->setxstate) > > + break; > > + ret = -EFAULT; > > + if (copy_from_user(&u.flags, addr, sizeof(u.flags))) > > + break; > > + ret = sb->s_qop->setxstate(sb, u.flags, cmds); > > + break; > > + > > + case Q_XGETQSTAT: > > + if (sb->s_qop->getxstate) > > + ret = sb->s_qop->getxstate(sb, &u.fqs); > > + if (!ret && copy_to_user(addr, &u.fqs, sizeof(u.fqs))) > > + ret = -EFAULT; > > + break; > > + > > + case Q_XSETQLIM: > > + if (!sb->s_qop->setxquota) > > + break; > > + ret = -EFAULT; > > + if (copy_from_user(&u.fdq, addr, sizeof(u.fdq))) > > + break; > > + ret = sb->s_qop->setxquota(sb, type, id, &u.fdq); > > + break; > > + > > + case Q_XGETQUOTA: > > + if (sb->s_qop->getxquota) > > + ret = sb->s_qop->getxquota(sb, type, id, &u.fdq); > > + if (!ret && copy_to_user(addr, &u.fdq, sizeof(u.fdq))) > > + ret = -EFAULT; > > + break; > > + > > + default: > > + } > > + drop_super(sb); > > + unlock_kernel(); > > + return ret; > > +} > > diff -Naur 2.4.18-pre3-ac2/fs/super.c 2.4.18-pre3-ac2-quotactl/fs/super.c > > --- 2.4.18-pre3-ac2/fs/super.c Sat Dec 22 04:42:03 2001 > > +++ 2.4.18-pre3-ac2-quotactl/fs/super.c Wed Jan 23 12:26:41 2002 > > @@ -437,6 +437,7 @@ > > sema_init(&s->s_dquot.dqio_sem, 1); > > sema_init(&s->s_dquot.dqoff_sem, 1); > > s->s_maxbytes = MAX_NON_LFS; > > + s->s_qop = sb_generic_quota_ops; > > } > > return s; > > } > > diff -Naur 2.4.18-pre3-ac2/include/linux/fs.h 2.4.18-pre3-ac2-quotactl/include/linux/fs.h > > --- 2.4.18-pre3-ac2/include/linux/fs.h Wed Jan 23 12:24:44 2002 > > +++ 2.4.18-pre3-ac2-quotactl/include/linux/fs.h Wed Jan 23 14:50:06 2002 > > @@ -365,6 +365,7 @@ > > /* > > * Includes for diskquotas and mount structures. > > */ > > +#include > > #include > > #include > > > > @@ -691,6 +692,20 @@ > > struct mem_dqinfo info[MAXQUOTAS]; /* Information for each quota type */ > > }; > > > > +struct quota_operations { > > + int (*quotaon)(struct super_block *, short, char *); > > + int (*quotaoff)(struct super_block *, short); > > + int (*quotasync)(struct super_block *, short); > > + int (*getinfo)(struct super_block *, short, struct mem_dqinfo *); > > + int (*setinfo)(struct super_block *, short, struct mem_dqinfo *, int); > > + int (*getdqblk)(struct super_block *, short, qid_t, struct mem_dqblk *); > > + int (*setdqblk)(struct super_block *, short, qid_t, struct mem_dqblk *, int); > > + int (*getxstate)(struct super_block *, struct fs_quota_stat *); > > + int (*setxstate)(struct super_block *, unsigned int, int); > > + int (*getxquota)(struct super_block *, short, qid_t, struct fs_disk_quota *); > > + int (*setxquota)(struct super_block *, short, qid_t, struct fs_disk_quota *); > > +}; > > + > > /* > > * Umount options > > */ > > @@ -752,7 +767,8 @@ > > > > struct block_device *s_bdev; > > struct list_head s_instances; > > - struct quota_info s_dquot; /* Diskquota specific options */ > > + struct quota_info s_dquot; /* Diskquota specific options */ > > + struct quota_operations *s_qop; > > > > union { > > struct minix_sb_info minix_sb; > > diff -Naur 2.4.18-pre3-ac2/include/linux/quota.h 2.4.18-pre3-ac2-quotactl/include/linux/quota.h > > --- 2.4.18-pre3-ac2/include/linux/quota.h Wed Jan 23 12:24:44 2002 > > +++ 2.4.18-pre3-ac2-quotactl/include/linux/quota.h Wed Jan 23 14:43:51 2002 > > @@ -107,7 +107,7 @@ > > #define Q_SETQUOTA 0x0E00 /* set limits and usage */ > > #define Q_SETUSE 0x0F00 /* set usage */ > > /* 0x1000 used by old RSQUASH */ > > -#define Q_GETSTATS 0x1100 /* get collected stats */ > > +/* 0x1100 used by GETSTATS v2, since replaced by procfs entry */ > > > > /* > > * The following structure defines the format of the disk quota file > > @@ -255,13 +255,6 @@ > > #define dq_btime dq_dqb.dqb_btime > > > > /* > > - * Flags used for set_dqblk. > > - */ > > -#define SET_QUOTA 0x01 > > -#define SET_USE 0x02 > > -#define SET_QLIMIT 0x04 > > - > > -/* > > * Flags used for set_info > > */ > > #define ISET_GRACE 0x01 > > diff -Naur 2.4.18-pre3-ac2/include/linux/quotaops.h 2.4.18-pre3-ac2-quotactl/include/linux/quotaops.h > > --- 2.4.18-pre3-ac2/include/linux/quotaops.h Wed Jan 23 12:24:44 2002 > > +++ 2.4.18-pre3-ac2-quotactl/include/linux/quotaops.h Wed Jan 23 15:03:56 2002 > > @@ -17,6 +17,9 @@ > > > > #include > > > > +extern struct quota_operations generic_quota_ops; > > +#define sb_generic_quota_ops (&generic_quota_ops) > > + > > /* > > * declaration of quota_function calls in kernel. > > */ > > @@ -167,6 +170,7 @@ > > /* > > * NO-OP when quota not configured. > > */ > > +#define sb_generic_quota_ops (NULL) > > #define DQUOT_INIT(inode) do { } while(0) > > #define DQUOT_DROP(inode) do { } while(0) > > #define DQUOT_ALLOC_INODE(inode) (0) > > diff -Naur 2.4.18-pre3-ac2/include/linux/sysctl.h 2.4.18-pre3-ac2-quotactl/include/linux/sysctl.h > > --- 2.4.18-pre3-ac2/include/linux/sysctl.h Wed Jan 23 12:24:44 2002 > > +++ 2.4.18-pre3-ac2-quotactl/include/linux/sysctl.h Wed Jan 23 14:43:51 2002 > > @@ -533,7 +533,7 @@ > > FS_STATINODE=2, > > FS_MAXINODE=3, /* int:maximum number of inodes that can be allocated */ > > FS_NRDQUOT=4, /* int:current number of allocated dquots */ > > - FS_MAXDQUOT=5, /* int:maximum number of dquots that can be allocated */ > > + /* was FS_MAXDQUOT */ > > FS_NRFILE=6, /* int:current number of allocated filedescriptors */ > > FS_MAXFILE=7, /* int:maximum number of filedescriptors that can be allocated */ > > FS_DENTRY=8, > > diff -Naur 2.4.18-pre3-ac2/include/linux/xqm.h 2.4.18-pre3-ac2-quotactl/include/linux/xqm.h > > --- 2.4.18-pre3-ac2/include/linux/xqm.h Thu Jan 1 10:00:00 1970 > > +++ 2.4.18-pre3-ac2-quotactl/include/linux/xqm.h Wed Jan 23 14:43:51 2002 > > @@ -0,0 +1,159 @@ > > +/* > > + * Copyright (c) 1995-2001 Silicon Graphics, Inc. All Rights Reserved. > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms of version 2.1 of the GNU Lesser General Public License > > + * as published by the Free Software Foundation. > > + * > > + * This program is distributed in the hope that it would be useful, but > > + * WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > + * > > + * Further, this software is distributed without any warranty that it is > > + * free of the rightful claim of any third person regarding infringement > > + * or the like. Any license provided herein, whether implied or > > + * otherwise, applies only to this software file. Patent licenses, if > > + * any, provided herein do not apply to combinations of this program with > > + * other software, or any other product whatsoever. > > + * > > + * You should have received a copy of the GNU Lesser General Public > > + * License along with this program; if not, write the Free Software > > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, > > + * USA. > > + * > > + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, > > + * Mountain View, CA 94043, or: > > + * > > + * http://www.sgi.com > > + * > > + * For further information regarding this notice, see: > > + * > > + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ > > + */ > > +#ifndef _LINUX_XQM_H > > +#define _LINUX_XQM_H > > + > > +#include > > + > > +/* > > + * Disk quota - quotactl(2) commands for the XFS Quota Manager (XQM). > > + */ > > + > > +#define XQM_CMD(x) (('X'<<8)+(x)) /* note: forms first QCMD argument */ > > +#define Q_XQUOTAON XQM_CMD(0x1) /* enable accounting/enforcement */ > > +#define Q_XQUOTAOFF XQM_CMD(0x2) /* disable accounting/enforcement */ > > +#define Q_XGETQUOTA XQM_CMD(0x3) /* get disk limits and usage */ > > +#define Q_XSETQLIM XQM_CMD(0x4) /* set disk limits */ > > +#define Q_XGETQSTAT XQM_CMD(0x5) /* get quota subsystem status */ > > +#define Q_XQUOTARM XQM_CMD(0x6) /* free disk space used by dquots */ > > + > > +/* > > + * fs_disk_quota structure: > > + * > > + * This contains the current quota information regarding a user/proj/group. > > + * It is 64-bit aligned, and all the blk units are in BBs (Basic Blocks) of > > + * 512 bytes. > > + */ > > +#define FS_DQUOT_VERSION 1 /* fs_disk_quota.d_version */ > > +typedef struct fs_disk_quota { > > + __s8 d_version; /* version of this structure */ > > + __s8 d_flags; /* XFS_{USER,PROJ,GROUP}_QUOTA */ > > + __u16 d_fieldmask; /* field specifier */ > > + __u32 d_id; /* user, project, or group ID */ > > + __u64 d_blk_hardlimit;/* absolute limit on disk blks */ > > + __u64 d_blk_softlimit;/* preferred limit on disk blks */ > > + __u64 d_ino_hardlimit;/* maximum # allocated inodes */ > > + __u64 d_ino_softlimit;/* preferred inode limit */ > > + __u64 d_bcount; /* # disk blocks owned by the user */ > > + __u64 d_icount; /* # inodes owned by the user */ > > + __s32 d_itimer; /* zero if within inode limits */ > > + /* if not, we refuse service */ > > + __s32 d_btimer; /* similar to above; for disk blocks */ > > + __u16 d_iwarns; /* # warnings issued wrt num inodes */ > > + __u16 d_bwarns; /* # warnings issued wrt disk blocks */ > > + __s32 d_padding2; /* padding2 - for future use */ > > + __u64 d_rtb_hardlimit;/* absolute limit on realtime blks */ > > + __u64 d_rtb_softlimit;/* preferred limit on RT disk blks */ > > + __u64 d_rtbcount; /* # realtime blocks owned */ > > + __s32 d_rtbtimer; /* similar to above; for RT disk blks */ > > + __u16 d_rtbwarns; /* # warnings issued wrt RT disk blks */ > > + __s16 d_padding3; /* padding3 - for future use */ > > + char d_padding4[8]; /* yet more padding */ > > +} fs_disk_quota_t; > > + > > +/* > > + * These fields are sent to Q_XSETQLIM to specify fields that need to change. > > + */ > > +#define FS_DQ_ISOFT (1<<0) > > +#define FS_DQ_IHARD (1<<1) > > +#define FS_DQ_BSOFT (1<<2) > > +#define FS_DQ_BHARD (1<<3) > > +#define FS_DQ_RTBSOFT (1<<4) > > +#define FS_DQ_RTBHARD (1<<5) > > +#define FS_DQ_LIMIT_MASK (FS_DQ_ISOFT | FS_DQ_IHARD | FS_DQ_BSOFT | \ > > + FS_DQ_BHARD | FS_DQ_RTBSOFT | FS_DQ_RTBHARD) > > +/* > > + * These timers can only be set in super user's dquot. For others, timers are > > + * automatically started and stopped. Superusers timer values set the limits > > + * for the rest. In case these values are zero, the DQ_{F,B}TIMELIMIT values > > + * defined below are used. > > + * These values also apply only to the d_fieldmask field for Q_XSETQLIM. > > + */ > > +#define FS_DQ_BTIMER (1<<6) > > +#define FS_DQ_ITIMER (1<<7) > > +#define FS_DQ_RTBTIMER (1<<8) > > +#define FS_DQ_TIMER_MASK (FS_DQ_BTIMER | FS_DQ_ITIMER | FS_DQ_RTBTIMER) > > + > > +/* > > + * The following constants define the default amount of time given a user > > + * before the soft limits are treated as hard limits (usually resulting > > + * in an allocation failure). These may be modified by the quotactl(2) > > + * system call with the Q_XSETQLIM command. > > + */ > > +#define DQ_FTIMELIMIT (7 * 24*60*60) /* 1 week */ > > +#define DQ_BTIMELIMIT (7 * 24*60*60) /* 1 week */ > > + > > +/* > > + * Various flags related to quotactl(2). Only relevant to XFS filesystems. > > + */ > > +#define XFS_QUOTA_UDQ_ACCT (1<<0) /* user quota accounting */ > > +#define XFS_QUOTA_UDQ_ENFD (1<<1) /* user quota limits enforcement */ > > +#define XFS_QUOTA_GDQ_ACCT (1<<2) /* group quota accounting */ > > +#define XFS_QUOTA_GDQ_ENFD (1<<3) /* group quota limits enforcement */ > > + > > +#define XFS_USER_QUOTA (1<<0) /* user quota type */ > > +#define XFS_PROJ_QUOTA (1<<1) /* (IRIX) project quota type */ > > +#define XFS_GROUP_QUOTA (1<<2) /* group quota type */ > > + > > +/* > > + * fs_quota_stat is the struct returned in Q_XGETQSTAT for a given file system. > > + * Provides a centralized way to get meta infomation about the quota subsystem. > > + * eg. space taken up for user and group quotas, number of dquots currently > > + * incore. > > + */ > > +#define FS_QSTAT_VERSION 1 /* fs_quota_stat.qs_version */ > > + > > +/* > > + * Some basic infomation about 'quota files'. > > + */ > > +typedef struct fs_qfilestat { > > + __u64 qfs_ino; /* inode number */ > > + __u64 qfs_nblks; /* number of BBs 512-byte-blks */ > > + __u32 qfs_nextents; /* number of extents */ > > +} fs_qfilestat_t; > > + > > +typedef struct fs_quota_stat { > > + __s8 qs_version; /* version number for future changes */ > > + __u16 qs_flags; /* XFS_QUOTA_{U,P,G}DQ_{ACCT,ENFD} */ > > + __s8 qs_pad; /* unused */ > > + fs_qfilestat_t qs_uquota; /* user quota storage information */ > > + fs_qfilestat_t qs_gquota; /* group quota storage information */ > > + __u32 qs_incoredqs; /* number of dquots incore */ > > + __s32 qs_btimelimit; /* limit for blks timer */ > > + __s32 qs_itimelimit; /* limit for inodes timer */ > > + __s32 qs_rtbtimelimit;/* limit for rt blks timer */ > > + __u16 qs_bwarnlimit; /* limit for num warnings */ > > + __u16 qs_iwarnlimit; /* limit for num warnings */ > > +} fs_quota_stat_t; > > + > > +#endif /* _LINUX_XQM_H */ > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-linux-xfs@oss.sgi.com Wed Feb 27 14:19:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RMJMW19020 for linux-xfs-outgoing; Wed, 27 Feb 2002 14:19:22 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RMJH918997 for ; Wed, 27 Feb 2002 14:19:17 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 NAA24420 for ; Wed, 27 Feb 2002 13:14:49 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA34013 for ; Wed, 27 Feb 2002 15:18:01 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA72875 for ; Wed, 27 Feb 2002 15:18:00 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1RLI0s30928; Wed, 27 Feb 2002 15:18:00 -0600 Message-Id: <200202272118.g1RLI0s30928@jen.americas.sgi.com> Date: Wed, 27 Feb 2002 15:18:00 -0600 Subject: TAKE - make xfs superblock coherent with block layer To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The xfs super block lived in its own special buffer which was invisible from the /dev/xxx interface. This makes it a general purpose buffer. No change in filesystem functionality, but now I understand why the locking on this beast needs work. Date: Wed Feb 27 13:15:13 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.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:112914a linux/fs/xfs/xfs_buf.h - 1.81 - Make XFS_BUF_V_IODONESEMA do something - forced shutdown only case linux/fs/xfs/xfs_log_recover.c - 1.219 - minor cleanup linux/fs/xfs/xfs_mount.c - 1.270 - Change how we manage the super block buffer - it is now in the cache with all the other metadata linux/fs/xfs/pagebuf/page_buf_locking.c - 1.5 - Fold some code together, we were doing everything pagebuf_lock does, but not calling it. linux/fs/xfs/pagebuf/page_buf.c - 1.9 - Expand pagebuf_rele for the PBF_FS_MANAGED flag - the filesystem does not want this buffer to get freed. linux/fs/xfs/pagebuf/page_buf.h - 1.5 - Define PBF_FS_MANAGED From owner-linux-xfs@oss.sgi.com Wed Feb 27 14:23:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RMNV419204 for linux-xfs-outgoing; Wed, 27 Feb 2002 14:23:31 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RMNS919182 for ; Wed, 27 Feb 2002 14:23:28 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 NAA24862 for ; Wed, 27 Feb 2002 13:19:01 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA33736 for ; Wed, 27 Feb 2002 15:22:12 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA88225 for ; Wed, 27 Feb 2002 15:22:12 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1RLMBk31733; Wed, 27 Feb 2002 15:22:11 -0600 Message-Id: <200202272122.g1RLMBk31733@jen.americas.sgi.com> Date: Wed, 27 Feb 2002 15:22:11 -0600 Subject: TAKE - turn back on regression test 017 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Feb 27 13:21:43 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:112916a cmd/xfstests/017 - 1.4 - Turn test back on. From owner-linux-xfs@oss.sgi.com Wed Feb 27 15:15:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RNFcs21672 for linux-xfs-outgoing; Wed, 27 Feb 2002 15:15:38 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RNFW921649 for ; Wed, 27 Feb 2002 15:15:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA00967 for ; Wed, 27 Feb 2002 14:11:03 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA53380; Thu, 28 Feb 2002 09:14:12 +1100 (EST) Date: Thu, 28 Feb 2002 09:14:12 +1100 (EST) From: Nathan Scott Message-Id: <200202272214.JAA53380@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - acl_valid.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ugh... drop this on the ground merging between different trees. AG, the original warning was: acl_valid.c: In function `acl_valid': acl_valid.c:34: warning: implicit declaration of function `acl_check' cheers. Date: Wed Feb 27 14:10:29 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:112924a acl/libacl/acl_valid.c - 1.3 - fix build failure, missing definition of NULL. From owner-linux-xfs@oss.sgi.com Wed Feb 27 15:22:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RNM0u21893 for linux-xfs-outgoing; Wed, 27 Feb 2002 15:22:00 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RNLu921870 for ; Wed, 27 Feb 2002 15:21:57 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1RMLohd025188 for ; Wed, 27 Feb 2002 14:21:51 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA70091; Thu, 28 Feb 2002 09:20:34 +1100 (EST) Date: Thu, 28 Feb 2002 09:20:34 +1100 (EST) From: Nathan Scott Message-Id: <200202272220.JAA70091@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ag@bestbits.at Subject: TAKE - S/390 + IA64 syscall update Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Feb 27 14:19:35 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:112926a attr/configure.in - 1.8 - package is no longer XFS specific, annotate as such. attr/VERSION - 1.13 attr/doc/CHANGES - 1.15 attr/debian/changelog - 1.14 attr/libattr/syscalls.c - 1.6 - 2.0.2 - add in S/390 system call numbers from Martin Schwidefsky; revert IA64 syscall numbering after further mail with David Mosberger (apparently sys_tkill will be moved). From owner-linux-xfs@oss.sgi.com Wed Feb 27 15:40:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1RNevk22256 for linux-xfs-outgoing; Wed, 27 Feb 2002 15:40:57 -0800 Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1RNeb922231 for ; Wed, 27 Feb 2002 15:40:37 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id 2E9718052A0; Wed, 27 Feb 2002 17:40:30 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id DEB334000AE; Wed, 27 Feb 2002 17:40:29 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 17:40:29 -0500 Message-ID: From: "FORRESTER,JUSTIN (HP-Loveland,ex1)" To: "FORRESTER,JUSTIN (HP-Loveland,ex1)" , "'Eric Sandeen'" , "'Steve Lord'" Cc: "DICKENS,CARY (HP-Loveland,ex2)" , "'Xfs \"Mailing List (E-mail)'" , "PATTERSON,ANDREW (HP-Loveland,ex2)" Subject: RE: oops umounting full LVM snapshots Date: Wed, 27 Feb 2002 17:40:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've got some more info about the umount oops that might be helpful. It looks like what is happening in our case is the following: - overflow a LVM snapshot - in response, LVM *de-activates* the logical volume for the snapshot, such that subsequent write attempts cause I/O errors - XFS attempts to write log information, gets the I/O error, and shuts the filesystem down. - something is corrupted at this point, such that writes to a *different* XFS filesystem result in the kernel oops. In our case this is when umount writes to /etc/mtab, which is not even on an LVM volume. I've included some log information below that substantiates this theory. Thanks, Justin The following lvscan was executed after the snapshot was overflowed, you can see the snapshot volume is inactive: ---------------------------> tom# lvscan lvscan -- ACTIVE "/dev/vg01/lvol1" [96.00 MB] lvscan -- ACTIVE Original "/dev/vg02/lvol1" [992.00 MB] lvscan -- inactive Snapshot "/dev/vg02/lvol1-snap1" [15.94 MB] of /dev/vg02/lvol1 lvscan -- 3 logical volumes with 1.08 GB total in 2 volume groups lvscan -- 2 active / 1 inactive logical volumes <--------------------------- Then, when the umount was executed we see syslog messages from XFS shutting the fs down: ---------------------------> Feb 27 14:49:07 localhost kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/vg02/lvol1-snap1 Feb 27 14:49:07 localhost kernel: lvm - lvm_map: ll_rw_blk for inactive LV /dev/vg02/lvol1-snap1 Feb 27 14:49:07 localhost kernel: I/O error in filesystem ("lvm(58,1)") meta-data dev 0x3a01 block 0xf809f Feb 27 14:49:07 localhost kernel: ("xlog_iodone") error 5 buf count 1024 Feb 27 14:49:07 localhost kernel: xfs_force_shutdown(lvm(58,1),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01bfe36 Feb 27 14:49:07 localhost kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,1) Feb 27 14:49:07 localhost kernel: Please umount the filesystem, and rectify the problem(s) <---------------------------- Then in my original message below we see the xfs write to /etc/mtab causing the oops. > -----Original Message----- > From: FORRESTER,JUSTIN (HP-Loveland,ex1) [mailto:justin_forrester@hp.com] > Sent: Wednesday, February 27, 2002 11:29 AM > To: 'Eric Sandeen'; 'Steve Lord' > Cc: DICKENS,CARY (HP-Loveland,ex2); 'Xfs "Mailing List (E-mail)'; > PATTERSON,ANDREW (HP-Loveland,ex2) > Subject: RE: oops umounting full LVM snapshots > > > > > We were able to capture an oops yesterday (as opposed to the machine just > locking up hard). Here's the oops that we got while umounting a full > snapshot volume (lvm 1.0.2, kernel 2.4.17). > > Thanks, > Justin > > > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010282 > eax: 00000000 ebx: 00000002 ecx: f3bee6 edx: c03ff1ac > esi: f3bee600 edi: c2defa00 ebp: f3c94080 esp: f2ecfd48 > ds: 0018 es: 0018 ss: 0018 > Process umount (pid: 7235, stackpage=f4141000) > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] [] [] [] [] > Code: 0f 0b 83 3a 00 75 05 89 0a 89 49 24 8b 02 89 41 20 8b 02 8b > > >>EIP; c0135468 <__insert_into_lru_list+1c/5c> <===== > Trace; c0135f5c <__refile_buffer+54/5c> > Trace; c0135f7b > Trace; c0135ebe <__mark_buffer_dirty+26/2c> > Trace; c01da7eb > Trace; c01dac0b <__pb_block_commit_write_async+47/4c> > Trace; c01d9b80 > Trace; c01dadc5 <__pagebuf_do_delwri+1b5/23c> > Trace; c01daf87 <_pagebuf_file_write+13b/1f4> > Trace; c01db103 > Trace; c01dff8c > Trace; c01e12c3 > Trace; c01dff8c > Trace; c01dc464 > Trace; c0133f57 > Trace; c0106d6f > Code; c0135468 <__insert_into_lru_list+1c/5c> > 00000000 <_EIP>: > Code; c0135468 <__insert_into_lru_list+1c/5c> <===== > 0: 0f 0b ud2a <===== > Code; c013546a <__insert_into_lru_list+1e/5c> > 2: 83 3a 00 cmpl $0x0,(%edx) > Code; c013546d <__insert_into_lru_list+21/5c> > 5: 75 05 jne c <_EIP+0xc> c0135474 > <__insert_into_lru_list+28/5c> > Code; c013546f <__insert_into_lru_list+23/5c> > 7: 89 0a mov %ecx,(%edx) > Code; c0135471 <__insert_into_lru_list+25/5c> > 9: 89 49 24 mov %ecx,0x24(%ecx) > Code; c0135474 <__insert_into_lru_list+28/5c> > c: 8b 02 mov (%edx),%eax > Code; c0135476 <__insert_into_lru_list+2a/5c> > e: 89 41 20 mov %eax,0x20(%ecx) > Code; c0135479 <__insert_into_lru_list+2d/5c> > 11: 8b 02 mov (%edx),%eax > Code; c013547b <__insert_into_lru_list+2f/5c> > 13: 8b 00 mov (%eax),%eax > > > > > > -----Original Message----- > > From: Eric Sandeen [mailto:sandeen@sgi.com] > > Sent: Tuesday, February 26, 2002 5:34 PM > > To: Steve Lord > > Cc: DICKENS,CARY " "(HP-Loveland,ex2); Xfs "Mailing List (E-mail); > > PATTERSON,ANDREW " "(HP-Loveland,ex2) > > Subject: RE: oops umounting full LVM snapshots > > > > I'm starting to wonder, now... I patched the kernel to increase the > > stack by 100% and I still get the oops. The patch also allows me to see > > stack depth, and things look ok. > > > > FWIW, it's even simpler to show the problem, it's not necessary to > > overflow the snapshot or even copy anything to them. Just create a > > couple snapshot volumes, mount them, and unmount them. Unmounting the > > first snapshot does a forced shutdown, unmounting the second one does a > > force shutdown and then oopses. > > > > Just for kicks I created 2 dirty xfs filesystems and mounted them > > ro,norecovery, and unmounted - so at least that works. > > > > So it looks like maybe with lvm, xfs is trying to do more log flushing > > than it should on an ro filesystem, which generates the i/o error, which > > shuts us down - not sure about the oops yet. I'm sure Steve will pipe > > up if this theory is too far out of line. :) > > > > Still looking... > > > > -Eric > > > > > > On Tue, 2002-02-26 at 14:11, Steve Lord wrote: > > > > > If it is stack overflow as we suspect then different drivers may push > it > > > over the edge in different ways. What we need to do is catch it in the > > > act and see if there isn't something we can push off the stack. > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Feb 27 16:01:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S01Bs22802 for linux-xfs-outgoing; Wed, 27 Feb 2002 16:01:11 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S010922776 for ; Wed, 27 Feb 2002 16:01:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA01718 for ; Wed, 27 Feb 2002 15:00:56 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA35224; Wed, 27 Feb 2002 16:59:42 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA50724; Wed, 27 Feb 2002 16:59:42 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: "FORRESTER,JUSTIN ""(HP-Loveland,ex1)" Cc: "'Steve Lord'" , "DICKENS,CARY ""(HP-Loveland,ex2)" , "'Xfs \ Mailing List (E-mail)'" , "PATTERSON,ANDREW ""(HP-Loveland,ex2)" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 16:59:42 -0600 Message-Id: <1014850782.31777.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, with Steve's help I think we're getting this narrowed down. There seem to be 2 issues: 1) umounting snapshot causes I/O error & filesystem shutdown 2) subsequent oops The first seems to be that when quota is enabled, _mount_ causes a transaction via xfs_qm_mount_quotas. Now the log is dirty, it must be flushed on umount, but we're ro -> error -> shutdown. The second seems to follow from the first, if after this error LVM frees a buffer that pagebuf subsequently wants to free again, things fall down. We've seen the oops in various unrelated places. Not as clear on this one yet, but I'll try error injection over an LVM volume and see what happens. But if we can fix the first problem, the second will go away in this _particular_ case. :) FWIW, I have not seen any compiler dependency for this problem yet... -Eric On Wed, 2002-02-27 at 16:40, FORRESTER,JUSTIN (HP-Loveland,ex1) wrote: > > I've got some more info about the umount oops that might be helpful. It > looks like what is happening in our case is the following: > > - overflow a LVM snapshot > - in response, LVM *de-activates* the logical volume for the snapshot, such > that subsequent write attempts cause I/O errors > - XFS attempts to write log information, gets the I/O error, and shuts the > filesystem down. > - something is corrupted at this point, such that writes to a *different* > XFS filesystem result in the kernel oops. In our case this is when umount > writes to /etc/mtab, which is not even on an LVM volume. > > I've included some log information below that substantiates this theory. > > Thanks, > Justin -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Feb 27 16:13:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S0Dw523157 for linux-xfs-outgoing; Wed, 27 Feb 2002 16:13:58 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S0Dt923134 for ; Wed, 27 Feb 2002 16:13:55 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA02586 for ; Wed, 27 Feb 2002 15:13:55 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA82927 for ; Wed, 27 Feb 2002 17:12:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA53424 for ; Wed, 27 Feb 2002 17:12:38 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1RNCbP07941; Wed, 27 Feb 2002 17:12:37 -0600 Message-Id: <200202272312.g1RNCbP07941@jen.americas.sgi.com> Date: Wed, 27 Feb 2002 17:12:37 -0600 Subject: TAKE - queue buffer heads on the correct list Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No operational difference as far as xfs is concerned, but we were putting data buffers on a list intended for metadata. Date: Wed Feb 27 15:11:09 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112932a linux/fs/xfs/xfs_vfsops.c - 1.338 linux/fs/xfs/linux/xfs_lrw.c - 1.125 linux/fs/xfs/pagebuf/page_buf_io.c - 1.14 - Use the inode_data_buffers functions instead of the inode_buffers functions. From owner-linux-xfs@oss.sgi.com Wed Feb 27 17:07:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S17VD24107 for linux-xfs-outgoing; Wed, 27 Feb 2002 17:07:31 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S17P924084 for ; Wed, 27 Feb 2002 17:07:25 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id BAA867942 for ; Thu, 28 Feb 2002 01:09:50 +0100 (CET) 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 LAA26096; Thu, 28 Feb 2002 11:06:04 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA90190; Thu, 28 Feb 2002 11:06:02 +1100 (AEDT) Date: Thu, 28 Feb 2002 11:06:02 +1100 From: Nathan Scott To: Christoph Hellwig , Jan Kara Cc: linux-xfs@oss.sgi.com Subject: New VFS quota (was Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch) Message-ID: <20020228110602.I193798@wobbly.melbourne.sgi.com> References: <20020227144011.C193798@wobbly.melbourne.sgi.com> <20020227174116.B944@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020227174116.B944@caldera.de>; from hch@caldera.de on Wed, Feb 27, 2002 at 05:41:16PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 05:41:16PM +0100, Christoph Hellwig wrote: > On Wed, Feb 27, 2002 at 02:40:11PM +1100, Nathan Scott wrote: > > On Tue, Feb 26, 2002 at 10:36:02PM -0500, Shawn Starr wrote: > > > > > > I'm told there's a suse patch with XFS + quota? > > > ftp://ftp.suse.com/pub/people/mantel > > > > > > Im going to try this one out. > > > Shawn. > > > > > > > Ah - I didn't realise this was online somewhere. Yes, that should > > work - Hubert (Mantel), Jan and I were discussing this last week and > > he reported good success (showed me his merge & it looked fine). > > What about just including new-quota in the XFS tree? > I'm very tempted - I'll discuss with the rest of the folk here, IMO this is the right thing to do at this stage. Would anyone out there have a problem if we did this? It sounds like it will make life alot easier for alot of people. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 27 17:23:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S1Nln24495 for linux-xfs-outgoing; Wed, 27 Feb 2002 17:23:47 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S1Ng924470 for ; Wed, 27 Feb 2002 17:23:42 -0800 Received: (qmail 4275 invoked from network); 28 Feb 2002 00:25:04 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 28 Feb 2002 00:25:04 -0000 Date: Wed, 27 Feb 2002 19:25:03 -0500 (EST) From: Shawn Starr To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch In-Reply-To: <20020227133042.B193798@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm going to try to build again using the newer quota patch that was mentioned on lkml today. Shawn. On Wed, 27 Feb 2002, Nathan Scott wrote: > On Tue, Feb 26, 2002 at 09:19:49PM -0500, Shawn Starr wrote: > > > > Well, I got it to build but I can't mount the drive ;-) > > > > VFS panic's on trying to mount the disk. I suspect the struct super_block > > or so broke XFS? > > send me your fs/dquot.c, fs/quota.c, & include/linux/fs.h. > > cheers. > > -- > Nathan > > > From owner-linux-xfs@oss.sgi.com Wed Feb 27 17:37:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S1bPD24829 for linux-xfs-outgoing; Wed, 27 Feb 2002 17:37:25 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S1bI924807 for ; Wed, 27 Feb 2002 17:37:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1S0bAhd004515 for ; Wed, 27 Feb 2002 16:37:10 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA26353; Thu, 28 Feb 2002 11:35:54 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA99247; Thu, 28 Feb 2002 11:35:53 +1100 (AEDT) Date: Thu, 28 Feb 2002 11:35:53 +1100 From: Nathan Scott To: Shawn Starr Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch Message-ID: <20020228113553.L193798@wobbly.melbourne.sgi.com> References: <20020227133042.B193798@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spstarr@sh0n.net on Wed, Feb 27, 2002 at 07:25:03PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 07:25:03PM -0500, Shawn Starr wrote: > > I'm going to try to build again using the newer quota patch that was > mentioned on lkml today. > > Shawn. > The files you sent me last night looked OK. I'm not sure what the failure to mount root was caused by... did you recompile everything from scratch? (do you have eg. root filesystem as a module, and not recompile that? - since struct superblock changed, this might be one possible explanation). Not too likely though, I guess, so I'm not sure what your problem was. Maybe we will end up inserting the new VFS quota code into our tree directly, then you needn't worry about this. cheers for now. > > On Wed, 27 Feb 2002, Nathan Scott wrote: > > > On Tue, Feb 26, 2002 at 09:19:49PM -0500, Shawn Starr wrote: > > > > > > Well, I got it to build but I can't mount the drive ;-) > > > > > > VFS panic's on trying to mount the disk. I suspect the struct super_block > > > or so broke XFS? > > > > send me your fs/dquot.c, fs/quota.c, & include/linux/fs.h. > > > > cheers. > > > > -- > > Nathan > > > > > > > -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 27 17:37:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S1biU24886 for linux-xfs-outgoing; Wed, 27 Feb 2002 17:37:44 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S1bd924864 for ; Wed, 27 Feb 2002 17:37:40 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g1S0aAx16902; Wed, 27 Feb 2002 18:36:10 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: [doc bug] cmd/acl/REAME --> doc/INSTALL From: Alvaro Figueroa To: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 27 Feb 2002 18:36:09 -0600 Message-Id: <1014856569.15895.9.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As I was reading trough the xfs documentation on building the userland tools, I found that the file cmd/acl/REAME references to doc/INSTALL which doesn't exist. Please fix it. See the file doc/INSTALL for build, installation and post- install configuration steps. $ ls cmd/acl/doc/ CHANGES CVS/ LICENSE Makefile PORTING TODO extensions.txt libacl.txt Thanks -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Wed Feb 27 17:53:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S1rLd25299 for linux-xfs-outgoing; Wed, 27 Feb 2002 17:53:21 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S1rG925269 for ; Wed, 27 Feb 2002 17:53:17 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA869611 for ; Thu, 28 Feb 2002 01:55:43 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA92435 for linux-xfs@oss.sgi.com; Thu, 28 Feb 2002 11:51:56 +1100 (EST) Date: Thu, 28 Feb 2002 11:51:56 +1100 (EST) From: Nathan Scott Message-Id: <200202280051.LAA92435@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - IA64 syscalls Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Userspace done earlier, this is the kernel side. Date: Wed Feb 27 16:51:11 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:112942a linux/arch/ia64/kernel/entry.S - 1.21 linux/include/asm-ia64/unistd.h - 1.16 - Fix up numbers allocated to IA64 syscalls. From owner-linux-xfs@oss.sgi.com Wed Feb 27 17:54:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S1s6k25358 for linux-xfs-outgoing; Wed, 27 Feb 2002 17:54:06 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S1rv925336 for ; Wed, 27 Feb 2002 17:53:57 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA874816 for ; Thu, 28 Feb 2002 01:56:23 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA17051; Thu, 28 Feb 2002 11:52:36 +1100 (EST) Date: Thu, 28 Feb 2002 11:52:36 +1100 (EST) From: Nathan Scott Message-Id: <200202280052.LAA17051@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, fede2@fuerzag.ulatina.ac.cr, ag@bestbits.at Subject: TAKE - missing doc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 06:36:09PM -0600, Alvaro Figueroa wrote: > > As I was reading trough the xfs documentation on building the userland > tools, I found that the file cmd/acl/REAME references to doc/INSTALL > which doesn't exist. Please fix it. > > > See the file doc/INSTALL for build, installation and post- > install configuration steps. > > > $ ls cmd/acl/doc/ > CHANGES CVS/ LICENSE Makefile PORTING TODO extensions.txt > libacl.txt > Fixed, thanks for reporting it. cheers. Date: Wed Feb 27 16:44:54 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:112940a acl/doc/INSTALL - 1.3 acl/doc/Makefile - 1.7 - add missing file describing how to install the package. attr/doc/INSTALL - 1.2 - update words a little to reflect last round of changes. From owner-linux-xfs@oss.sgi.com Wed Feb 27 17:54:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S1sSC25425 for linux-xfs-outgoing; Wed, 27 Feb 2002 17:54:28 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S1sM925394 for ; Wed, 27 Feb 2002 17:54:22 -0800 Received: (qmail 4398 invoked from network); 28 Feb 2002 00:55:44 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 28 Feb 2002 00:55:44 -0000 Date: Wed, 27 Feb 2002 19:55:44 -0500 (EST) From: Shawn Starr To: Nathan Scott cc: Christoph Hellwig , Jan Kara , Subject: Re: New VFS quota (was Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch) In-Reply-To: <20020228110602.I193798@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Perhaps a CONFIG option if some people don't want to use it? CONFIG_NEW_VFS_QUOTA ? Shawn. On Thu, 28 Feb 2002, Nathan Scott wrote: > On Wed, Feb 27, 2002 at 05:41:16PM +0100, Christoph Hellwig wrote: > > On Wed, Feb 27, 2002 at 02:40:11PM +1100, Nathan Scott wrote: > > > On Tue, Feb 26, 2002 at 10:36:02PM -0500, Shawn Starr wrote: > > > > > > > > I'm told there's a suse patch with XFS + quota? > > > > ftp://ftp.suse.com/pub/people/mantel > > > > > > > > Im going to try this one out. > > > > Shawn. > > > > > > > > > > Ah - I didn't realise this was online somewhere. Yes, that should > > > work - Hubert (Mantel), Jan and I were discussing this last week and > > > he reported good success (showed me his merge & it looked fine). > > > > What about just including new-quota in the XFS tree? > > > > I'm very tempted - I'll discuss with the rest of the folk here, > IMO this is the right thing to do at this stage. > > Would anyone out there have a problem if we did this? It sounds > like it will make life alot easier for alot of people. > > cheers. > > -- > Nathan > > > From owner-linux-xfs@oss.sgi.com Wed Feb 27 18:01:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S21fk25932 for linux-xfs-outgoing; Wed, 27 Feb 2002 18:01:41 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S21X925909 for ; Wed, 27 Feb 2002 18:01:33 -0800 Received: (qmail 4436 invoked from network); 28 Feb 2002 01:02:56 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 28 Feb 2002 01:02:56 -0000 Date: Wed, 27 Feb 2002 20:02:55 -0500 (EST) From: Shawn Starr To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch In-Reply-To: <20020228113553.L193798@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I use XFS as my root partition. I will rebuild the tree clean, and try again. Some people report success with the changes I made. I will give more details in an hour (takes that long to build kernel on a P200 :/) Shawn. On Thu, 28 Feb 2002, Nathan Scott wrote: > On Wed, Feb 27, 2002 at 07:25:03PM -0500, Shawn Starr wrote: > > > > I'm going to try to build again using the newer quota patch that was > > mentioned on lkml today. > > > > Shawn. > > > > The files you sent me last night looked OK. I'm not sure what the > failure to mount root was caused by... did you recompile everything > from scratch? (do you have eg. root filesystem as a module, and not > recompile that? - since struct superblock changed, this might be one > possible explanation). Not too likely though, I guess, so I'm not > sure what your problem was. > > Maybe we will end up inserting the new VFS quota code into our tree > directly, then you needn't worry about this. > > cheers for now. > > > > > On Wed, 27 Feb 2002, Nathan Scott wrote: > > > > > On Tue, Feb 26, 2002 at 09:19:49PM -0500, Shawn Starr wrote: > > > > > > > > Well, I got it to build but I can't mount the drive ;-) > > > > > > > > VFS panic's on trying to mount the disk. I suspect the struct super_block > > > > or so broke XFS? > > > > > > send me your fs/dquot.c, fs/quota.c, & include/linux/fs.h. > > > > > > cheers. > > > > > > -- > > > Nathan > > > > > > > > > > > > > -- > Nathan > > > From owner-linux-xfs@oss.sgi.com Wed Feb 27 18:04:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S24a126129 for linux-xfs-outgoing; Wed, 27 Feb 2002 18:04:36 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S24U926103 for ; Wed, 27 Feb 2002 18:04:30 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g1S14Nhd006922 for ; Wed, 27 Feb 2002 17:04:24 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26590; Thu, 28 Feb 2002 12:03:06 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA94970; Thu, 28 Feb 2002 12:03:05 +1100 (AEDT) Date: Thu, 28 Feb 2002 12:03:05 +1100 From: Nathan Scott To: "Jeffrey D. Means" , Lawrence Walton , Andreas Gruenbacher Cc: acl-devel@bestbits.at, linux-xfs@oss.sgi.com Subject: Re: why does this not work?? Message-ID: <20020228120305.N193798@wobbly.melbourne.sgi.com> References: <006701c1bf6d$dbdc8f90$0264a8c0@jeffw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006701c1bf6d$dbdc8f90$0264a8c0@jeffw>; from meaje@picotech.net on Wed, Feb 27, 2002 at 02:05:05AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi there, This sort of question really belongs on the ACL mailing list, ie. acl-devel@bestbits.at, now that we're using common userspace code for ext2, ext3 and XFS (or will be soon for the ext2/3 folks). Andreas wrote this bit of code/man page ... he would be the best person to ask. The answer isn't immediately obvious to me - my first thought was the "d:" prefix isn't allowed, but I see from the latest man pages that it is now... Andreas? cheers. On Wed, Feb 27, 2002 at 02:05:05AM -0700, Jeffrey D. Means wrote: > [root@trouble www]# setfacl -s > d:u::rwx,d:g::rx,d:o::---,d:u:scoth:rwx,d:u:meaje:rwx,d:mask:rwx > paperstreet2 > setfacl: paperstreet2: Resulting ACL `': Missing or wrong entry at entry > 1 > [root@trouble www]# > > I can not set default acls either by explicit command 'setfacl -s' I get > the above message about being a wrong entry at 1, however if I enter the > same command specifying the -m instead of -s it works, why?? > > ------------- > Jeffrey D. Means > CIO for PicoTech > Ft. Collins, Colorado > On Wed, Feb 27, 2002 at 10:45:22AM -0800, Lawrence Walton wrote: > Jeffrey D. Means [meaje@picotech.net] wrote: > > [root@trouble www]# setfacl -s > > d:u::rwx,d:g::rx,d:o::---,d:u:scoth:rwx,d:u:meaje:rwx,d:mask:rwx > > paperstreet2 > > setfacl: paperstreet2: Resulting ACL `': Missing or wrong entry at entry > > 1 > > [root@trouble www]# > I don't know why that syntax is different per se, but try this > > setfacl -dm u::rwx,g::r-x,o::---,u:scoth:rwx,u:meaje:rwx,m::rwx > -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 27 18:11:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S2Bhd26438 for linux-xfs-outgoing; Wed, 27 Feb 2002 18:11:43 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S2Bd926415 for ; Wed, 27 Feb 2002 18:11:39 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1S2BXFH009512 for ; Wed, 27 Feb 2002 18:11:33 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g1S1BSu29328; Thu, 28 Feb 2002 12:11:28 +1100 Date: Thu, 28 Feb 2002 12:11:28 +1100 From: Keith Owens Message-Id: <200202280111.g1S1BSu29328@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb v2.1-2.5.5-{common,i386}-1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Feb 27 17:10:50 PST 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:112943a linux/kdb/modules/kdbm_pg.c - 1.53 linux/kdb/ChangeLog - 1.16 linux/arch/i386/kdb/ChangeLog - 1.3 From owner-linux-xfs@oss.sgi.com Wed Feb 27 18:18:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S2Ih726716 for linux-xfs-outgoing; Wed, 27 Feb 2002 18:18:43 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S2Id926694 for ; Wed, 27 Feb 2002 18:18:39 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA02573 for ; Wed, 27 Feb 2002 17:18:33 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26694; Thu, 28 Feb 2002 12:17:17 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA99644; Thu, 28 Feb 2002 12:17:16 +1100 (AEDT) Date: Thu, 28 Feb 2002 12:17:16 +1100 From: Nathan Scott To: Shawn Starr , Jan Kara Cc: linux-xfs@oss.sgi.com Subject: Re: New VFS quota (was Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch) Message-ID: <20020228121716.O193798@wobbly.melbourne.sgi.com> References: <20020228110602.I193798@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spstarr@sh0n.net on Wed, Feb 27, 2002 at 07:55:44PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 07:55:44PM -0500, Shawn Starr wrote: > > Perhaps a CONFIG option if some people don't want to use it? > > CONFIG_NEW_VFS_QUOTA ? > > Shawn. > The config option would be CONFIG_QUOTA if people don't want to use it, currently anyway (ie. use new format or no VFS quota at all). Jan is working on new patches which allow both the new and the old quota formats to co-exist in the same kernel, they seem to be quite far along (bit not quite finished) so maybe we will go straight to those patches, maybe not. I've sent Jan some private mail - we'll discuss it and see what would be best if we do proceed down this path. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 27 21:42:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1S5gAU29975 for linux-xfs-outgoing; Wed, 27 Feb 2002 21:42:10 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1S5g5929953 for ; Wed, 27 Feb 2002 21:42:05 -0800 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 UAA09802 for ; Wed, 27 Feb 2002 20:43:35 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA08990 for linux-xfs@oss.sgi.com; Thu, 28 Feb 2002 15:40:45 +1100 (EST) Date: Thu, 28 Feb 2002 15:40:45 +1100 (EST) From: Nathan Scott Message-Id: <200202280440.PAA08990@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix some warnings Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Feb 27 16:49:53 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112941a linux/arch/ia64/kernel/entry.S - 1.20 linux/include/asm-ia64/unistd.h - 1.16 - Fix up numbers allocated to IA64 syscalls in 2.4 too. Date: Wed Feb 27 20:39:36 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112950a linux/fs/xfs/linux/xfs_super.c - 1.160 - fix compile warning. linux/fs/xfs/xfs_acl.h - 1.8 linux/fs/xfs/xfs_acl.c - 1.14 linux/fs/xfs/linux/xfs_xattr.c - 1.7 - rearrange code a bit to fix some compile warnings if CONFIG_POSIX_ACL is not defined. From owner-linux-xfs@oss.sgi.com Thu Feb 28 04:54:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SCs3L05500 for linux-xfs-outgoing; Thu, 28 Feb 2002 04:54:03 -0800 Received: from linux.nameip.net ([61.254.24.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SCs0905478 for ; Thu, 28 Feb 2002 04:54:01 -0800 Received: (qmail 2437 invoked by uid 500); 28 Feb 2002 11:53:48 -0000 Subject: Updated 2.4 kernel available for RedHat 7.1 & 7.2 From: Seung-young Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 28 Feb 2002 20:53:48 +0900 Message-Id: <1014897228.2002.1.camel@linux.nameip.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, just wanted to inform that; http://www.redhat.com/support/errata/RHSA-2002-028.html -- JabberID: so1713@myjabber.net From owner-linux-xfs@oss.sgi.com Thu Feb 28 05:03:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SD3Nm05937 for linux-xfs-outgoing; Thu, 28 Feb 2002 05:03:23 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SD3K905915 for ; Thu, 28 Feb 2002 05:03:20 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g1SC2WK24689; Thu, 28 Feb 2002 13:02:32 +0100 Date: Thu, 28 Feb 2002 13:02:32 +0100 From: Christoph Hellwig To: Shawn Starr Cc: Nathan Scott , Jan Kara , linux-xfs@oss.sgi.com Subject: Re: New VFS quota (was Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch) Message-ID: <20020228130232.A24617@caldera.de> References: <20020228110602.I193798@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spstarr@sh0n.net on Wed, Feb 27, 2002 at 07:55:44PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Feb 27, 2002 at 07:55:44PM -0500, Shawn Starr wrote: > Perhaps a CONFIG option if some people don't want to use it? > > CONFIG_NEW_VFS_QUOTA ? The quota patch is to intrusive to allow such config option. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Thu Feb 28 05:15:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SDFZ806241 for linux-xfs-outgoing; Thu, 28 Feb 2002 05:15:35 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SDFV906217 for ; Thu, 28 Feb 2002 05:15:31 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g1SCFG15081583; Thu, 28 Feb 2002 13:15:17 +0100 (CET) Message-Id: <4.3.2.7.2.20020228131409.03802530@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Feb 2002 13:14:23 +0100 To: Seung-young Oh , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Updated 2.4 kernel available for RedHat 7.1 & 7.2 In-Reply-To: <1014897228.2002.1.camel@linux.nameip.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 20:53 28-2-2002 +0900, Seung-young Oh wrote: >Hello, >just wanted to inform that; > >http://www.redhat.com/support/errata/RHSA-2002-028.html They already know. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Feb 28 05:16:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SDGLW06383 for linux-xfs-outgoing; Thu, 28 Feb 2002 05:16:21 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SDGI906359 for ; Thu, 28 Feb 2002 05:16:19 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 EAA15007 for ; Thu, 28 Feb 2002 04:11:51 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA42875 for ; Thu, 28 Feb 2002 06:15:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA60659 for ; Thu, 28 Feb 2002 06:15:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1SCEtB15671; Thu, 28 Feb 2002 06:14:55 -0600 Message-Id: <200202281214.g1SCEtB15671@jen.americas.sgi.com> Date: Thu, 28 Feb 2002 06:14:55 -0600 Subject: TAKE - pagebuf use after free fix To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fix some racy code, courtesy of Andrew Morton, the fix that is, not the race. Date: Thu Feb 28 04:13:45 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:112952a linux/fs/xfs/pagebuf/page_buf_io.c - 1.15 - fix potential use after free on some hardware From owner-linux-xfs@oss.sgi.com Thu Feb 28 05:26:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SDQTn06778 for linux-xfs-outgoing; Thu, 28 Feb 2002 05:26:29 -0800 Received: from pooh.lsc.hu (IDENT:postfix@pooh.lsc.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SDQE906750 for ; Thu, 28 Feb 2002 05:26:14 -0800 Received: by pooh.lsc.hu (Postfix, from userid 547) id 02558E05D7; Thu, 28 Feb 2002 13:29:48 +0100 (CET) Date: Thu, 28 Feb 2002 13:29:48 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: Build failure with kdb Message-ID: <20020228132948.A32089@lsc.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I have included Ingo's O1 scheduler K3 in the XFS kernel 2.4.18, and I get a compile error to kdb. I have tried to find a solution, but no success. Can someone help me out? The output is: gcc -D__KERNEL__ -I/home/staff/gcs/kernel/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -I /home/staff/gcs/kernel/linux/arch/i386/kdb -DKBUILD_BASENAME=kdbmain -DEXPORT_SYMTAB -c kdbmain.c kdbmain.c: In function `kdb_ps': kdbmain.c:2347: warning: implicit declaration of function `task_has_cpu' kdbmain.c:2347: structure has no member named `processor' make[2]: *** [kdbmain.o] Error 1 make[2]: Leaving directory `/home/staff/gcs/kernel/linux/kdb' Thanks, GCS -- BorsodChem Joint-Stock Company Linux Support Center University of Miskolc Software engineer Programmer System administrator +36-48-511211/27-90 +36-20-4441745 From owner-linux-xfs@oss.sgi.com Thu Feb 28 05:36:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SDaiM07073 for linux-xfs-outgoing; Thu, 28 Feb 2002 05:36:44 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SDad907050 for ; Thu, 28 Feb 2002 05:36:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA937935 for ; Thu, 28 Feb 2002 13:39:13 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA42769; Thu, 28 Feb 2002 06:35:12 -0600 (CST) Received: from sgi.com (9jfA/z4BWrf1/9fqAx3qKufxy6cN2MSJ@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA97164; Thu, 28 Feb 2002 06:35:12 -0600 (CST) Message-ID: <3C7E2460.1050200@sgi.com> Date: Thu, 28 Feb 2002 06:36:48 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: GCS CC: linux-xfs@oss.sgi.com Subject: Re: Build failure with kdb References: <20020228132948.A32089@lsc.hu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk GCS wrote: >Hi! > > I have included Ingo's O1 scheduler K3 in the XFS kernel 2.4.18, and I get a >compile error to kdb. I have tried to find a solution, but no success. >Can someone help me out? The output is: >gcc -D__KERNEL__ -I/home/staff/gcs/kernel/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -I /home/staff/gcs/kernel/linux/arch/i386/kdb -DKBUILD_BASENAME=kdbmain -DEXPORT_SYMTAB -c kdbmain.c >kdbmain.c: In function `kdb_ps': >kdbmain.c:2347: warning: implicit declaration of function `task_has_cpu' >kdbmain.c:2347: structure has no member named `processor' >make[2]: *** [kdbmain.o] Error 1 >make[2]: Leaving directory `/home/staff/gcs/kernel/linux/kdb' > >Thanks, >GCS > Try replacing task_has_cpu(p) with p->state == TASK_RUNNING All this actually effects is the output of the ps command in kdb. Totally non-essential for xfs itself. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 28 07:49:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SFnbS12942 for linux-xfs-outgoing; Thu, 28 Feb 2002 07:49:37 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SFnN912916 for ; Thu, 28 Feb 2002 07:49:24 -0800 Received: (qmail 24597 invoked from network); 28 Feb 2002 14:50:44 -0000 Received: from unknown (HELO dwws-10-0-0-78-tor-dcn.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 28 Feb 2002 14:50:44 -0000 Subject: Re: 2.4.19-pre1-ac1 + XFS + 2.4.18-pre3-quota patch From: Shawn Starr To: Nathan Scott Cc: xfs In-Reply-To: <20020228113553.L193798@wobbly.melbourne.sgi.com> References: <20020227133042.B193798@wobbly.melbourne.sgi.com> <20020228113553.L193798@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 28 Feb 2002 09:54:00 -0500 Message-Id: <1014908070.15830.1.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I fixed, it it mounted fine ;-) the XFS test tools fail hard though, but it might be due to the partitions i created (32MB each). Oddly, I dont see any XFS corruption though. But I don't use quota or other XFS features just core XFS which works great. Shawn. On Wed, 2002-02-27 at 19:35, Nathan Scott wrote: > On Wed, Feb 27, 2002 at 07:25:03PM -0500, Shawn Starr wrote: > > > > I'm going to try to build again using the newer quota patch that was > > mentioned on lkml today. > > > > Shawn. > > > > The files you sent me last night looked OK. I'm not sure what the > failure to mount root was caused by... did you recompile everything > from scratch? (do you have eg. root filesystem as a module, and not > recompile that? - since struct superblock changed, this might be one > possible explanation). Not too likely though, I guess, so I'm not > sure what your problem was. > > Maybe we will end up inserting the new VFS quota code into our tree > directly, then you needn't worry about this. > > cheers for now. > > > > > On Wed, 27 Feb 2002, Nathan Scott wrote: > > > > > On Tue, Feb 26, 2002 at 09:19:49PM -0500, Shawn Starr wrote: > > > > > > > > Well, I got it to build but I can't mount the drive ;-) > > > > > > > > VFS panic's on trying to mount the disk. I suspect the struct super_block > > > > or so broke XFS? > > > > > > send me your fs/dquot.c, fs/quota.c, & include/linux/fs.h. > > > > > > cheers. > > > > > > -- > > > Nathan > > > > > > > > > > > > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Thu Feb 28 10:06:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SI60X17011 for linux-xfs-outgoing; Thu, 28 Feb 2002 10:06:00 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SI5t916989 for ; Thu, 28 Feb 2002 10:05:56 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g1SH4Dg17821; Thu, 28 Feb 2002 11:04:13 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: "left shift count" warning while compiling From: Alvaro Figueroa To: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Feb 2002 11:04:13 -0600 Message-Id: <1014915853.17485.10.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm getting lots of this: /usr/include/linux/byteorder/swab.h: In function `__fswab64': /usr/include/linux/byteorder/swab.h:165: warning: left shift count >= width of type Could this be safely ignored? I'm on a sparc64 box. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Feb 28 11:28:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SJSGE18624 for linux-xfs-outgoing; Thu, 28 Feb 2002 11:28:16 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SJSA918602 for ; Thu, 28 Feb 2002 11:28:10 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g1SIQXY17934; Thu, 28 Feb 2002 12:26:33 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: mkfs.xfs says "can't determine device size" From: Alvaro Figueroa To: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Feb 2002 12:26:32 -0600 Message-Id: <1014920792.17527.12.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk mkfs -t xfs -f /dev/scsi/host1/bus0/target8/lun0/part1 mkfs.xfs: warning - cannot set blocksize on block device /dev/scsi/host1/bus0/target8/lun0/part1: Invalid argument mkfs.xfs: can't determine device size I have a sparc64 box, using devfs and a CVS kernel (2 days ago or something like that). On sparc, one generally uses a "Sun Label", this disk is partitioned as follows. Disk /dev/scsi/host1/bus0/target8/lun0/disc (Sun disk label): 19 heads, 80 sectors, 2733 cylinders Units = cylinders of 1520 * 512 bytes Device Flag Start End Blocks Id System /dev/scsi/host1/bus0/target8/lun0/disc1 1 2733 2076320 83 Linux native /dev/scsi/host1/bus0/target8/lun0/disc3 0 2733 2077080 5 Whole disk Any ideas? -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Feb 28 12:01:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SK1kl22178 for linux-xfs-outgoing; Thu, 28 Feb 2002 12:01:46 -0800 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SK1g922156 for ; Thu, 28 Feb 2002 12:01:42 -0800 Received: from [192.168.168.25] (gabe-g4.clubphoto.local [192.168.168.25]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id LAA07907 for ; Thu, 28 Feb 2002 11:01:41 -0800 User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Thu, 28 Feb 2002 11:01:40 -0800 Subject: Weird networking problem From: "Gabe E. Nydick" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hey folks, I have a stock redhat 7.2 with all of the users space xfs stuff added and a vanilla patched 2.4.17-xfs-smp kernel. That can't connect via port 25 to certain hosts. When I down rev my kernel to 2.4.14-xfs-smp, it goes away. (I don't think there is anything special about 2.4.14, it is just the previous kernel I had) Hardware - dual PIII 1GHz - dual eepro100 using e100.o or eepro100.o as drivers Hosts I couldn't connect to - mta01.cdpd.airdata.com - mail.mailzone.net Plus others I haven't been able to find anyone else with networking issues under 2.4.17, so I figured maybe it is a 2.4.17-xfs specific thing. Anybody had similar issues? Can anyone else using 2.4.17-xfs-smp try to telnet to these hosts over port 25 and tell me if they get the same problem? Thanks, Gabe From owner-linux-xfs@oss.sgi.com Thu Feb 28 12:07:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SK7WO22500 for linux-xfs-outgoing; Thu, 28 Feb 2002 12:07:32 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SK7Q922478 for ; Thu, 28 Feb 2002 12:07:26 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 LAA25243 for ; Thu, 28 Feb 2002 11:02:59 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA46486; Thu, 28 Feb 2002 13:06:09 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA62184; Thu, 28 Feb 2002 13:06:09 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1SJ5xE01306; Thu, 28 Feb 2002 13:05:59 -0600 Subject: Re: Weird networking problem From: Steve Lord To: "Gabe E. Nydick" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 28 Feb 2002 13:05:59 -0600 Message-Id: <1014923159.24545.68.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-28 at 13:01, Gabe E. Nydick wrote: > Hey folks, > > I have a stock redhat 7.2 with all of the users space xfs stuff added > and a vanilla patched 2.4.17-xfs-smp kernel. That can't connect via port 25 > to certain hosts. When I down rev my kernel to 2.4.14-xfs-smp, it goes > away. (I don't think there is anything special about 2.4.14, it is just the > previous kernel I had) > > Hardware > - dual PIII 1GHz > - dual eepro100 using e100.o or eepro100.o as drivers > > Hosts I couldn't connect to > - mta01.cdpd.airdata.com > - mail.mailzone.net > Plus others > > I haven't been able to find anyone else with networking issues under 2.4.17, > so I figured maybe it is a 2.4.17-xfs specific thing. Anybody had similar > issues? Can anyone else using 2.4.17-xfs-smp try to telnet to these hosts > over port 25 and tell me if they get the same problem? > > Thanks, > Gabe I don't think it is xfs specific, there is a tcp option which got twiddled I think. This page explains the 'feature' http://gtf.org/garzik/ecn/ and I think /proc/sys/net/ipv4/tcp_ecn controls the flag being on or off. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 28 12:52:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SKqQZ23764 for linux-xfs-outgoing; Thu, 28 Feb 2002 12:52:26 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SKqG923740 for ; Thu, 28 Feb 2002 12:52:16 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1SJq9hd017341 for ; Thu, 28 Feb 2002 11:52:10 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA48830; Thu, 28 Feb 2002 13:50:52 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA53296; Thu, 28 Feb 2002 13:50:52 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1SJogd25846; Thu, 28 Feb 2002 13:50:42 -0600 Subject: Re: mkfs.xfs says "can't determine device size" From: Steve Lord To: Alvaro Figueroa Cc: XFS to linux port mailing list In-Reply-To: <1014920792.17527.12.camel@lucy> References: <1014920792.17527.12.camel@lucy> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 28 Feb 2002 13:50:41 -0600 Message-Id: <1014925841.26083.82.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-28 at 12:26, Alvaro Figueroa wrote: > mkfs -t xfs -f /dev/scsi/host1/bus0/target8/lun0/part1 > > mkfs.xfs: warning - cannot set blocksize on block device > /dev/scsi/host1/bus0/target8/lun0/part1: Invalid argument > mkfs.xfs: can't determine device size > > > I have a sparc64 box, using devfs and a CVS kernel (2 days ago or > something like that). On sparc, one generally uses a "Sun Label", this > disk is partitioned as follows. > > > Disk /dev/scsi/host1/bus0/target8/lun0/disc (Sun disk label): 19 heads, > 80 sectors, 2733 cylinders > Units = cylinders of 1520 * 512 bytes > > Device Flag Start End > Blocks Id System > /dev/scsi/host1/bus0/target8/lun0/disc1 1 2733 > 2076320 83 Linux native > /dev/scsi/host1/bus0/target8/lun0/disc3 0 2733 > 2077080 5 Whole disk > > > Any ideas? > > -- > Alvaro Figueroa Any chance strace exists for sparc64, could you run strace -s on the mkfs.xfs process. I suspect the size is supposed to come out of an ioctl and it won't interpret that, but it might tell us something. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 28 12:56:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SKuPm24034 for linux-xfs-outgoing; Thu, 28 Feb 2002 12:56:25 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SKuL924010 for ; Thu, 28 Feb 2002 12:56:21 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g1SJuFhd017576 for ; Thu, 28 Feb 2002 11:56:15 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA48689; Thu, 28 Feb 2002 13:54:59 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA38434; Thu, 28 Feb 2002 13:54:59 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1SJsnD26187; Thu, 28 Feb 2002 13:54:49 -0600 Subject: Re: mkfs.xfs says "can't determine device size" From: Steve Lord To: Steve Lord Cc: Alvaro Figueroa , XFS to linux port mailing list In-Reply-To: <1014925841.26083.82.camel@jen.americas.sgi.com> References: <1014920792.17527.12.camel@lucy> <1014925841.26083.82.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 28 Feb 2002 13:54:49 -0600 Message-Id: <1014926089.26083.87.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-28 at 13:50, Steve Lord wrote: > > Any chance strace exists for sparc64, could you run strace -s on the > mkfs.xfs process. I mean strace -v Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 28 13:03:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SL3dS24498 for linux-xfs-outgoing; Thu, 28 Feb 2002 13:03:39 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SL3W924471 for ; Thu, 28 Feb 2002 13:03:33 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g1SK1sk17990; Thu, 28 Feb 2002 14:01:54 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: mkfs.xfs says "can't determine device size" From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <1014926089.26083.87.camel@jen.americas.sgi.com> References: <1014920792.17527.12.camel@lucy> <1014925841.26083.82.camel@jen.americas.sgi.com> <1014926089.26083.87.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Feb 2002 14:01:54 -0600 Message-Id: <1014926514.17527.14.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Any chance strace exists for sparc64, could you run strace -s on the > > mkfs.xfs process. > > I mean strace -v > Short version. ustat(0x851, 0xefffe3b8) = -1 EINVAL (Invalid argument) open("/dev/scsi/host1/bus0/target8/lun0/part1", O_RDONLY|0x40000) = 3 SYS_139() = 0 SYS_139() = 0 ustat(0x851, 0xefffe3b8) = -1 EINVAL (Invalid argument) open("/dev/scsi/host1/bus0/target8/lun0/part1", O_RDWR|0x40000) = 4 SYS_139() = 0 ioctl(4, 0x80041271, 0xefffe364) = -1 EINVAL (Invalid argument) write(2, "mkfs.xfs: warning - cannot set b"..., 115mkfs.xfs: warning - cannot set blocksize on block device /dev/scsi/host1/bus0/target8/lun0/part1: Invalid argument ) = 115 SYS_139() = 0 open("/dev/scsi/host1/bus0/target8/lun0/part1", O_RDONLY|0x40000) = 5 ioctl(5, 0x40041272, 0xefffe360) = -1 EINVAL (Invalid argument) write(2, "mkfs.xfs: can\'t determine device"..., 38mkfs.xfs: can't determine device size ) = 38 exit(1) = ? Not-so-short version http://fuerzag.ulatina.ac.cr/~fede2/XFS,%20mkfs%20strace%20log.txt -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Feb 28 13:58:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SLwWV25602 for linux-xfs-outgoing; Thu, 28 Feb 2002 13:58:32 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SLwP925580 for ; Thu, 28 Feb 2002 13:58:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA994056 for ; Thu, 28 Feb 2002 22:01:02 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA89703 for linux-xfs@oss.sgi.com; Fri, 1 Mar 2002 07:57:00 +1100 (EST) Date: Fri, 1 Mar 2002 07:57:00 +1100 (EST) From: Nathan Scott Message-Id: <200202282057.HAA89703@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix module builds Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk auto-qa picked this problem up... Date: Thu Feb 28 12:51:43 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113002a linux/kernel/ksyms.c - 1.125 - add "EXPORT_SYMBOL(buffer_insert_inode_data_queue);" line to fix modular XFS builds. From owner-linux-xfs@oss.sgi.com Thu Feb 28 14:18:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SMIIn26187 for linux-xfs-outgoing; Thu, 28 Feb 2002 14:18:18 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SMIC926156 for ; Thu, 28 Feb 2002 14:18:12 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA01059 for ; Thu, 28 Feb 2002 13:18:12 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02341; Fri, 1 Mar 2002 08:16:50 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA02733; Fri, 1 Mar 2002 08:16:50 +1100 (AEDT) Date: Fri, 1 Mar 2002 08:16:49 +1100 From: Nathan Scott To: Alvaro Figueroa Cc: XFS to linux port mailing list Subject: Re: mkfs.xfs says "can't determine device size" Message-ID: <20020301081649.T193798@wobbly.melbourne.sgi.com> References: <1014920792.17527.12.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014920792.17527.12.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Thu, Feb 28, 2002 at 12:26:32PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Feb 28, 2002 at 12:26:32PM -0600, Alvaro Figueroa wrote: > mkfs -t xfs -f /dev/scsi/host1/bus0/target8/lun0/part1 > > mkfs.xfs: warning - cannot set blocksize on block device > /dev/scsi/host1/bus0/target8/lun0/part1: Invalid argument > ... > Any ideas? > The device driver you're using doesn't support the BLKBSZSET ioctl. It should also be returning ENOTTY (rather than EINVAL) according to a recent discussion on linux-kernel for ioctl commands which it doesn't recognise. [ Is there a FAQ entry for this one, Seth? ] > mkfs.xfs: can't determine device size I assume you're using mkfs from xfsprogs-2.0.0 -- in which case, your device driver also doesn't support the BLKGETSIZE64 ioctl. This second one is fatal because mkfs needs to know how big your device is. You should be able to make some more progress using a filesystem in a regular file - from a quick look in the code, that short-circuits out before issuing the ioctl. Otherwise, you will need to contact the author for your device driver I think, and see if they have fixed this. [ Eric, I wonder if we should issue a warning here and fall back to the old BLKGETSIZE ioctl if BLKGETSIZE64 fails? ] cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 28 14:24:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SMO3Y26387 for linux-xfs-outgoing; Thu, 28 Feb 2002 14:24:03 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SMNp926363 for ; Thu, 28 Feb 2002 14:23:51 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 NAA17406 for ; Thu, 28 Feb 2002 13:19:22 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA50537; Thu, 28 Feb 2002 15:22:29 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA81619; Thu, 28 Feb 2002 15:22:29 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g1SLMIU31881; Thu, 28 Feb 2002 15:22:18 -0600 Subject: Re: mkfs.xfs says "can't determine device size" From: Steve Lord To: Nathan Scott Cc: Alvaro Figueroa , XFS to linux port mailing list In-Reply-To: <20020301081649.T193798@wobbly.melbourne.sgi.com> References: <1014920792.17527.12.camel@lucy> <20020301081649.T193798@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 28 Feb 2002 15:22:18 -0600 Message-Id: <1014931338.24566.137.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-28 at 15:16, Nathan Scott wrote: > On Thu, Feb 28, 2002 at 12:26:32PM -0600, Alvaro Figueroa wrote: > > mkfs -t xfs -f /dev/scsi/host1/bus0/target8/lun0/part1 > > > > mkfs.xfs: warning - cannot set blocksize on block device > > /dev/scsi/host1/bus0/target8/lun0/part1: Invalid argument > > ... > > Any ideas? > > > > The device driver you're using doesn't support the BLKBSZSET ioctl. > It should also be returning ENOTTY (rather than EINVAL) according > to a recent discussion on linux-kernel for ioctl commands which it > doesn't recognise. > > [ Is there a FAQ entry for this one, Seth? ] > > > mkfs.xfs: can't determine device size > > I assume you're using mkfs from xfsprogs-2.0.0 -- in which case, > your device driver also doesn't support the BLKGETSIZE64 ioctl. > > This second one is fatal because mkfs needs to know how big your > device is. You should be able to make some more progress using > a filesystem in a regular file - from a quick look in the code, > that short-circuits out before issuing the ioctl. Otherwise, you > will need to contact the author for your device driver I think, > and see if they have fixed this. Does a mkfs with a -d size=xxxxb still do the ioctl call? Probably since it is in the initialization code isn't it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Feb 28 14:27:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SMRxm26610 for linux-xfs-outgoing; Thu, 28 Feb 2002 14:27:59 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SMRt926588 for ; Thu, 28 Feb 2002 14:27:55 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA17801 for ; Thu, 28 Feb 2002 13:23:27 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02427; Fri, 1 Mar 2002 08:26:22 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA03461; Fri, 1 Mar 2002 08:26:21 +1100 (AEDT) Date: Fri, 1 Mar 2002 08:26:21 +1100 From: Nathan Scott To: Steve Lord Cc: Alvaro Figueroa , XFS to linux port mailing list Subject: Re: mkfs.xfs says "can't determine device size" Message-ID: <20020301082621.U193798@wobbly.melbourne.sgi.com> References: <1014920792.17527.12.camel@lucy> <20020301081649.T193798@wobbly.melbourne.sgi.com> <1014931338.24566.137.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014931338.24566.137.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Feb 28, 2002 at 03:22:18PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Feb 28, 2002 at 03:22:18PM -0600, Steve Lord wrote: > On Thu, 2002-02-28 at 15:16, Nathan Scott wrote: > > I assume you're using mkfs from xfsprogs-2.0.0 -- in which case, > > your device driver also doesn't support the BLKGETSIZE64 ioctl. > > > > This second one is fatal because mkfs needs to know how big your > > device is. You should be able to make some more progress using > > a filesystem in a regular file - from a quick look in the code, > > that short-circuits out before issuing the ioctl. Otherwise, you > > will need to contact the author for your device driver I think, > > and see if they have fixed this. > > Does a mkfs with a -d size=xxxxb still do the ioctl call? Probably > since it is in the initialization code isn't it. yes, looks like it does still do the ioctl in that case. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 28 15:50:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1SNodc28273 for linux-xfs-outgoing; Thu, 28 Feb 2002 15:50:39 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1SNoZ928248 for ; Thu, 28 Feb 2002 15:50:35 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1008468 for ; Thu, 28 Feb 2002 23:53:15 +0100 (CET) mail_from (sandeen@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA51928; Thu, 28 Feb 2002 16:49:12 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA11038; Thu, 28 Feb 2002 16:49:12 -0600 (CST) Date: Thu, 28 Feb 2002 16:49:12 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Nathan Scott cc: Alvaro Figueroa , XFS to linux port mailing list Subject: Re: mkfs.xfs says "can't determine device size" In-Reply-To: <20020301081649.T193798@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 1 Mar 2002, Nathan Scott wrote: > [ Eric, I wonder if we should issue a warning here and fall back > to the old BLKGETSIZE ioctl if BLKGETSIZE64 fails? ] Yep, was just thinking this... -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 28 16:01:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2101Ih28716 for linux-xfs-outgoing; Thu, 28 Feb 2002 16:01:18 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2101B928694 for ; Thu, 28 Feb 2002 16:01:11 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g1SMxVD18247; Thu, 28 Feb 2002 16:59:31 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: mkfs.xfs says "can't determine device size" From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020301081649.T193798@wobbly.melbourne.sgi.com> References: <1014920792.17527.12.camel@lucy> <20020301081649.T193798@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Feb 2002 16:59:31 -0600 Message-Id: <1014937171.17485.30.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The device driver you're using doesn't support the BLKBSZSET ioctl. > It should also be returning ENOTTY (rather than EINVAL) according > to a recent discussion on linux-kernel for ioctl commands which it > doesn't recognise. I might be talking rubish[1], but this is plain scsi disk. What specific device is lacking this support? Should I report this to the vger lkml? What should I say? > > mkfs.xfs: can't determine device size > > I assume you're using mkfs from xfsprogs-2.0.0 -- in which case, > your device driver also doesn't support the BLKGETSIZE64 ioctl. Yes. > This second one is fatal because mkfs needs to know how big your > device is. You should be able to make some more progress using > a filesystem in a regular file Should a raid or LVM object do it? [1] I'm still a begginer at trying to know the kernel insternals, and I still haven't read the ioctrl section ;), so... -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Feb 28 16:23:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g210Nl229224 for linux-xfs-outgoing; Thu, 28 Feb 2002 16:23:47 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g210Nf929202 for ; Thu, 28 Feb 2002 16:23:41 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA00842 for ; Thu, 28 Feb 2002 15:19:12 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03309; Fri, 1 Mar 2002 10:21:58 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA93775; Fri, 1 Mar 2002 10:21:57 +1100 (AEDT) Date: Fri, 1 Mar 2002 10:21:57 +1100 From: Nathan Scott To: Alvaro Figueroa Cc: XFS to linux port mailing list Subject: Re: mkfs.xfs says "can't determine device size" Message-ID: <20020301102157.Z193798@wobbly.melbourne.sgi.com> References: <1014920792.17527.12.camel@lucy> <20020301081649.T193798@wobbly.melbourne.sgi.com> <1014937171.17485.30.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014937171.17485.30.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Thu, Feb 28, 2002 at 04:59:31PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Alvaro, On Thu, Feb 28, 2002 at 04:59:31PM -0600, Alvaro Figueroa wrote: > > The device driver you're using doesn't support the BLKBSZSET ioctl. > > It should also be returning ENOTTY (rather than EINVAL) according > > to a recent discussion on linux-kernel for ioctl commands which it > > doesn't recognise. > > I might be talking rubish[1], but this is plain scsi disk. What specific > device is lacking this support? > Should I report this to the vger lkml? What should I say? You can tell which SCSI device driver is in use by looking in /proc/scsi/scsi (at least, that works on my system). Then you should look up that driver in the kernel MAINTAINERS file (linux/MAINTAINERS in XFS CVS tree) and send that person an email asking them whether the issue is known (just forward them my earlier mail if you like). > > > mkfs.xfs: can't determine device size > > > > I assume you're using mkfs from xfsprogs-2.0.0 -- in which case, > > your device driver also doesn't support the BLKGETSIZE64 ioctl. > > Yes. > > > This second one is fatal because mkfs needs to know how big your > > device is. You should be able to make some more progress using > > a filesystem in a regular file > > Should a raid or LVM object do it? All block devices should support these two ioctls, but some do not. I think LVM still does not support BLKBSZSET for example, but I'm not sure on that one (it was awhile ago last time I saw that complaint on the LVM list). > [1] I'm still a begginer at trying to know the kernel insternals, and I > still haven't read the ioctrl section ;), so... No problem. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 28 16:30:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g210Udk29437 for linux-xfs-outgoing; Thu, 28 Feb 2002 16:30:39 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g210UX929411 for ; Thu, 28 Feb 2002 16:30:34 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1007573 for ; Fri, 1 Mar 2002 00:33:14 +0100 (CET) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA49422 for ; Thu, 28 Feb 2002 17:29:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA13910 for ; Thu, 28 Feb 2002 17:29:15 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g1SNTFV26631; Thu, 28 Feb 2002 17:29:15 -0600 Message-Id: <200202282329.g1SNTFV26631@stout.americas.sgi.com> Date: Thu, 28 Feb 2002 17:29:15 -0600 From: Eric Sandeen Subject: TAKE - libxfs: Fall back to BLKGETSIZE if necessary Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Feb 28 15:28:05 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:113021a cmd/xfsprogs/doc/CHANGES - 1.56 - Document BLKGETSIZE64->BLKGETSIZE fallback cmd/xfsprogs/libxfs/init.c - 1.13 - If BLKGETSIZE64 fails, try BLKGETSIZE From owner-linux-xfs@oss.sgi.com Thu Feb 28 16:41:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g210fpR29762 for linux-xfs-outgoing; Thu, 28 Feb 2002 16:41:51 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g210fX929739 for ; Thu, 28 Feb 2002 16:41:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1008884 for ; Fri, 1 Mar 2002 00:44:11 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA28152; Fri, 1 Mar 2002 10:40:09 +1100 (EST) Date: Fri, 1 Mar 2002 10:40:09 +1100 (EST) From: Nathan Scott Message-Id: <200202282340.KAA28152@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ag@bestbits.at Subject: TAKE - minor attr/acl userspace update Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We should now be in sync, I think Andreas. cheers. Date: Thu Feb 28 15:38:36 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:113022a attr/VERSION - 1.14 attr/doc/CHANGES - 1.16 attr/debian/changelog - 1.15 attr/libattr/syscalls.c - 1.7 attr/test/attr.test - 1.2 - bump version, incorporate Andreas test update & ARM syscalls. acl/VERSION - 1.19 acl/doc/CHANGES - 1.22 acl/debian/changelog - 1.12 - bump version, incorporate Andreas' last round of patches. acl/man/man1/getfacl.1 - 1.5 acl/man/man1/setfacl.1 - 1.6 acl/libacl/libobj.h - 1.2 acl/libacl/libacl.h - 1.2 acl/libacl/acl_valid.c - 1.4 acl/libacl/acl_to_text.c - 1.2 acl/libacl/acl_to_any_text.c - 1.2 acl/libacl/acl_size.c - 1.2 acl/libacl/acl_set_tag_type.c - 1.2 acl/libacl/acl_set_qualifier.c - 1.2 acl/libacl/acl_set_permset.c - 1.2 acl/libacl/acl_set_file_mode.c - 1.2 acl/libacl/acl_set_file.c - 1.2 acl/libacl/acl_set_fd_mode.c - 1.2 acl/libacl/acl_set_fd.c - 1.2 acl/libacl/acl_init.c - 1.2 acl/libacl/acl_get_tag_type.c - 1.2 acl/libacl/acl_get_qualifier.c - 1.2 acl/libacl/acl_get_permset.c - 1.2 acl/libacl/acl_get_perm.c - 1.2 acl/libacl/acl_get_file_mode.c - 1.2 acl/libacl/acl_get_file.c - 1.2 acl/libacl/acl_get_fd_mode.c - 1.2 acl/libacl/acl_get_fd.c - 1.2 acl/libacl/acl_get_entry.c - 1.2 acl/libacl/acl_from_text.c - 1.3 acl/libacl/acl_from_mode.c - 1.2 acl/libacl/acl_free.c - 1.2 acl/libacl/acl_extended_file.c - 1.2 acl/libacl/acl_extended_fd.c - 1.2 acl/libacl/acl_error.c - 1.2 acl/libacl/acl_equiv_mode.c - 1.2 acl/libacl/acl_entry_to_any_str.c - 1.3 acl/libacl/acl_entries.c - 1.2 acl/libacl/acl_dup.c - 1.2 acl/libacl/acl_delete_perm.c - 1.2 acl/libacl/acl_delete_entry.c - 1.2 acl/libacl/acl_delete_def_file.c - 1.4 acl/libacl/acl_create_entry.c - 1.2 acl/libacl/acl_copy_int.c - 1.2 acl/libacl/acl_copy_ext.c - 1.2 acl/libacl/acl_copy_entry.c - 1.2 acl/libacl/acl_cmp.c - 1.2 acl/libacl/acl_clear_perms.c - 1.2 acl/libacl/acl_check.c - 1.2 acl/libacl/acl_calc_mask.c - 1.2 acl/libacl/acl_add_perm.c - 1.2 acl/libacl/__acl_to_xattr.h - 1.2 acl/libacl/__acl_to_xattr.c - 1.2 acl/libacl/__acl_reorder_obj_p.c - 1.2 acl/libacl/__acl_from_xattr.c - 1.2 - minor formatting changes to functions, one/two little bug fixes (in acl_from_text and acl_delete_def_file); man page updates. From owner-linux-xfs@oss.sgi.com Thu Feb 28 17:22:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g211MN830623 for linux-xfs-outgoing; Thu, 28 Feb 2002 17:22:23 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g211MH930601 for ; Thu, 28 Feb 2002 17:22:17 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g210KbD18306; Thu, 28 Feb 2002 18:20:37 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: mkfs.xfs says "can't determine device size" From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020301102157.Z193798@wobbly.melbourne.sgi.com> References: <1014920792.17527.12.camel@lucy> <20020301081649.T193798@wobbly.melbourne.sgi.com> <1014937171.17485.30.camel@lucy> <20020301102157.Z193798@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Feb 2002 18:20:36 -0600 Message-Id: <1014942036.17527.32.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > You can tell which SCSI device driver is in use by looking > in /proc/scsi/scsi (at least, that works on my system). I don't have a scsi x86 box at hand, but what appears at /proc/scsi/scsi are the attatched devices (from all scsi controlers). But that disc is attatched to a QLogic SBus SCSI controller. $ cat /proc/scsi/qlogicpti/1 PTI Qlogic,ISP SBUS SCSI irq 53 regs at fd01e000 > Then you should look up that driver in the kernel MAINTAINERS > file (linux/MAINTAINERS in XFS CVS tree) and send that person > an email asking them whether the issue is known (just forward > them my earlier mail if you like). I haven't been able to found a reference to that card at that file, aldo I can almost bet that its mantainer its David S. Miller. I'm gonna write it to sparclinux@vger.kernel.org. > All block devices should support these two ioctls, but some do > not. Ok. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Feb 28 18:07:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21274D31514 for linux-xfs-outgoing; Thu, 28 Feb 2002 18:07:04 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2126u931488 for ; Thu, 28 Feb 2002 18:06:57 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g21158R18368; Thu, 28 Feb 2002 19:05:08 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Does the qlogic drive supports properly BLKBSZSET and BLKGETSIZE64 ioctrls? From: Alvaro Figueroa To: Linux Sparc Vger Maling List Cc: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Feb 2002 19:05:07 -0600 Message-Id: <1014944707.17527.36.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm testing XFS on a ultra1 with an extra qlogic sbus card. As I was trying to format a partition on a disc attatched to the qlogic card, mkfs.xfs retunrned a couple of errors, that, as the guys from the XFS list told me, has to do with the qlogic driver that doesn't support certain ioctrls. The "mentioned" ioctls are BLKBSZSET (it returned an improper error value) and BLKGETSIZE64. Please, read mail were they mention this at http://marc.theaimsgroup.com/?l=linux-xfs&m=101493112804964&w=2, and the thread at http://marc.theaimsgroup.com/?t=101492099300002&r=1&w=2 In advance, thanks a lot. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Feb 28 18:55:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g212tlP32422 for linux-xfs-outgoing; Thu, 28 Feb 2002 18:55:47 -0800 Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g212tf932398 for ; Thu, 28 Feb 2002 18:55:41 -0800 Received: from starfleet.attglobal.net (slip-32-100-182-239.wi.us.prserv.net[32.100.182.239]) by prserv.net (out2) with ESMTP id <20020301015523202050vev6e>; Fri, 1 Mar 2002 01:55:25 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g211t1p11567 for linux-xfs@oss.sgi.com; Thu, 28 Feb 2002 19:55:01 -0600 Date: Thu, 28 Feb 2002 19:55:01 -0600 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: 2.4.18 support? Message-ID: <20020301015501.GA7814@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net X-Mailer: Mutt 1.3.27i (2002-01-22) X-System: Dual i686 Xeon 450MHz with 256MB ECC-SDRAM X-Machine: IBM Intellistation Z Pro 686522U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.16 Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.0-7.13 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I realize it is very soon, but how long will it take for XFS to be released for the 2.4.18 kernel? --=20 -- Skylar Thompson (skylar@attglobal.net) --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ft90nMU1m27tfjARAnQeAJ9y7s5kXF67ucZkuKKbfR7bMZbedwCgkVi4 53cI4rswimA49fq+A+geAFM= =xuVn -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-linux-xfs@oss.sgi.com Thu Feb 28 18:59:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g212xMc32583 for linux-xfs-outgoing; Thu, 28 Feb 2002 18:59:22 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g212xJ932558 for ; Thu, 28 Feb 2002 18:59:19 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA02696 for ; Thu, 28 Feb 2002 18:00:48 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04658; Fri, 1 Mar 2002 12:57:56 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA79758; Fri, 1 Mar 2002 12:57:54 +1100 (AEDT) Date: Fri, 1 Mar 2002 12:57:54 +1100 From: Nathan Scott To: Skylar Thompson Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 support? Message-ID: <20020301125754.C193798@wobbly.melbourne.sgi.com> References: <20020301015501.GA7814@starfleet.attglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020301015501.GA7814@starfleet.attglobal.net>; from skylar@starfleet.attglobal.net.sgi.com on Thu, Feb 28, 2002 at 07:55:01PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Feb 28, 2002 at 07:55:01PM -0600, Skylar Thompson wrote: > I realize it is very soon, but how long will it take for XFS to be released > for the 2.4.18 kernel? > > -- > -- Skylar Thompson (skylar@attglobal.net) CVS has been at 2.4.18 for all of this week. The patches should be available early next week, I believe. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 28 19:00:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2130HZ00302 for linux-xfs-outgoing; Thu, 28 Feb 2002 19:00:17 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2130D932747 for ; Thu, 28 Feb 2002 19:00:14 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g211wXp18412; Thu, 28 Feb 2002 19:58:33 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: 2.4.18 support? From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020301015501.GA7814@starfleet.attglobal.net> References: <20020301015501.GA7814@starfleet.attglobal.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Feb 2002 19:58:33 -0600 Message-Id: <1014947913.17527.40.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I realize it is very soon, but how long will it take for XFS to be released > for the 2.4.18 kernel? The current CVS tree is already build under 2.4.18. A weekly snapshot will be created this weekend. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Feb 28 19:10:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g213APv00590 for linux-xfs-outgoing; Thu, 28 Feb 2002 19:10:25 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g213AG900567 for ; Thu, 28 Feb 2002 19:10:17 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g213AAFH006955 for ; Thu, 28 Feb 2002 19:10:11 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA92519; Fri, 1 Mar 2002 13:08:53 +1100 (EST) Date: Fri, 1 Mar 2002 13:08:53 +1100 (EST) From: Nathan Scott Message-Id: <200203010208.NAA92519@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: jack@ucw.cz Subject: TAKE - New VFS quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This incorporates the 32bit UID/GID VFS quota patch from Jan Kara, and adds the extra quotactl patch for XFS support too. If you are a quota user on ext2/ext3/ufs/udf, this affects you and you should read the convertquota(1) man page. If you have been using one of the SGI-modified Redhat releases that we've put out in the past, and you use quota on ext2/ext3/ufs/udf, then you are already running this code. *** This change does not affect people using XFS quota at all. *** I expect to incorporate a new set of changes from Jan sometime in the next couple of weeks also. Jan's next patchset allows the two VFS quota formats to coexist (ie. his new format as well as the one in Linus' kernels) in the same kernel. There'll be some new config options then, allowing support for either one or both formats to be selected, and also allowing them to be built as modules. But thats not quite ready yet - just an appetiser for Jan's current work. cheers. Date: Thu Feb 28 17:47:17 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:113039a cmd/xfsmisc/quota-patch-2.4.17-3.diff - 1.1 - Jan Kara's 32 bit UID quota patch, now used in XFS kernel code also. cmd/xfsmisc/README - 1.8 - Add several notes about the quota patches in this directory. Modid: 2.4.x-xfs:slinx:113039b linux/include/linux/quotaops.h - 1.12 linux/include/linux/quota.h - 1.8 linux/include/asm-sparc64/ioctls.h - 1.3 linux/include/asm-sparc/ioctls.h - 1.3 linux/include/asm-m68k/ioctls.h - 1.3 linux/include/asm-i386/ioctls.h - 1.3 linux/include/asm-alpha/ioctls.h - 1.5 linux/arch/sparc64/kernel/sys_sparc32.c - 1.41 linux/include/asm-sh/ioctls.h - 1.4 linux/arch/ia64/ia32/sys_ia32.c - 1.19 linux/include/asm-ia64/ioctls.h - 1.2 linux/include/asm-parisc/ioctls.h - 1.2 linux/include/asm-cris/ioctls.h - 1.2 linux/fs/ioctl.c - 1.12 linux/fs/inode.c - 1.61 - Modifications from Jan Kara's 32 bit UID quota patch. linux/fs/super.c - 1.73 linux/fs/noquot.c - 1.8 linux/fs/dquot.c - 1.45 linux/fs/quota.c - 1.5 linux/include/linux/fs.h - 1.143 - Modifications from Jan Kara's 32 bit UID quota patch + XFS support. From owner-linux-xfs@oss.sgi.com Thu Feb 28 20:10:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g214A9S01798 for linux-xfs-outgoing; Thu, 28 Feb 2002 20:10:09 -0800 Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g214A5901776 for ; Thu, 28 Feb 2002 20:10:05 -0800 Received: from user-1120ejj.dsl.mindspring.com ([66.32.58.115] helo=waltsathlon.localhost.net) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16gdQo-0005fB-00 for linux-xfs@oss.sgi.com; Thu, 28 Feb 2002 22:10:02 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id BE02A818617 for ; Thu, 28 Feb 2002 19:09:16 -0800 (PST) Message-ID: <3C7EF0DC.5070101@mindspring.com> Date: Thu, 28 Feb 2002 19:09:16 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Fwd: Geocrawler.com - linux-kernel - Congrats Marcelo, Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Interesting post on lkml regarding XFS in the mainstream 2.4 kernel series. Maybe alan is the man to talk to? I sure would like to see this become part of the kernel as opposed to patching everytime. Although, I must say, the folks at SGI have done a wonderful job of staying on top of every release, bug fixes etc... From owner-linux-xfs@oss.sgi.com Thu Feb 28 20:23:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g214Nps02215 for linux-xfs-outgoing; Thu, 28 Feb 2002 20:23:51 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g214Ng902191 for ; Thu, 28 Feb 2002 20:23:42 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA04603 for ; Thu, 28 Feb 2002 19:23:41 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA81038 for linux-xfs@oss.sgi.com; Fri, 1 Mar 2002 14:22:22 +1100 (EST) Date: Fri, 1 Mar 2002 14:22:22 +1100 (EST) From: Nathan Scott Message-Id: <200203010322.OAA81038@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 2.5 merge of new VFS quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Feb 28 19:20:24 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs Author: nathans Merged by: nathans Merged mods: 2.4.x-xfs:slinx:113039b The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:113039b linux/include/linux/quotaops.h - 1.14 linux/include/linux/quota.h - 1.9 linux/include/asm-sparc64/ioctls.h - 1.3 linux/include/asm-sparc/ioctls.h - 1.3 linux/include/asm-m68k/ioctls.h - 1.3 linux/include/asm-i386/ioctls.h - 1.3 linux/include/asm-alpha/ioctls.h - 1.5 linux/arch/sparc64/kernel/sys_sparc32.c - 1.44 linux/include/asm-sh/ioctls.h - 1.4 linux/arch/ia64/ia32/sys_ia32.c - 1.20 linux/include/asm-ia64/ioctls.h - 1.2 linux/include/asm-parisc/ioctls.h - 1.2 linux/include/asm-cris/ioctls.h - 1.2 linux/fs/ioctl.c - 1.13 linux/fs/inode.c - 1.67 - Merge of 2.4.x-xfs:slinx:113039b by nathans. Modifications from Jan Kara's 32 bit UID quota patch. linux/include/linux/fs.h - 1.155 linux/fs/super.c - 1.77 linux/fs/noquot.c - 1.8 linux/fs/dquot.c - 1.51 linux/fs/quota.c - 1.5 - Merge of 2.4.x-xfs:slinx:113039b by nathans. Modifications from Jan Kara's 32 bit UID quota patch + XFS support. From owner-linux-xfs@oss.sgi.com Thu Feb 28 21:33:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g215XP903401 for linux-xfs-outgoing; Thu, 28 Feb 2002 21:33:25 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g215XJ903379 for ; Thu, 28 Feb 2002 21:33:19 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.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 UAA01529 for ; Thu, 28 Feb 2002 20:28:51 -0800 (PST) mail_from (sandeen@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA54716; Thu, 28 Feb 2002 22:32:02 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA67462; Thu, 28 Feb 2002 22:32:02 -0600 (CST) Date: Thu, 28 Feb 2002 22:32:01 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "FORRESTER,JUSTIN (HP-Loveland,ex1)" cc: "'Steve Lord'" , "'Xfs Mailing List (E-mail)'" Subject: RE: oops umounting full LVM snapshots In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Justin, I was going to do something like this tomorrow, but I keep getting sidetracked on trying to figure out more about what's going on - like why this is only a problem on IDE, not SCSI...? -Eric On Thu, 28 Feb 2002, FORRESTER,JUSTIN (HP-Loveland,ex1) wrote: > > I was able to get rid of the problem with a simple hack to clear out the > quota flags in the [in-core] sb if we're mounted ro. The fs shutdown > problem went away, as did the subsequent oops. fyi. > > Justin > >