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 20