From owner-linux-xfs@oss.sgi.com Sat Mar 1 03:54:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 03:54:28 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h21BsNeA006459 for ; Sat, 1 Mar 2003 03:54:24 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18p5ZO-0003JY-00 for linux-xfs@oss.sgi.com; Sat, 01 Mar 2003 12:54:22 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18p5Tg-0006bx-00; Sat, 01 Mar 2003 12:48:28 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Bernhard Erdmann Subject: Re: XFS version 1 on linux Date: Sat, 1 Mar 2003 12:48:33 +0100 User-Agent: KMail/1.5 Cc: Christopher Pelton , linux-xfs@oss.sgi.com References: <200302280906.16457.juergen.sauer@automatix.de> <3E6050F2.3000908@berdmann.de> In-Reply-To: <3E6050F2.3000908@berdmann.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303011248.37172.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h21BsOeA006460 X-archive-position: 2987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 1. März 2003 07:19 schrieb Bernhard Erdmann: > Juergen Sauer wrote: > [...] > > Ok, all that should work, really. > > You shold be able to: > > - transfer the DVDs > > - transfer the Harddisks > > - Install Linux on the SGI machine (http://www.debian.org) > > > > First, you may Check it / Test is before you do the real work: > > You find at: http://www.knopper.net/knoppix/ > > an single iso-CD Linux, ready to run without installing anything, just > > burn it to CD. > > It has the current XFS included and you may test your datatransfer > > work without any risks. > I guess this SGI box has one or more MIPS CPU - Knoppix is for the i386 > architecture. Of course, Knoppix is to test out on PC/i386 Achitecture. You need a MIPS Distribution for Running on SGI Hardware, there a lot aroud. mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+YJ4TW7UKI9EqarERAs4wAKDULKpngIVtTNr1+TLRNQ04B0nlZgCeKUCY La1SDl/hVkk8xZJHJBHiYqw= =f+7K -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Mar 1 05:44:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 05:44:11 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h21Di7eA008164 for ; Sat, 1 Mar 2003 05:44:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h21Di2Kp009561 for ; Sat, 1 Mar 2003 05:44:02 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA18290; Sat, 1 Mar 2003 07:44:01 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-24.corp.sgi.com [134.15.64.24]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA66020; Sat, 1 Mar 2003 07:44:00 -0600 (CST) Subject: Re: Compile Error....kmem_zalloc From: Stephen Lord To: Scott Jepson Cc: Marc Schmitt , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Mar 2003 07:42:44 -0600 Message-Id: <1046526165.1711.38.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2003-02-28 at 11:04, Scott Jepson wrote: > Looks like I'm running a different qlogin driver: > > kernel: 2.4.20 > XFS: 1.2.0 > qla2xxx: qla2x00-v6.04.00b8 I am running this version - but xfs is built in and the driver is a module. Steve From owner-linux-xfs@oss.sgi.com Sat Mar 1 09:30:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 09:30:36 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h21HU9eA010162 for ; Sat, 1 Mar 2003 09:30:10 -0800 Received: from [209.96.179.24] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18pABC-000Etv-00; Sat, 01 Mar 2003 11:49:42 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h21GXJr22449; Sat, 1 Mar 2003 11:33:19 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h21GXFUY004011; Sat, 1 Mar 2003 11:33:15 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h21GX9X9004004; Sat, 1 Mar 2003 11:33:09 -0500 Date: Sat, 1 Mar 2003 11:33:09 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Cc: linux-list@ssc.com, ext3-users@redhat.com Subject: Re: XFS vs. ext3 Message-ID: <20030301163305.GA3906@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-list@ssc.com, ext3-users@redhat.com References: <20030226044329.GP2107@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030226044329.GP2107@dkp.com> User-Agent: Mutt/1.4i X-archive-position: 2989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shannon@widomaker.com Precedence: bulk X-list: linux-xfs On Tue, Feb 25, 2003 at 11:43:30PM -0500, Andrew Klaassen wrote: > In our last IMAX film project, right at crunch time, we were > getting a whole bunch of dropped frames during compositing. Our > compositing program would report "invalid file" partway through > writing, and move on to the next frame. I assume you are getting the error on the Windows machine, correct? If that's true, I don't know you can blame ext3. For one thing, you cannot drop a frame or anything due to a particular filesystem unless there is an error; the filesystem code has failed. This should show up as a serious problem or at least a system log entry. Did you check the Linux side of things, in Samba and system logs? I guess I'm trying to figure out how you know it is the filesystem. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Sat Mar 1 21:05:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 21:05:38 -0800 (PST) Received: from c2mailgw02.mailcentro.net (c2gw.mailcentro.com [207.183.238.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h2255ZeA015880 for ; Sat, 1 Mar 2003 21:05:35 -0800 Received: from c2web201 (207.183.238.51) by c2mailgw02.mailcentro.net (NPlex 6.0.045) id 3E615A3500021C5C for linux-xfs@oss.sgi.com; Sat, 1 Mar 2003 20:07:00 -0800 X-Version: Mailcentro 1.0 X-SenderIP: 68.46.72.236 X-SenderID: 5759619 From: "Vash the Stampede" Message-Id: <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Date: Sat, 1 Mar 2003 23:11:31 -0500 X-Priority: Normal Content-Type: text/html To: linux-xfs@oss.sgi.com Reply-To: Webmaster@kkpc.zzn.com Subject: XFS Problem - mkfs.xfs: No such file or directory X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-archive-position: 2990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: webmaster@kkpc.zzn.com Precedence: bulk X-list: linux-xfs
mymachine dev # mkfs -t xfs /dev/hda5
mkfs.xfs: No such file or directory
mymachine dev # uname -a
Linux mymachine.mydomain.com 2.4.19-xfs #2 Sat Mar 1
22:41:09 EST 2003          own CPU Type AuthenticAMD
GNU/Linux


That's the output of my console. I cannot figure out why this isn't
working, but it isn't. I patched my kernel using the XFS 1.2
Release patch on a 2.4.19 vanilla-sources kernel from kernel.org

I'm in desperate need of an answer for this problem, since I need
to make a partition soon.



Get your Free E-mail at http://kkpc.zzn.com
___________________________________________________________
Get your own Web-based E-mail Service at http://www.zzn.com

From owner-linux-xfs@oss.sgi.com Sat Mar 1 21:22:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 21:22:17 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h225MAeA016425 for ; Sat, 1 Mar 2003 21:22:12 -0800 Received: (qmail 29871 invoked from network); 2 Mar 2003 05:22:08 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Mar 2003 05:22:08 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id C4366300087; Sun, 2 Mar 2003 16:22:06 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id A69018F; Sun, 2 Mar 2003 16:22:06 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Webmaster@kkpc.zzn.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Problem - mkfs.xfs: No such file or directory In-reply-to: Your message of "Sat, 01 Mar 2003 23:11:31 CDT." <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Mar 2003 16:22:01 +1100 Message-ID: <22247.1046582521@ocs3.intra.ocs.com.au> X-archive-position: 2991 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 1 Mar 2003 23:11:31 -0500, "Vash the Stampede" wrote: > Please send in plain text to this list, not html. >mkfs.xfs: No such file or directory What does 'ldd -v /sbin/mkfs.xfs' report? From owner-linux-xfs@oss.sgi.com Sat Mar 1 21:25:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 21:25:58 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h225PueA016866 for ; Sat, 1 Mar 2003 21:25:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h225PoKp007602 for ; Sat, 1 Mar 2003 21:25:50 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA04579; Sat, 1 Mar 2003 23:25:49 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id XAA22598; Sat, 1 Mar 2003 23:25:49 -0600 (CST) Date: Sat, 1 Mar 2003 23:22:45 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Vash the Stampede cc: linux-xfs@oss.sgi.com Subject: Re: XFS Problem - mkfs.xfs: No such file or directory In-Reply-To: <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by zok.sgi.com id h225PoKp007602 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h225PueA016869 X-archive-position: 2992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs You need to install the xfsprogs userspace. ftp://oss.sgi.com/projects/xfs/Release-1.2/cmd_tars -Eric On Sat, 1 Mar 2003, Vash the Stampede wrote: > mymachine dev # mkfs -t xfs /dev/hda5 > mkfs.xfs: No such file or directory > mymachine dev # uname -a > Linux mymachine.mydomain.com 2.4.19-xfs #2 Sat > Mar 1 > 22:41:09 EST 2003          own CPU Type > AuthenticAMD > GNU/Linux > > > That's the output of my console. I cannot figure > out why this isn't > working, but it isn't. I patched my kernel using > the XFS 1.2 > Release patch on a 2.4.19 vanilla-sources kernel > from kernel.org > > I'm in desperate need of an answer for this > problem, since I need > to make a partition soon. > > > > Get your Free E-mail at http://kkpc.zzn.com > ___________________________________________________________ > Get your own Web-based E-mail Service at > http://www.zzn.com > > > From owner-linux-xfs@oss.sgi.com Sun Mar 2 07:56:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 07:56:55 -0800 (PST) Received: from zafiro.ciencias.ubiobio.cl (IDENT:postfix@zafiro.ciencias.ubiobio.cl [146.83.193.221]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h22FukeA029462 for ; Sun, 2 Mar 2003 07:56:47 -0800 Received: by zafiro.ciencias.ubiobio.cl (Postfix, from userid 500) id BD48613DF8; Sun, 2 Mar 2003 12:56:40 -0300 (CLST) Received: from localhost (localhost [127.0.0.1]) by zafiro.ciencias.ubiobio.cl (Postfix) with ESMTP id AB0F313DEE; Sun, 2 Mar 2003 12:56:40 -0300 (CLST) Date: Sun, 2 Mar 2003 12:56:39 -0300 (CLST) From: Leonardo Saavedra Henriquez X-Sender: leo@zafiro.ciencias.ubiobio.cl To: Vash the Stampede Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Problem - mkfs.xfs: No such file or directory In-Reply-To: <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leo@ubiobio.cl Precedence: bulk X-list: linux-xfs On Sat, 1 Mar 2003, Vash the Stampede wrote: > I'm in desperate need of an answer for this > problem, since I need > to make a partition soon. Which Linux distributions? if is RedHat or rpm based, you need to install xfsprogs from ftp://oss.sgi.com/projects/xfs/cmd_rpms/ if your distribution is debian you only need to "apt-get it" apt-get install xfsprogs xfsdump attr attr-dev or follow the instruccion for cvs download from xfs home page and then you have to compile your self xfsprogs. -- +----------------------------------------------+ ,''`. | Leonardo Saavedra Henriquez |leo@ubiobio.cl | : :' : | Est. Ing Civil en Informatica|U. del Bio-Bio | `. `' +----------------------------------------------+ `- [leo-> ~ $] cd pub && more beer From owner-linux-xfs@oss.sgi.com Sun Mar 2 14:33:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 14:34:04 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h22MXueA032589 for ; Sun, 2 Mar 2003 14:33:58 -0800 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18pc1s-0005Df-00 for linux-xfs@oss.sgi.com; Sun, 02 Mar 2003 23:33:56 +0100 Received: from [217.88.212.121] (helo=kernelpanix.aura.of.mankind) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18pc1r-0000Ai-00 for linux-xfs@oss.sgi.com; Sun, 02 Mar 2003 23:33:56 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.6/8.11.2) id h22MSUW16501 for linux-xfs@oss.sgi.com; Sun, 2 Mar 2003 23:28:30 +0100 Date: Sun, 2 Mar 2003 23:28:30 +0100 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: [PATCH] xfs_fsr: avoid unnessary copying Message-ID: <20030302232830.A16452@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 2994 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@s2y4n2c.de Precedence: bulk X-list: linux-xfs Hi This patch moves the check for improved extent count directly after the preallocation of the extents. So it can avoid copying of the extent data in the case that no improvement is made. The patch is against current CVS. On my testsystem with 3 files which cant improved the elapsed time went down from 3min to 6s and saved about 3GB disk io. utz --- xfs_fsr.c.orig Sat Mar 1 13:53:36 2003 +++ xfs_fsr.c Sun Mar 2 23:02:25 2003 @@ -967,7 +967,8 @@ { int tfd; int srval; - int nextents, extent, cur_nextents, new_nextents; + int nextents, extent, cur_nextents; + int new_nextents = 0; unsigned blksz_dio; unsigned dio_min; struct dioattr dio; @@ -1111,6 +1112,15 @@ return -1; } } + /* Check if the extent count improved */ + new_nextents = getnextents(tfd); + if (cur_nextents <= new_nextents) { + if (vflag) + fsrprintf(_("No improvement made: %s\n"), fname); + close(tfd); + free(fbuf); + return 1; /* no change/no error */ + } for (cnt = outmap[extent].bmv_length; cnt > 0; cnt -= ct, pos += ct) { if (nfrags && --nfrags) { @@ -1195,15 +1205,6 @@ sx.sx_offset = 0; sx.sx_length = statp->bs_size; - /* Check if the extent count improved */ - new_nextents = getnextents(tfd); - if (cur_nextents <= new_nextents) { - if (vflag) - fsrprintf(_("No improvement made: %s\n"), fname); - close(tfd); - return 1; /* no change/no error */ - } - /* switch to the owner's id, to keep quota in line */ if (fchown(tfd, statp->bs_uid, statp->bs_gid) < 0) { if (vflag) From owner-linux-xfs@oss.sgi.com Sun Mar 2 15:18:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 15:19:04 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h22NIqeA000814 for ; Sun, 2 Mar 2003 15:18:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h22NIkG8031990 for ; Sun, 2 Mar 2003 15:18:46 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA29919; Sun, 2 Mar 2003 17:18:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA80928; Sun, 2 Mar 2003 17:18:46 -0600 (CST) Date: Sun, 2 Mar 2003 17:15:34 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: utz lehmann cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying In-Reply-To: <20030302232830.A16452@s2y4n2c.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Thanks Utz - Chris W. had talked about doing this too, I'm glad someone got around to it. :) I'll look at the patch more closely when I'm in the office tomorrow, but it sounds like the right thing to do. -Eric On Sun, 2 Mar 2003, utz lehmann wrote: > Hi > > This patch moves the check for improved extent count directly after the > preallocation of the extents. So it can avoid copying of the extent data in > the case that no improvement is made. The patch is against current CVS. > > On my testsystem with 3 files which cant improved the elapsed time went down > from 3min to 6s and saved about 3GB disk io. > > > utz > From owner-linux-xfs@oss.sgi.com Sun Mar 2 16:38:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 16:38:33 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h230cNeA003685 for ; Sun, 2 Mar 2003 16:38:24 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h230mbkq003975 for ; Sun, 2 Mar 2003 18:48:38 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h230ax7L482624 for ; Mon, 3 Mar 2003 11:36:59 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h230axSu481802 for linux-xfs@oss.sgi.com; Mon, 3 Mar 2003 11:36:59 +1100 (EST) Date: Mon, 3 Mar 2003 11:36:59 +1100 (EST) From: Nathan Scott Message-Id: <200303030036.h230axSu481802@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_stats.pl X-archive-position: 2996 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Cleanup code, add missing pb_get_read metric, leave quota metrics to xqmstats (in quota-tools package) giving more compact layout here. Date: Sun Mar 2 16:35:14 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:140671a cmd/xfsmisc/xfs_stats.pl - 1.4 From owner-linux-xfs@oss.sgi.com Mon Mar 3 09:55:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 09:55:17 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h23Ht7eA013489 for ; Mon, 3 Mar 2003 09:55:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h23Ht1G8025910 for ; Mon, 3 Mar 2003 09:55:01 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA33095 for ; Mon, 3 Mar 2003 11:55:01 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA52669 for ; Mon, 3 Mar 2003 11:55:01 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h23Ht0g28911; Mon, 3 Mar 2003 11:55:00 -0600 Message-Id: <200303031755.h23Ht0g28911@jen.americas.sgi.com> Date: Mon, 3 Mar 2003 11:55:00 -0600 Subject: TAKE - some optizations in writing out the xfs log To: linux-xfs@oss.sgi.com X-archive-position: 2998 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 727 Lines: 25 reduce byte swapping and spinlock usage in log write path Date: Mon Mar 3 09:54:29 PST 2003 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:140714a linux/fs/xfs/xfs_log.c - 1.265 - only update h_numlog_ops and the iclog byte offset once per use of an iclog in a transaction, instead of once per log item. Keep h_numlog_ops in host byte order until we are about to write it out, then endian flip it. linux/fs/xfs/xfs_log_priv.h - 1.86 - minor cleanup, remove function argument which was always zero linux/fs/xfs/xfs_log_recover.c - 1.257 - drop second argument from xlog_assign_tail_lsn From owner-linux-xfs@oss.sgi.com Mon Mar 3 11:20:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 11:21:04 -0800 (PST) Received: from mail.dkp.com (mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h23JKoeA019500 for ; Mon, 3 Mar 2003 11:20:53 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id DAEC82AD4F; Mon, 3 Mar 2003 14:20:49 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 3A6D72AD4E; Mon, 3 Mar 2003 14:20:49 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id 217806F017; Mon, 3 Mar 2003 14:20:47 -0500 (EST) Date: Mon, 3 Mar 2003 14:20:47 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com, linux-list@ssc.com Cc: ext3-users@redhat.com Subject: Re: XFS vs. ext3 Message-ID: <20030303192047.GC22652@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-list@ssc.com, ext3-users@redhat.com References: <20030226044329.GP2107@dkp.com> <20030301163305.GA3906@widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030301163305.GA3906@widomaker.com> User-Agent: Mutt/1.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 2999 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 1478 Lines: 40 On Sat, Mar 01, 2003 at 11:33:09AM -0500, Charles Shannon Hendrix wrote: > On Tue, Feb 25, 2003 at 11:43:30PM -0500, Andrew Klaassen wrote: > > > In our last IMAX film project, right at crunch time, we were > > getting a whole bunch of dropped frames during compositing. > > Our compositing program would report "invalid file" partway > > through writing, and move on to the next frame. > > I assume you are getting the error on the Windows machine, > correct? > > If that's true, I don't know you can blame ext3. For one > thing, you cannot drop a frame or anything due to a particular > filesystem unless there is an error; the filesystem code has > failed. This should show up as a serious problem or at least > a system log entry. > > Did you check the Linux side of things, in Samba and system > logs? > > I guess I'm trying to figure out how you know it is the > filesystem. I have no idea if it is the filesystem or not - I just know that changing the filesystem made the problem go away. My half-baked theory at this point is that XFS is less likely to respond so slowly to requests under load that Samba/Windows 2000 give up than ext3 is. I doubt there is any corruption because of gaps in the filesystem code itself. Unfortunately, my chance for further testing has been delayed, because we just lost (another) GigE blade on our Foundry switch, and there aren't enough free GigE ports to test through. Hopefully in a couple of weeks... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Mar 3 17:57:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 17:58:00 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h241vrf30185 for ; Mon, 3 Mar 2003 17:57:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h23NnBKp025839 for ; Mon, 3 Mar 2003 15:49:12 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h23Nls7L727087; Tue, 4 Mar 2003 10:47:54 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h23Nls3R727995; Tue, 4 Mar 2003 10:47:54 +1100 (EST) Date: Tue, 4 Mar 2003 10:47:54 +1100 (EST) From: Nathan Scott Message-Id: <200303032347.h23Nls3R727995@snort.melbourne.sgi.com> To: agruen@suse.de, linux-xfs@oss.sgi.com Subject: TAKE - get/setfacl error reporting X-archive-position: 3000 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 15 More error reporting tweaks from AndreasG - report errors on directories that nftw can't read. Date: Mon Mar 3 15:46:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:140780a cmd/acl/setfacl/setfacl.c - 1.9 cmd/acl/getfacl/getfacl.c - 1.11 From owner-linux-xfs@oss.sgi.com Mon Mar 3 17:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 17:58:19 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h241wFf30252 for ; Mon, 3 Mar 2003 17:58:15 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h23MfwKp015387 for ; Mon, 3 Mar 2003 14:41:59 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h23Mef7L725718; Tue, 4 Mar 2003 09:40:41 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h23Meeti725475; Tue, 4 Mar 2003 09:40:40 +1100 (EST) Date: Tue, 4 Mar 2003 09:40:40 +1100 (EST) From: Nathan Scott Message-Id: <200303032240.h23Meeti725475@snort.melbourne.sgi.com> To: agruen@suse.de, linux-xfs@oss.sgi.com Subject: TAKE - get/setfacl error reporting X-archive-position: 3001 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 353 Lines: 14 Tweak error reporting (patch from AndreasG) - also show path on error. Date: Mon Mar 3 14:40:05 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:140768a cmd/acl/setfacl/setfacl.c - 1.8 cmd/acl/getfacl/getfacl.c - 1.10 From owner-linux-xfs@oss.sgi.com Mon Mar 3 18:19:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 18:19:58 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h242Jrf00465 for ; Mon, 3 Mar 2003 18:19:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h242UFkq016602 for ; Mon, 3 Mar 2003 20:30:16 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h242IZ7L740012 for ; Tue, 4 Mar 2003 13:18:35 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h242IYf6740800 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 13:18:34 +1100 (EST) Date: Tue, 4 Mar 2003 13:18:34 +1100 (EST) From: Nathan Scott Message-Id: <200303040218.h242IYf6740800@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 3002 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 700 Lines: 23 Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. Date: Mon Mar 3 18:17:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140809a linux/fs/xfs/pagebuf/page_buf.c - 1.100 - Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. linux/fs/xfs/pagebuf/page_buf.h - 1.59 linux/fs/xfs/linux/xfs_aops.c - 1.19 - Remove an unused parameter from pagebuf_lookup. From owner-linux-xfs@oss.sgi.com Mon Mar 3 18:21:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 18:21:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h242Lnf00615 for ; Mon, 3 Mar 2003 18:21:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h242WCkq016661 for ; Mon, 3 Mar 2003 20:32:13 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h242KW7L739801 for ; Tue, 4 Mar 2003 13:20:32 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h242KV4S740761 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 13:20:31 +1100 (EST) Date: Tue, 4 Mar 2003 13:20:31 +1100 (EST) From: Nathan Scott Message-Id: <200303040220.h242KV4S740761@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - export end_buffer_io_async X-archive-position: 3003 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 438 Lines: 16 Export the end_buffer_io_async from the kernel - we need access to this in order to implement support for unwritten extents in XFS. Date: Mon Mar 3 18:19:52 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140810a linux/kernel/ksyms.c - 1.142 linux/include/linux/fs.h - 1.160 linux/fs/buffer.c - 1.116 From owner-linux-xfs@oss.sgi.com Mon Mar 3 18:27:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 18:27:07 -0800 (PST) Received: from andrei.myip.org (12-234-128-127.client.attbi.com [12.234.128.127]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h242Qof01273 for ; Mon, 3 Mar 2003 18:26:51 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 048A12FA71 for ; Mon, 3 Mar 2003 14:09:06 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 1D2592FA71 for ; Mon, 3 Mar 2003 14:09:05 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id C02641967B for ; Mon, 3 Mar 2003 14:08:54 -0800 (PST) Subject: Re: XFS vs. ext3 From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs In-Reply-To: <20030303192047.GC22652@dkp.com> References: <20030226044329.GP2107@dkp.com> <20030301163305.GA3906@widomaker.com> <20030303192047.GC22652@dkp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Mar 2003 14:08:54 -0800 Message-Id: <1046729334.20565.173.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 3004 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2518 Lines: 54 On Mon, 2003-03-03 at 11:20, Andrew Klaassen wrote: > > My half-baked theory at this point is that XFS is less likely to > respond so slowly to requests under load that Samba/Windows 2000 > give up than ext3 is. I doubt there is any corruption because > of gaps in the filesystem code itself. (I'm speaking from my own personal perspective) Or it just could be the FS itself that makes the difference. I have my share of experiences with disk-bandwidth-hungry applications on Linux. I'm doing quite a bit of work with digital video, which is a very disk-I/O intensive thing. For example, i'm capturing DV video streams (actually on Digital8 support, not proper DVCAM or DVCPRO or anything) over IEEE1394 (that's FireWire for you MacOS guys, or i.Link for the Sony gang). I'm using for that purpose an application that's the bare minimum (dvgrab) so there's no CPU overhead or anything. The process is entirely disk-I/O bound. For NTSC 720x480 interlaced 29.9fps 16bit-sound DV stream, the space requirement is like 16GB per hour. With XFS, i don't have to worry about anything, i just let it capture and do other stuff at the same time with that system. I sort of like that. :-) With Ext3 it happened, albeit rarely, to get dropped frames if i use the disks with other applications while capturing, so i have to be careful with the other stuff i'm doing with the system at the same time. ReiserFS seems to have the worst performance for this workload (albeit it's doing great for other things, i won't deny that). Even when capturing analog video, it's all the same. Capturing raw YUV is brutal; there's a huge stress on the disk I/O. It's better to not do anything else at that time, not even touch that whole spindle, no matter what's the filesystem. Capturing in lossless compressed formats is slightly better, but at the cost of some CPU effort. Capturing in lossy formats such as the MPEG4 family is a lot better from the disk p.o.v., i could use any FS i want, but then the CPU is used a lot (only when capturing high-quality material, though), so the system becomes CPU-bound. So it's a trade-off, but even then i still see XFS as being the best choice for the partition where i generate the primary files - it has the smallest percentage of lost frames in any scenario. The hardware i'm using are, typically, recent AthlonXP systems, with large non-RAID IDE drives (yeah, i know), running recent 2.4 Linux kernels. -- Florin Andrei "Do not look into laser with remaining eye." - on a laser pointer From owner-linux-xfs@oss.sgi.com Mon Mar 3 19:11:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 19:11:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h243BRf12277 for ; Mon, 3 Mar 2003 19:11:27 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h243Lnkq017808 for ; Mon, 3 Mar 2003 21:21:51 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h243A87L748885 for ; Tue, 4 Mar 2003 14:10:08 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h243A8gX754331 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 14:10:08 +1100 (EST) Date: Tue, 4 Mar 2003 14:10:08 +1100 (EST) From: Nathan Scott Message-Id: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - unwritten extents X-archive-position: 3005 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1066 Lines: 31 Support for unwritten extents. Create separate IO completion thread pools in pagebuf for log/data IO, to prevent deadlocks when scheduling iclog/unwritten extent IO completion handlers. We also no longer create as many pagebuf threads as there are CPUs, but cap this at 8 threads max (or 2 threads per CPU for machines with <=4 CPUs). cheers. Date: Mon Mar 3 19:08:37 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140814a linux/fs/xfs/xfs_buf.h - 1.104 linux/fs/xfs/pagebuf/page_buf.c - 1.101 linux/fs/xfs/pagebuf/page_buf.h - 1.60 - Create separate IO completion thread pools in pagebuf for log/data IO, to prevent deadlocks when scheduling iclog/unwritten extent IO completion handlers. We also no longer create as many pagebuf threads as there are CPUs, but cap this at 8 threads max (or 2 threads per CPU for machines with <=4 CPUs). linux/fs/xfs/linux/xfs_aops.c - 1.20 - Support for unwritten extents. From owner-linux-xfs@oss.sgi.com Mon Mar 3 19:21:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 19:21:17 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h243L8f14172 for ; Mon, 3 Mar 2003 19:21:08 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h243L70a027495 for ; Mon, 3 Mar 2003 19:21:07 -0800 From: "l.a walsh" To: Subject: Pagebuf behavior.... Date: Mon, 3 Mar 2003 19:21:07 -0800 Message-ID: <000401c2e1fd$18b732f0$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C2E1BA.0A93F2F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 3006 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 12752 Lines: 228 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2E1BA.0A93F2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Running with 2.4.20 and the early feb xfs patches, still have debug enabled....(maybe that's it?).... But, running two long-running tar/bzip2 routines (mach=2xP3-1GB)...did a chmod/chgrp -R in a directory tree that has about 185,000 files.... Seemed to take a long time. I'm used to the first of the pair taking a while if they aren't in cache. But the 2nd did as well... looked at top and saw: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 9 root 20 0 0 0 0 RW 96.8 0.0 7:58 pagebuf/0 10 root 20 0 0 0 0 SW 79.3 0.0 7:47 pagebuf/1 7 root 20 0 0 0 0 DW 18.0 0.0 7:31 kupdated 16415 root 15 0 556 556 456 D 2.8 0.0 1:25 chmod 14275 root 16 4 7784 7784 352 R N 1.7 0.7 114:08 bzip2 14405 root 17 12 7784 7784 352 R N 0.9 0.7 67:36 bzip2 16418 root 11 0 1032 1032 820 R 0.3 0.1 0:00 top --- Wow! ... seems like alot of overhead for a chmod running on one disk (SCSI). The tars were executing on a separate disk/IDE. Just a WAG, but I'm guessing this isn't normal behavior? I did dump /proc/meminfo, and slabinfo (included below) immediately after the event. System has been up for almost 7 days now, so could be some housekeeping is broken somewhere, perhaps a side effect only produced with debugging enabled? Dunno -- Very strange. meminfo: total: used: free: shared: buffers: cached: Mem: 1056473088 1047224320 9248768 0 0 402280448 Swap: 271425536 16781312 254644224 MemTotal: 1031712 kB MemFree: 9032 kB MemShared: 0 kB Buffers: 0 kB Cached: 391020 kB SwapCached: 1832 kB Active: 129052 kB Inactive: 306576 kB HighTotal: 131064 kB HighFree: 1760 kB LowTotal: 900648 kB LowFree: 7272 kB SwapTotal: 265064 kB SwapFree: 248676 kB slabinfo: ....was going to include it...but the colums are waAay wide and will certainly get malformed, so will attach it -- hopefully it will be decipherable. ------=_NextPart_000_0005_01C2E1BA.0A93F2F0 Content-Type: text/plain; name="slabinfo.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="slabinfo.txt" slabinfo - version: 1.1 (statistics) (SMP) kmem_cache 91 91 288 7 7 1 : 91 91 = 7 0 0 : 124 62 : 28 7 0 0 tcp_tw_bucket 2 40 96 1 1 1 : 280 165154 104= 1 1040 0 : 252 126 : 31482 4270 34709 0 tcp_bind_bucket 14 290 24 2 2 1 : 290 507049 5= 2 50 0 : 252 126 : 38511 4134 42577 2 tcp_open_request 0 0 64 0 0 1 : 177 82812 122= 7 1227 0 : 252 126 : 9707 2726 11206 0 inet_peer_cache 1 78 48 1 1 1 : 156 6372 2= 3 22 0 : 252 126 : 129 105 210 0 ip_fib_hash 22 145 24 1 1 1 : 145 521 = 1 0 0 : 252 126 : 26 6 9 0 ip_dst_cache 103 312 160 13 13 1 : 1176 662676 23= 9 226 0 : 252 126 : 143682 6966 150228 78 arp_cache 4 64 120 2 2 1 : 160 42863 6= 3 61 0 : 252 126 : 1990 623 2546 0 blkdev_requests 1024 1040 96 26 26 1 : 1160 1160 2= 9 3 0 : 252 126 : 1251 58 256 0 ktrace_ent 0 0 4096 0 0 1 : 0 0 = 0 0 0 : 60 30 : 0 0 0 0 ktrace_hdr 0 0 32 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 xfs_acl 0 0 312 0 0 1 : 36 9814 78= 6 786 0 : 124 62 : 427191 1603 428008 0 xfs_chashlist 15233 15246 28 121 121 1 : 23562 1854717 40= 4 283 0 : 252 126 : 157320 16084 157093 799 xfs_ili 100125 100125 156 4005 4005 1 : 100125 910347 852= 6 4521 0 : 252 126 : 357955 23151 270719 1789 xfs_ifork 30 118 64 2 2 1 : 767 35198 9= 6 94 0 : 252 126 : 8788 511 9140 33 xfs_efi_item 0 0 268 0 0 1 : 154 64924 257= 7 2577 0 : 124 62 : 200126 6550 203940 159 xfs_efd_item 0 0 268 0 0 1 : 154 68504 240= 8 2408 0 : 124 62 : 200167 6340 203940 159 xfs_buf_item 48 48 160 2 2 1 : 432 429391 333= 2 3330 0 : 252 126 : 978111 17033 991786 17 xfs_dabuf 145 145 24 1 1 1 : 145 3142176 785= 8 7857 0 : 252 126 : 27356631 47890 27396663 0 xfs_da_state 0 0 344 0 0 1 : 33 52183 405= 6 4056 0 : 124 62 : 1594104 8868 1598916 0 xfs_trans 13 13 596 1 1 2 : 416 841628 925= 4 9253 0 : 124 62 : 2121499 36198 2139577 8859 xfs_inode 438104 438104 472 54763 54763 1 : 569456 7043358 54= 3669 488906 0 : 124 62 : 6458628 1136986 6521197 92656 xfs_btree_cur 28 28 140 1 1 1 : 112 385133 1157= 6 11575 0 : 252 126 : 1427764 25430 1441618 0 xfs_bmap_free_item 0 0 20 0 0 1 : 169 384010 16= 20 1620 0 : 252 126 : 207215 5552 211147 0 page_buf_t 365 756 212 41 42 1 : 8280 4721260 1303= 5 12993 0 : 252 126 : 57055544 93467 57134484 1423 linvfs_icache 435743 435743 544 62249 62249 1 : 569443 7072240 63= 5204 572955 0 : 124 62 : 5725828 1319034 5880757 93166 nfs_write_data 0 0 352 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 nfs_read_data 0 0 336 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 nfs_page 0 0 100 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 devfsd_event 0 0 28 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 dnotify_cache 3 126 28 1 1 1 : 252 5783 = 8 7 0 : 252 126 : 142 55 186 0 file_lock_cache 20 180 108 5 5 1 : 324 1840563 85= 2 847 0 : 252 126 : 28774166 21588 28794882 0 fasync_cache 0 0 24 0 0 1 : 290 969642 7= 1 71 0 : 252 126 : 82159 8123 90211 0 uid_cache 7 113 32 1 1 1 : 226 8794 = 3 2 0 : 252 126 : 49 78 117 0 skbuff_head_cache 345 552 164 23 23 1 : 600 10485627 1= 27 104 0 : 252 126 : 11593766 86530 11628859 51084 sock 101 162 864 18 18 2 : 324 466404 88= 5 867 0 : 124 62 : 1244115 12037 1255149 19 sigqueue 28 28 140 1 1 1 : 280 1087512 1941= 1 19410 0 : 252 126 : 8688326 60678 8728672 921 kiobuf 0 0 68 0 0 1 : 112 5012 5= 0 50 0 : 252 126 : 824 143 917 0 cdev_cache 1765 1800 52 25 25 1 : 1872 31696 27= 0 245 0 : 252 126 : 22452 665 20941 141 bdev_cache 9 168 68 3 3 1 : 168 1008 = 7 4 0 : 252 126 : 169 20 173 0 mnt_cache 20 112 68 2 2 1 : 168 930 = 5 3 0 : 252 126 : 38 16 34 0 inode_cache 224 224 492 28 28 1 : 336 1131552 155= 5 1514 0 : 124 62 : 5456661 26259 5481089 118 dentry_cache 518793 518793 116 15721 15721 1 : 518793 9857984 10= 2470 7446 0 : 252 126 : 11851103 261917 11450519 41274 filp 1224 1292 112 38 38 1 : 1292 4442 3= 8 0 0 : 252 126 : 1146 116 0 0 names_cache 2 2 4096 2 2 1 : 25 48473 4272= 6 42724 0 : 60 30 : 49788723 90573 49836570 0 buffer_head 83759 178812 108 4967 4967 1 : 244944 24158109 479= 59 42992 0 : 252 126 : 37381905 276289 37476158 50536 mm_struct 185 208 152 8 8 1 : 338 433119 30= 3 295 0 : 252 126 : 1024191 4957 1028775 10 vm_area_struct 1915 2300 76 46 46 1 : 4050 5035250 75= 0 704 0 : 252 126 : 59852858 41754 59875546 16503 fs_cache 185 312 48 4 4 1 : 390 541359 3= 4 30 0 : 252 126 : 1024121 4768 1028760 37 files_cache 122 126 428 14 14 1 : 207 212135 48= 7 473 0 : 124 62 : 1024010 5332 1028687 110 signal_act 87 87 1312 29 29 1 : 153 74583 136= 2 1333 0 : 60 30 : 1023616 6605 1028432 363 size-131072(DMA) 0 0 131072 0 0 32 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-131072 0 0 131072 0 0 32 : 1 15 = 2 2 0 : 0 0 : 0 0 0 0 size-65536(DMA) 0 0 65536 0 0 16 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-65536 3 3 65536 3 3 16 : 3 3 = 3 0 0 : 0 0 : 0 0 0 0 size-32768(DMA) 0 0 32768 0 0 8 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-32768 19 19 32768 19 19 8 : 19 43 2= 7 8 0 : 0 0 : 0 0 0 0 size-16384(DMA) 0 0 16384 0 0 4 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-16384 6 6 16384 6 6 4 : 18 10195488 206= 25 20619 0 : 0 0 : 0 0 0 0 size-8192(DMA) 0 0 8192 0 0 2 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-8192 15 15 8192 15 15 2 : 25 179 5= 0 35 0 : 0 0 : 0 0 0 0 size-4096(DMA) 0 0 4096 0 0 1 : 0 0 = 0 0 0 : 60 30 : 0 0 0 0 size-4096 53 53 4096 53 53 1 : 137 222766 2666= 8 26615 0 : 60 30 : 616770 62342 646210 6181 size-2048(DMA) 0 0 2048 0 0 1 : 0 0 = 0 0 0 : 60 30 : 0 0 0 0 size-2048 112 144 2048 72 72 1 : 266 5262476 7014= 2 70070 0 : 60 30 : 22292403 327567 22408453 141269 size-1024(DMA) 0 0 1024 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 size-1024 316 316 1024 79 79 1 : 360 68572 55= 0 471 0 : 124 62 : 166917 3168 169279 21 size-512(DMA) 0 0 512 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 size-512 680 680 512 85 85 1 : 808 1063370 1174= 9 11664 0 : 124 62 : 8477136 55811 8519507 1077 size-256(DMA) 0 0 264 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 size-256 1740 1740 264 116 116 1 : 2685 4709731 402= 3 3907 0 : 124 62 : 13467588 93831 13537706 18027 size-128(DMA) 0 0 136 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 size-128 7436 7448 136 266 266 1 : 11956 3346655 171= 4 1448 0 : 252 126 : 6028515 33362 6052766 338 size-64(DMA) 0 0 72 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 size-64 14257 14257 72 269 269 1 : 36623 2291101 253= 5 2266 0 : 252 126 : 2146995 23755 2152357 1706 size-32(DMA) 0 0 40 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 size-32 82248 82248 40 894 894 1 : 96968 7739798 828= 2 7388 0 : 252 126 : 27413177 75945 27390722 8009 ------=_NextPart_000_0005_01C2E1BA.0A93F2F0-- From owner-linux-xfs@oss.sgi.com Tue Mar 4 00:14:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 00:14:52 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h248Eif20844 for ; Tue, 4 Mar 2003 00:14:44 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 87A7E14331; Tue, 4 Mar 2003 09:14:43 +0100 (MET) Date: Tue, 4 Mar 2003 09:14:42 +0100 From: Andi Kleen To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - unwritten extents Message-ID: <20030304081442.GA14913@wotan.suse.de> References: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> X-archive-position: 3007 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 177 Lines: 7 On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > Support for unwritten extents. Create separate IO completion Gratulations. Do they work fully already? -Andi From owner-linux-xfs@oss.sgi.com Tue Mar 4 01:29:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 01:30:01 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h249Tdf29228 for ; Tue, 4 Mar 2003 01:29:40 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 9D7A7AC34 for ; Tue, 4 Mar 2003 10:19:08 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id E7631190C6 for ; Tue, 4 Mar 2003 10:19:09 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 6AAE530881D for ; Tue, 4 Mar 2003 10:07:47 +0100 (CET) Message-ID: <3E646CE3.BA8A100A@ch.sauter-bc.com> Date: Tue, 04 Mar 2003 10:07:47 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Success with software RAID5 / XFS resizing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3008 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1430 Lines: 37 First I want to thank everybody involved with XFS development for the ongoing effort producing a really high quality filesystem for Linux! I have successfully upgraded my home server from 4x15G disks to 4x60G. I was afraid first but everything went so easy that I wanted to let other people know how I did it. Word of WARNING: Doing backups is strongly recommended!! This has worked for me, YMMV!! Here we go: The four 15G disks were partitioned with several small partitions for system on RAID1 and one big partition for /home on RAID5 with external v1 log on a RAID1. The RAID5 consisted of four 11G partitions located 'at the end' of each disk, resulting in a ~33G RAID5 volume. I have now replaced disk1, partitioned the new disk, and did a raidhotadd for every partition. After all volumes were synced, I replaced the same steps for disk 2-4. Now I had all disks replaced but with the same RAID and XFS volumes on it. Now I did umount /home xfs_check /dev/md8 raidstop /dev/md8 Then I used fdisk to delete the 11G partition on every disk and replaced it with a new partition with the full size but the same starting point. A reboot ensured that all partition tables were reread. (Note: one must _not_ change the chunk size or anything else in /etc/raidtab at this point!!) Now I simply did the following: mkraid /dev/md8 mount /home xfs_growfs /home and voila, /home is now 168G in size with all data in place! Simon From owner-linux-xfs@oss.sgi.com Tue Mar 4 01:54:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 01:54:28 -0800 (PST) Received: from hbcse.tifr.res.in (hbcse.tifr.res.in [158.144.44.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h249sIf30526 for ; Tue, 4 Mar 2003 01:54:19 -0800 Received: from linto (helo=localhost) by hbcse.tifr.res.in with local-esmtp (Exim 3.35 #1 (Debian)) id 18q95H-0004gR-00 for ; Tue, 04 Mar 2003 15:21:39 +0530 Date: Tue, 4 Mar 2003 15:21:38 +0530 (IST) From: "'Linto Joseph Mathew" To: linux-xfs@oss.sgi.com Subject: Problem while I formatting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3009 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linto@hbcse.tifr.res.in Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 11 I have partition (logical /dev/hda6 ) of size 16 MB.When i tried to format using mkfs.xfs (ie mkfs.xfs /dev/hda6 ) it showing that " warning - cannot set block size on bock device /dev/hda6 :Input/output error".I am not thinking that it is a H/W problem because mkfs.ext3 and mkfs.reiserfs are working on /dev/hda6.What is the minimum size required for xfs partition? Regards, Linto. From owner-linux-xfs@oss.sgi.com Tue Mar 4 02:45:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 02:45:33 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24AjSf02753 for ; Tue, 4 Mar 2003 02:45:28 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 9309359D385; Tue, 4 Mar 2003 11:14:04 +0100 (CET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h24AE4424928; Tue, 4 Mar 2003 11:14:04 +0100 X-Authentication-Warning: chimera.suse.cz: Host test12.suse.cz [10.20.3.140] claimed to be alienAngel.upjs.sk Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.6/8.12.6/Submit) with ESMTP id h24ADaiE012356; Tue, 4 Mar 2003 11:13:36 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Tue, 4 Mar 2003 11:13:36 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: "'Linto Joseph Mathew" Cc: linux-xfs@oss.sgi.com Subject: Re: Problem while I formatting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3010 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 246 Lines: 10 On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > > I have partition (logical /dev/hda6 ) of size 16 MB.When i tried to I think, your partiton is too small. The minimum allocation group size is 16 MB, but you need space for logs. jan From owner-linux-xfs@oss.sgi.com Tue Mar 4 03:37:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 03:37:17 -0800 (PST) Received: from hbcse.tifr.res.in (webmail.hbcse.tifr.res.in [158.144.44.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24Bb2f03777 for ; Tue, 4 Mar 2003 03:37:03 -0800 Received: from linto (helo=localhost) by hbcse.tifr.res.in with local-esmtp (Exim 3.35 #1 (Debian)) id 18qAgU-0005VZ-00; Tue, 04 Mar 2003 17:04:10 +0530 Date: Tue, 4 Mar 2003 17:04:10 +0530 (IST) From: "'Linto Joseph Mathew" To: Jan Derfinak cc: linux-xfs@oss.sgi.com Subject: Re: Problem while I formatting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3011 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linto@hbcse.tifr.res.in Precedence: bulk X-list: linux-xfs Content-Length: 523 Lines: 26 Greetings jan, I tried the same thing on my another partition, ie /dev/hda5 of size 5 GB.But still it showing the same err.I don't understand what is this? Is xfs needed primary partition? regards , Linto On Tue, 4 Mar 2003, Jan Derfinak wrote: > On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > > > > > I have partition (logical /dev/hda6 ) of size 16 MB.When i tried to > > I think, your partiton is too small. > The minimum allocation group size is 16 MB, but you need space for logs. > > jan > > From owner-linux-xfs@oss.sgi.com Tue Mar 4 05:15:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 05:15:22 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24DFEf05481 for ; Tue, 4 Mar 2003 05:15:15 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id EE79659D398; Tue, 4 Mar 2003 14:15:10 +0100 (CET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h24DFA413228; Tue, 4 Mar 2003 14:15:10 +0100 X-Authentication-Warning: chimera.suse.cz: Host test12.suse.cz [10.20.3.140] claimed to be alienAngel.upjs.sk Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.6/8.12.6/Submit) with ESMTP id h24DEQPb013256; Tue, 4 Mar 2003 14:14:26 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Tue, 4 Mar 2003 14:14:26 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: "'Linto Joseph Mathew" Cc: linux-xfs@oss.sgi.com Subject: Re: Problem while I formatting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3012 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 639 Lines: 21 On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > Greetings jan, > I tried the same thing on my another partition, ie /dev/hda5 of size > 5 GB.But still it showing the same err.I don't understand what is this? > Is xfs needed primary partition? No. Please show us mkfs.xfs -V, kernel version. Do you have self compiled xfsprogs or binary one? How you run mkfs.xfs? jan -- We've been walled-in, malled-in, insulated, air-conditioned, cine-plexed, programmed, brainwashed, unalterably directed by materialism, consumerism, and capitalism, unaware of our own heartbeats, only dimly aware of our diminished, starving spirits. From owner-linux-xfs@oss.sgi.com Tue Mar 4 05:27:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 05:27:50 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24DRlf06154 for ; Tue, 4 Mar 2003 05:27:47 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24DRlG8019593 for ; Tue, 4 Mar 2003 05:27:47 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA87408; Tue, 4 Mar 2003 07:27:46 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA08683; Tue, 4 Mar 2003 07:27:45 -0600 (CST) Subject: Re: Problem while I formatting From: Stephen Lord To: Jan Derfinak Cc: "'Linto Joseph Mathew" , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 07:26:27 -0600 Message-Id: <1046784389.1367.2.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3013 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1166 Lines: 34 On Tue, 2003-03-04 at 07:14, Jan Derfinak wrote: > On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > > > Greetings jan, > > I tried the same thing on my another partition, ie /dev/hda5 of size > > 5 GB.But still it showing the same err.I don't understand what is this? > > Is xfs needed primary partition? > No. > > Please show us mkfs.xfs -V, kernel version. > Do you have self compiled xfsprogs or binary one? > How you run mkfs.xfs? > > I suspect you need a newer mkfs.xfs binary, also, if you are getting output like this: meta-data=/dev/sda2 isize=256 agcount=8, agsize=64511 blks data = bsize=4096 blocks=516088, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 It actually worked. There is an ioctl call which xfs attempts to use, it is not implemented by all block devices and mkfs actually carries on after the failure anyway. Steve From owner-linux-xfs@oss.sgi.com Tue Mar 4 05:32:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 05:32:09 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24DW7f06781 for ; Tue, 4 Mar 2003 05:32:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24DW7G8019985 for ; Tue, 4 Mar 2003 05:32:07 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA31140; Tue, 4 Mar 2003 07:32:06 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA15853; Tue, 4 Mar 2003 07:32:05 -0600 (CST) Subject: Re: TAKE - unwritten extents From: Stephen Lord To: Andi Kleen Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20030304081442.GA14913@wotan.suse.de> References: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> <20030304081442.GA14913@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 07:30:47 -0600 Message-Id: <1046784648.1367.9.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3014 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 486 Lines: 14 On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > Support for unwritten extents. Create separate IO completion > > Gratulations. Do they work fully already? Yep, they are all there. The preallocation calls are still restricted to privileged user's, that should get fixed up soon. I also have some ideas for reworking how we use daemons for this and other things - but that may take a little while to show up. Steve From owner-linux-xfs@oss.sgi.com Tue Mar 4 06:48:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 06:48:14 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24Em9f08426 for ; Tue, 4 Mar 2003 06:48:10 -0800 Received: (qmail 24496 invoked from network); 4 Mar 2003 14:48:08 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 4 Mar 2003 14:48:08 +0000 Subject: Re: TAKE - unwritten extents From: Tony Gale To: linux-xfs@oss.sgi.com In-Reply-To: <1046784648.1367.9.camel@dstl.gov.uk> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gQeaC/cvPYfI2ofS/J6+" Organization: Message-Id: <1046789287.28300.4.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 04 Mar 2003 14:48:07 +0000 X-archive-position: 3015 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 1258 Lines: 40 --=-gQeaC/cvPYfI2ofS/J6+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-03-04 at 13:30, Stephen Lord wrote: > On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > > Support for unwritten extents. Create separate IO completion > >=20 > > Gratulations. Do they work fully already? >=20 > Yep, they are all there. The preallocation calls are still restricted > to privileged user's, that should get fixed up soon. I also have some > ideas for reworking how we use daemons for this and other things - but > that may take a little while to show up. >=20 Please excuse my ignorance, but what are "unwritten extents", and should I be excited about their support? Cheers, -tony --=-gQeaC/cvPYfI2ofS/J6+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPmS8px/0GZs/Z0FlAQIYaAP/Xod0TdUOXx2DZmg58ndar3qRNMl0yvr/ r5lkIKHfNODAN84sHf2iJxPVKngz/1JflkuhQDj/OLO2WSATTgu3F66w7IZFag/8 3xsNRlzm/FFVCoeDUJXH5XzBovcLq9ual1gHUPSITVajUsYVOF4jqqZgdNOuGrQQ WHPd0RlT8bw= =qkmx -----END PGP SIGNATURE----- --=-gQeaC/cvPYfI2ofS/J6+-- From owner-linux-xfs@oss.sgi.com Tue Mar 4 07:02:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 07:02:27 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24F2Lf09202 for ; Tue, 4 Mar 2003 07:02:21 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24F2KKp017341 for ; Tue, 4 Mar 2003 07:02:20 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA48992; Tue, 4 Mar 2003 09:02:19 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA95974; Tue, 4 Mar 2003 09:02:19 -0600 (CST) Subject: Re: TAKE - unwritten extents From: Stephen Lord To: Tony Gale Cc: linux-xfs@oss.sgi.com In-Reply-To: <1046789287.28300.4.camel@syntax.dstl.gov.uk> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> <1046789287.28300.4.camel@syntax.dstl.gov.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 09:00:56 -0600 Message-Id: <1046790057.1367.89.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3016 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1342 Lines: 36 On Tue, 2003-03-04 at 08:48, Tony Gale wrote: > On Tue, 2003-03-04 at 13:30, Stephen Lord wrote: > > On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > > > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > > > Support for unwritten extents. Create separate IO completion > > > > > > Gratulations. Do they work fully already? > > > > Yep, they are all there. The preallocation calls are still restricted > > to privileged user's, that should get fixed up soon. I also have some > > ideas for reworking how we use daemons for this and other things - but > > that may take a little while to show up. > > > > Please excuse my ignorance, but what are "unwritten extents", and should > I be excited about their support? Unwritten extents improve the security of the file preallocation interface in xfs. When you preallocate space in a file, it is not zeroed on disk, So if you read from it you get old data. Unless you have unwritten extent support. For this reason the preallocate calls on linux were restricted to root. Unwritten extents slow things down when they are used, which is why they are selectable via a mkfs option: mkfs -t xfs -d unwritten=1 So nothing too exciting, unless you are attempting to read Irix created filesystems on linux, or need the preallocation interface and have security concerns. Steve From owner-linux-xfs@oss.sgi.com Tue Mar 4 08:25:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 08:25:12 -0800 (PST) Received: from mail.srz-berlin.de (ambrosius.srz-berlin.de [217.9.41.134]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24GP5f11521 for ; Tue, 4 Mar 2003 08:25:05 -0800 Received: from [192.168.1.17] (helo=srz-berlin.de) by mail.srz-berlin.de with esmtp (Exim 6.66 #1) id 18qFDu-0002T4-00 for linux-xfs@oss.sgi.com; Tue, 04 Mar 2003 17:24:58 +0100 Message-ID: <3E64D298.ADC2C124@srz-berlin.de> Date: Tue, 04 Mar 2003 17:21:44 +0100 From: Axel Bringenberg Organization: Satz-Rechen-Zentrum Berlin - Systemgruppe (http://www.srz.de) X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.4.9-31SGI_XFS_1.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *18qFDu-0002T4-00*2YyB2WAfRsg* on Astaro Security Linux X-archive-position: 3017 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: A.Bringenberg@srz-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 472 Lines: 19 Eric Sandeen schrieb: > > I think that Russell fixed this on the latest iso, can you verify that > you're using the latest? Oups - yes: my fault. it was the v3 iso image, sorry. But with v4 I have the next problem: a installation (custom, with "everything" packages) failed on disc 6 while installing "anaconda-8.0-2XFS". iso images is ok (check with md5sum an installer-build test). Regards, - bringi Axel Bringenberg -- Satz-Rechen-Zentrum Berlin - Systemgruppe From owner-linux-xfs@oss.sgi.com Tue Mar 4 08:51:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 08:51:39 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24GpZf14268 for ; Tue, 4 Mar 2003 08:51:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24GpYF6009188 for ; Tue, 4 Mar 2003 08:51:35 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA89723 for ; Tue, 4 Mar 2003 10:51:33 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA18173 for ; Tue, 4 Mar 2003 10:51:33 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2507FZ11589 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 19:07:15 -0500 Resent-Message-Id: <200303050007.h2507FZ11589@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA81705 for ; Tue, 4 Mar 2003 10:47:31 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h24GlUok18723640 for ; Tue, 4 Mar 2003 08:47:30 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h24GiUQv001644 for ; Tue, 4 Mar 2003 17:44:30 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h24GiUIr001643 for hch@sgi.com; Tue, 4 Mar 2003 17:44:30 +0100 Date: Tue, 4 Mar 2003 17:44:30 +0100 From: Christoph Hellwig Message-Id: <200303041644.h24GiUIr001643@lab343.munich.sgi.com> Subject: TAKE - remove VFS_DOUNMOUNT To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 4 Mar 2003 19:07:14 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3018 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 437 Lines: 17 No need for it on Linux. Date: Tue Mar 4 08:45:43 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:140841a linux/fs/xfs/xfs_vfsops.c - 1.403 linux/fs/xfs/linux/xfs_fs_subr.c - 1.38 linux/fs/xfs/linux/xfs_super.c - 1.256 linux/fs/xfs/linux/xfs_vfs.h - 1.31 linux/fs/xfs/linux/xfs_fs_subr.h - 1.10 From owner-linux-xfs@oss.sgi.com Tue Mar 4 09:03:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 09:03:14 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24H34f15275 for ; Tue, 4 Mar 2003 09:03:04 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9D8EA14543; Tue, 4 Mar 2003 18:03:03 +0100 (MET) Date: Tue, 4 Mar 2003 18:03:00 +0100 From: Andi Kleen To: Tony Gale Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - unwritten extents Message-ID: <20030304170300.GA7113@wotan.suse.de> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> <1046789287.28300.4.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046789287.28300.4.camel@syntax.dstl.gov.uk> X-archive-position: 3019 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1031 Lines: 24 On Tue, Mar 04, 2003 at 02:48:07PM +0000, Tony Gale wrote: > On Tue, 2003-03-04 at 13:30, Stephen Lord wrote: > > On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > > > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > > > Support for unwritten extents. Create separate IO completion > > > > > > Gratulations. Do they work fully already? > > > > Yep, they are all there. The preallocation calls are still restricted > > to privileged user's, that should get fixed up soon. I also have some > > ideas for reworking how we use daemons for this and other things - but > > that may take a little while to show up. > > > > Please excuse my ignorance, but what are "unwritten extents", and should > I be excited about their support? Basically it makes preallocation useful and secure. Preallocation has potentially big advantages for handling of very big files with consistent performance. With preallocation XFS can essentially only use a single extent for the whole file and avoid any fragmentation at all. -Andi From owner-linux-xfs@oss.sgi.com Tue Mar 4 10:20:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 10:20:21 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24IK8f21341 for ; Tue, 4 Mar 2003 10:20:09 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AB94B1830E07; Tue, 4 Mar 2003 10:20:08 -0800 (PST) Date: Tue, 4 Mar 2003 10:20:08 -0800 From: Chris Wedgwood To: Stephen Lord Cc: Tony Gale , linux-xfs@oss.sgi.com Subject: Re: TAKE - unwritten extents Message-ID: <20030304182008.GA25814@f00f.org> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> <1046789287.28300.4.camel@syntax.dstl.gov.uk> <1046790057.1367.89.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046790057.1367.89.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3020 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 358 Lines: 12 On Tue, Mar 04, 2003 at 09:00:56AM -0600, Stephen Lord wrote: > So nothing too exciting, unless you are attempting to read Irix > created filesystems on linux, or need the preallocation interface > and have security concerns. For most people the biggest implication will be that non-root users defragment files (xfs_fsr) if they choose to do so. --cw From owner-linux-xfs@oss.sgi.com Tue Mar 4 11:36:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 11:36:35 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24JaOf25712 for ; Tue, 4 Mar 2003 11:36:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24JaOF6030081 for ; Tue, 4 Mar 2003 11:36:24 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA40188 for ; Tue, 4 Mar 2003 13:36:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA05444 for ; Tue, 4 Mar 2003 13:36:23 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24JaMW17922; Tue, 4 Mar 2003 13:36:22 -0600 Message-Id: <200303041936.h24JaMW17922@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 13:36:22 -0600 Subject: TAKE - Make KDB compatible with LBD X-archive-position: 3021 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 490 Lines: 16 Make KDB compatible with the LBD (large block device) patch: Cast sector / block numbers to (unsigned long long) and print with %llu - works for 32 or 64 bit block numbers. Date: Tue Mar 4 11:35:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140870a linux/kdb/modules/kdbm_vm.c - 1.23 linux/kdb/modules/kdbm_pg.c - 1.62 From owner-linux-xfs@oss.sgi.com Tue Mar 4 12:16:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 12:16:41 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24KGVf27624 for ; Tue, 4 Mar 2003 12:16:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24KGUnH006338 for ; Tue, 4 Mar 2003 12:16:30 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA06170 for ; Tue, 4 Mar 2003 14:16:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA77947 for ; Tue, 4 Mar 2003 14:16:29 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24KGSZ19726; Tue, 4 Mar 2003 14:16:28 -0600 Message-Id: <200303042016.h24KGSZ19726@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 14:16:28 -0600 Subject: TAKE - Add error reporting for EFSCORRUPTED X-archive-position: 3022 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3236 Lines: 85 Add error reporting calls in error paths that return EFSCORRUPTED Date: Tue Mar 4 12:15:43 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: gwehrman@sgi.com Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136445a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136445a linux/fs/xfs/xfs_ialloc.c - 1.163 linux/fs/xfs/xfs_rw.c - 1.373 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/xfs_da_btree.c - 1.138 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED and cmn_error messages for additional information. linux/fs/xfs/xfs_vnodeops.c - 1.584 linux/fs/xfs/xfs_dir2_block.c - 1.29 linux/fs/xfs/xfs_dir.c - 1.148 linux/fs/xfs/xfs_log_recover.c - 1.258 linux/fs/xfs/xfs_dir_leaf.c - 1.109 linux/fs/xfs/xfs_mount.c - 1.317 linux/fs/xfs/xfs_btree.c - 1.103 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/xfs_btree.h - 1.54 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in macros that return EFSCORRUPTED linux/fs/xfs/xfs_qm.c - 1.94 linux/fs/xfs/xfs_inode.c - 1.362 linux/fs/xfs/xfs_attr_leaf.c - 1.68 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/xfs_error.c - 1.37 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add xfs_error_report and xfs_corruption_error functions. These are called by the XFS_ERROR_REPORT and XFS_CORRUPTION_ERROR macros placed in places where there is an error that will result in a filesystem shutdown. linux/fs/xfs/xfs_error.h - 1.30 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. add prototypes for xfs_error_report and xfs_corruption error and macros to call them. linux/fs/xfs/xfs_alloc.c - 1.163 linux/fs/xfs/xfs_bmap.c - 1.300 linux/fs/xfs/xfs_dir2_node.c - 1.29 linux/fs/xfs/xfs_attr.c - 1.101 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/linux/xfs_globals.c - 1.41 linux/fs/xfs/linux/xfs_linux.h - 1.98 linux/fs/xfs/linux/xfs_sysctl.h - 1.10 linux/fs/xfs/linux/xfs_sysctl.c - 1.15 linux/fs/xfs/linux/xfs_iomap.c - 1.6 From owner-linux-xfs@oss.sgi.com Tue Mar 4 12:51:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 12:51:17 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24KpAf28516 for ; Tue, 4 Mar 2003 12:51:10 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24L1bkq017241 for ; Tue, 4 Mar 2003 15:01:37 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA99903 for ; Tue, 4 Mar 2003 14:51:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA94446 for ; Tue, 4 Mar 2003 14:51:08 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24Kp7S25088; Tue, 4 Mar 2003 14:51:07 -0600 Message-Id: <200303042051.h24Kp7S25088@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 14:51:07 -0600 Subject: TAKE - Fix v1dir getdents to not return false EFSCORRUPTED X-archive-position: 3023 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 670 Lines: 22 fix getdents so that xfs_da_read_buf doesn't return an EFSCORRUPTED except when there is a real problem. Date: Tue Mar 4 12:49:48 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: overby Author: cwf Merged by: sandeen Merged mods: irix6.5f:irix:138531a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138531a linux/fs/xfs/xfs_dir.c - 1.149 - Merge of irix6.5f:irix:138531a by sandeen. Merge of irix6.5m:irix:138531a by cwf. fix getdents so that xfs_da_read_buf doesn't return an EFSCORRUPTED except when there is a real problem. From owner-linux-xfs@oss.sgi.com Tue Mar 4 13:17:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 13:17:37 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24LHUf29656 for ; Tue, 4 Mar 2003 13:17:30 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24LRvkq018170 for ; Tue, 4 Mar 2003 15:27:57 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA53520 for ; Tue, 4 Mar 2003 15:17:26 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA68214 for ; Tue, 4 Mar 2003 15:17:29 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24LHRl27423; Tue, 4 Mar 2003 15:17:27 -0600 Message-Id: <200303042117.h24LHRl27423@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 15:17:27 -0600 Subject: TAKE - Fix freespace entry search to handle holes X-archive-position: 3024 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 678 Lines: 23 Fix freespace entry search to handle holes in the freespace area correctly. Date: Tue Mar 4 13:16:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: cwf lord Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:133509a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:133509a linux/fs/xfs/xfs_dir2_node.c - 1.30 - Merge of irix6.5f:irix:133509a by sandeen. Merge of grove2-6520stage:irix:133509a by roehrich. Merge of grove2:irix:133509a by roehrich. Fix freespace entry search to handle holes in the freespace area correctly. From owner-linux-xfs@oss.sgi.com Tue Mar 4 13:35:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 13:35:55 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24LZgf00533 for ; Tue, 4 Mar 2003 13:35:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24LZgnH024336 for ; Tue, 4 Mar 2003 13:35:42 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA45168 for ; Tue, 4 Mar 2003 15:35:41 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA07712 for ; Tue, 4 Mar 2003 15:35:41 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24LZdL28246; Tue, 4 Mar 2003 15:35:39 -0600 Message-Id: <200303042135.h24LZdL28246@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 15:35:39 -0600 Subject: TAKE - Fix target_linkzero calculation in rename X-archive-position: 3025 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 684 Lines: 23 Fix target_linkzero calculation Date: Tue Mar 4 13:35:08 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: overby Author: gwehrman Merged by: sandeen Merged mods: irix6.5f:irix:135993a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:135993a linux/fs/xfs/xfs_rename.c - 1.47 - Merge of irix6.5f:irix:135993a by sandeen. Merge of grove2-6520stage:irix:135993a by roehrich. Merge of grove2:irix:135993a by roehrich. Bug 836139. Don't calculate target_linkzero until after droping the old '.' link when it is a directory that is being moved. From owner-linux-xfs@oss.sgi.com Tue Mar 4 14:29:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 14:29:50 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24MTef01527 for ; Tue, 4 Mar 2003 14:29:40 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24MTd9n012594 for ; Tue, 4 Mar 2003 14:29:39 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA31822 for ; Tue, 4 Mar 2003 16:29:38 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA12652 for ; Tue, 4 Mar 2003 16:29:38 -0600 (CST) Subject: hold off on cvs updates for a bit - merge flurry From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 16:29:37 -0600 Message-Id: <1046816977.6344.27.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3026 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 16 I'm pushing in a bunch of backmerges from irix, and things may not be entirely stable until I'm done. Guess I could have done it all in one big merge but it's easier to wrap my head around one mod at a time. I'll let you know when I'm done. Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Mar 4 15:30:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 15:30:59 -0800 (PST) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24NUtf02673 for ; Tue, 4 Mar 2003 15:30:55 -0800 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id h24NUseD017995 for ; Tue, 4 Mar 2003 18:30:54 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-SMTP) with ESMTP id h24NUrje017990 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 4 Mar 2003 18:30:53 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id h24NUrh6017986 for ; Tue, 4 Mar 2003 18:30:53 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Tue, 4 Mar 2003 18:30:52 -0500 (EST) From: "Benito A. Venegas" X-X-Sender: Reply-To: "Benito A. Venegas" To: Linux XFS List Subject: How-to convert XFS log v1 -> v2 In-Reply-To: <20030227232109.GA2236@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3027 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Content-Length: 898 Lines: 32 Team xfs: I have 1 FS, 1/4 TB waiting to be converted from v1 to v2. I have a full backup , but I don't want to waste and make a wrong step, and well, recreate FS with xfs v2 and recover the info from tape :/ (My would kill me) The FS was created with mkfs -t xfs -l size=32768b -f /dev/sdb1 and mounted with: mount -t xfs -o logbufs=8,logbsize=32768 /dev/sdb1 /nas02 But I was reading xfs_db manual, based in Chris Wedgwood tip, and I am not so clear how to do it. I heard in the list there was a procedure done in IRIX to convert file systems to v1 to v2, but I am not sure if Eric or Steve have worked on that yet (export to linux). Also I dont know if I can do it in my current file system in the way I created previously. I wouldn't like to rebuild the FS again only for v2, but I know it's going to be much better... I hope you can help me boys. Thanks Benito.- From owner-linux-xfs@oss.sgi.com Tue Mar 4 15:52:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 15:52:37 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24NqSf10797 for ; Tue, 4 Mar 2003 15:52:28 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24NqRnH018809 for ; Tue, 4 Mar 2003 15:52:27 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA09115 for ; Tue, 4 Mar 2003 17:52:26 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA99088 for ; Tue, 4 Mar 2003 17:52:26 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24NqOp06076; Tue, 4 Mar 2003 17:52:24 -0600 Message-Id: <200303042352.h24NqOp06076@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 17:52:24 -0600 Subject: TAKE - Last of the dir2 backmerges from Irix X-archive-position: 3028 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1273 Lines: 30 Last of the dir2 backmerges from Irix Date: Tue Mar 4 15:51:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Merged by: sandeen Merged mods: irix6.5f:irix:137928a,irix6.5f:irix:137929a,irix6.5f:irix:138887a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140918a linux/fs/xfs/xfs_dir2_node.c - 1.32 - Merge of irix6.5f:irix:137928a originally by overby on 02/04/03 Merge of grove2-6520stage:irix:137928a by roehrich. Merge of cxfs-client2.5.0:irix:137928a by roehrich. Merge of grove2:irix:137928a by roehrich. Fix xfs_dir2_node_addname_int call to xfs_da_read_buf. Allow it to return a NULL buf pointer if the block isn't there. Merge of irix6.5f:irix:137929a originally by overby on 02/04/03 Merge of grove2-6520stage:irix:137929a by roehrich. Merge of cxfs-client2.5.0:irix:137929a by roehrich. Merge of grove2:irix:137929a by roehrich. in xfs_dir2_node_trim_free, make reading a nonexistant freespace block a non-fatal error. Merge of irix6.5f:irix:138887a originally by overby on 02/06/03 Merge of irix6.5m:irix:138887a by overby. Check for a NULL freespace buffer pointer before calling xfs_da_buf_done. From owner-linux-xfs@oss.sgi.com Tue Mar 4 15:55:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 15:55:45 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24Ntgf13195 for ; Tue, 4 Mar 2003 15:55:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24Ntg9n023019 for ; Tue, 4 Mar 2003 15:55:42 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA52903 for ; Tue, 4 Mar 2003 17:55:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA14580; Tue, 4 Mar 2003 17:55:41 -0600 (CST) Subject: Re: hold off on cvs updates for a bit - merge flurry From: Eric Sandeen To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1046816977.6344.27.camel@stout.americas.sgi.com> References: <1046816977.6344.27.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 17:55:38 -0600 Message-Id: <1046822138.6313.52.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3029 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 199 Lines: 8 Ok, I think all the dir v2 changes are in now... carry on.... Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Mar 4 16:06:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 16:06:21 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h2506If22219 for ; Tue, 4 Mar 2003 16:06:18 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2506I9n024332 for ; Tue, 4 Mar 2003 16:06:18 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA41919 for ; Tue, 4 Mar 2003 18:06:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id SAA14110 for ; Tue, 4 Mar 2003 18:06:17 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2506Fs07250; Tue, 4 Mar 2003 18:06:15 -0600 Message-Id: <200303050006.h2506Fs07250@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 18:06:15 -0600 Subject: TAKE - getdents fix for dir v2 X-archive-position: 3030 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 531 Lines: 20 getdents needs to check for reaching the end of a directory block when searching for the entry after the "cookie" that comes in with the call. Date: Tue Mar 4 16:05:12 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: cwf kbeck Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:139574a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139574a linux/fs/xfs/xfs_dir2_leaf.c - 1.30 From owner-linux-xfs@oss.sgi.com Tue Mar 4 17:28:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 17:28:36 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h251SSf27408 for ; Tue, 4 Mar 2003 17:28:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h251cskq024532 for ; Tue, 4 Mar 2003 19:38:55 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h251R97L846276 for ; Wed, 5 Mar 2003 12:27:09 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h251R9AY846418 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 12:27:09 +1100 (EST) Date: Wed, 5 Mar 2003 12:27:09 +1100 (EST) From: Nathan Scott Message-Id: <200303050127.h251R9AY846418@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor unwritten extents tweak X-archive-position: 3031 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 508 Lines: 17 Implement a suggestion from Christoph - instead of using a new pagebuf flag, we now pass in an additional parameter to pagebuf_iodone instead. Date: Tue Mar 4 17:26:08 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140933a linux/fs/xfs/xfs_buf.h - 1.105 linux/fs/xfs/pagebuf/page_buf.c - 1.102 linux/fs/xfs/pagebuf/page_buf.h - 1.61 linux/fs/xfs/linux/xfs_aops.c - 1.21 From owner-linux-xfs@oss.sgi.com Tue Mar 4 17:55:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 17:55:11 -0800 (PST) Received: from provone.provsol.net (66.83.239.66.nw.nuvox.net [66.83.239.66]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h251t7f08986 for ; Tue, 4 Mar 2003 17:55:08 -0800 Received: from serria.provsol.int (serria.provsol.int [192.168.20.22]) by provone.provsol.net (Postfix) with ESMTP id 4ED59F3 for ; Tue, 4 Mar 2003 19:55:07 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by serria.provsol.int (Postfix) with ESMTP id 3FD8FA02529 for ; Tue, 4 Mar 2003 19:55:07 -0600 (CST) Received: from orion (orion.provsol.int [192.168.20.23]) by serria.provsol.int (Postfix) with SMTP id F2454A017DE for ; Tue, 4 Mar 2003 19:55:06 -0600 (CST) From: "Vernon A. Fort" To: Subject: RE: XFS and RH8 failing install Date: Tue, 4 Mar 2003 19:55:35 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3E64D298.ADC2C124@srz-berlin.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS snapshot-20020300 X-archive-position: 3032 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vfort@provident-solutions.com Precedence: bulk X-list: linux-xfs Content-Length: 1213 Lines: 46 I'm having the exact same problem. I have successfully install RedHat-7.3-XFS on this hardware (a new drive - exactly the same but just new). The specs: Athlon 1900+ 768meg ram WD 40gig drive (ata100) Etc.... It seems like the disc 6 completes and fails to prompt for the next CD....again, the exact same problem, failing to install anaconda-8.0-2XFS.. Andy ----------------------------------- Vernon A. Fort (Andy) Provident Solutions, LLC (615) 427-4016 http://www.provident-solutions.com -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Axel Bringenberg Sent: Tuesday, March 04, 2003 10:22 AM To: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install Eric Sandeen schrieb: > > I think that Russell fixed this on the latest iso, can you verify that > you're using the latest? Oups - yes: my fault. it was the v3 iso image, sorry. But with v4 I have the next problem: a installation (custom, with "everything" packages) failed on disc 6 while installing "anaconda-8.0-2XFS". iso images is ok (check with md5sum an installer-build test). Regards, - bringi Axel Bringenberg -- Satz-Rechen-Zentrum Berlin - Systemgruppe From owner-linux-xfs@oss.sgi.com Tue Mar 4 18:24:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 18:24:59 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h252Oqf21199 for ; Tue, 4 Mar 2003 18:24:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24MWp9n012998 for ; Tue, 4 Mar 2003 14:32:51 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA76661 for ; Tue, 4 Mar 2003 16:32:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA61360 for ; Tue, 4 Mar 2003 16:32:51 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24MWn130725; Tue, 4 Mar 2003 16:32:49 -0600 Message-Id: <200303042232.h24MWn130725@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 16:32:49 -0600 Subject: TAKE - Rearrange leaf space allocation X-archive-position: 3033 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 902 Lines: 26 Rearrange leaf space allocation Date: Tue Mar 4 14:32:14 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: cwf@sgi.com Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136459a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136459a linux/fs/xfs/xfs_dir2_node.c - 1.31 - Merge of irix6.5f:irix:136459a by sandeen. Merge of grove2-6520stage:irix:136459a by roehrich. Merge of grove2:irix:136459a by roehrich. Move the leaf space allocation in xfs_dir2_node_addname_int from before allocating data space to within data space allocation. This is to fix a problem where new leaf space block was not allocated when it should have been. Now xfs_node_addname_int will allocate a free space block if it finds that the one it needs is missing. From owner-linux-xfs@oss.sgi.com Tue Mar 4 20:08:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 20:08:10 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25482f31844 for ; Tue, 4 Mar 2003 20:08:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h254809n007327 for ; Tue, 4 Mar 2003 20:08:01 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2546h7L852710 for ; Wed, 5 Mar 2003 15:06:43 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2546hYh860271 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 15:06:43 +1100 (EST) Date: Wed, 5 Mar 2003 15:06:43 +1100 (EST) From: Nathan Scott Message-Id: <200303050406.h2546hYh860271@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bigger, better unwritten extent tweak X-archive-position: 3035 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 730 Lines: 21 Ah -- knew if I stared at it long enough I'd see a way to do this. Remove the page array I created to hold pages until we could setup enough state for the IO completion handlers to do their thing - we now make more judicious use of the atomic pb_io_remaining field to ensure the IO completion handlers are never called before the pb is completely setup. Also fixed several comments, and renamed several functions which are no longer specific to delayed allocation. cheers. Date: Tue Mar 4 20:03:40 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140937a linux/fs/xfs/linux/xfs_aops.c - 1.22 From owner-linux-xfs@oss.sgi.com Tue Mar 4 21:46:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 21:47:04 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h255kvf01511 for ; Tue, 4 Mar 2003 21:46:57 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h255ku9n012850 for ; Tue, 4 Mar 2003 21:46:56 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA21375; Tue, 4 Mar 2003 23:46:56 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id XAA32205; Tue, 4 Mar 2003 23:46:55 -0600 (CST) Date: Tue, 4 Mar 2003 23:46:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: utz lehmann cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying In-Reply-To: <20030302232830.A16452@s2y4n2c.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3036 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2345 Lines: 80 Ok, this isn't quite right. For a file with holes, the "best-case" scenario is > 1 extent. I think your patch will bail out if any particular extent on one side of a hole does not defrag, rather than looking at all extents in a hole-y file. I think the right way to do it is to do 2 loops - first loop, go through allocating extents (accounting for holes if necessary). THEN check how many extents the temp file has, and proceed with copying in a 2nd loop if things look better. I have a patch that does this, I'll probably get it checked in tomorrow if it looks good to a reviewer or two. Thanks, -Eric On Sun, 2 Mar 2003, utz lehmann wrote: > Hi > > This patch moves the check for improved extent count directly after the > preallocation of the extents. So it can avoid copying of the extent data in > the case that no improvement is made. The patch is against current CVS. > > On my testsystem with 3 files which cant improved the elapsed time went down > from 3min to 6s and saved about 3GB disk io. > > > utz > > > --- xfs_fsr.c.orig Sat Mar 1 13:53:36 2003 > +++ xfs_fsr.c Sun Mar 2 23:02:25 2003 > @@ -967,7 +967,8 @@ > { > int tfd; > int srval; > - int nextents, extent, cur_nextents, new_nextents; > + int nextents, extent, cur_nextents; > + int new_nextents = 0; > unsigned blksz_dio; > unsigned dio_min; > struct dioattr dio; > @@ -1111,6 +1112,15 @@ > return -1; > } > } > + /* Check if the extent count improved */ > + new_nextents = getnextents(tfd); > + if (cur_nextents <= new_nextents) { > + if (vflag) > + fsrprintf(_("No improvement made: %s\n"), fname); > + close(tfd); > + free(fbuf); > + return 1; /* no change/no error */ > + } > for (cnt = outmap[extent].bmv_length; cnt > 0; > cnt -= ct, pos += ct) { > if (nfrags && --nfrags) { > @@ -1195,15 +1205,6 @@ > sx.sx_offset = 0; > sx.sx_length = statp->bs_size; > > - /* Check if the extent count improved */ > - new_nextents = getnextents(tfd); > - if (cur_nextents <= new_nextents) { > - if (vflag) > - fsrprintf(_("No improvement made: %s\n"), fname); > - close(tfd); > - return 1; /* no change/no error */ > - } > - > /* switch to the owner's id, to keep quota in line */ > if (fchown(tfd, statp->bs_uid, statp->bs_gid) < 0) { > if (vflag) > > > > From owner-linux-xfs@oss.sgi.com Wed Mar 5 00:48:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 00:48:29 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h258mMf04293 for ; Wed, 5 Mar 2003 00:48:22 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18qUZU-0008T9-00 for linux-xfs@oss.sgi.com; Wed, 05 Mar 2003 09:48:16 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18qUZ5-0002DT-00 for linux-xfs@oss.sgi.com; Wed, 05 Mar 2003 09:47:51 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Wed, 5 Mar 2003 10:48:54 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303051048.54271.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h258mMf04294 X-archive-position: 3037 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1157 Lines: 40 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, does anybody know a 'working' patch for a 2.4 Kernel, included XFS of course ? The well known/common patches for 2.4 Kernels are failing on our XFS stable kernels. Without this patched the ide modules are not enableing DMA/UDMA at all so this is not a usable solution. The original Nvidia "Drivers" has only "audio" and "network" drivers, but nvida excluded the IDE Part. (Bad Boys!). You can google the "common" solutions here: http://www.google.com/search?hl=en&ie=ISO-8859-1&q=linux%2Bnforce2%2Bide&btnG=Google+Search But those does not work/patch works not on linux-2.4-XFS Kernels. Has anybody already got a working solution ? TIA - quite a lot ... mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZcgGW7UKI9EqarERAl1TAJ9C/Pl2CpUZhbuytBGYsorogkn/eACeLB17 vzQyEhb2OSu141mx/MkNmoI= =og0Y -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 01:08:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 01:08:08 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25985f05103 for ; Wed, 5 Mar 2003 01:08:05 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id A995CAC38; Wed, 5 Mar 2003 10:19:21 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 3796819012; Wed, 5 Mar 2003 10:19:21 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 8F63B30881E; Wed, 5 Mar 2003 10:08:01 +0100 (CET) Message-ID: <3E65BE71.3D819D0D@ch.sauter-bc.com> Date: Wed, 05 Mar 2003 10:08:01 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: juergen.sauer@automatix.de Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? References: <200303051048.54271.juergen.sauer@automatix.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 3038 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1704 Lines: 55 Juergen Sauer schrieb: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Moin, > > does anybody know a 'working' patch for a 2.4 Kernel, > included XFS of course ? > > The well known/common patches for 2.4 Kernels are failing on our > XFS stable kernels. > > Without this patched the ide modules are not enableing DMA/UDMA at all so > this is not a usable solution. > > The original Nvidia "Drivers" has only "audio" and "network" drivers, but > nvida excluded the IDE Part. (Bad Boys!). Nvidia is one of those companies who generate too much headaches for Linux users. Just think about all the graphic cards related problems with binary only kernel modules... The good news is that DMA/UDMA seems to work well with nforce chipsets. I'm always using XFS enhanced RedHat Kernels and I did not have any problems. I just enabled UDMA with kernel parameter, IIRC it was something like 'ide0=ata66 ide1=ata66'. HTH Simon > > You can google the "common" solutions here: > http://www.google.com/search?hl=en&ie=ISO-8859-1&q=linux%2Bnforce2%2Bide&btnG=Google+Search > But those does not work/patch works not on linux-2.4-XFS Kernels. > > Has anybody already got a working solution ? > > TIA - quite a lot ... > > mfG > Jürgen > automatiX Linux Support Crew > - -- > Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** > ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** > ** http://www.automatix.de http://www.kranautomatisierung.de ** > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+ZcgGW7UKI9EqarERAl1TAJ9C/Pl2CpUZhbuytBGYsorogkn/eACeLB17 > vzQyEhb2OSu141mx/MkNmoI= > =og0Y > -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 01:35:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 01:36:03 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h259Zsf06133 for ; Wed, 5 Mar 2003 01:35:54 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id D313C1830671; Wed, 5 Mar 2003 01:35:54 -0800 (PST) Date: Wed, 5 Mar 2003 01:35:54 -0800 From: Chris Wedgwood To: Juergen Sauer Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Message-ID: <20030305093554.GA29602@f00f.org> References: <200303051048.54271.juergen.sauer@automatix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303051048.54271.juergen.sauer@automatix.de> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3039 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 23 On Wed, Mar 05, 2003 at 10:48:54AM +0100, Juergen Sauer wrote: > The well known/common patches for 2.4 Kernels are failing on our XFS > stable kernels. failing? how so? > Without this patched the ide modules are not enableing DMA/UDMA at > all so this is not a usable solution. does the amd7xx IDE driver fix this? it has some nv IDs in there by the looks of things? if not, what does "lspci -n" say for the ide controller? > Has anybody already got a working solution ? avoid hardware where vendors make your life difficult --cw From owner-linux-xfs@oss.sgi.com Wed Mar 5 01:56:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 01:56:58 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h259upf06833 for ; Wed, 5 Mar 2003 01:56:51 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 732DD146A7 for ; Wed, 5 Mar 2003 10:56:50 +0100 (MET) Date: Wed, 5 Mar 2003 10:56:50 +0100 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: cvs checkout stalling Message-ID: <20030305095649.GA25200@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 3040 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 15 When I check out or update linux-2.4-xfs the checkout always stalls on U linux/scripts/lxdialog/yesno.c cvs server: Updating linux/scripts/usb Fresh checkout makes no difference. That's towards the end so it may do some book kepping issue on the server. Does anybody else have these problems with CVS? Thanks, -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 5 02:12:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 02:12:24 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25ACLf07581 for ; Wed, 5 Mar 2003 02:12:21 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id A6AD4AC38 for ; Wed, 5 Mar 2003 11:23:38 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 4E4E519160 for ; Wed, 5 Mar 2003 11:23:39 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 84E8E30881D for ; Wed, 5 Mar 2003 11:12:19 +0100 (CET) Message-ID: <3E65CD83.5C2BC92F@ch.sauter-bc.com> Date: Wed, 05 Mar 2003 11:12:19 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: RedHat errata kernel with XFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 259 Lines: 8 I've just created source rpm for RedHat errata kernel, based on Seth's last version. This one is untested at all but seems to build fine on RedHat 7.3. It can be found here http://www.sauter-bc.com/XFS/kernel-2.4.18-26SGI_XFS_1.2.0.src.rpm Good luck! Simon From owner-linux-xfs@oss.sgi.com Wed Mar 5 02:25:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 02:25:26 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25APMf09476 for ; Wed, 5 Mar 2003 02:25:22 -0800 Received: (qmail 14779 invoked from network); 5 Mar 2003 10:25:19 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 5 Mar 2003 10:25:16 +0000 Subject: Re: cvs checkout stalling From: Tony Gale To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030305095649.GA25200@dstl.gov.uk> References: <20030305095649.GA25200@dstl.gov.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/ZOnGNRMUwnFVcOyV8yw" Organization: Message-Id: <1046859916.6953.1.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Mar 2003 10:25:17 +0000 X-archive-position: 3042 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 1175 Lines: 38 --=-/ZOnGNRMUwnFVcOyV8yw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-03-05 at 09:56, Andi Kleen wrote: > When I check out or update linux-2.4-xfs the checkout always stalls on=20 >=20 > U linux/scripts/lxdialog/yesno.c > cvs server: Updating linux/scripts/usb > >=20 > Fresh checkout makes no difference. >=20 > That's towards the end so it may do some book kepping issue on the=20 > server. Does anybody else have these problems with CVS? As Seth told me last week "upgrade your cvs tools". 1.11.5 works fine. Or you can simply break out, as the update has actually finished. -tony --=-/ZOnGNRMUwnFVcOyV8yw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPmXQjB/0GZs/Z0FlAQKq7AQAgkO7h/1zlSPEW6dSjVgdhRwMVL9AgWl6 /+ypFRIGLPbFRBaJ6RUqmfEunEtlDbjbZtx/vNugOrYoGUvIf56m5igNWJY/zXOK PSsNr2TbCI6jGZzx8N2ayo83d058jLm6V8Ko6MqBMRHzjRcIc/s4jHgoA+LVtut3 jXgIw7LNR8o= =WCP9 -----END PGP SIGNATURE----- --=-/ZOnGNRMUwnFVcOyV8yw-- From owner-linux-xfs@oss.sgi.com Wed Mar 5 02:45:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 02:45:52 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25Ajhf11499 for ; Wed, 5 Mar 2003 02:45:44 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 39A4B146AE; Wed, 5 Mar 2003 11:45:43 +0100 (MET) Date: Wed, 5 Mar 2003 11:45:39 +0100 From: Andi Kleen To: Tony Gale Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: cvs checkout stalling Message-ID: <20030305104539.GC3051@wotan.suse.de> References: <20030305095649.GA25200@dstl.gov.uk> <1046859916.6953.1.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046859916.6953.1.camel@syntax.dstl.gov.uk> X-archive-position: 3043 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 209 Lines: 7 > As Seth told me last week "upgrade your cvs tools". 1.11.5 works fine. > Or you can simply break out, as the update has actually finished. Ok thanks for the hint. Will update. This was cvs 1.11.1p1 -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 5 03:54:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 03:54:54 -0800 (PST) Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25Bskf13142 for ; Wed, 5 Mar 2003 03:54:46 -0800 Received: by dmz.tecosim.de (Postfix, from userid 10) id A92DB1402D; Wed, 5 Mar 2003 12:54:44 +0100 (CET) Received: from alg-ru-ext.tecosim.com(195.135.152.146), claiming to be "alg-ru.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdAPxrDj; Wed Mar 5 12:54:42 2003 Received: from ns.tecosim.de (unknown [10.0.2.1]) by alg-ru.tecosim.de (Postfix) with ESMTP id 98A5418015; Wed, 5 Mar 2003 12:54:41 +0100 (CET) Received: from donner.tecosim.de (donner.tecosim.de [10.0.16.1]) by ns.tecosim.de (8.11.6/8.11.6) with ESMTP id h25Bseg22234; Wed, 5 Mar 2003 12:54:40 +0100 Received: (from leh@localhost) by donner.tecosim.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) id h25Bseq21706; Wed, 5 Mar 2003 12:54:40 +0100 Date: Wed, 5 Mar 2003 12:54:40 +0100 From: Utz Lehmann To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying Message-ID: <20030305125440.F20654@de.tecosim.com> References: <20030302232830.A16452@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from sandeen@sgi.com on Tue, Mar 04, 2003 at 11:46:50PM -0600 X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-archive-position: 3044 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ulehmann@de.tecosim.com Precedence: bulk X-list: linux-xfs Content-Length: 2947 Lines: 98 Hi Eric Eric Sandeen [sandeen@sgi.com] wrote: > Ok, this isn't quite right. For a file with holes, the "best-case" > scenario is > 1 extent. I think your patch will bail out > if any particular extent on one side of a hole does not defrag, > rather than looking at all extents in a hole-y file. No. I have tested that case. cur_nextents and getnextents() are always for the whole file and not for a group of non hole extents that will preallocated at once. Sometimes there will be unnessary coping of extents when the file is hole-y. But the final result is the same. > > I think the right way to do it is to do 2 loops - first loop, go > through allocating extents (accounting for holes if necessary). > THEN check how many extents the temp file has, and proceed with > copying in a 2nd loop if things look better. I thought about that too. It's the better way. But this require to spilt the loop. I dont know if it's worth. utz > > I have a patch that does this, I'll probably get it checked in tomorrow > if it looks good to a reviewer or two. > > Thanks, > -Eric > > On Sun, 2 Mar 2003, utz lehmann wrote: > > > Hi > > > > This patch moves the check for improved extent count directly after the > > preallocation of the extents. So it can avoid copying of the extent data in > > the case that no improvement is made. The patch is against current CVS. > > > > On my testsystem with 3 files which cant improved the elapsed time went down > > from 3min to 6s and saved about 3GB disk io. > > > > > > utz > > > > > > --- xfs_fsr.c.orig Sat Mar 1 13:53:36 2003 > > +++ xfs_fsr.c Sun Mar 2 23:02:25 2003 > > @@ -967,7 +967,8 @@ > > { > > int tfd; > > int srval; > > - int nextents, extent, cur_nextents, new_nextents; > > + int nextents, extent, cur_nextents; > > + int new_nextents = 0; > > unsigned blksz_dio; > > unsigned dio_min; > > struct dioattr dio; > > @@ -1111,6 +1112,15 @@ > > return -1; > > } > > } > > + /* Check if the extent count improved */ > > + new_nextents = getnextents(tfd); > > + if (cur_nextents <= new_nextents) { > > + if (vflag) > > + fsrprintf(_("No improvement made: %s\n"), fname); > > + close(tfd); > > + free(fbuf); > > + return 1; /* no change/no error */ > > + } > > for (cnt = outmap[extent].bmv_length; cnt > 0; > > cnt -= ct, pos += ct) { > > if (nfrags && --nfrags) { > > @@ -1195,15 +1205,6 @@ > > sx.sx_offset = 0; > > sx.sx_length = statp->bs_size; > > > > - /* Check if the extent count improved */ > > - new_nextents = getnextents(tfd); > > - if (cur_nextents <= new_nextents) { > > - if (vflag) > > - fsrprintf(_("No improvement made: %s\n"), fname); > > - close(tfd); > > - return 1; /* no change/no error */ > > - } > > - > > /* switch to the owner's id, to keep quota in line */ > > if (fchown(tfd, statp->bs_uid, statp->bs_gid) < 0) { > > if (vflag) > > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Mar 5 06:27:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 06:27:55 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25ERkf17363 for ; Wed, 5 Mar 2003 06:27:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25ERjnH006915 for ; Wed, 5 Mar 2003 06:27:45 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA85228 for ; Wed, 5 Mar 2003 08:27:44 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA72515 for ; Wed, 5 Mar 2003 08:27:43 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h25LhOr18843 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 16:43:24 -0500 Resent-Message-Id: <200303052143.h25LhOr18843@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA70195 for ; Wed, 5 Mar 2003 08:26:58 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h25LgcT18775 for hch@sgi.com; Wed, 5 Mar 2003 16:42:38 -0500 Date: Wed, 5 Mar 2003 16:42:38 -0500 From: Christoph Hellwig Message-Id: <200303052142.h25LgcT18775@taclab54.munich.sgi.com> Subject: TAKE - Spelling fixes from 2.5.64 Resent-From: hch@sgi.com Resent-Date: Wed, 5 Mar 2003 16:43:24 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3045 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 17 Date: Wed Mar 5 06:26:06 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/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:140951a linux/fs/xfs/xfs_trans_dquot.c - 1.40 linux/fs/xfs/xfs_buf_item.c - 1.136 linux/fs/xfs/xfs_da_btree.c - 1.139 linux/fs/xfs/xfs_dquot.c - 1.73 linux/fs/xfs/xfs_dir_leaf.c - 1.110 linux/fs/xfs/xfs_mount.c - 1.318 linux/fs/xfs/xfs_inode.c - 1.363 linux/fs/xfs/xfs_attr_leaf.c - 1.69 From owner-linux-xfs@oss.sgi.com Wed Mar 5 07:51:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 07:51:21 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25FpEf20776 for ; Wed, 5 Mar 2003 07:51:14 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25G1ikq005399 for ; Wed, 5 Mar 2003 10:01:44 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA13720; Wed, 5 Mar 2003 09:51:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA59825; Wed, 5 Mar 2003 09:51:12 -0600 (CST) Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying From: Eric Sandeen To: Utz Lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030305125440.F20654@de.tecosim.com> References: <20030302232830.A16452@s2y4n2c.de> <20030305125440.F20654@de.tecosim.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Mar 2003 09:51:04 -0600 Message-Id: <1046879464.13282.41.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3046 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 616 Lines: 20 On Wed, 2003-03-05 at 05:54, Utz Lehmann wrote: > No. I have tested that case. cur_nextents and getnextents() are always for > the whole file and not for a group of non hole extents that will preallocated > at once. > Sometimes there will be unnessary coping of extents when the file is hole-y. > But the final result is the same. Ok, yes - I agree. Finally took a few moments to really look at it. Well, so I have code for both ways now... I'll check one of them in. :) Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 5 08:31:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 08:32:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25GVpf21780 for ; Wed, 5 Mar 2003 08:31:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25GVo9n024028 for ; Wed, 5 Mar 2003 08:31:51 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA00079 for ; Wed, 5 Mar 2003 10:31:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA30147 for ; Wed, 5 Mar 2003 10:31:50 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25GVf219340; Wed, 5 Mar 2003 10:31:41 -0600 Message-Id: <200303051631.h25GVf219340@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 10:31:41 -0600 Subject: TAKE - Eliminate a race condition in xfs_inval_cached_pages X-archive-position: 3047 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 23 Eliminate a race condition in xfs_inval_cached_pages Date: Wed Mar 5 08:30:55 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: gwehrman Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136462a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136462b linux/fs/xfs/xfs_rw.c - 1.374 - Merge of irix6.5f:irix:136462a by sandeen. Merge of grove2-6520stage:irix:136462a by roehrich. Merge of grove2:irix:136462a by roehrich. Eliminate a race condition in xfs_inval_cached_pages by using XFS_ILOCK_DEMOTE instead of unlock / lock. From owner-linux-xfs@oss.sgi.com Wed Mar 5 09:06:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 09:06:59 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25H6mf22652 for ; Wed, 5 Mar 2003 09:06:48 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25H6l9n028065 for ; Wed, 5 Mar 2003 09:06:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA36124 for ; Wed, 5 Mar 2003 11:06:47 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA63056 for ; Wed, 5 Mar 2003 11:06:46 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h25H6ku20613; Wed, 5 Mar 2003 11:06:46 -0600 Message-Id: <200303051706.h25H6ku20613@jen.americas.sgi.com> Date: Wed, 5 Mar 2003 11:06:46 -0600 Subject: TAKE 877736 - Eliminate a race condition in xfs_inval_cached_pages X-archive-position: 3048 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 434 Lines: 16 back out the last change to this file, it is incorrect, the merge tools broke on this one before. The actual fix has been in xfs linux for a long time. Date: Wed Mar 5 08:47:58 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 Undoes mod: 2.4.x-xfs:slinx:136462b The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140964a linux/fs/xfs/xfs_rw.c - 1.375 From owner-linux-xfs@oss.sgi.com Wed Mar 5 09:55:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 09:55:44 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25HtRf24756 for ; Wed, 5 Mar 2003 09:55:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25HtQ9n031805 for ; Wed, 5 Mar 2003 09:55:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA70156 for ; Wed, 5 Mar 2003 11:55:25 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA55887 for ; Wed, 5 Mar 2003 11:55:23 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h261B4H19971 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 20:11:04 -0500 Resent-Message-Id: <200303060111.h261B4H19971@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA77659 for ; Wed, 5 Mar 2003 11:52:04 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h25Hq2ok19132740 for ; Wed, 5 Mar 2003 09:52:02 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h25Hn1M0007800 for ; Wed, 5 Mar 2003 18:49:01 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h25Hn1Zo007799 for hch@sgi.com; Wed, 5 Mar 2003 18:49:01 +0100 Date: Wed, 5 Mar 2003 18:49:01 +0100 From: Christoph Hellwig Message-Id: <200303051749.h25Hn1Zo007799@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.64 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Wed, 5 Mar 2003 20:11:04 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3049 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 50114 Lines: 1279 Date: Wed Mar 5 09:44:20 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:140970a linux/drivers/acpi/events/evgpeblk.c - 1.1 linux/scripts/genksyms/parse.y - 1.1 linux/scripts/genksyms/parse.h_shipped - 1.1 linux/scripts/genksyms/parse.c_shipped - 1.1 linux/scripts/genksyms/lex.l - 1.1 linux/Documentation/DocBook/usb.tmpl - 1.1 linux/scripts/genksyms/lex.c_shipped - 1.1 linux/Documentation/arm/XScale/IOP3XX/IQ80310 - 1.1 linux/Documentation/arm/XScale/IOP3XX/IQ80321 - 1.1 linux/Documentation/arm/XScale/IOP3XX/aau.txt - 1.1 linux/Documentation/arm/XScale/IOP3XX/dma.txt - 1.1 linux/Documentation/arm/XScale/IOP3XX/message.txt - 1.1 linux/Documentation/arm/XScale/IOP3XX/pmon.txt - 1.1 linux/Documentation/arm/XScale/cache-lock.txt - 1.1 linux/Documentation/arm/XScale/pmu.txt - 1.1 linux/Documentation/arm/XScale/tlb-lock.txt - 1.1 linux/scripts/genksyms/keywords.gperf - 1.1 linux/Documentation/cpu-freq/core.txt - 1.1 linux/Documentation/cpu-freq/cpu-drivers.txt - 1.1 linux/Documentation/cpu-freq/governors.txt - 1.1 linux/Documentation/cpu-freq/index.txt - 1.1 linux/Documentation/cpu-freq/user-guide.txt - 1.1 linux/scripts/genksyms/keywords.c_shipped - 1.1 linux/scripts/genksyms/genksyms.h - 1.1 linux/drivers/base/init.c - 1.1 linux/drivers/char/watchdog/amd7xx_tco.c - 1.1 linux/scripts/genksyms/genksyms.c - 1.1 linux/drivers/cpufreq/userspace.c - 1.1 linux/scripts/genksyms/Makefile - 1.1 linux/net/ipv6/netfilter/ip6t_frag.c - 1.1 linux/include/linux/netfilter_ipv6/ip6t_ipv6header.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_opts.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_rt.h - 1.1 linux/net/sctp/proc.c - 1.1 linux/include/linux/netfilter_ipv6/ip6t_hl.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_frag.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_esp.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_ah.h - 1.1 linux/fs/sysfs/bin.c - 1.1 linux/fs/sysfs/dir.c - 1.1 linux/net/ipv6/netfilter/ip6t_rt.c - 1.1 linux/net/ipv6/netfilter/ip6t_ipv6header.c - 1.1 linux/drivers/hotplug/cpqphp_sysfs.c - 1.1 linux/drivers/scsi/scsi_pc98.c - 1.1 linux/drivers/usb/input/kbtab.c - 1.1 linux/drivers/usb/serial/keyspan_mpr_fw.h - 1.1 linux/net/ipv6/netfilter/ip6t_hl.c - 1.1 linux/net/ipv6/netfilter/ip6t_hbh.c - 1.1 linux/drivers/video/cg14.c - 1.1 linux/drivers/usb/serial/keyspan_usa49wlc_fw.h - 1.1 linux/drivers/video/bw2.c - 1.1 linux/net/ipv6/netfilter/ip6t_esp.c - 1.1 linux/fs/sysfs/file.c - 1.1 linux/drivers/video/cg3.c - 1.1 linux/drivers/video/cg6.c - 1.1 linux/net/ipv6/netfilter/ip6t_dst.c - 1.1 linux/drivers/video/ffb.c - 1.1 linux/drivers/video/p9100.c - 1.1 linux/net/ipv6/netfilter/ip6t_ah.c - 1.1 linux/drivers/video/sbuslib.c - 1.1 linux/drivers/video/sbuslib.h - 1.1 linux/arch/i386/kernel/srat.c - 1.1 linux/fs/sysfs/mount.c - 1.1 linux/init/do_mounts_md.c - 1.1 linux/drivers/video/tcx.c - 1.1 linux/fs/sysfs/symlink.c - 1.1 linux/init/do_mounts.h - 1.1 linux/init/do_mounts_devfs.c - 1.1 linux/init/do_mounts_rd.c - 1.1 linux/arch/i386/mm/boot_ioremap.c - 1.1 linux/fs/sysfs/sysfs.h - 1.1 linux/include/asm-i386/srat.h - 1.1 linux/include/asm-arm/arch-pxa/bitfield.h - 1.1 linux/scripts/README.Menuconfig - 1.4 linux/scripts/Makefile - 1.17 linux/net/sunrpc/auth_unix.c - 1.13 linux/net/socket.c - 1.51 linux/net/netsyms.c - 1.62 linux/net/irda/irttp.c - 1.21 linux/net/irda/irlmp_event.c - 1.21 linux/net/ipx/af_ipx.c - 1.33 linux/net/ipv6/sit.c - 1.28 linux/net/ipv6/route.c - 1.29 linux/net/ipv6/ndisc.c - 1.29 linux/net/ipv6/addrconf.c - 1.32 linux/net/ipv4/tcp.c - 1.51 linux/net/core/dev.c - 1.69 linux/net/core/Makefile - 1.14 linux/mm/swap_state.c - 1.59 linux/mm/swap.c - 1.34 linux/mm/slab.c - 1.52 linux/mm/mmap.c - 1.72 linux/mm/memory.c - 1.101 linux/mm/filemap.c - 1.150 linux/kernel/sys.c - 1.48 linux/kernel/module.c - 1.39 linux/kernel/ksyms.c - 1.183 linux/kernel/fork.c - 1.85 linux/kernel/exit.c - 1.66 linux/init/main.c - 1.102 linux/include/video/sbusfb.h - 1.7 linux/include/net/irda/irda_device.h - 1.16 linux/include/linux/time.h - 1.12 linux/include/linux/swap.h - 1.73 linux/include/linux/smp.h - 1.26 linux/include/linux/serial.h - 1.18 linux/include/linux/sdla_x25.h - 1.5 linux/include/linux/pci.h - 1.73 linux/include/linux/net.h - 1.13 linux/include/linux/module.h - 1.46 linux/include/linux/mm.h - 1.114 linux/include/linux/list.h - 1.24 linux/include/linux/if.h - 1.7 linux/include/linux/ghash.h - 1.3 linux/include/linux/fs.h - 1.208 linux/include/linux/dcache.h - 1.34 linux/include/linux/cyclades.h - 1.10 linux/include/asm-sparc64/uaccess.h - 1.10 linux/include/asm-sparc64/pbm.h - 1.13 linux/include/asm-sparc64/ioctl.h - 1.3 linux/include/asm-sparc64/hardirq.h - 1.19 linux/include/asm-sparc/uaccess.h - 1.11 linux/include/asm-sparc/ioctl.h - 1.4 linux/include/asm-ppc/uaccess.h - 1.14 linux/include/asm-ppc/page.h - 1.22 linux/include/asm-mips/processor.h - 1.21 linux/include/asm-mips/pgtable.h - 1.20 linux/include/asm-mips/pci.h - 1.14 linux/include/asm-mips/mipsregs.h - 1.10 linux/include/asm-m68k/posix_types.h - 1.5 linux/include/asm-m68k/page.h - 1.15 linux/include/asm-m68k/io.h - 1.10 linux/include/asm-m68k/dvma.h - 1.8 linux/include/asm-i386/uaccess.h - 1.20 linux/include/asm-i386/sigcontext.h - 1.5 linux/include/asm-i386/semaphore.h - 1.19 linux/include/asm-i386/page.h - 1.35 linux/include/asm-arm/proc-fns.h - 1.13 linux/include/asm-arm/bitops.h - 1.14 linux/include/asm-alpha/pci.h - 1.18 linux/include/asm-alpha/mman.h - 1.6 linux/include/asm-alpha/bitops.h - 1.15 linux/fs/ufs/util.h - 1.11 linux/fs/super.c - 1.97 linux/fs/proc/array.c - 1.58 linux/fs/nfsd/nfsctl.c - 1.39 linux/fs/nfsd/export.c - 1.49 linux/fs/inode.c - 1.91 linux/fs/filesystems.c - 1.26 linux/fs/ext2/ialloc.c - 1.35 linux/fs/ext2/dir.c - 1.27 linux/fs/dcache.c - 1.47 linux/fs/buffer.c - 1.150 linux/drivers/video/virgefb.c - 1.20 linux/drivers/video/tcxfb.c - 1.11 linux/drivers/video/sbusfb.c - 1.26 linux/drivers/video/retz3fb.c - 1.21 linux/drivers/video/macfb.c - 1.18 linux/drivers/video/fbmem.c - 1.59 linux/drivers/video/creatorfb.c - 1.17 linux/drivers/video/controlfb.c - 1.27 linux/drivers/video/cgthreefb.c - 1.13 linux/drivers/video/cgsixfb.c - 1.16 linux/drivers/video/cgfourteenfb.c - 1.15 linux/drivers/video/bwtwofb.c - 1.13 linux/drivers/video/amifb.c - 1.27 linux/drivers/video/Makefile - 1.51 linux/drivers/scsi/wd33c93.c - 1.12 linux/drivers/scsi/sym53c8xx.c - 1.41 linux/drivers/scsi/sym53c416.c - 1.17 linux/drivers/scsi/st.c - 1.63 linux/drivers/scsi/sr.c - 1.62 linux/drivers/scsi/sgiwd93.c - 1.16 linux/drivers/scsi/seagate.c - 1.24 linux/drivers/scsi/sd.c - 1.83 linux/drivers/scsi/scsi_syms.c - 1.29 linux/drivers/scsi/scsi_proc.c - 1.16 linux/drivers/scsi/scsi_ioctl.c - 1.28 linux/drivers/scsi/scsi.h - 1.45 linux/drivers/scsi/scsi.c - 1.71 linux/drivers/scsi/qlogicpti.c - 1.26 linux/drivers/scsi/qlogicfc.c - 1.35 linux/drivers/scsi/ncr53c8xx.c - 1.32 linux/drivers/scsi/megaraid.c - 1.44 linux/drivers/scsi/mac_NCR5380.c - 1.8 linux/drivers/scsi/ibmmca.c - 1.23 linux/drivers/scsi/hosts.c - 1.42 linux/drivers/scsi/gdth.h - 1.13 linux/drivers/scsi/gdth.c - 1.26 linux/drivers/scsi/g_NCR5380.c - 1.21 linux/drivers/scsi/fdomain.c - 1.29 linux/drivers/scsi/esp.c - 1.32 linux/drivers/scsi/atari_NCR5380.c - 1.9 linux/drivers/scsi/aha1542.c - 1.33 linux/drivers/scsi/aha152x.c - 1.37 linux/drivers/scsi/NCR53c406a.c - 1.19 linux/drivers/scsi/NCR53C9x.c - 1.23 linux/drivers/scsi/NCR5380.c - 1.18 linux/drivers/scsi/Makefile - 1.50 linux/drivers/scsi/FlashPoint.c - 1.4 linux/drivers/scsi/AM53C974.c - 1.19 linux/drivers/sbus/char/envctrl.c - 1.20 linux/drivers/net/via-rhine.c - 1.41 linux/drivers/net/tlan.c - 1.32 linux/drivers/net/sunlance.c - 1.31 linux/drivers/net/sunhme.h - 1.14 linux/drivers/net/sunhme.c - 1.41 linux/drivers/net/smc-ultra.c - 1.27 linux/drivers/net/slhc.c - 1.15 linux/drivers/net/ne.c - 1.25 linux/drivers/net/irda/actisys.c - 1.14 linux/drivers/net/hp100.c - 1.27 linux/drivers/net/eth16i.c - 1.24 linux/drivers/net/eepro100.c - 1.56 linux/drivers/net/e2100.c - 1.19 linux/drivers/net/dgrs.c - 1.23 linux/drivers/net/cs89x0.c - 1.28 linux/drivers/net/atp.c - 1.23 linux/drivers/net/acenic.c - 1.44 linux/drivers/net/8390.c - 1.28 linux/drivers/net/3c527.c - 1.23 linux/drivers/net/3c515.c - 1.28 linux/drivers/net/3c509.c - 1.43 linux/drivers/net/3c503.c - 1.25 linux/drivers/net/3c501.c - 1.25 linux/drivers/macintosh/via-pmu.c - 1.24 linux/drivers/isdn/hisax/teles3.c - 1.19 linux/drivers/isdn/hisax/sedlbauer.c - 1.23 linux/drivers/isdn/hisax/rawhdlc.c - 1.8 linux/drivers/isdn/hisax/niccy.c - 1.21 linux/drivers/isdn/hisax/l3dss1.c - 1.19 linux/drivers/isdn/hisax/ix1_micro.c - 1.16 linux/drivers/isdn/hisax/elsa.c - 1.24 linux/drivers/isdn/hisax/diva.c - 1.20 linux/drivers/isdn/hisax/asuscom.c - 1.19 linux/drivers/char/vt.c - 1.33 linux/drivers/char/tty_io.c - 1.64 linux/drivers/char/synclink.c - 1.35 linux/drivers/char/rocket_int.h - 1.5 linux/drivers/char/nvram.c - 1.28 linux/drivers/char/n_hdlc.c - 1.19 linux/drivers/char/ftape/zftape/zftape-write.c - 1.6 linux/drivers/char/ftape/zftape/zftape-vtbl.h - 1.5 linux/drivers/char/ftape/lowlevel/ftape_syms.c - 1.5 linux/drivers/char/ftape/lowlevel/ftape-calibr.c - 1.6 linux/drivers/char/epca.c - 1.26 linux/drivers/char/cyclades.c - 1.28 linux/drivers/char/cd1865.h - 1.4 linux/drivers/char/Makefile - 1.82 linux/drivers/cdrom/sbpcd.c - 1.35 linux/drivers/cdrom/cdrom.c - 1.53 linux/drivers/block/loop.c - 1.79 linux/drivers/block/ll_rw_blk.c - 1.128 linux/drivers/block/genhd.c - 1.48 linux/drivers/acorn/net/ether3.c - 1.17 linux/drivers/acorn/block/mfmhd.c - 1.37 linux/drivers/acorn/block/fd1772.c - 1.33 linux/arch/sparc64/solaris/entry64.S - 1.6 linux/arch/sparc64/prom/misc.c - 1.15 linux/arch/sparc64/prom/Makefile - 1.15 linux/arch/sparc64/mm/Makefile - 1.13 linux/arch/sparc64/lib/Makefile - 1.16 linux/arch/sparc64/kernel/traps.c - 1.26 linux/arch/sparc64/kernel/time.c - 1.30 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.53 linux/arch/sparc64/kernel/setup.c - 1.38 linux/arch/sparc64/kernel/ioctl32.c - 1.68 linux/arch/sparc64/kernel/init_task.c - 1.11 linux/arch/sparc64/kernel/Makefile - 1.31 linux/arch/sparc64/defconfig - 1.87 linux/arch/sparc/mm/sun4c.c - 1.42 linux/arch/sparc/mm/srmmu.c - 1.43 linux/arch/sparc/mm/iommu.c - 1.15 linux/arch/sparc/lib/checksum.S - 1.3 linux/arch/sparc/lib/blockops.S - 1.3 linux/arch/sparc/kernel/time.c - 1.25 linux/arch/sparc/kernel/ioport.c - 1.25 linux/arch/sparc/kernel/init_task.c - 1.10 linux/arch/ppc/kernel/time.c - 1.25 linux/arch/mips/kernel/traps.c - 1.13 linux/arch/mips/kernel/time.c - 1.16 linux/arch/mips/kernel/setup.c - 1.15 linux/arch/mips/kernel/r4k_switch.S - 1.9 linux/arch/mips/kernel/r4k_misc.S - 1.9 linux/arch/mips/kernel/r2300_switch.S - 1.9 linux/arch/mips/kernel/r2300_misc.S - 1.6 linux/arch/mips/kernel/process.c - 1.16 linux/arch/mips/kernel/pci.c - 1.11 linux/arch/mips/kernel/irq.c - 1.15 linux/arch/m68k/q40/README - 1.7 linux/arch/m68k/kernel/time.c - 1.9 linux/arch/m68k/kernel/head.S - 1.12 linux/arch/i386/mm/ioremap.c - 1.20 linux/arch/i386/mm/Makefile - 1.14 linux/arch/i386/kernel/time.c - 1.36 linux/arch/i386/kernel/smp.c - 1.55 linux/arch/i386/kernel/setup.c - 1.89 linux/arch/i386/kernel/ldt.c - 1.17 linux/arch/i386/kernel/irq.c - 1.54 linux/arch/i386/kernel/io_apic.c - 1.55 linux/arch/i386/kernel/i386_ksyms.c - 1.67 linux/arch/i386/kernel/entry.S - 1.75 linux/arch/i386/kernel/apm.c - 1.59 linux/arch/i386/kernel/Makefile - 1.46 linux/arch/i386/boot/bootsect.S - 1.17 linux/arch/arm/kernel/time.c - 1.23 linux/arch/arm/kernel/ptrace.c - 1.26 linux/arch/arm/kernel/entry-armv.S - 1.39 linux/arch/arm/kernel/entry-armo.S - 1.17 linux/arch/alpha/lib/checksum.c - 1.4 linux/arch/alpha/kernel/traps.c - 1.29 linux/arch/alpha/kernel/time.c - 1.28 linux/arch/alpha/kernel/smp.c - 1.43 linux/arch/alpha/kernel/process.c - 1.34 linux/arch/alpha/kernel/entry.S - 1.36 linux/arch/alpha/boot/tools/objstrip.c - 1.5 linux/Makefile - 1.241 linux/MAINTAINERS - 1.134 linux/Documentation/ioctl-number.txt - 1.21 linux/Documentation/filesystems/vfs.txt - 1.8 linux/Documentation/filesystems/hpfs.txt - 1.5 linux/Documentation/00-INDEX - 1.16 linux/net/decnet/dn_dev.c - 1.17 linux/include/net/dn_dev.h - 1.6 linux/fs/hpfs/dnode.c - 1.8 linux/drivers/video/cyber2000fb.c - 1.37 linux/drivers/net/sk_mca.c - 1.16 linux/drivers/isdn/hisax/avm_pci.c - 1.20 linux/drivers/isdn/eicon/eicon_idi.c - 1.17 linux/Documentation/networking/decnet.txt - 1.11 linux/Documentation/kernel-parameters.txt - 1.22 linux/drivers/net/declance.c - 1.19 linux/arch/mips/dec/boot/decstation.c - 1.2 linux/arch/mips/baget/wbflush.c - 1.4 linux/drivers/block/cpqarray.c - 1.65 linux/drivers/parport/parport_pc.c - 1.54 linux/drivers/char/sx.c - 1.32 linux/drivers/char/generic_serial.c - 1.15 linux/Documentation/sx.txt - 1.3 linux/drivers/scsi/oktagon_esp.c - 1.12 linux/drivers/isdn/hisax/isurf.c - 1.16 linux/drivers/isdn/hisax/hfcscard.c - 1.13 linux/arch/m68k/math-emu/fp_util.S - 1.5 linux/drivers/net/sis900.c - 1.42 linux/drivers/net/sb1000.c - 1.21 linux/drivers/net/fc/tach_structs.h - 1.3 linux/drivers/net/fc/iph5526.c - 1.24 linux/drivers/atm/suni.c - 1.11 linux/drivers/atm/horizon.h - 1.5 linux/drivers/atm/horizon.c - 1.16 linux/net/core/netfilter.c - 1.20 linux/net/atm/lec.h - 1.8 linux/net/atm/lec.c - 1.18 linux/net/802/fc.c - 1.4 linux/include/linux/fcdevice.h - 1.3 linux/arch/alpha/kernel/pci.c - 1.30 linux/arch/sparc64/kernel/pci_common.c - 1.20 linux/arch/sh/kernel/time.c - 1.19 linux/arch/sh/kernel/irq.c - 1.17 linux/drivers/video/p9100fb.c - 1.7 linux/drivers/video/p9100.h - 1.3 linux/drivers/scsi/ips.c - 1.38 linux/include/linux/n_r3964.h - 1.4 linux/include/asm-sh/semaphore.h - 1.7 linux/drivers/pcmcia/i82365.c - 1.34 linux/drivers/pcmcia/cardbus.c - 1.27 linux/arch/m68k/sun3/config.c - 1.11 linux/fs/udf/dir.c - 1.23 linux/include/asm-m68k/swim_iop.h - 1.2 linux/include/asm-sparc64/pci.h - 1.14 linux/include/asm-sparc/pci.h - 1.13 linux/drivers/net/pcmcia/Makefile - 1.26 linux/include/linux/acpi.h - 1.35 linux/drivers/net/tokenring/olympic.c - 1.25 linux/arch/i386/lib/mmx.c - 1.10 linux/arch/i386/kernel/smpboot.c - 1.58 linux/include/linux/pci_ids.h - 1.85 linux/drivers/net/wan/z85230.c - 1.13 linux/drivers/net/wan/sealevel.c - 1.13 linux/drivers/net/wan/sdlamain.c - 1.15 linux/drivers/net/wan/sdla_x25.c - 1.16 linux/drivers/net/wan/sdla_ppp.c - 1.21 linux/drivers/net/wan/sdla_fr.c - 1.21 linux/drivers/net/wan/sbni.c - 1.21 linux/drivers/net/wan/hostess_sv11.c - 1.12 linux/drivers/net/wan/dlci.c - 1.11 linux/Documentation/vm/locking - 1.9 linux/include/asm-i386/pgtable-2level.h - 1.11 linux/fs/proc/proc_misc.c - 1.56 linux/drivers/scsi/sun3_scsi.c - 1.15 linux/drivers/net/sk98lin/skxmac2.c - 1.7 linux/drivers/net/sk98lin/skgepnmi.c - 1.6 linux/drivers/net/sk98lin/skgesirq.c - 1.6 linux/Documentation/networking/sk98lin.txt - 1.6 linux/drivers/net/sk98lin/h/lm80.h - 1.5 linux/drivers/net/sk98lin/h/skdrv1st.h - 1.8 linux/drivers/net/sk98lin/h/skdrv2nd.h - 1.5 linux/drivers/net/sk98lin/skvpd.c - 1.7 linux/drivers/net/sk98lin/skge.c - 1.23 linux/drivers/net/sk98lin/skgehwt.c - 1.4 linux/drivers/net/sk98lin/skqueue.c - 1.5 linux/drivers/net/sk98lin/ski2c.c - 1.5 linux/drivers/net/sk98lin/h/xmac_ii.h - 1.6 linux/drivers/net/sk98lin/skcsum.c - 1.5 linux/arch/ppc/mm/mem_pieces.h - 1.5 linux/arch/ppc/mm/mem_pieces.c - 1.8 linux/include/linux/agp_backend.h - 1.27 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.18 linux/kernel/timer.c - 1.41 linux/drivers/char/agp/agp.h - 1.35 linux/drivers/i2c/i2c-dev.c - 1.25 linux/drivers/i2c/i2c-core.c - 1.22 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.10 linux/arch/sparc64/kernel/sbus.c - 1.19 linux/arch/sparc64/kernel/iommu_common.h - 1.6 linux/include/linux/telephony.h - 1.9 linux/drivers/telephony/ixj.c - 1.27 linux/drivers/net/tokenring/smctr.c - 1.19 linux/net/sched/sch_gred.c - 1.13 linux/drivers/ieee1394/raw1394.c - 1.25 linux/drivers/ieee1394/ieee1394_core.c - 1.28 linux/drivers/ieee1394/ohci1394.h - 1.19 linux/drivers/ieee1394/ohci1394.c - 1.29 linux/drivers/ieee1394/ieee1394_types.h - 1.18 linux/drivers/ieee1394/ieee1394_transactions.h - 1.7 linux/drivers/ieee1394/ieee1394_transactions.c - 1.14 linux/arch/i386/kernel/apic.c - 1.41 linux/drivers/ieee1394/hosts.c - 1.18 linux/arch/i386/kernel/mpparse.c - 1.35 linux/drivers/ieee1394/Makefile - 1.20 linux/drivers/scsi/scsi_scan.c - 1.41 linux/drivers/net/wan/sdla_chdlc.c - 1.21 linux/drivers/net/tokenring/madgemc.c - 1.9 linux/drivers/char/scc.h - 1.2 linux/drivers/atm/iphase.h - 1.4 linux/drivers/atm/iphase.c - 1.18 linux/arch/ia64/ia32/ia32_signal.c - 1.13 linux/arch/alpha/kernel/pci_iommu.c - 1.22 linux/arch/ia64/kernel/irq.c - 1.26 linux/arch/ia64/kernel/smp.c - 1.21 linux/arch/ia64/kernel/time.c - 1.19 linux/arch/ia64/lib/checksum.c - 1.4 linux/arch/ia64/lib/do_csum.S - 1.8 linux/arch/ia64/kernel/perfmon.c - 1.21 linux/fs/adfs/dir_f.c - 1.11 linux/kernel/pm.c - 1.14 linux/include/asm-ia64/page.h - 1.20 linux/drivers/scsi/sun3_NCR5380.c - 1.9 linux/drivers/isdn/hisax/hfc_sx.c - 1.18 linux/arch/i386/kernel/microcode.c - 1.22 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.12 linux/fs/devfs/base.c - 1.52 linux/drivers/isdn/hysdn/hysdn_boot.c - 1.8 linux/drivers/net/skfp/hwt.c - 1.2 linux/drivers/net/skfp/h/smc.h - 1.3 linux/drivers/net/tulip/tulip_core.c - 1.45 linux/drivers/net/tulip/interrupt.c - 1.19 linux/drivers/char/nwflash.c - 1.17 linux/include/asm-mips64/sn/klconfig.h - 1.5 linux/include/asm-mips64/processor.h - 1.14 linux/include/asm-mips64/pgtable.h - 1.17 linux/include/asm-mips64/pci.h - 1.10 linux/include/asm-mips64/mipsregs.h - 1.8 linux/drivers/atm/fore200e.c - 1.18 linux/arch/mips64/kernel/traps.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-pci-dma.c - 1.5 linux/arch/mips64/kernel/r4k_switch.S - 1.4 linux/arch/mips64/kernel/process.c - 1.10 linux/include/asm-sh/pci.h - 1.14 linux/arch/sh/kernel/fpu.c - 1.6 linux/include/linux/usb.h - 1.56 linux/drivers/usb/serial/usb-serial.h - 1.29 linux/drivers/ide/ide-dma.c - 1.36 linux/drivers/ide/ide-cd.c - 1.58 linux/Documentation/DocBook/Makefile - 1.41 linux/drivers/net/tokenring/lanstreamer.c - 1.15 linux/Documentation/DocBook/kernel-api.tmpl - 1.26 linux/net/ipv4/netfilter/ipt_state.c - 1.5 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.14 linux/net/ipv4/netfilter/ipchains_core.c - 1.14 linux/net/ipv4/netfilter/ip_tables.c - 1.17 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.20 linux/net/ipv4/netfilter/ip_nat_core.c - 1.18 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.18 linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c - 1.8 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.12 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.12 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.19 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.13 linux/Documentation/DocBook/parportbook.tmpl - 1.10 linux/drivers/video/sa1100fb.c - 1.21 linux/drivers/usb/serial/visor.c - 1.50 linux/arch/ia64/kernel/minstate.h - 1.10 linux/drivers/net/wan/lmc/lmc_main.c - 1.14 linux/drivers/net/pppoe.c - 1.26 linux/drivers/char/rio/riotty.c - 1.7 linux/drivers/char/rio/riotable.c - 1.7 linux/drivers/char/rio/rioroute.c - 1.6 linux/drivers/char/rio/list.h - 1.2 linux/drivers/char/rio/rioparam.c - 1.4 linux/drivers/char/rio/rioinit.c - 1.6 linux/drivers/char/rio/parmmap.h - 1.2 linux/drivers/char/rio/rio_linux.c - 1.19 linux/include/asm-s390/types.h - 1.5 linux/drivers/s390/net/iucv.h - 1.6 linux/drivers/s390/char/con3215.c - 1.12 linux/drivers/s390/block/dasd_eckd.c - 1.15 linux/drivers/s390/block/dasd.c - 1.38 linux/include/asm-s390/processor.h - 1.13 linux/arch/s390/kernel/time.c - 1.11 linux/arch/s390/kernel/smp.c - 1.19 linux/net/ipv6/netfilter/ip6_tables.c - 1.16 linux/net/ipv6/netfilter/Makefile - 1.14 linux/arch/mips64/kernel/smp.c - 1.11 linux/arch/mips64/sgi-ip27/ip27-nmi.c - 1.4 linux/drivers/char/drm/i810_drm.h - 1.5 linux/drivers/usb/serial/keyspan.h - 1.16 linux/drivers/usb/serial/keyspan.c - 1.40 linux/drivers/acpi/tables.c - 1.10 linux/drivers/acpi/resources/rsxface.c - 1.14 linux/drivers/acpi/resources/rsutils.c - 1.16 linux/drivers/acpi/resources/rsmemory.c - 1.13 linux/drivers/acpi/hardware/hwregs.c - 1.19 linux/drivers/acpi/hardware/hwgpe.c - 1.16 linux/drivers/acpi/events/evxfevnt.c - 1.16 linux/drivers/acpi/events/evxface.c - 1.19 linux/drivers/acpi/events/evsci.c - 1.14 linux/drivers/acpi/events/evrgnini.c - 1.17 linux/drivers/acpi/events/evmisc.c - 1.18 linux/drivers/acpi/events/evevent.c - 1.22 linux/drivers/acpi/ec.c - 1.18 linux/drivers/acpi/dispatcher/dsobject.c - 1.24 linux/drivers/ieee1394/video1394.c - 1.26 linux/drivers/mtd/ftl.c - 1.32 linux/drivers/mtd/mtdchar.c - 1.12 linux/drivers/usb/storage/freecom.c - 1.21 linux/drivers/media/video/zr36120_i2c.c - 1.2 linux/drivers/media/video/saa7110.c - 1.9 linux/drivers/media/radio/radio-terratec.c - 1.12 linux/drivers/media/radio/radio-sf16fmi.c - 1.17 linux/drivers/media/radio/radio-rtrack2.c - 1.12 linux/drivers/media/radio/radio-gemtek.c - 1.12 linux/drivers/media/radio/radio-aimslab.c - 1.12 linux/drivers/isdn/hysdn/hycapi.c - 1.13 linux/drivers/isdn/hisax/l3ni1.c - 1.12 linux/drivers/isdn/eicon/idi.c - 1.5 linux/drivers/isdn/eicon/adapter.h - 1.5 linux/drivers/acpi/events/Makefile - 1.8 linux/drivers/block/cciss.c - 1.52 linux/drivers/block/cciss_cmd.h - 1.10 linux/drivers/md/md.c - 1.70 linux/drivers/net/hamachi.c - 1.22 linux/drivers/scsi/cpqfcTScontrol.c - 1.9 linux/drivers/scsi/cpqfcTSinit.c - 1.27 linux/drivers/scsi/cpqfcTSworker.c - 1.15 linux/include/asm-ppc/uninorth.h - 1.7 linux/include/linux/cciss_ioctl.h - 1.4 linux/mm/oom_kill.c - 1.21 linux/drivers/usb/serial/belkin_sa.c - 1.28 linux/Documentation/networking/netdevices.txt - 1.3 linux/net/irda/irsyms.c - 1.12 linux/include/linux/ethtool.h - 1.14 linux/arch/sparc64/lib/U3memcpy.S - 1.3 linux/arch/sparc64/lib/U3copy_to_user.S - 1.3 linux/arch/sparc64/lib/U3copy_in_user.S - 1.3 linux/arch/sparc64/lib/U3copy_from_user.S - 1.4 linux/include/asm-parisc/mman.h - 1.4 linux/drivers/usb/serial/mct_u232.c - 1.29 linux/arch/parisc/mm/init.c - 1.7 linux/arch/parisc/kernel/time.c - 1.7 linux/arch/i386/kernel/dmi_scan.c - 1.25 linux/arch/parisc/kernel/ptrace.c - 1.8 linux/include/asm-parisc/assembly.h - 1.4 linux/arch/parisc/kernel/irq.c - 1.10 linux/arch/parisc/kernel/cache.c - 1.3 linux/drivers/acpi/tables/tbconvrt.c - 1.17 linux/drivers/atm/firestream.c - 1.14 linux/drivers/acpi/power.c - 1.14 linux/arch/m68k/ifpsp060/src/pfpsp.S - 1.6 linux/arch/m68k/ifpsp060/src/fpsp.S - 1.6 linux/arch/m68k/ifpsp060/src/isp.S - 1.5 linux/include/asm-ia64/sn/klconfig.h - 1.5 linux/include/asm-ia64/sn/sn_cpuid.h - 1.5 linux/arch/ia64/lib/swiotlb.c - 1.11 linux/arch/ia64/sn/io/hcl.c - 1.8 linux/arch/ia64/sn/io/l1.c - 1.7 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.6 linux/include/asm-ia64/sn/pci/bridge.h - 1.6 linux/fs/reiserfs/stree.c - 1.28 linux/fs/reiserfs/super.c - 1.33 linux/drivers/acpi/acpi_ksyms.c - 1.17 linux/drivers/acpi/hardware/hwsleep.c - 1.16 linux/drivers/acpi/hardware/hwtimer.c - 1.14 linux/fs/reiserfs/lbalance.c - 1.9 linux/fs/reiserfs/journal.c - 1.39 linux/fs/reiserfs/do_balan.c - 1.14 linux/drivers/usb/storage/unusual_devs.h - 1.17 linux/arch/s390x/kernel/time.c - 1.10 linux/arch/s390x/kernel/smp.c - 1.16 linux/include/asm-s390x/processor.h - 1.10 linux/Documentation/s390/TAPE - 1.3 linux/arch/alpha/kernel/pci-noop.c - 1.6 linux/arch/cris/drivers/ethernet.c - 1.11 linux/arch/cris/drivers/serial.c - 1.13 linux/arch/cris/kernel/kgdb.c - 1.6 linux/arch/cris/kernel/process.c - 1.14 linux/arch/cris/kernel/setup.c - 1.12 linux/arch/cris/kernel/signal.c - 1.11 linux/arch/cris/kernel/time.c - 1.9 linux/arch/cris/mm/fault.c - 1.9 linux/arch/cris/mm/tlb.c - 1.6 linux/arch/s390x/kernel/exec32.c - 1.6 linux/drivers/s390/block/dasd_fba.c - 1.11 linux/include/asm-s390x/types.h - 1.4 linux/drivers/s390/block/dasd_diag.c - 1.11 linux/drivers/s390/block/dasd_3990_erp.c - 1.12 linux/include/asm-cris/uaccess.h - 1.5 linux/include/asm-cris/processor.h - 1.12 linux/include/asm-cris/namei.h - 1.2 linux/drivers/scsi/aic7xxx_old.c - 1.29 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.13 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.8 linux/drivers/net/wan/dscc4.c - 1.17 linux/drivers/net/sungem.h - 1.9 linux/drivers/net/sungem.c - 1.25 linux/drivers/net/wan/wanpipe_multppp.c - 1.9 linux/Documentation/DocBook/deviceiobook.tmpl - 1.3 linux/net/wanrouter/af_wanpipe.c - 1.13 linux/Documentation/s390/s390dbf.txt - 1.4 linux/include/asm-i386/rwsem.h - 1.8 linux/arch/mips/mips-boards/generic/pci.c - 1.5 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.9 linux/arch/mips/math-emu/sp_sub.c - 1.2 linux/arch/mips/math-emu/sp_mul.c - 1.2 linux/arch/cris/boot/rescue/head.S - 1.6 linux/arch/mips/math-emu/sp_fdp.c - 1.2 linux/arch/mips/math-emu/sp_div.c - 1.2 linux/arch/mips/math-emu/sp_add.c - 1.2 linux/arch/mips/math-emu/ieee754sp.c - 1.2 linux/arch/mips/math-emu/ieee754dp.c - 1.2 linux/arch/mips/math-emu/ieee754.c - 1.2 linux/arch/mips/math-emu/dp_sub.c - 1.3 linux/arch/mips/math-emu/dp_mul.c - 1.2 linux/arch/mips/math-emu/dp_div.c - 1.2 linux/arch/mips/math-emu/dp_add.c - 1.2 linux/include/asm-sparc64/rwsem.h - 1.5 linux/include/linux/rwsem-spinlock.h - 1.4 linux/drivers/net/irda/irda-usb.c - 1.30 linux/drivers/net/wireless/orinoco.c - 1.16 linux/drivers/net/wireless/todo.txt - 1.3 linux/arch/cris/drivers/eeprom.c - 1.10 linux/drivers/mtd/nftlcore.c - 1.29 linux/drivers/mtd/nand/spia.c - 1.6 linux/drivers/mtd/maps/vmax301.c - 1.3 linux/drivers/mtd/maps/sun_uflash.c - 1.3 linux/drivers/mtd/maps/sc520cdp.c - 1.3 linux/drivers/mtd/maps/sbc_gxx.c - 1.4 linux/drivers/mtd/maps/sa1100-flash.c - 1.7 linux/drivers/mtd/maps/rpxlite.c - 1.3 linux/drivers/mtd/maps/pnc2000.c - 1.3 linux/drivers/mtd/maps/physmap.c - 1.3 linux/drivers/mtd/maps/octagon-5066.c - 1.3 linux/drivers/mtd/maps/ocelot.c - 1.3 linux/drivers/mtd/maps/nora.c - 1.3 linux/drivers/mtd/maps/netsc520.c - 1.3 linux/drivers/mtd/maps/iq80310.c - 1.4 linux/drivers/mtd/maps/elan-104nc.c - 1.5 linux/drivers/mtd/maps/dc21285.c - 1.4 linux/drivers/mtd/maps/dbox2-flash.c - 1.3 linux/drivers/mtd/maps/cstm_mips_ixx.c - 1.3 linux/drivers/mtd/maps/cfi_flagadm.c - 1.3 linux/drivers/mtd/devices/pmc551.c - 1.5 linux/drivers/mtd/chips/sharp.c - 1.4 linux/drivers/mtd/chips/map_rom.c - 1.3 linux/drivers/mtd/chips/map_ram.c - 1.3 linux/drivers/mtd/chips/jedec.c - 1.7 linux/drivers/mtd/chips/cfi_probe.c - 1.3 linux/drivers/mtd/chips/cfi_cmdset_0002.c - 1.4 linux/drivers/mtd/chips/cfi_cmdset_0001.c - 1.3 linux/drivers/mtd/chips/amd_flash.c - 1.5 linux/drivers/media/radio/miropcm20-rds-core.c - 1.5 linux/drivers/media/radio/miropcm20-radio.c - 1.8 linux/drivers/acpi/utilities/utglobal.c - 1.19 linux/drivers/acpi/utilities/utcopy.c - 1.17 linux/drivers/net/wireless/airo.c - 1.26 linux/arch/sh/stboards/pcidma.c - 1.2 linux/drivers/usb/serial/pl2303.c - 1.28 linux/arch/sh/kernel/pci-sh7751.c - 1.6 linux/arch/sh/kernel/pci-dma.c - 1.3 linux/arch/mips64/math-emu/sp_sub.c - 1.2 linux/arch/mips64/math-emu/sp_mul.c - 1.2 linux/arch/mips64/math-emu/sp_fdp.c - 1.2 linux/drivers/isdn/tpam/tpam_commands.c - 1.7 linux/arch/mips64/math-emu/sp_div.c - 1.2 linux/arch/mips64/math-emu/sp_add.c - 1.2 linux/arch/mips64/math-emu/ieee754sp.c - 1.2 linux/arch/mips64/math-emu/ieee754dp.c - 1.2 linux/arch/mips64/math-emu/dp_sub.c - 1.2 linux/arch/mips64/math-emu/dp_mul.c - 1.2 linux/arch/mips64/math-emu/dp_add.c - 1.2 linux/arch/mips64/math-emu/dp_div.c - 1.2 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.16 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.9 linux/arch/cris/drivers/lpslave/e100lpslavenet.c - 1.6 linux/drivers/media/video/zr36067.c - 1.12 linux/drivers/usb/usb-skeleton.c - 1.21 linux/drivers/char/ser_a2232.c - 1.7 linux/include/asm-alpha/rwsem.h - 1.5 linux/drivers/video/pvr2fb.c - 1.8 linux/drivers/message/fusion/mptscsih.c - 1.17 linux/drivers/message/fusion/mptlan.c - 1.10 linux/drivers/ieee1394/sbp2.c - 1.20 linux/drivers/ieee1394/sbp2.h - 1.13 linux/drivers/ieee1394/nodemgr.c - 1.15 linux/drivers/char/drm/drm_vm.h - 1.16 linux/include/asm-arm/arch-sa1100/simpad.h - 1.3 linux/include/net/irda/vlsi_ir.h - 1.5 linux/arch/arm/mach-sa1100/irq.c - 1.11 linux/arch/ppc/kernel/temp.c - 1.4 linux/arch/ppc/kernel/l2cr.S - 1.6 linux/drivers/video/sstfb.c - 1.13 linux/drivers/scsi/dpt_i2o.c - 1.21 linux/arch/mips/au1000/common/serial.c - 1.8 linux/arch/mips64/mips-boards/generic/pci.c - 1.3 linux/arch/mips/ddb5xxx/common/pci.c - 1.4 linux/drivers/i2c/i2c-adap-ite.c - 1.8 linux/drivers/i2c/i2c-algo-ite.c - 1.5 linux/include/asm-mips/ddb5xxx/ddb5xxx.h - 1.2 linux/Documentation/input/joystick-api.txt - 1.2 linux/fs/jffs2/compr_rtime.c - 1.4 linux/scripts/mkspec - 1.4 linux/arch/i386/kernel/nmi.c - 1.13 linux/drivers/char/mwave/tp3780i.h - 1.2 linux/drivers/mtd/maps/l440gx.c - 1.2 linux/drivers/mtd/devices/blkmtd.c - 1.21 linux/drivers/mtd/maps/integrator-flash.c - 1.3 linux/drivers/mtd/chips/map_absent.c - 1.2 linux/drivers/mtd/chips/jedec_probe.c - 1.4 linux/drivers/mtd/maps/cdb89712.c - 1.2 linux/drivers/mtd/maps/tqm8xxl.c - 1.2 linux/fs/namespace.c - 1.27 linux/drivers/mtd/maps/solutionengine.c - 1.2 linux/drivers/pcmcia/sa1100_graphicsclient.c - 1.4 linux/drivers/pcmcia/sa1100_generic.c - 1.14 linux/drivers/pcmcia/sa1100_freebird.c - 1.4 linux/drivers/pcmcia/sa1100_flexanet.c - 1.4 linux/drivers/pcmcia/sa1100_cerf.c - 1.5 linux/drivers/pcmcia/sa1100_assabet.c - 1.7 linux/drivers/pcmcia/sa1100_adsbitsy.c - 1.5 linux/drivers/pcmcia/sa1100.h - 1.5 linux/drivers/pcmcia/sa1100_graphicsmaster.c - 1.5 linux/drivers/pcmcia/sa1100_h3600.c - 1.4 linux/drivers/pcmcia/sa1100_jornada720.c - 1.6 linux/drivers/pcmcia/sa1100_neponset.c - 1.7 linux/drivers/pcmcia/sa1100_pangolin.c - 1.4 linux/drivers/pcmcia/sa1100_pfs168.c - 1.5 linux/drivers/pcmcia/sa1100_simpad.c - 1.5 linux/drivers/pcmcia/sa1100_stork.c - 1.5 linux/drivers/pcmcia/sa1100_xp860.c - 1.5 linux/drivers/pcmcia/sa1100_yopy.c - 1.4 linux/drivers/i2c/i2c-proc.c - 1.11 linux/include/linux/i2c-proc.h - 1.5 linux/drivers/message/i2o/i2o_core.c - 1.10 linux/drivers/message/i2o/i2o_block.c - 1.30 linux/drivers/atm/lanai.c - 1.7 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.4 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.6 linux/net/8021q/vlan.h - 1.4 linux/Documentation/networking/ifenslave.c - 1.4 linux/drivers/scsi/sym53c8xx_2/sym_conf.h - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_fw.c - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_fw1.h - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_fw2.h - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.13 linux/drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.6 linux/fs/ext3/file.c - 1.9 linux/fs/ext3/namei.c - 1.18 linux/drivers/hotplug/pci_hotplug_core.c - 1.18 linux/drivers/hotplug/cpqphp_proc.c - 1.7 linux/drivers/hotplug/cpqphp_pci.c - 1.9 linux/drivers/hotplug/cpqphp_core.c - 1.12 linux/drivers/hotplug/cpqphp.h - 1.5 linux/drivers/hotplug/Makefile - 1.9 linux/fs/intermezzo/super.c - 1.10 linux/fs/jbd/revoke.c - 1.10 linux/fs/seq_file.c - 1.7 linux/fs/ext3/dir.c - 1.8 linux/drivers/net/pcmcia/axnet_cs.c - 1.8 linux/fs/bio.c - 1.27 linux/include/linux/device.h - 1.28 linux/init/do_mounts.c - 1.25 linux/include/linux/gfp.h - 1.10 linux/drivers/usb/serial/ipaq.c - 1.20 linux/drivers/usb/serial/ipaq.h - 1.7 linux/drivers/usb/serial/kl5kusb105.c - 1.18 linux/arch/arm/mach-iop310/iop310-pci.c - 1.9 linux/arch/arm/mach-iop310/mm.c - 1.4 linux/arch/arm/kernel/head.S - 1.8 linux/drivers/block/cciss_scsi.c - 1.10 linux/lib/crc32.c - 1.7 linux/drivers/ieee1394/dv1394-private.h - 1.7 linux/drivers/ieee1394/dv1394.c - 1.12 linux/include/net/iw_handler.h - 1.5 linux/drivers/net/wireless/wavelan_cs.h - 1.2 linux/drivers/base/core.c - 1.23 linux/drivers/base/Makefile - 1.12 linux/include/linux/pnpbios.h - 1.8 linux/sound/sound_core.c - 1.7 linux/arch/ppc/4xx_io/serial_sicc.c - 1.4 linux/sound/pci/es1968.c - 1.14 linux/sound/pci/ens1370.c - 1.17 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.5 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.13 linux/sound/pci/ali5451/ali5451.c - 1.16 linux/sound/oss/wavfront.c - 1.4 linux/sound/oss/trident.h - 1.4 linux/sound/oss/trident.c - 1.11 linux/sound/oss/rme96xx.c - 1.8 linux/sound/oss/opl3sa2.c - 1.8 linux/sound/oss/nec_vrc5477.c - 1.5 linux/sound/oss/maestro3.c - 1.7 linux/sound/oss/maestro.c - 1.8 linux/sound/oss/ite8172.c - 1.5 linux/sound/oss/es1371.c - 1.9 linux/sound/oss/dmasound/dmasound_core.c - 1.4 linux/sound/oss/dmasound/dmasound_awacs.c - 1.5 linux/arch/ppc/platforms/pmac_feature.c - 1.5 linux/sound/oss/cs46xx.c - 1.7 linux/sound/oss/cs4232.c - 1.6 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.15 linux/arch/x86_64/kernel/apic.c - 1.12 linux/arch/x86_64/kernel/bluesmoke.c - 1.7 linux/arch/x86_64/kernel/io_apic.c - 1.6 linux/arch/x86_64/kernel/irq.c - 1.8 linux/arch/x86_64/kernel/ldt.c - 1.7 linux/arch/x86_64/kernel/nmi.c - 1.9 linux/arch/x86_64/kernel/smp.c - 1.12 linux/arch/x86_64/kernel/smpboot.c - 1.13 linux/arch/x86_64/kernel/time.c - 1.10 linux/arch/x86_64/mm/ioremap.c - 1.8 linux/sound/oss/awe_wave.c - 1.4 linux/sound/oss/ad1848.c - 1.10 linux/sound/oss/ad1816.c - 1.4 linux/sound/isa/wavefront/wavefront_synth.c - 1.9 linux/sound/isa/wavefront/wavefront_fx.c - 1.7 linux/sound/isa/opl3sa2.c - 1.13 linux/sound/drivers/mtpav.c - 1.13 linux/sound/core/seq/seq_timer.c - 1.8 linux/sound/core/seq/seq_midi_emul.c - 1.6 linux/sound/core/device.c - 1.10 linux/include/asm-x86_64/semaphore.h - 1.4 linux/include/asm-x86_64/rwsem.h - 1.6 linux/include/sound/wavefront.h - 1.3 linux/include/asm-alpha/thread_info.h - 1.5 linux/include/asm-x86_64/uaccess.h - 1.6 linux/arch/ppc64/boot/addRamDisk.c - 1.3 linux/arch/ppc64/boot/addSystemMap.c - 1.3 linux/arch/ppc64/kernel/head.S - 1.11 linux/arch/ppc64/kernel/ioctl32.c - 1.17 linux/arch/ppc64/kernel/lmb.c - 1.5 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.10 linux/arch/ppc64/kernel/pci_dn.c - 1.7 linux/arch/ppc64/kernel/ras.c - 1.3 linux/arch/ppc64/kernel/smp.c - 1.16 linux/arch/ppc64/kernel/time.c - 1.14 linux/arch/ppc64/xmon/xmon.c - 1.10 linux/include/asm-ppc64/uaccess.h - 1.6 linux/include/asm-ppc64/pgtable.h - 1.10 linux/include/asm-ppc64/page.h - 1.12 linux/drivers/hotplug/ibmphp_res.c - 1.5 linux/drivers/hotplug/ibmphp_hpc.c - 1.7 linux/drivers/hotplug/ibmphp_core.c - 1.11 linux/drivers/hotplug/ibmphp.h - 1.4 linux/fs/jfs/jfs_dmap.c - 1.12 linux/fs/quota_v2.c - 1.10 linux/drivers/net/tg3.h - 1.14 linux/drivers/net/tg3.c - 1.17 linux/drivers/pcmcia/sa1111_generic.h - 1.2 linux/drivers/pcmcia/sa1111_generic.c - 1.7 linux/drivers/pcmcia/sa1100_system3.c - 1.4 linux/drivers/pcmcia/sa1100_shannon.c - 1.3 linux/drivers/net/tulip/winbond-840.c - 1.9 linux/drivers/pcmcia/sa1100_generic.h - 1.4 linux/drivers/pcmcia/sa1100_badge4.c - 1.6 linux/drivers/net/tulip/xircom_cb.c - 1.6 linux/drivers/net/tulip/xircom_tulip_cb.c - 1.4 linux/drivers/net/e100/e100.h - 1.13 linux/drivers/net/e100/e100_config.c - 1.8 linux/drivers/net/e100/e100_eeprom.c - 1.5 linux/drivers/net/e100/e100_main.c - 1.15 linux/Documentation/sound/oss/Wavefront - 1.2 linux/arch/ia64/sn/fakeprom/fpmem.c - 1.4 linux/arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.3 linux/arch/ia64/sn/kernel/sn1/sn1_smp.c - 1.4 linux/kernel/futex.c - 1.15 linux/arch/ia64/sn/kernel/setup.c - 1.6 linux/include/asm-ia64/sn/sn2/shub_mmr.h - 1.2 linux/include/asm-ia64/sn/sn2/mmzone_sn2.h - 1.3 linux/include/asm-ia64/sn/sn1/mmzone_sn1.h - 1.3 linux/include/asm-ia64/sn/pda.h - 1.3 linux/arch/ia64/sn/kernel/llsc4.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.3 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.4 linux/arch/ia64/sn/io/sn1/pcibr.c - 1.6 linux/net/ipv4/netfilter/arp_tables.c - 1.3 linux/drivers/net/wan/comx-hw-munich.c - 1.8 linux/drivers/ieee1394/eth1394.c - 1.6 linux/drivers/net/sb1250-mac.c - 1.3 linux/drivers/usb/image/microtek.c - 1.9 linux/drivers/usb/class/bluetty.c - 1.15 linux/drivers/usb/core/hcd.h - 1.14 linux/drivers/usb/core/hub.c - 1.20 linux/include/asm-arm/arch-pxa/time.h - 1.3 linux/include/asm-arm/arch-pxa/system.h - 1.3 linux/include/asm-arm/arch-pxa/pxa-regs.h - 1.5 linux/include/asm-arm/arch-pxa/lubbock.h - 1.2 linux/drivers/usb/input/hid-core.c - 1.15 linux/include/asm-arm/arch-pxa/irqs.h - 1.2 linux/include/asm-arm/arch-pxa/hardware.h - 1.3 linux/drivers/usb/media/konicawc.c - 1.10 linux/drivers/usb/host/ehci-dbg.c - 1.13 linux/arch/arm/mach-pxa/Makefile - 1.7 linux/arch/arm/mach-pxa/generic.c - 1.5 linux/arch/arm/mach-pxa/irq.c - 1.5 linux/arch/arm/mach-pxa/leds.c - 1.2 linux/arch/arm/mach-pxa/lubbock.c - 1.7 linux/drivers/usb/host/ehci-hcd.c - 1.18 linux/drivers/usb/host/ehci-q.c - 1.17 linux/drivers/usb/host/ehci-sched.c - 1.13 linux/drivers/usb/host/ehci.h - 1.11 linux/drivers/usb/host/ohci-dbg.c - 1.13 linux/drivers/usb/host/ohci-hcd.c - 1.18 linux/drivers/usb/host/ohci-hub.c - 1.8 linux/drivers/usb/host/ohci-mem.c - 1.11 linux/drivers/usb/host/ohci-q.c - 1.20 linux/drivers/usb/host/ohci.h - 1.10 linux/drivers/base/sys.c - 1.9 linux/drivers/base/base.h - 1.13 linux/drivers/usb/image/mdc800.c - 1.12 linux/drivers/usb/image/scanner.c - 1.18 linux/drivers/usb/image/scanner.h - 1.12 linux/drivers/usb/input/Makefile - 1.9 linux/drivers/ieee1394/amdtp.c - 1.7 linux/drivers/ieee1394/eth1394.h - 1.4 linux/mm/pdflush.c - 1.12 linux/drivers/usb/misc/auerswald.c - 1.13 linux/drivers/usb/misc/rio500.c - 1.8 linux/drivers/pcmcia/sa1100_trizeps.c - 1.4 linux/fs/ntfs/attrib.c - 1.10 linux/include/sound/uda1341.h - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.8 linux/drivers/char/synclinkmp.c - 1.8 linux/fs/ntfs/namei.c - 1.8 linux/fs/ntfs/mft.c - 1.8 linux/fs/ntfs/layout.h - 1.4 linux/drivers/char/pcmcia/synclink_cs.c - 1.9 linux/sound/i2c/l3/uda1341.c - 1.6 linux/fs/ntfs/aops.c - 1.12 linux/net/ipv6/ipv6_syms.c - 1.6 linux/drivers/pci/hotplug.c - 1.10 linux/drivers/pci/probe.c - 1.13 linux/fs/fs-writeback.c - 1.14 linux/arch/i386/pci/numa.c - 1.7 linux/arch/i386/pci/visws.c - 1.5 linux/init/Makefile - 1.15 linux/include/linux/jiffies.h - 1.4 linux/Documentation/block/biodoc.txt - 1.3 linux/kernel/suspend.c - 1.21 linux/drivers/video/cfbcopyarea.c - 1.7 linux/drivers/base/bus.c - 1.13 linux/drivers/char/drm/i830_drm.h - 1.3 linux/drivers/video/cfbimgblt.c - 1.7 linux/include/linux/suspend.h - 1.9 linux/fs/mpage.c - 1.18 linux/drivers/acpi/pci_link.c - 1.9 linux/drivers/acpi/processor.c - 1.17 linux/drivers/acpi/osl.c - 1.15 linux/include/asm-s390x/rwsem.h - 1.4 linux/drivers/isdn/hisax/amd7930_fn.c - 1.9 linux/drivers/isdn/hisax/enternow_pci.c - 1.6 linux/drivers/usb/host/ohci-sa1111.c - 1.12 linux/drivers/usb/class/usb-midi.h - 1.3 linux/drivers/s390/net/lcs.c - 1.11 linux/arch/i386/kernel/suspend.c - 1.10 linux/include/asm-s390/rwsem.h - 1.4 linux/drivers/usb/host/ohci-pci.c - 1.6 linux/arch/i386/kernel/cpu/intel.c - 1.12 linux/arch/i386/kernel/cpu/cyrix.c - 1.7 linux/arch/i386/kernel/cpu/amd.c - 1.9 linux/arch/i386/kernel/cpu/centaur.c - 1.5 linux/arch/arm/mm/proc-arm6_7.S - 1.6 linux/net/llc/llc_pdu.c - 1.6 linux/include/net/llc_conn.h - 1.7 linux/arch/i386/mm/pageattr.c - 1.3 linux/fs/direct-io.c - 1.17 linux/drivers/serial/clps711x.c - 1.7 linux/drivers/serial/uart00.c - 1.8 linux/drivers/serial/sa1100.c - 1.6 linux/drivers/serial/core.c - 1.9 linux/drivers/serial/anakin.c - 1.7 linux/drivers/serial/amba.c - 1.8 linux/drivers/serial/8250.c - 1.13 linux/arch/i386/mm/pgtable.c - 1.6 linux/drivers/serial/21285.c - 1.7 linux/include/linux/serial_core.h - 1.10 linux/Documentation/vm/overcommit-accounting - 1.3 linux/drivers/serial/sunzilog.c - 1.10 linux/drivers/serial/sunsu.c - 1.11 linux/net/sched/sch_htb.c - 1.6 linux/drivers/usb/misc/speedtouch.c - 1.12 linux/drivers/usb/misc/usblcd.c - 1.5 linux/drivers/i2c/i2c-algo-ibm_ocp.c - 1.4 linux/drivers/base/intf.c - 1.5 linux/net/ipv4/netfilter/ipt_helper.c - 1.2 linux/net/ipv4/netfilter/ipt_conntrack.c - 1.2 linux/drivers/base/class.c - 1.8 linux/include/net/sctp/user.h - 1.3 linux/net/sctp/ulpevent.c - 1.5 linux/net/sctp/protocol.c - 1.13 linux/net/sctp/Makefile - 1.5 linux/include/net/sctp/sctp.h - 1.10 linux/net/sctp/associola.c - 1.9 linux/net/sctp/endpointola.c - 1.6 linux/net/sctp/input.c - 1.10 linux/net/sctp/inqueue.c - 1.3 linux/net/sctp/ipv6.c - 1.10 linux/net/sctp/output.c - 1.7 linux/include/net/sctp/ulpqueue.h - 1.4 linux/net/sctp/outqueue.c - 1.9 linux/net/sctp/primitive.c - 1.5 linux/include/net/sctp/ulpevent.h - 1.2 linux/net/sctp/tsnmap.c - 1.2 linux/net/sctp/sm_make_chunk.c - 1.10 linux/include/net/sctp/command.h - 1.4 linux/net/sctp/sm_sideeffect.c - 1.11 linux/net/sctp/sm_statefuns.c - 1.10 linux/include/net/sctp/tsnmap.h - 1.2 linux/include/net/sctp/structs.h - 1.11 linux/net/sctp/socket.c - 1.11 linux/net/sctp/ulpqueue.c - 1.5 linux/arch/i386/mm/discontig.c - 1.6 linux/arch/i386/kernel/numaq.c - 1.5 linux/include/asm-i386/mmzone.h - 1.6 linux/include/asm-i386/numaq.h - 1.6 linux/drivers/ide/setup-pci.c - 1.10 linux/drivers/ide/ppc/pmac.c - 1.5 linux/drivers/ide/ppc/mpc8xx.c - 1.3 linux/drivers/ide/pci/pdc202xx_new.c - 1.9 linux/arch/um/kernel/irq.c - 1.6 linux/include/asm-um/pgtable.h - 1.6 linux/drivers/ide/arm/icside.c - 1.4 linux/arch/i386/mm/hugetlbpage.c - 1.12 linux/include/asm-i386/numnodes.h - 1.2 linux/arch/sparc64/mm/hugetlbpage.c - 1.6 linux/net/bridge/netfilter/ebtable_nat.c - 1.2 linux/net/bridge/netfilter/ebtable_filter.c - 1.2 linux/net/bridge/netfilter/ebtable_broute.c - 1.2 linux/drivers/base/platform.c - 1.4 linux/arch/i386/mach-visws/visws_apic.c - 1.4 linux/arch/ia64/mm/hugetlbpage.c - 1.6 linux/drivers/block/deadline-iosched.c - 1.7 linux/drivers/base/hotplug.c - 1.8 linux/drivers/base/cpu.c - 1.5 linux/drivers/usb/core/driverfs.c - 1.6 linux/Documentation/cpufreq - 1.3 linux/Documentation/vm/hugetlbpage.txt - 1.4 linux/include/asm-generic/topology.h - 1.4 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.7 linux/include/asm-i386/topology.h - 1.5 linux/sound/pci/cs46xx/dsp_spos.h - 1.5 linux/kernel/cpufreq.c - 1.9 linux/net/llc/af_llc.c - 1.4 linux/include/sound/cs46xx_dsp_spos.h - 1.6 linux/include/linux/cpufreq.h - 1.10 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.9 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.7 linux/sound/usb/usbaudio.c - 1.9 linux/drivers/usb/misc/usbtest.c - 1.9 linux/drivers/scsi/nsp32.c - 1.6 linux/drivers/scsi/aacraid/linit.c - 1.8 linux/drivers/scsi/aacraid/commsup.c - 1.3 linux/drivers/scsi/aacraid/comminit.c - 1.2 linux/fs/cifs/cifs_unicode.h - 1.2 linux/fs/nfsd/nfs4xdr.c - 1.8 linux/fs/cifs/cifspdu.h - 1.4 linux/arch/i386/kernel/timers/timer_tsc.c - 1.9 linux/drivers/isdn/hardware/eicon/istream.c - 1.2 linux/drivers/isdn/hardware/eicon/i4l_idi.c - 1.3 linux/drivers/isdn/hardware/eicon/dadapter.c - 1.2 linux/drivers/isdn/hardware/eicon/di.c - 1.2 linux/Documentation/arm/XScale/IOP310/IQ80310 - 1.2 linux/drivers/mtd/maps/autcpu12-nvram.c - 1.2 linux/drivers/mtd/maps/ceiva.c - 1.2 linux/drivers/mtd/maps/edb7312.c - 1.2 linux/drivers/mtd/maps/epxa10db-flash.c - 1.2 linux/drivers/mtd/maps/fortunet.c - 1.2 linux/drivers/mtd/maps/impa7.c - 1.2 linux/drivers/mtd/maps/pci.c - 1.2 linux/fs/afs/vnode.c - 1.2 linux/arch/i386/oprofile/nmi_int.c - 1.6 linux/drivers/block/scsi_ioctl.c - 1.6 linux/arch/x86_64/kernel/pci-gart.c - 1.5 linux/arch/x86_64/kernel/e820.c - 1.4 linux/arch/x86_64/mm/pageattr.c - 1.3 linux/scripts/Makefile.clean - 1.4 linux/drivers/isdn/i4l/isdn_ppp_ccp.c - 1.5 linux/fs/sysfs/Makefile - 1.4 linux/fs/sysfs/inode.c - 1.8 linux/include/linux/sysfs.h - 1.7 linux/drivers/pnp/interface.c - 1.7 linux/include/linux/kobject.h - 1.7 linux/drivers/net/pcmcia/Kconfig - 1.4 linux/arch/i386/Kconfig - 1.13 linux/drivers/net/wireless/Kconfig - 1.5 linux/arch/i386/mach-voyager/voyager_smp.c - 1.6 linux/scripts/Makefile.build - 1.8 linux/include/asm-parisc/pdc_chassis.h - 1.2 linux/arch/ia64/mm/discontig.c - 1.3 linux/include/asm-parisc/eisa_eeprom.h - 1.2 linux/include/asm-parisc/cacheflush.h - 1.2 linux/include/asm-ia64/mmzone.h - 1.3 linux/drivers/media/dvb/av7110/saa7146_core.c - 1.4 linux/drivers/media/dvb/av7110/saa7146.c - 1.3 linux/arch/parisc/kernel/perf.c - 1.6 linux/arch/parisc/kernel/perf_images.h - 1.2 linux/arch/parisc/kernel/smp.c - 1.4 linux/drivers/md/dm-table.c - 1.5 linux/drivers/md/dm-ioctl.c - 1.5 linux/drivers/scsi/Kconfig - 1.8 linux/drivers/char/agp/Kconfig - 1.7 linux/drivers/hotplug/acpiphp_glue.c - 1.6 linux/drivers/hotplug/acpiphp_pci.c - 1.3 linux/arch/sparc/Kconfig - 1.8 linux/arch/sparc64/Kconfig - 1.8 linux/fs/befs/linuxvfs.c - 1.6 linux/fs/befs/btree.c - 1.4 linux/fs/befs/ChangeLog - 1.5 linux/net/ipv6/netfilter/Kconfig - 1.2 linux/drivers/acpi/Kconfig - 1.5 linux/drivers/video/Kconfig - 1.9 linux/drivers/usb/serial/Kconfig - 1.6 linux/drivers/usb/input/Kconfig - 1.6 linux/fs/hugetlbfs/inode.c - 1.9 linux/fs/eventpoll.c - 1.6 linux/include/asm-m68knommu/MC68328.h - 1.2 linux/include/asm-m68knommu/MC68EZ328.h - 1.2 linux/include/asm-m68knommu/MC68VZ328.h - 1.2 linux/drivers/parisc/sba_iommu.c - 1.5 linux/drivers/parisc/dino.c - 1.6 linux/drivers/parisc/ccio-dma.c - 1.6 linux/include/linux/hugetlb.h - 1.6 linux/include/asm-m68knommu/mcftimer.h - 1.2 linux/drivers/net/fec.c - 1.4 linux/drivers/mtd/maps/uclinux.c - 1.2 linux/include/asm-v850/sim.h - 1.3 linux/include/asm-m68knommu/siginfo.h - 1.2 linux/drivers/base/firmware.c - 1.3 linux/include/asm-m68knommu/unistd.h - 1.2 linux/arch/v850/kernel/time.c - 1.4 linux/arch/m68knommu/kernel/ints.c - 1.3 linux/arch/m68knommu/kernel/syscalltable.S - 1.3 linux/arch/m68knommu/kernel/time.c - 1.3 linux/arch/m68knommu/platform/5307/entry.S - 1.3 linux/arch/m68knommu/platform/68360/ints.c - 1.2 linux/arch/v850/kernel/rte_ma1_cb.c - 1.2 linux/arch/v850/kernel/rte_cb_multi.c - 1.3 linux/arch/v850/kernel/ma.c - 1.2 linux/arch/v850/kernel/irq.c - 1.5 linux/drivers/net/b44.h - 1.2 linux/drivers/net/irda/actisys-sir.c - 1.2 linux/drivers/net/irda/irtty-sir.c - 1.2 linux/drivers/net/irda/sir_dev.c - 1.3 linux/drivers/net/irda/sir_kthread.c - 1.5 linux/drivers/hotplug/cpci_hotplug_pci.c - 1.4 linux/drivers/serial/68328serial.h - 1.2 linux/arch/i386/kernel/cpu/mcheck/non-fatal.c - 1.3 linux/arch/ppc/syslib/mpc10x_common.c - 1.5 linux/net/ipv4/esp.c - 1.4 linux/drivers/s390/char/sclp.c - 1.2 linux/drivers/s390/char/sclp_rw.c - 1.2 linux/Documentation/fb/sstfb.txt - 1.2 linux/Documentation/scsi/ibmmca.txt - 1.3 linux/drivers/usb/serial/kobil_sct.c - 1.3 linux/drivers/ieee1394/dma.c - 1.3 linux/drivers/acpi/events/evgpe.c - 1.6 linux/drivers/s390/cio/device_fsm.c - 1.2 linux/include/asm-s390x/ccwdev.h - 1.2 linux/include/asm-s390/ccwdev.h - 1.2 linux/drivers/char/agp/intel-agp.c - 1.6 linux/drivers/s390/cio/qdio.h - 1.3 linux/drivers/char/watchdog/Kconfig - 1.5 linux/drivers/char/watchdog/Makefile - 1.4 linux/drivers/char/watchdog/acquirewdt.c - 1.5 linux/drivers/char/watchdog/i810-tco.c - 1.4 linux/drivers/ide/ide-io.c - 1.3 linux/drivers/char/watchdog/ib700wdt.c - 1.4 linux/drivers/char/watchdog/machzwd.c - 1.5 linux/drivers/char/watchdog/mixcomwd.c - 1.4 linux/drivers/char/watchdog/pcwd.c - 1.5 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.5 linux/drivers/char/watchdog/wdt977.c - 1.5 linux/drivers/char/watchdog/wdt_pci.c - 1.4 linux/drivers/char/watchdog/shwdt.c - 1.4 linux/drivers/char/watchdog/softdog.c - 1.4 linux/drivers/char/watchdog/wdt.c - 1.5 linux/drivers/i2c/busses/i2c-amd8111.c - 1.2 linux/drivers/i2c/chips/adm1021.c - 1.3 linux/drivers/i2c/chips/lm75.c - 1.3 linux/arch/i386/kernel/sysenter.c - 1.4 linux/lib/crc32defs.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx.h - 1.3 linux/drivers/scsi/aic7xxx/aic79xx_core.c - 1.4 linux/include/asm-i386/mach-summit/mach_apic.h - 1.5 linux/include/asm-i386/mach-numaq/mach_apic.h - 1.4 linux/include/asm-i386/mach-default/mach_apic.h - 1.4 linux/include/asm-i386/mach-default/do_timer.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.6 linux/drivers/scsi/aic7xxx/aic79xx_osm.h - 1.4 linux/drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.3 linux/drivers/char/watchdog/indydog.c - 1.3 linux/drivers/char/watchdog/sc520_wdt.c - 1.5 linux/drivers/ide/pci/triflex.h - 1.2 linux/arch/ppc/platforms/4xx/ibmstbx25.h - 1.4 linux/net/sunrpc/rpc_pipe.c - 1.4 linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.4 linux/include/asm-i386/mach-bigsmp/mach_apic.h - 1.3 linux/include/linux/ipmi.h - 1.2 linux/arch/sparc64/kernel/us3_cpufreq.c - 1.2 linux/arch/alpha/kernel/sys_marvel.c - 1.3 linux/drivers/char/hangcheck-timer.c - 1.2 linux/include/acpi/acconfig.h - 1.3 linux/include/acpi/acdebug.h - 1.3 linux/arch/i386/kernel/cpu/cpufreq/acpi.c - 1.2 linux/include/acpi/acutils.h - 1.3 linux/include/acpi/acresrc.h - 1.3 linux/include/acpi/acpixf.h - 1.4 linux/arch/arm/common/sa1111.c - 1.3 linux/include/acpi/aclocal.h - 1.3 linux/include/acpi/acevents.h - 1.3 linux/include/acpi/acglobal.h - 1.3 linux/include/acpi/achware.h - 1.3 linux/drivers/cpufreq/Makefile - 1.2 linux/scripts/modpost.c - 1.3 linux/scripts/mk_elfconfig.c - 1.2 linux/drivers/cpufreq/Kconfig - 1.2 linux/scripts/Makefile.modpost - 1.2 linux/drivers/char/agp/alpha-agp.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.2 linux/drivers/acpi/sleep/proc.c - 1.2 linux/drivers/acpi/sleep/main.c - 1.2 linux/drivers/ieee1394/ieee1394-ioctl.h - 1.2 linux/arch/i386/kernel/acpi/wakeup.S - 1.2 linux/arch/i386/kernel/acpi/boot.c - 1.2 linux/arch/i386/kernel/acpi/sleep.c - 1.2 linux/arch/m68knommu/platform/5307/vectors.c - 1.2 linux/drivers/net/wireless/arlan.c - 1.2 linux/drivers/net/wireless/arlan-proc.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/Kconfig - 1.2 linux/kernel/posix-timers.c - 1.2 linux/include/asm-i386/mach-visws/cobalt.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:07:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:08:03 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25I7pf25540 for ; Wed, 5 Mar 2003 10:07:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25I7p9n000370 for ; Wed, 5 Mar 2003 10:07:51 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA55488 for ; Wed, 5 Mar 2003 12:07:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA90369 for ; Wed, 5 Mar 2003 12:07:50 -0600 (CST) Subject: TAKE - Fix indices into xfs_min/xfs_max for sysctls in 2.5.x From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Mar 2003 12:07:40 -0600 Message-Id: <1046887661.13282.59.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3050 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 451 Lines: 19 Fix indices into xfs_min/xfs_max for sysctls in 2.5.x Date: Wed Mar 5 10:03:28 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:140972a linux/fs/xfs/linux/xfs_sysctl.c - 1.14 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:23:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:23:51 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25INnf26307 for ; Wed, 5 Mar 2003 10:23:49 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25INm9n001749 for ; Wed, 5 Mar 2003 10:23:48 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA32718 for ; Wed, 5 Mar 2003 12:23:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA37182 for ; Wed, 5 Mar 2003 12:23:47 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25INci21229; Wed, 5 Mar 2003 12:23:38 -0600 Message-Id: <200303051823.h25INci21229@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 12:23:38 -0600 Subject: TAKE - Add stack trace print to xfs_error_report X-archive-position: 3051 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 862 Lines: 30 Add stack trace print to xfs_error_report, warning cleanup Date: Wed Mar 5 10:23:21 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: gwehrman lord Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136543a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136543a linux/fs/xfs/xfs_error.c - 1.38 - Merge of irix6.5f:irix:136543a by sandeen. Merge of grove2-6520stage:irix:136543a by roehrich. Merge of grove2:irix:136543a by roehrich. fix warnings about xfs_mount linux/fs/xfs/xfs_error.h - 1.31 - Merge of irix6.5f:irix:136543a by sandeen. Merge of grove2-6520stage:irix:136543a by roehrich. Merge of grove2:irix:136543a by roehrich. add xfs_stack_trace to print stack traces for xfs_error_report. From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:24:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:24:57 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25IOKf26362 for ; Wed, 5 Mar 2003 10:24:20 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18qdYx-0000PP-00 for linux-xfs@oss.sgi.com; Wed, 05 Mar 2003 19:24:19 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18qdWI-0003Eh-00; Wed, 05 Mar 2003 19:21:34 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Chris Wedgwood Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Wed, 5 Mar 2003 20:22:34 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: <200303051048.54271.juergen.sauer@automatix.de> <20030305093554.GA29602@f00f.org> In-Reply-To: <20030305093554.GA29602@f00f.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303052022.38108.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h25IOLf26364 X-archive-position: 3052 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 2030 Lines: 57 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 10:35 schrieb Chris Wedgwood: A few Remarks before to other replies, yes, Nvidia is well known to have problems with linux. (proprietrary, buggy, incomplete driver etc). On the other hand we are doing here a evaluation, if this board is usable. > On Wed, Mar 05, 2003 at 10:48:54AM +0100, Juergen Sauer wrote: > > The well known/common patches for 2.4 Kernels are failing on our XFS > > stable kernels. > failing? how so? The XFS Kernel 2.4.20-xfs out of the SGI/CVS Repository does not know about the the nforce2 ide and gives errors, if I enable DMA/UDMA modes. The common patches for fixing it are working against plain vanilla kernel - - without XFS. :-<< > does the amd7xx IDE driver fix this? it has some nv IDs in there by > the looks of things? The amd7xx driver is not in the kernel visible here. Should it be visible? (Error in config.in ?) > if not, what does "lspci -n" say for the ide controller? lspci -v 00:09.0 IDE interface: nVidia Corporation: Unknown device 0065 (rev a2) (prog-if 8a [Master SecP PriP]) Subsystem: Asustek Computer, Inc.: Unknown device 0c11 Flags: bus master, 66Mhz, fast devsel, latency 0 I/O ports at f000 [size=16] Capabilities: [44] Power Management version 2 lspci -n 00:09.0 Class 0101: 10de:0065 (rev a2) > avoid hardware where vendors make your life difficult Best idea - but it is not for private usage, it's for a small series of cheap performant development boxes. Paralell we requested the drivers from ASUS/Germany. mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Zk59W7UKI9EqarERAlzfAJ9qUGTBTY58PA1YatALPmfI1CtGMgCfZ1wA xHyx7U5L41Xu2hD3XUzqDL8= =9RY1 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:29:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:29:35 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25ITXf26895 for ; Wed, 5 Mar 2003 10:29:33 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25ITWnH032087 for ; Wed, 5 Mar 2003 10:29:32 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA58210 for ; Wed, 5 Mar 2003 12:29:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA64085 for ; Wed, 5 Mar 2003 12:29:32 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25ITM921984; Wed, 5 Mar 2003 12:29:22 -0600 Message-Id: <200303051829.h25ITM921984@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 12:29:22 -0600 Subject: TAKE - check the inode for extents after getting the shared lock X-archive-position: 3053 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 848 Lines: 25 In open, check the inode for extents after getting the shared lock on the inode. The inode could have changed since before the lock. Date: Wed Mar 5 10:29:00 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: lord Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:137931a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:137931a linux/fs/xfs/xfs_vnodeops.c - 1.585 - Merge of irix6.5f:irix:137931a by sandeen. Merge of grove2-6520stage:irix:137931a by roehrich. Merge of cxfs-client2.5.0:irix:137931a by roehrich. Merge of grove2:irix:137931a by roehrich. In open, check the inode for extents after getting the shared lock on the inode. The inode could have changed since before the lock. From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:59:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:59:50 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25Ixff28533 for ; Wed, 5 Mar 2003 10:59:41 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25IxfnH002680 for ; Wed, 5 Mar 2003 10:59:41 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA36581 for ; Wed, 5 Mar 2003 12:59:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA36241 for ; Wed, 5 Mar 2003 12:59:40 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25IxUD22534; Wed, 5 Mar 2003 12:59:30 -0600 Message-Id: <200303051859.h25IxUD22534@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 12:59:30 -0600 Subject: TAKE - Remove #if(n)def __KERNEL__ from xfs_error.c X-archive-position: 3054 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 13 Remove #if(n)def __KERNEL__ from xfs_error.c, not needed Date: Wed Mar 5 10:59:24 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140981a linux/fs/xfs/xfs_error.c - 1.39 From owner-linux-xfs@oss.sgi.com Wed Mar 5 11:08:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 11:09:03 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25J8tf29347 for ; Wed, 5 Mar 2003 11:08:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25J8s9n006276 for ; Wed, 5 Mar 2003 11:08:54 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA80903 for ; Wed, 5 Mar 2003 13:08:54 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA94714 for ; Wed, 5 Mar 2003 13:08:54 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h25J9B0t9154565 for ; Wed, 5 Mar 2003 13:09:11 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h25J9BC28582151 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 13:09:11 -0600 (CST) Date: Wed, 5 Mar 2003 13:09:11 -0600 (CST) From: Dean Roehrich Message-Id: <200303051909.h25J9BC28582151@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 883150 - fix mem leak in dm_send_namesp_event X-archive-position: 3055 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 520 Lines: 18 Date: Wed Mar 5 11:08:26 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs Inspected by: felixb Author: roehrich Merged by: roehrich Merged mods: grove2:irix:140983a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140983a linux/fs/xfs/dmapi/dmapi_event.c - 1.11 - Merge of grove2:irix:140983a by roehrich. dm_send_namesp_event leaked memory via tdp1 and tdp2 when preunmount comes in but the HSM doesn't want it. From owner-linux-xfs@oss.sgi.com Wed Mar 5 11:27:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 11:27:29 -0800 (PST) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25JRJf30185 for ; Wed, 5 Mar 2003 11:27:19 -0800 Received: from localhost (ifrs@fiesta.cs.tu-berlin.de [130.149.17.4]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with SMTP id UAA21184 for ; Wed, 5 Mar 2003 20:25:05 +0100 (MET) Date: Wed, 5 Mar 2003 20:25:04 +0100 From: Robert Starzynski To: XFS Mailing List Subject: incremental backup with xfsdump Message-Id: <20030305202504.2502bb80.ifrs@cs.tu-berlin.de> X-Mailer: Sylpheed version 0.8.10claws13 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.g_nlHKg'ktGl2:" X-archive-position: 3056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ifrs@cs.tu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1093 Lines: 42 --=.g_nlHKg'ktGl2: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi! I want to do an incremental backup with xfsdump excluding at the same time a directory so the "-s" switch doesn't work. Due to the docs I have use the SGI_XFSDUMP_SKIP_FILE attribute. I expected that setting this attribute on a directory would recursively exclude all files in that directory from the backup but unfortunately that's not the case. Is there a smarter way to do such an incremental backup than just setting this attribute on every file in that directory before a backup? (I have to assure that every file added since the last backup gets this attribute too.) I'm currently using the following debian packages: kernel-patch-xfs 1.2pre4-1 xfsdump 2.2.4-1 (dump format 3.0) attr 2.2.0-1 Thanks, Robert --=.g_nlHKg'ktGl2: Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Zk8Q9xefhZz8LH4RAjxvAJ98JV8VorICq8F766CTvMAHxDNQgwCgq2so IlQ4JCI4AdHydcjH1sPwATk= =ESF5 -----END PGP SIGNATURE----- --=.g_nlHKg'ktGl2:-- From owner-linux-xfs@oss.sgi.com Wed Mar 5 12:18:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 12:18:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h25KIm40024774 for ; Wed, 5 Mar 2003 12:18:48 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h25KImKT024772 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 12:18:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h25KIk42024759 for ; Wed, 5 Mar 2003 12:18:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h25KI2B2024689; Wed, 5 Mar 2003 12:18:02 -0800 Date: Wed, 5 Mar 2003 12:18:02 -0800 Message-Id: <200303052018.h25KI2B2024689@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 221] reload xfs/dmapi module crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3058 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 719 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=221 roehrich@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From roehrich@sgi.com 2003-03-05 12:18 ------- I checked in the following mod to fix the mem leak. Modid: 2.4.x-xfs:slinx:140983a linux/fs/xfs/dmapi/dmapi_event.c - 1.11 dm_send_namesp_event leaked memory via tdp1 and tdp2 when preunmount comes in but the HSM doesn't want it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 5 12:52:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 12:52:24 -0800 (PST) Received: from andrei.myip.org (12-234-128-127.client.attbi.com [12.234.128.127]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25Kom40025529 for ; Wed, 5 Mar 2003 12:52:20 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 089962FA71 for ; Wed, 5 Mar 2003 12:50:48 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 6FA6A2FA71 for ; Wed, 5 Mar 2003 12:50:47 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 1DE1C1967B for ; Wed, 5 Mar 2003 12:50:37 -0800 (PST) Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs In-Reply-To: <200303051048.54271.juergen.sauer@automatix.de> References: <200303051048.54271.juergen.sauer@automatix.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Mar 2003 12:50:36 -0800 Message-Id: <1046897437.31215.43.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 3059 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1018 Lines: 31 On Wed, 2003-03-05 at 01:48, Juergen Sauer wrote: > > The well known/common patches for 2.4 Kernels are failing on our > XFS stable kernels. > Without this patched the ide modules are not enableing DMA/UDMA at all so > this is not a usable solution. Is this a specific nForce2 problem? I was able to use XFS and DMA on nForce1 with no problems. > The original Nvidia "Drivers" has only "audio" and "network" drivers, but > nvida excluded the IDE Part. (Bad Boys!). Is it related just to IDE for the CD-ROM, or for all devices? If it's just for CD-ROMs, here's an excerpt from the RELEASE-NOTES for RH8.0: ########################### DMA is disabled on CD-ROM drives in this release in a different but more reliable way than previously. If you are sure that your CD-ROM drive is capable of IDE DMA, place the following line in the /etc/modules.conf file: options ide-cd dma=1 ############################ -- Florin Andrei "It is not because books are too expensive that they worship football." - Paul Graham From owner-linux-xfs@oss.sgi.com Wed Mar 5 13:05:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 13:05:17 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25L5D40029710 for ; Wed, 5 Mar 2003 13:05:15 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id D2484183068A; Wed, 5 Mar 2003 13:05:13 -0800 (PST) Date: Wed, 5 Mar 2003 13:05:13 -0800 From: Chris Wedgwood To: Juergen Sauer Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Message-ID: <20030305210513.GA427@f00f.org> References: <200303051048.54271.juergen.sauer@automatix.de> <20030305093554.GA29602@f00f.org> <200303052022.38108.juergen.sauer@automatix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303052022.38108.juergen.sauer@automatix.de> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3060 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 509 Lines: 19 On Wed, Mar 05, 2003 at 08:22:34PM +0100, Juergen Sauer wrote: > The XFS Kernel 2.4.20-xfs out of the SGI/CVS Repository does not > know about the the nforce2 ide and gives errors, if I enable > DMA/UDMA modes. I knows about the nv/amd driver though > The amd7xx driver is not in the kernel visible here. Should it be > visible? (Error in config.in ?) CONFIG_BLK_DEV_AMD74XX=y actually, i think you need an -ac tree for this, i was looking at the 2.5.x where the nv ide and amd ide are unified --cw From owner-linux-xfs@oss.sgi.com Wed Mar 5 13:57:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 13:58:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25LvqRu000672 for ; Wed, 5 Mar 2003 13:57:53 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25Lvl9n025500 for ; Wed, 5 Mar 2003 13:57:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA02286 for ; Wed, 5 Mar 2003 15:57:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA36661 for ; Wed, 5 Mar 2003 15:57:40 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25LvT529618; Wed, 5 Mar 2003 15:57:29 -0600 Message-Id: <200303052157.h25LvT529618@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 15:57:29 -0600 Subject: TAKE - Get all of userspace building within the tree again X-archive-position: 3061 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 378 Lines: 15 Get all of userspace building within the tree again Date: Wed Mar 5 13:57:25 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:141016a acl/libacl/Makefile - 1.22 - Add to LTLDFLAGS, don't clobber - lost settings from top level Makefile From owner-linux-xfs@oss.sgi.com Wed Mar 5 14:11:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 14:11:39 -0800 (PST) Received: from jello277.jellocom.de (root@jello277.jellocom.de [217.17.194.152]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25MAERu003784 for ; Wed, 5 Mar 2003 14:11:30 -0800 Received: from cobo-1.intranet.cobonet.de (ppp587.jetz.de [217.17.206.75]) (authenticated bits=0) by jello277.jellocom.de (8.12.8/8.12.1) with ESMTP id h25MA4oq000940; Wed, 5 Mar 2003 23:10:04 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Thomas Bittermann To: juergen.sauer@automatix.de Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Wed, 5 Mar 2003 23:09:46 +0100 User-Agent: KMail/1.4.3 References: <200303051048.54271.juergen.sauer@automatix.de> <20030305093554.GA29602@f00f.org> <200303052022.38108.juergen.sauer@automatix.de> In-Reply-To: <200303052022.38108.juergen.sauer@automatix.de> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <200303052309.51984.t.bittermann@online.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h25MBVRu003879 X-archive-position: 3062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: t.bittermann@online.de Precedence: bulk X-list: linux-xfs Content-Length: 1898 Lines: 62 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Juergen, I'm using a "home-grown" 2.4.21-pre5-ac1 with XFS (CVS-2003-03-05). Alan's patch removes nvidia.* from drivers/ide/pci (pre5). It includes nForce(2) support in drivers/ide/pci/amd74xx.* so be sure to activate "AMD Viper support". For now I could say it works stable and fast on my Leadtek K7NCR18D-Pro (nForce2): [root@cobo-1 root]# hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 7476/255/63, sectors = 120103200, start = 0 [root@localhost root]# hdparm -itT /dev/hda /dev/hda: Model=IC35L060AVER07-0, FwRev=ER6OA46A, SerialNo=SZPTZT98569 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 2 3 4 5 Timing buffer-cache reads: 128 MB in 0.36 seconds =355.56 MB/sec Timing buffered disk reads: 64 MB in 1.66 seconds = 38.55 MB/sec The box isn't really under stress but it serves my imap stuff and I'm coding a lot with Eclipse and compiling new kernels every hour ;-) Hope this helps... Cheers Thomas PS: XFS really ROCKS and you xfs-dev-guys doing a very good job! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZnWq3E3TGgPB70IRAu/SAKCe9PNkeOOLukyf5ne577NjNWHFdACfZQkQ M4wWS9TYhMU5Hy+2ImWQuF0= =ecXm -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 18:20:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 18:20:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h262Knq9012471 for ; Wed, 5 Mar 2003 18:20:49 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h262Kn2U012469 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 18:20:49 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h262Klq9012456 for ; Wed, 5 Mar 2003 18:20:47 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h261Pc30012127; Wed, 5 Mar 2003 17:25:38 -0800 Date: Wed, 5 Mar 2003 17:25:38 -0800 Message-Id: <200303060125.h261Pc30012127@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 227] New: unmount fail X-Bugzilla-Reason: AssignedTo X-archive-position: 3063 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 977 Lines: 47 http://oss.sgi.com/bugzilla/show_bug.cgi?id=227 Summary: unmount fail Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: grandsonata@netscape.net If this is a userspace bug, what version of the package are you using: XFS 1.2 What kernel are you using: 2.4.19 Where did the XFS code come from? (CVS, Linus, your distribution, etc): SGI Description of Problem: Unmounting at shutdown failed. Didn't happen in version 1.1. How Reproducible: not really reproducible. don't know what cause the unmount to fail. Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 5 19:20:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 19:20:52 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h263Knq9014020 for ; Wed, 5 Mar 2003 19:20:49 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h263KmjX014018 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 19:20:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h263KlqB014005 for ; Wed, 5 Mar 2003 19:20:47 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h262WQTA013092; Wed, 5 Mar 2003 18:32:26 -0800 Date: Wed, 5 Mar 2003 18:32:26 -0800 Message-Id: <200303060232.h262WQTA013092@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 228] New: xfs_repair can't deal with small (agcount==1) filesystems X-Bugzilla-Reason: AssignedTo X-archive-position: 3064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 27 http://oss.sgi.com/bugzilla/show_bug.cgi?id=228 Summary: xfs_repair can't deal with small (agcount==1) filesystems Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: cw@f00f.org xfs_repair barfs if you try to repair a fs with only on ag (no spare sb's): charon:~# xfs_repair /dev/hda1 Phase 1 - find and verify superblock... Only one AG detected - cannot proceed. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 5 20:42:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 20:42:18 -0800 (PST) Received: from web10402.mail.yahoo.com (web10402.mail.yahoo.com [216.136.130.94]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h264g9q9014841 for ; Wed, 5 Mar 2003 20:42:10 -0800 Message-ID: <20030306044209.13733.qmail@web10402.mail.yahoo.com> Received: from [66.25.61.37] by web10402.mail.yahoo.com via HTTP; Wed, 05 Mar 2003 20:42:09 PST Date: Wed, 5 Mar 2003 20:42:09 -0800 (PST) From: John Subject: cvs 2.4 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3065 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsh_45@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 340 Lines: 14 Hay I've been trying to check out the 2.4xfs tree and it keeps hanging up at linux/scrips/usb. the last line printed is cvs is updating said file. It did this yesterday and again tonight. John __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Mar 5 21:13:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 21:13:32 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h265DPq9016018 for ; Wed, 5 Mar 2003 21:13:30 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 222D41833FEA; Wed, 5 Mar 2003 21:13:25 -0800 (PST) Date: Wed, 5 Mar 2003 21:13:25 -0800 From: Chris Wedgwood To: John Cc: linux-xfs@oss.sgi.com Subject: Re: cvs 2.4 Message-ID: <20030306051325.GB2317@f00f.org> References: <20030306044209.13733.qmail@web10402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030306044209.13733.qmail@web10402.mail.yahoo.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3067 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 274 Lines: 11 On Wed, Mar 05, 2003 at 08:42:09PM -0800, John wrote: > I've been trying to check out the 2.4xfs tree and it keeps hanging > up at linux/scrips/usb. the last line printed is cvs is updating > said file. It did this yesterday and again tonight. get a newer cvs --cw From owner-linux-xfs@oss.sgi.com Wed Mar 5 21:13:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 21:13:17 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h265DAq9015947 for ; Wed, 5 Mar 2003 21:13:11 -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 h265D3nH031924 for ; Wed, 5 Mar 2003 21:13:04 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13181; Thu, 6 Mar 2003 16:11:47 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 26A873000B8; Thu, 6 Mar 2003 16:11:45 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 898458F; Thu, 6 Mar 2003 16:11:45 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: John Cc: linux-xfs@oss.sgi.com Subject: Re: cvs 2.4 In-reply-to: Your message of "Wed, 05 Mar 2003 20:42:09 -0800." <20030306044209.13733.qmail@web10402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Mar 2003 16:11:39 +1100 Message-ID: <15726.1046927499@kao2.melbourne.sgi.com> X-archive-position: 3066 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 548 Lines: 14 On Wed, 5 Mar 2003 20:42:09 -0800 (PST), John wrote: >I've been trying to check out the 2.4xfs tree and it >keeps hanging up at linux/scrips/usb. the last line >printed is cvs is updating said file. It did this >yesterday and again tonight. This is getting to be a FAQ. cvs on oss.sgi.com has been upgraded to fix a security problem that affected all CVS servers. Users need to upgrade their CVS clients to access any of the fixed severs. For RH users, http://www.redhat.com/mailing-lists/redhat-watch-list/msg00950.html From owner-linux-xfs@oss.sgi.com Wed Mar 5 21:23:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 21:23:55 -0800 (PST) Received: from web10412.mail.yahoo.com (web10412.mail.yahoo.com [216.136.128.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h265NDq9016852 for ; Wed, 5 Mar 2003 21:23:53 -0800 Message-ID: <20030306052312.33727.qmail@web10412.mail.yahoo.com> Received: from [66.25.61.37] by web10412.mail.yahoo.com via HTTP; Wed, 05 Mar 2003 21:23:12 PST Date: Wed, 5 Mar 2003 21:23:12 -0800 (PST) From: John Subject: Re: cvs 2.4 To: Keith Owens Cc: linux-xfs@oss.sgi.com In-Reply-To: <15726.1046927499@kao2.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsh_45@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 646 Lines: 28 > This is getting to be a FAQ. That's a good idea, or maybe someone at SGI should add this note on cvs clients on their cvs instructions webpage? > > cvs on oss.sgi.com has been upgraded to fix a > security problem that > affected all CVS servers. Users need to upgrade > their CVS clients to > access any of the fixed severs. For RH users, > http://www.redhat.com/mailing-lists/redhat-watch-list/msg00950.html sorry I'm a lazy ass debian user running woody, but I know what to do now Thanks __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Mar 5 23:13:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 23:14:06 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h267Dvq9017925 for ; Wed, 5 Mar 2003 23:13:58 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h267DpnH005443 for ; Wed, 5 Mar 2003 23:13:51 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h267CU7L1013144 for ; Thu, 6 Mar 2003 18:12:30 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h267CTrL1014062 for linux-xfs@oss.sgi.com; Thu, 6 Mar 2003 18:12:29 +1100 (EST) Date: Thu, 6 Mar 2003 18:12:29 +1100 (EST) From: Nathan Scott Message-Id: <200303060712.h267CTrL1014062@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 3069 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3917 Lines: 120 Fix up print format compiler warnings. Date: Wed Mar 5 20:28:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141056a linux/fs/xfs/xfs_da_btree.c - 1.140 linux/fs/xfs/xfs_dir2_node.c - 1.33 New xfsprogs version - enabled unwritten extents by default, new commands in xfs_db and xfs_admin to manipulate the version extflg bit on unmounted filesystems, make xfs_db check for a dirty log before zeroing it in the uuid command, man page updates, sync'd up user/kernel code and headers. Add stripe information into xfs_bmap output. Date: Wed Mar 5 22:59:34 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141069a cmd/xfsprogs/db/bmap.c - 1.8 cmd/xfsprogs/db/data.c - 1.5 cmd/xfsprogs/db/data.h - 1.5 cmd/xfsprogs/db/dquot.c - 1.7 cmd/xfsprogs/db/write.c - 1.7 cmd/xfsprogs/db/dir2.c - 1.5 cmd/xfsprogs/db/attr.c - 1.5 cmd/xfsprogs/db/sb.c - 1.8 cmd/xfsprogs/db/dir.c - 1.5 cmd/xfsprogs/db/sb.h - 1.5 cmd/xfsprogs/db/cntbt.c - 1.5 cmd/xfsprogs/db/bnobt.c - 1.5 cmd/xfsprogs/db/dbread.c - 1.5 cmd/xfsprogs/db/mount.h - 1.5 cmd/xfsprogs/db/mount.c - 1.6 cmd/xfsprogs/db/bmapbt.c - 1.5 cmd/xfsprogs/db/bmroot.c - 1.5 cmd/xfsprogs/db/inobt.c - 1.5 cmd/xfsprogs/db/inode.c - 1.6 cmd/xfsprogs/db/faddr.c - 1.6 cmd/xfsprogs/db/init.h - 1.6 cmd/xfsprogs/db/init.c - 1.8 cmd/xfsprogs/db/uuid.h - 1.5 cmd/xfsprogs/db/uuid.c - 1.8 cmd/xfsprogs/db/agf.c - 1.6 cmd/xfsprogs/db/frag.c - 1.9 cmd/xfsprogs/db/freesp.c - 1.9 cmd/xfsprogs/db/agi.c - 1.6 cmd/xfsprogs/db/command.c - 1.6 cmd/xfsprogs/db/convert.c - 1.6 cmd/xfsprogs/db/agfl.c - 1.6 cmd/xfsprogs/db/check.c - 1.12 cmd/xfsprogs/db/block.c - 1.5 cmd/xfsprogs/db/main.c - 1.6 cmd/xfsprogs/db/io.c - 1.9 cmd/xfsprogs/db/text.c - 1.5 - Rationalise headers in xfs_db, fix up early initialisation so we can use libxlog to check for a dirty log, add version command. cmd/xfsprogs/man/man8/xfs_db.8 - 1.6 - Add new version command for setting feature bits in superblocks. cmd/xfsprogs/db/xfs_admin.sh - 1.8 cmd/xfsprogs/man/man8/xfs_admin.8 - 1.2 - Add -e option which sets unwritten extent bit. cmd/xfsprogs/VERSION - 1.67 cmd/xfsprogs/doc/CHANGES - 1.92 cmd/xfsprogs/debian/changelog - 1.60 - New xfsprogs version - enabled unwritten extents by default, new commands in xfs_db and xfs_admin to manipulate the version extflg bit on unmounted filesystems, make xfs_db check for a dirty log before zeroing it in the uuid command, man page updates, sync'd up user/kernel code and headers. Add stripe information into xfs_bmap output. cmd/xfsprogs/bmap/xfs_bmap.c - 1.13 - Add stripe information into xfs_bmap output. cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.40 - Enable unwritten extents by default. cmd/xfsprogs/include/libxfs.h - 1.22 cmd/xfsprogs/libxfs/init.c - 1.25 - Add flags for libxfs_mount so that xfs_db can use it too. cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.19 cmd/xfsprogs/include/xfs_log.h - 1.13 cmd/xfsprogs/include/xfs_log_priv.h - 1.12 cmd/xfsprogs/include/libxlog.h - 1.5 cmd/xfsprogs/include/xfs_bmap_btree.h - 1.9 cmd/xfsprogs/include/xfs_btree.h - 1.7 cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.17 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.20 cmd/xfsprogs/libxfs/xfs.h - 1.29 cmd/xfsprogs/libxfs/xfs_dir2_block.c - 1.10 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.14 cmd/xfsprogs/libxfs/xfs_dir_leaf.c - 1.13 cmd/xfsprogs/libxfs/xfs_btree.c - 1.12 cmd/xfsprogs/libxfs/xfs_inode.c - 1.16 cmd/xfsprogs/libxfs/xfs_attr_leaf.c - 1.8 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.18 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.18 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.13 - Sync with recent kernel changes. cmd/xfsprogs/po/xfsprogs.pot - 1.3 - Update after additional output for xfs_bmap. From owner-linux-xfs@oss.sgi.com Thu Mar 6 00:20:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 00:20:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h268Koq9018899 for ; Thu, 6 Mar 2003 00:20:50 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h268KoZx018897 for linux-xfs@oss.sgi.com; Thu, 6 Mar 2003 00:20:50 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h268Kmq9018884 for ; Thu, 6 Mar 2003 00:20:48 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h267lRPI018565; Wed, 5 Mar 2003 23:47:27 -0800 Date: Wed, 5 Mar 2003 23:47:27 -0800 Message-Id: <200303060747.h267lRPI018565@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 227] unmount fail X-Bugzilla-Reason: AssignedTo X-archive-position: 3070 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 582 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=227 ------- Additional Comments From olaf@cbk.poznan.pl 2003-03-05 23:47 ------- Hi, Have this one too... I use CVS from January 10. But I had it earlier, too. As I have several XFS partitions I have to check if it is all the time one of them or it is by chance. I have putted some echos in "halt" script to get it, but from this time it occured only once, so I have to wait to have reproducible results. Olaf ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 6 00:53:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 00:53:16 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h268qQq9019562 for ; Thu, 6 Mar 2003 00:53:07 -0800 Received: (qmail 27959 invoked from network); 6 Mar 2003 08:52:22 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 6 Mar 2003 08:52:22 +0000 Subject: Re: cvs 2.4 From: Tony Gale To: Keith Owens Cc: John , linux-xfs@oss.sgi.com In-Reply-To: <15726.1046927499@dstl.gov.uk> References: <15726.1046927499@dstl.gov.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-H2CIaA7X8Gwwdq0/VEln" Organization: Message-Id: <1046940743.4262.3.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 08:52:23 +0000 X-archive-position: 3071 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 1285 Lines: 40 --=-H2CIaA7X8Gwwdq0/VEln Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-03-06 at 05:11, Keith Owens wrote: > On Wed, 5 Mar 2003 20:42:09 -0800 (PST),=20 > John wrote: > >I've been trying to check out the 2.4xfs tree and it > >keeps hanging up at linux/scrips/usb. the last line > >printed is cvs is updating said file. It did this > >yesterday and again tonight. >=20 > This is getting to be a FAQ. >=20 > cvs on oss.sgi.com has been upgraded to fix a security problem that > affected all CVS servers. Users need to upgrade their CVS clients to > access any of the fixed severs. For RH users, > http://www.redhat.com/mailing-lists/redhat-watch-list/msg00950.html Note though, that the RH updated RPM doesn't fix the hanging problem. -tony --=-H2CIaA7X8Gwwdq0/VEln Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPmcMRx/0GZs/Z0FlAQLdNAP+NSgx/ZzSefH5w15abylITnPIz8j3uIDL a77gqZ8PEZo3tJl2nIjTKOTuc4cZS3Oxwhvqqm9MKBuCfJgniJCmfjKDvPy+tBjQ CnO+JAMfd4AYElqKXdqO99Svd3gzGKZyQTShlOzj9jun+2/2wVi0CWYnfZdItC7u 4efRYusQiiI= =YfTK -----END PGP SIGNATURE----- --=-H2CIaA7X8Gwwdq0/VEln-- From owner-linux-xfs@oss.sgi.com Thu Mar 6 03:04:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 03:04:33 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26B4Pq9025009 for ; Thu, 6 Mar 2003 03:04:26 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26B4J9n019216 for ; Thu, 6 Mar 2003 03:04:19 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h26B3IK08337; Thu, 6 Mar 2003 22:03:18 +1100 Date: Thu, 6 Mar 2003 22:03:18 +1100 From: Keith Owens Message-Id: <200303061103.h26B3IK08337@sherman.melbourne.sgi.com> Subject: TAKE - kdb memmap command is i386 only X-archive-position: 3072 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 394 Lines: 14 The kdb memmap command is specific to i386 and kills kdb on ia64. Patches to extend memmap to other architectures will be gratefull accepted. Date: Thu Mar 6 03:01:45 PST 2003 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:141086a linux/kdb/modules/kdbm_pg.c - 1.63 From owner-linux-xfs@oss.sgi.com Thu Mar 6 04:20:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 04:21:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h26CKqq9026782 for ; Thu, 6 Mar 2003 04:20:52 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h26CKqdd026780 for linux-xfs@oss.sgi.com; Thu, 6 Mar 2003 04:20:52 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h26CKnq9026766 for ; Thu, 6 Mar 2003 04:20:49 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h26BkFv2025816; Thu, 6 Mar 2003 03:46:15 -0800 Date: Thu, 6 Mar 2003 03:46:15 -0800 Message-Id: <200303061146.h26BkFv2025816@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 227] unmount fail X-Bugzilla-Reason: AssignedTo X-archive-position: 3073 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 410 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=227 ------- Additional Comments From grandsonata@netscape.net 2003-03-06 03:46 ------- Hi Olaf let me know if you capture some results as to what cause umounting fail. machine just hung there when umounting. ctr+alt+del does not work. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 6 06:20:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 06:20:45 -0800 (PST) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26EKdq9007108 for ; Thu, 6 Mar 2003 06:20:40 -0800 Received: (qmail 12876 invoked by alias); 6 Mar 2003 14:20:37 -0000 Received: from unknown (HELO avalanche) (195.228.226.66) by 0 with SMTP; 6 Mar 2003 14:20:37 -0000 Message-ID: <007001c2e3eb$9ff13500$0104a8c0@avalanche> Reply-To: "Gabor Forgacs" From: "Gabor Forgacs" To: "xfs mailing list" Subject: direct io performance problem Date: Thu, 6 Mar 2003 15:21:04 +0100 Organization: Colorfront MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 3074 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Content-Length: 1428 Lines: 47 Hi all we are testing the disk speed on linux, here how it is going: Test System kernel: 2.4.20 and 2.4.18 hardware: IBM Z-PRO , qlogic 2342 driver 6.4, 7-7 disks md parameters: chunck_size 32 XFS: i used the latest cvs version of the xfs (2.0) file sequence test were done with 12mb files whitout any previuos cached buffer all the files were read with one request (that is what we need) - xfs filesystem with direct-io with one thread reading can scale up to 220-230 Mb/sec with relativly low cpu load - xfs filesystem with direct-io with more than one thread is only capable ~100 mb/sec here probably there is some locking issue in the filesystem - xfs without direct-io can produce ~260-280 mb/sec with pretty high cpu load ,here the cpu load is probably related to the caching - ext3 is about the same like xfs without direct-io So right now, we can do fast diskio but unable to do anything else because it ruins the disk performance. What is your experience did you manage to get higher disk speed values on linux ? Any idea what else could we try? the same system under windos 2000 can do a sustain 300/310 mb/sec i suspect there is some bottleneck in the direct io implementation on linux. if the cached version can do 260-280 mb/sec with the extra memcpy then the driver should be fast enough to do the task. is there any recommendation to get the same io rate like on windows ? Thank You gabor forgacs From owner-linux-xfs@oss.sgi.com Thu Mar 6 06:41:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 06:41:51 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Ef7q9009239 for ; Thu, 6 Mar 2003 06:41:48 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18qwYT-0002f2-00; Thu, 06 Mar 2003 14:41:05 +0000 Date: Thu, 6 Mar 2003 14:41:05 +0000 From: Christoph Hellwig To: Gabor Forgacs Cc: xfs mailing list Subject: Re: direct io performance problem Message-ID: <20030306144105.A10089@infradead.org> References: <007001c2e3eb$9ff13500$0104a8c0@avalanche> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <007001c2e3eb$9ff13500$0104a8c0@avalanche>; from gabor@colorfront.com on Thu, Mar 06, 2003 at 03:21:04PM +0100 X-archive-position: 3075 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 295 Lines: 9 On Thu, Mar 06, 2003 at 03:21:04PM +0100, Gabor Forgacs wrote: > Hi all > > we are testing the disk speed on linux, here how it is going: I'd suggest using vendors kernel (i.e. the XFS patches redhat RPMs or SuSE's tree, they have certain important I/O fixes that mainline is still missing). From owner-linux-xfs@oss.sgi.com Thu Mar 6 07:29:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 07:29:07 -0800 (PST) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26FT2q9014922 for ; Thu, 6 Mar 2003 07:29:03 -0800 Received: (qmail 12498 invoked by alias); 6 Mar 2003 15:29:00 -0000 Received: from unknown (HELO avalanche) (195.228.226.66) by 0 with SMTP; 6 Mar 2003 15:29:00 -0000 Message-ID: <00ab01c2e3f5$2d5cbbe0$0104a8c0@avalanche> Reply-To: "Gabor Forgacs" From: "Gabor Forgacs" To: "Christoph Hellwig" Cc: "xfs mailing list" References: <007001c2e3eb$9ff13500$0104a8c0@avalanche> <20030306144105.A10089@infradead.org> Subject: Re: direct io performance problem Date: Thu, 6 Mar 2003 16:29:27 +0100 Organization: Colorfront MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 3076 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Content-Length: 656 Lines: 24 hi christoph which rpms do you advice could you point me there (we use rpm)? thank you ----- Original Message ----- From: "Christoph Hellwig" To: "Gabor Forgacs" Cc: "xfs mailing list" Sent: Thursday, March 06, 2003 3:41 PM Subject: Re: direct io performance problem > On Thu, Mar 06, 2003 at 03:21:04PM +0100, Gabor Forgacs wrote: > > Hi all > > > > we are testing the disk speed on linux, here how it is going: > > I'd suggest using vendors kernel (i.e. the XFS patches redhat RPMs > or SuSE's tree, they have certain important I/O fixes that mainline > is still missing). > > From owner-linux-xfs@oss.sgi.com Thu Mar 6 07:32:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 07:32:38 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26FWXq9015238 for ; Thu, 6 Mar 2003 07:32:34 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18qxMH-0002yr-00; Thu, 06 Mar 2003 15:32:33 +0000 Date: Thu, 6 Mar 2003 15:32:32 +0000 From: Christoph Hellwig To: Gabor Forgacs Cc: xfs mailing list Subject: Re: direct io performance problem Message-ID: <20030306153232.A11335@infradead.org> References: <007001c2e3eb$9ff13500$0104a8c0@avalanche> <20030306144105.A10089@infradead.org> <00ab01c2e3f5$2d5cbbe0$0104a8c0@avalanche> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00ab01c2e3f5$2d5cbbe0$0104a8c0@avalanche>; from gabor@colorfront.com on Thu, Mar 06, 2003 at 04:29:27PM +0100 X-archive-position: 3077 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 588 Lines: 18 On Thu, Mar 06, 2003 at 04:29:27PM +0100, Gabor Forgacs wrote: > hi christoph > > which rpms do you advice could you point me there (we use rpm)? > thank you RedHat-based: ftp://oss.sgi.com/projects/xfs/Release-1.2/kernel_rpms/2.4.18-18-RH/ SuSE: ftp://ftp.suse.com/pub/people/mantel/next/RPM/ Note that the RedHAT RPMs are not based on their latest errata, there are people who have patches their latest errata kernels with XFS, but Redat disabled O_DIRECT in never kernels, so you'll have to decide whether you want their latests fix, working O_DIRECT or hack the kernel yourself. From owner-linux-xfs@oss.sgi.com Thu Mar 6 07:56:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 07:56:35 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26FuVq9017596 for ; Thu, 6 Mar 2003 07:56:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26FuQnH009988 for ; Thu, 6 Mar 2003 07:56:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA82698 for ; Thu, 6 Mar 2003 09:56:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA45975 for ; Thu, 6 Mar 2003 09:56:26 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h26FuPr26163; Thu, 6 Mar 2003 09:56:25 -0600 Message-Id: <200303061556.h26FuPr26163@jen.americas.sgi.com> Date: Thu, 6 Mar 2003 09:56:25 -0600 Subject: TAKE - tweak io completion thread count again X-archive-position: 3078 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 477 Lines: 17 move back to a thread per cpu for I/O completion, we had second thoughts about this. Experiments in progress to use a new model here, but in the mean time, stick to one thread per cpu. Date: Thu Mar 6 07:56:00 PST 2003 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:141108a linux/fs/xfs/pagebuf/page_buf.c - 1.103 - define MAX_IO_DAEMONS as NR_CPUS From owner-linux-xfs@oss.sgi.com Thu Mar 6 11:39:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 11:39:20 -0800 (PST) Received: from hotmail.com (f65.sea2.hotmail.com [207.68.165.65]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26JcZq9006231 for ; Thu, 6 Mar 2003 11:39:13 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 11:38:30 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 06 Mar 2003 19:38:29 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: files written in multiple fragments Date: Thu, 06 Mar 2003 11:38:29 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Mar 2003 19:38:30.0231 (UTC) FILETIME=[F7303E70:01C2E417] X-archive-position: 3079 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2514 Lines: 57 Steve, I have encountered another oddity while writing successive files to my high speed XFS partition under linux. The problem that I am seeing is that files are intermittently written in several 1024 block fragments. This filesystem has been performing well for the past two weeks with many directories created, many files written, and many directories deleted. While this would normally not be a problem, it is a big performance hit when it comes time to read the file. Do you have any suggestions on how I might prevent this behavior? I have included the xfs_info and xfs_bmap output below. Thanks. Rick meta-data=/test isize=256 agcount=172, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=179566240, imaxpct=25 = sunit=1 swidth=10 blks, unwritten=0 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=40960 blocks=0, rtextents=0 test.36.data: 0: [0..10799]: 1368218048..1368228847 test.37.data: 0: [0..1023]: 1367828040..1367829063 1: [1024..2047]: 1367827016..1367828039 2: [2048..3071]: 1367825992..1367827015 3: [3072..4095]: 1367824968..1367825991 4: [4096..5119]: 1367823944..1367824967 5: [5120..6143]: 1367822920..1367823943 6: [6144..7167]: 1367821896..1367822919 7: [7168..8191]: 1367820872..1367821895 8: [8192..9215]: 1367819848..1367820871 9: [9216..10239]: 1367818824..1367819847 10: [10240..10799]: 1367818256..1367818815 test.38.data: 0: [0..10799]: 1368228848..1368239647 test.39.data: 0: [0..1023]: 1367817232..1367818255 1: [1024..2047]: 1367816208..1367817231 2: [2048..3071]: 1367815184..1367816207 3: [3072..4095]: 1367814160..1367815183 4: [4096..5119]: 1367813136..1367814159 5: [5120..6143]: 1367812112..1367813135 6: [6144..7167]: 1367811088..1367812111 7: [7168..8191]: 1367810064..1367811087 8: [8192..9215]: 1367809040..1367810063 9: [9216..10239]: 1367808016..1367809039 10: [10240..10799]: 1367807448..1367808007 _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Thu Mar 6 13:38:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 13:38:44 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Lbuq9013872 for ; Thu, 6 Mar 2003 13:38:37 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 14:38:21 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 14:37:50 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS29Q1M; Thu, 6 Mar 2003 14:37:43 -0700 From: "Buzbee, James" To: linux-xfs@oss.sgi.com Message-ID: <3E67BFA7.4080601@echostar.com> Date: Thu, 06 Mar 2003 14:37:43 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: LBA to File? X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3080 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 479 Lines: 13 We've been running an IDE analyzer on our system in order to better understand the pattern of disk usage for our application. We're seeing what appears to be a high number of writes to a particular area of the drive, and we're having trouble determining what is being accessed. The analyzer gives us output in terms of LBA accesses. Is there an easy way to translate an LBA address into a particular file or perhaps an internal XFS data structure? Thanks, Jim Buzbee From owner-linux-xfs@oss.sgi.com Thu Mar 6 13:48:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 13:48:59 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Lmoq9014503 for ; Thu, 6 Mar 2003 13:48:51 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D2139149FB; Thu, 6 Mar 2003 22:48:44 +0100 (MET) Subject: Re: LBA to File? From: Andi Kleen To: "Buzbee, James" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E67BFA7.4080601@echostar.com> References: <3E67BFA7.4080601@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 06 Mar 2003 22:48:43 +0100 Message-Id: <1046987324.1511.193.camel@averell> Mime-Version: 1.0 X-archive-position: 3081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 621 Lines: 16 On Thu, 2003-03-06 at 22:37, Buzbee, James wrote: > We've been running an IDE analyzer on our system in order to better > understand the pattern of disk usage for our application. We're seeing > what appears to be a high number of writes to a particular area of the > drive, and we're having trouble determining what is being accessed. The > analyzer gives us output in terms of LBA accesses. Is there an easy way > to translate an LBA address into a particular file or perhaps an > internal XFS data structure? I bet it is the XFS log. You can test by moving it to another partition or another disk. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 6 13:56:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 13:56:11 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26LtTq9015217 for ; Thu, 6 Mar 2003 13:56:09 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h26LtRk15656; Thu, 6 Mar 2003 16:55:27 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 6 Mar 2003 16:55:27 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: "Buzbee, James" cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? In-Reply-To: <3E67BFA7.4080601@echostar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3082 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 685 Lines: 18 On Thu, 6 Mar 2003 at 2:37pm, Buzbee, James wrote > We've been running an IDE analyzer on our system in order to better > understand the pattern of disk usage for our application. We're seeing > what appears to be a high number of writes to a particular area of the > drive, and we're having trouble determining what is being accessed. The > analyzer gives us output in terms of LBA accesses. Is there an easy way > to translate an LBA address into a particular file or perhaps an > internal XFS data structure? I don't know, but I'd hazard a guess that what you're seeing are journal writes... -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:05:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:05:18 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26M59q9016125 for ; Thu, 6 Mar 2003 14:05:10 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 15:05:31 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 15:04:59 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS29TBT; Thu, 6 Mar 2003 15:04:52 -0700 From: "Buzbee, James" To: Andi Kleen Cc: linux-xfs@oss.sgi.com Message-ID: <3E67C603.8040107@echostar.com> Date: Thu, 06 Mar 2003 15:04:51 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <1046987324.1511.193.camel@averell> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3083 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 879 Lines: 34 Andi Kleen wrote: > On Thu, 2003-03-06 at 22:37, Buzbee, James wrote: > >>We've been running an IDE analyzer on our system in order to better >>understand the pattern of disk usage for our application. We're seeing >>what appears to be a high number of writes to a particular area of the >>drive, and we're having trouble determining what is being accessed. The >>analyzer gives us output in terms of LBA accesses. Is there an easy way >>to translate an LBA address into a particular file or perhaps an >>internal XFS data structure? > > > I bet it is the XFS log. We actually see the writes occuring in two distinct areas on the drive. Would journal accesses show up this way? > > You can test by moving it to another partition or another disk. > We are in a single disk system using an internal log. Is there any way to move it ? Jim > -Andi > > From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:13:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:14:00 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26MDuq9017044 for ; Thu, 6 Mar 2003 14:13:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26MDonH020714 for ; Thu, 6 Mar 2003 14:13:51 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA44935; Thu, 6 Mar 2003 16:13:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h26MDoCI4856722; Thu, 6 Mar 2003 16:13:50 -0600 (CST) Subject: Re: LBA to File? From: Eric Sandeen To: "Buzbee, James" Cc: Andi Kleen , linux-xfs@oss.sgi.com In-Reply-To: <3E67C603.8040107@echostar.com> References: <3E67BFA7.4080601@echostar.com> <1046987324.1511.193.camel@averell> <3E67C603.8040107@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 16:13:29 -0600 Message-Id: <1046988809.438.267.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3084 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 741 Lines: 24 On Thu, 2003-03-06 at 16:04, Buzbee, James wrote: > > We actually see the writes occuring in two distinct areas on the drive. > Would journal accesses show up this way? The superblock could also be getting written a lot. > We are in a single disk system using an internal log. Is there any way > to move it ? While you can move an internal log with some xfs_db wizardry, it would probably be easiest to just re-make your fs with an external log on another partition. (oh, and there is also an undocumented mkfs option to put an internal log in a different AG... have to check the xfs_mkfs.c source). -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:16:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:16:35 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26MGVq9017698 for ; Thu, 6 Mar 2003 14:16:31 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 700B81830E0C; Thu, 6 Mar 2003 14:16:31 -0800 (PST) Date: Thu, 6 Mar 2003 14:16:31 -0800 From: Chris Wedgwood To: "Buzbee, James" Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030306221631.GA6770@f00f.org> References: <3E67BFA7.4080601@echostar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E67BFA7.4080601@echostar.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3085 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 708 Lines: 23 On Thu, Mar 06, 2003 at 02:37:43PM -0700, Buzbee, James wrote: > We've been running an IDE analyzer on our system in order to better > understand the pattern of disk usage for our application. We're > seeing what appears to be a high number of writes to a particular > area of the drive, and we're having trouble determining what is > being accessed. Is this near the middle of the fs? --- if so, it's likely an internal log. > The analyzer gives us output in terms of LBA accesses. Is there an > easy way to translate an LBA address into a particular file or > perhaps an internal XFS data structure? LBA -> block should be possible Finding the file for that would be expensive but doable. --cw From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:26:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:26:36 -0800 (PST) Received: from mailout2.echostar.com (mailout2.echostar.com [204.76.128.102]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26MQSq9019001 for ; Thu, 6 Mar 2003 14:26:30 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.102 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 15:25:44 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 15:26:22 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS29V08; Thu, 6 Mar 2003 15:26:18 -0700 From: "Buzbee, James" To: linux-xfs@oss.sgi.com Message-ID: <3E67CB02.2030600@echostar.com> Date: Thu, 06 Mar 2003 15:26:10 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3086 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 569 Lines: 20 Chris Wedgwood wrote: > On Thu, Mar 06, 2003 at 02:37:43PM -0700, Buzbee, James wrote: > > >>We've been running an IDE analyzer on our system in order to better >>understand the pattern of disk usage for our application. We're >>seeing what appears to be a high number of writes to a particular >>area of the drive, and we're having trouble determining what is >>being accessed. > > > Is this near the middle of the fs? --- if so, it's likely an internal > log. We're seeing two areas. One near the start of the partition, the other in the middle. Jim From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:51:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:51:52 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Mp7q9020375 for ; Thu, 6 Mar 2003 14:51:47 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 15:51:32 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 15:51:00 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS2953N; Thu, 6 Mar 2003 15:50:55 -0700 From: "Buzbee, James" To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-ID: <3E67D0CE.3080902@echostar.com> Date: Thu, 06 Mar 2003 15:50:54 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3087 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 487 Lines: 25 Eric Sandeen wrote: > On Thu, 2003-03-06 at 16:26, Buzbee, James wrote: > > >>We're seeing two areas. One near the start of the partition, the other > > > Superblock... > > >>in the middle. > > > ... and log. > > -Eric > The scary thing about what we are seeing is that the "grown defect list" on the disk is showing a lot of sectors in these two areas. It's almost as if we are wearing out the sectors in these areas by writing them so often. Strange but true ;-( Jim From owner-linux-xfs@oss.sgi.com Thu Mar 6 15:15:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 15:15:46 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26NFcq9021846 for ; Thu, 6 Mar 2003 15:15:39 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 79B95149C2; Fri, 7 Mar 2003 00:14:54 +0100 (MET) Subject: Re: LBA to File? From: Andi Kleen To: "Buzbee, James" Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3E67D0CE.3080902@echostar.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Mar 2003 00:14:53 +0100 Message-Id: <1046992493.1388.235.camel@averell> Mime-Version: 1.0 X-archive-position: 3088 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 974 Lines: 27 On Thu, 2003-03-06 at 23:50, Buzbee, James wrote: > The scary thing about what we are seeing is that the "grown defect list" > on the disk is showing a lot of sectors in these two areas. It's almost > as if we are wearing out the sectors in these areas by writing them so > often. Strange but true ;-( It was long suspected that journaling FS are bad for cheap IDE disks, but you're probably the first to really verify it using an IDE analyzer. There were also some informal experiences on that collected by the reiserfs people. Thanks for verify this. For that it would be actually nice to have some way to relocate the journal offline or better online. Then you could just move the journal around a bit once a week and avoid these problems. However you would need enough free space as the journal can only move into free space. I guess offline (umounted fs) would be already possible with XFS with some tweaks. Just don't fill the disk over 90% or so. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 6 15:34:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 15:34:25 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26NYIq9023111 for ; Thu, 6 Mar 2003 15:34:19 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26Nimkq011077 for ; Thu, 6 Mar 2003 17:44:48 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA72428; Thu, 6 Mar 2003 17:34:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h26NYBCI4856448; Thu, 6 Mar 2003 17:34:11 -0600 (CST) Subject: Re: LBA to File? From: Eric Sandeen To: Andi Kleen Cc: "Buzbee, James" , linux-xfs@oss.sgi.com In-Reply-To: <1046992493.1388.235.camel@averell> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046992493.1388.235.camel@averell> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 17:33:50 -0600 Message-Id: <1046993631.440.280.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3089 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 864 Lines: 22 > For that it would be actually nice to have some way to relocate the > journal offline or better online. Then you could just move the journal > around a bit once a week and avoid these problems. That's on the XFS todo list (even documented as "unimplemented" in the xfs_growfs man page...) I looked at it a bit, shouldn't be too hard, but need some time to do it. Moving it offline is pretty easy, could do it with an xfs_db script wrapper, I think. Hm, I suppose that for the truly paranoid, with cheap IDE disks, there could be an option to rotate an internal log through the AGs each time you mount. Of course that would be a lot of space sitting idle most of the time, but it's probably better than trashing the disk... :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 6 16:33:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 16:34:01 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h270Xrq9025086 for ; Thu, 6 Mar 2003 16:33:54 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 17:34:15 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 17:33:44 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS20D99; Thu, 6 Mar 2003 17:33:35 -0700 From: "Buzbee, James" To: Eric Sandeen Cc: Andi Kleen , linux-xfs@oss.sgi.com Message-ID: <3E67E8DF.30700@echostar.com> Date: Thu, 06 Mar 2003 17:33:35 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046992493.1388.235.camel@averell> <1046993631.440.280.camel@stout.americas.sgi.com> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3090 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 368 Lines: 16 Eric Sandeen wrote: ... > Hm, I suppose that for the truly paranoid, with cheap IDE disks, there > could be an option to rotate an internal log through the AGs each > time you mount. Of course that would be a lot of space sitting idle > most of the time, but it's probably better than trashing the disk... :) Yep, it would help our situation :-) > > -Eric > From owner-linux-xfs@oss.sgi.com Thu Mar 6 16:39:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 16:39:13 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h270cTq9026102 for ; Thu, 6 Mar 2003 16:39:09 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h270cNnH030318 for ; Thu, 6 Mar 2003 16:38:23 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA99537; Thu, 6 Mar 2003 18:38:22 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-25.corp.sgi.com [134.15.64.25]) by tulip-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h270cL6511182576; Thu, 6 Mar 2003 18:38:22 -0600 (CST) Subject: Re: LBA to File? From: Stephen Lord To: "Buzbee, James" Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3E67D0CE.3080902@echostar.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 18:36:51 -0600 Message-Id: <1046997413.1373.14.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1319 Lines: 31 On Thu, 2003-03-06 at 16:50, Buzbee, James wrote: > > The scary thing about what we are seeing is that the "grown defect list" > on the disk is showing a lot of sectors in these two areas. It's almost > as if we are wearing out the sectors in these areas by writing them so > often. Strange but true ;-( > > Jim > Ugh, yes these will be continually written to, the log in particular, I like Eric's idea, but the scope of that is fairly drastic and it will only postpone the inevitable - you can probably do the math to work out how long the drive will run before it runs out of bad blocks to remap to. All running with alternating logs would do is delay the drive becoming scrap metal. The reliability of these devices may not be up to the load you are placing on them. Not all ide drives are this bad, I have been running xfs on the same ide drive for about 3 years now - but then I am not running a PVR. I suspect also you may have the write cache turned off to avoid errors after a crash. Possibly the way your app runs is making things worse. There is a script in the cmd/misc directory called xfsstats.pl you can watch log activity with this. In particular xs_log_writes and xs_log_blocks. If log_blocks is not a reasonable multiple of log_writes then you are doing a lot of very small writes. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 6 16:48:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 16:48:14 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h270mBq9027338 for ; Thu, 6 Mar 2003 16:48:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26Md9nH022479 for ; Thu, 6 Mar 2003 14:39:09 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA59214; Thu, 6 Mar 2003 16:39:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h26Md8CI4794361; Thu, 6 Mar 2003 16:39:08 -0600 (CST) Subject: Re: LBA to File? From: Eric Sandeen To: "Buzbee, James" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E67CB02.2030600@echostar.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 16:38:48 -0600 Message-Id: <1046990328.439.273.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3092 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 302 Lines: 16 On Thu, 2003-03-06 at 16:26, Buzbee, James wrote: > We're seeing two areas. One near the start of the partition, the other Superblock... > in the middle. ... and log. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 6 17:42:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 17:42:41 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h271gXq9003079 for ; Thu, 6 Mar 2003 17:42:34 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h271gSbw015765 for ; Thu, 6 Mar 2003 17:42:28 -0800 From: "l.a walsh" To: Subject: Just some odd questions out of the blue... Date: Thu, 6 Mar 2003 17:42:28 -0800 Message-ID: <00a501c2e44a$cfaba280$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 3093 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2158 Lines: 52 I was reading a bit through the messages about high activity in the log file area of the disk. Seems like ...well...that's likely going to up the #seeks needed for writes, right? So lets say you had 2 disks...would it make sense to put the log of disk1 on disk2 and the log of disk2 on disk1? This would be under the assumption, that most often, you will be writing to 1 of the two disks (RAID stuff excluded from this meandering). Seems like if 90% of the time you are going to be writing to only 1 disk at a time, it could really eliminate excessive seekage and theoretically up throughput. Second question ... suppose one disk was faster than the other -- or one was a sda and the other hda. How much metadata is written compared to file data, i.e. is there some average ratio or range? On the assumption that metadata is smaller, seem like one could use a slower log disk for a primary work disk, and the slower log disk is mostly archival things that aren't written alot, but more read alot -- like mp3's, or CD images....things where the slower read isn't going to be a big problem. When writing to disks with a cache, does XFS force any flushes (like on log data?) Seem like even if you had a slower disk but an 8Mb cache you could keep up with a fairly good write speed on the faster disk. Dunno.... But here's another Q...if you don't flush the on disk cache after a log write, then it is 'granted' that the potential for metadata loss is at least the size of the on-disk cache. That could beg the question -- would it be of any benefit to write a pseudo-block device that lives on top of a disk that just does read-write caching -- maybe it lives with a 64Mb Buffer and attempts to use geometry knowledge of the disk to optimize head motion, whatever. But the point there, being, you could lose 64Mb of log data if the write-log function doesn't flush. If it does flush..well, that would eliminate much of the benefit of an off-disk pseudo device as well as the on-disk cache....some how that seems unfortunate. Maybe this is a 'tuneable' --write-log=sync/async? sorry for the meandering...just bouncing around ideas.... -linda From owner-linux-xfs@oss.sgi.com Thu Mar 6 17:55:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 17:55:08 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h271sjq9004394 for ; Thu, 6 Mar 2003 17:55:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2725Ekq012948 for ; Thu, 6 Mar 2003 20:05:15 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h271rM7L1099401 for ; Fri, 7 Mar 2003 12:53:22 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h271rMGX1099599 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 12:53:22 +1100 (EST) Date: Fri, 7 Mar 2003 12:53:22 +1100 (EST) From: Nathan Scott Message-Id: <200303070153.h271rMGX1099599@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 3094 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 14 Need to define cmn_err in libxfs for all gcc versions, ie. with both of the supported incantations of varargs cpp macros. Date: Thu Mar 6 17:52:48 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:141165a cmd/xfsprogs/libxfs/xfs.h - 1.30 From owner-linux-xfs@oss.sgi.com Thu Mar 6 18:00:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 18:00:54 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2720Iq9005627 for ; Thu, 6 Mar 2003 18:00:19 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2720D9n002633 for ; Thu, 6 Mar 2003 18:00:13 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA07884; Thu, 6 Mar 2003 20:00:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2720CCJ4831819; Thu, 6 Mar 2003 20:00:12 -0600 (CST) Date: Thu, 6 Mar 2003 19:59:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "l.a walsh" cc: linux-xfs@oss.sgi.com Subject: Re: Just some odd questions out of the blue... In-Reply-To: <00a501c2e44a$cfaba280$1403a8c0@sc.tlinx.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3095 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1945 Lines: 47 On Thu, 6 Mar 2003, l.a walsh wrote: > So lets say you had 2 disks...would it make sense to put the log > of disk1 on disk2 and the log of disk2 on disk1? This would be Yes, external logs are available for this reason. Your cross-log scenario would probably only help if you were really only writing to 1 fs at a time. > Second question ... suppose one disk was faster than the other -- > or one was a sda and the other hda. How much metadata is written > compared to file data, i.e. is there some average ratio or range? You can look at the stats with the xfs_stats.pl script in cvs. It really depends on the nature of your workload. > On the assumption that metadata is smaller, seem like one could use > a slower log disk for a primary work disk, and the slower log disk > is mostly archival things that aren't written alot, but more read > alot -- like mp3's, or CD images....things where the slower read isn't > going to be a big problem. True, for reads the log speed isn't critical, but for writes again it will depend on your workload. > When writing to disks with a cache, does XFS force any flushes (like > on log data?) Seem like even if you had a slower disk but an 8Mb > cache you could keep up with a fairly good write speed on the faster > disk. Which is great until you crash, if the cached data is lost... I don't think xfs explicitly does any ide cache flushing. > But here's another Q...if you don't flush the on disk cache after > a log write, then it is 'granted' that the potential for metadata > loss is at least the size of the on-disk cache. That could beg > the question -- would it be of any benefit to write a pseudo-block > device that lives on top of a disk that just does read-write > caching -- maybe it lives with a 64Mb Buffer and attempts to use > geometry knowledge of the disk to optimize head motion, whatever. Ick. :) I think the drive mfgr is the only one who has the knowledge. -Eric From owner-linux-xfs@oss.sgi.com Thu Mar 6 20:43:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 20:43:45 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h274haq9021389 for ; Thu, 6 Mar 2003 20:43:37 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h274s5kq015232 for ; Thu, 6 Mar 2003 22:54:06 -0600 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA25931 for ; Fri, 7 Mar 2003 15:42:14 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 3634C300087; Fri, 7 Mar 2003 15:42:14 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 32EF88F for ; Fri, 7 Mar 2003 15:42:14 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: lbs 2.1.2 builds for i386 again Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Mar 2003 15:42:09 +1100 Message-ID: <32686.1047012129@kao2.melbourne.sgi.com> X-archive-position: 3096 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 122 Lines: 3 XFS developers who are working on lbs 2.1.2 - PV 883422 means that lbs t-o-t will build again for i386 with kdb enabled. From owner-linux-xfs@oss.sgi.com Fri Mar 7 03:08:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 03:08:48 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27B7xq9007934 for ; Fri, 7 Mar 2003 03:08:40 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h27B7vP22647; Fri, 7 Mar 2003 12:07:57 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h27B7r130949; Fri, 7 Mar 2003 12:07:53 +0100 Date: Fri, 7 Mar 2003 12:07:53 +0100 (CET) From: Bogdan Costescu To: Eric Sandeen cc: Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: <1046993631.440.280.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3097 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1256 Lines: 30 On 6 Mar 2003, Eric Sandeen wrote: > Hm, I suppose that for the truly paranoid, with cheap IDE disks, No, not only for them. The frequent access exists for all drives and will destroy a high-end SCSI disk just as well, but maybe not as fast. > there could be an option to rotate an internal log through the AGs each > time you mount. Ehh, how about those using XFS on file servers that have to have an uptime of hundreds of days ? Changing its place online would be bliss... However, placing the journal seems to raise the problem: where ? As it's accessed often, it should be on the area of the disk where speed is maximum (speed = read+write+seek). But if it's moved, can the new location be controlled somehow so that it doesn't accidentally end up in an area with low speed ? Of course, that does mean that free space has to exist at the new location. That begs the question: could defragmentation or something similar take care of creating free space at a specific location on disk ? -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Fri Mar 7 05:56:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 05:56:17 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Du5q9032387 for ; Fri, 7 Mar 2003 05:56:06 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27Du09n010453 for ; Fri, 7 Mar 2003 05:56:00 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA03484; Fri, 7 Mar 2003 07:55:59 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27DtwCJ4893675; Fri, 7 Mar 2003 07:55:59 -0600 (CST) Date: Fri, 7 Mar 2003 07:55:32 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Bogdan Costescu cc: Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3098 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1824 Lines: 41 On Fri, 7 Mar 2003, Bogdan Costescu wrote: > On 6 Mar 2003, Eric Sandeen wrote: > > > Hm, I suppose that for the truly paranoid, with cheap IDE disks, > > No, not only for them. The frequent access exists for all drives and > will destroy a high-end SCSI disk just as well, but maybe not as fast. I think it's important to remember that XFS has been in use for -many- years on irix, on everything from personal desktops to huge servers with filesystems on the order of tens of terabytes. While I'm sure that usage patterns will affect the life of any device, I don't think that this has been a problem in general. (And, I can think of other disk usages patterns which could result in disproportional use of one area of a disk - /var/log partitions, for example). > Ehh, how about those using XFS on file servers that have to have an uptime > of hundreds of days ? Changing its place online would be bliss... Actually if this were implemented, a quick xfs_freeze/log move/xfs_thaw would be plausible. > However, placing the journal seems to raise the problem: where ? As it's > accessed often, it should be on the area of the disk where speed is > maximum (speed = read+write+seek). But if it's moved, can the new location > be controlled somehow so that it doesn't accidentally end up in an area > with low speed ? Of course, that does mean that free space has to exist at > the new location. That begs the question: could defragmentation or > something similar take care of creating free space at a specific location > on disk ? I think you're asking too much here... I think each individual disk would need to be profiled to even know where the "fast" spots are. And then technically, the log could go anywhere, but I think that for the effort involved, the returns would not be that great. -Eric From owner-linux-xfs@oss.sgi.com Fri Mar 7 06:17:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:17:08 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27EH1q9002800 for ; Fri, 7 Mar 2003 06:17:02 -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 ZBLDPQR6; Fri, 7 Mar 2003 09:17:29 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h27EFvfj027384; Fri, 7 Mar 2003 09:15:58 -0500 Message-ID: <3E68A99D.4060301@wgate.com> Date: Fri, 07 Mar 2003 09:15:57 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bogdan Costescu CC: Eric Sandeen , Andi Kleen , "Buzbee, James" , linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 2417 Lines: 52 Bogdan Costescu wrote: > On 6 Mar 2003, Eric Sandeen wrote: > > >>Hm, I suppose that for the truly paranoid, with cheap IDE disks, > > > No, not only for them. The frequent access exists for all drives and > will destroy a high-end SCSI disk just as well, but maybe not as fast. I would think that all of this "worry" is not a major issue. One of the reasons you may find more "remapped" blocks in the highly used areas is that they drive had more chance to notice a questionable sector. (That is a sector where error correction was needed to recover the data beyond the norm and thus it chose to relocate the sector) If you are worried that such usage patterns can be a problem, just look at filesystems such as FAT/FAT32/VFAT/etc. They always must write to the front of the disk (fat table) and read from that same area (except when cached) There is no noticable higher failure rate of drives due to FAT file system usage (don't count Windows re-install and file corruption as disk failures :-) NTFS also has the central allocation bitmap and control structures. The main problem with the "low end" IDE drives is that they are very fragile bits of mechanical equipment. Very small head to disk spacing and very high rotational rates and very high bit density means that failures will happen due to mechanical reasons. As you cut your costs and try to pump out millions of these units, the MTBF will tend to drop until you get some new technique to make them more reliable. Then then push the limits and make the drives double their bit density and half the head flying height and the cycle starts over. Given the track record of XFS and other file systems and usage patterns that cause certain areas of disks to be used much more often than others, I have not seen a major failure mode in many years. (There was the lubrication failure mode from many years ago, but that has long since been solved) That is not to say that we should not look at the fact that there are hot zones in where writing happens. The fact that there are hot zones (multiple) means that there is more seeking going on than you might want (albeit it may be needed). (And each seek does cause some mechanical wear and poses potential mechanical failure) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications 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 Fri Mar 7 06:29:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:29:42 -0800 (PST) Received: from oxygen.dynamix-ltd.com (proxy.dynamix-ltd.com [204.107.254.187]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27ESvq9003846 for ; Fri, 7 Mar 2003 06:29:38 -0800 Received: from dynamix-ltd.com (unknown [192.168.1.103]) by oxygen.dynamix-ltd.com (Postfix) with ESMTP id 94D75ED48; Fri, 7 Mar 2003 09:11:22 -0500 (EST) Message-ID: <3E68ACFD.20702@dynamix-ltd.com> Date: Fri, 07 Mar 2003 09:30:21 -0500 From: Andy Skunza User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> In-Reply-To: <1046997413.1373.14.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3100 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: askunza@dynamix-ltd.com Precedence: bulk X-list: linux-xfs Content-Length: 1535 Lines: 46 Stephen Lord wrote: >On Thu, 2003-03-06 at 16:50, Buzbee, James wrote: > > >>The scary thing about what we are seeing is that the "grown defect list" >>on the disk is showing a lot of sectors in these two areas. It's almost >>as if we are wearing out the sectors in these areas by writing them so >>often. Strange but true ;-( >> >>Jim >> >> >> > >Ugh, yes these will be continually written to, the log in particular, >I like Eric's idea, but the scope of that is fairly drastic and it >will only postpone the inevitable - you can probably do the math to >work out how long the drive will run before it runs out of bad >blocks to remap to. All running with alternating logs would do is >delay the drive becoming scrap metal. The reliability of these >devices may not be up to the load you are placing on them. >Not all ide drives are this bad, I have been running xfs on >the same ide drive for about 3 years now - but then I am >not running a PVR. I suspect also you may have the write cache >turned off to avoid errors after a crash. > >Possibly the way your app runs is making things worse. There is a script >in the cmd/misc directory called xfsstats.pl you can watch log activity >with this. In particular xs_log_writes and xs_log_blocks. If log_blocks >is not a reasonable multiple of log_writes then you are doing a lot of >very small writes. > >Steve > > > > > > What is a "reasonable multiple" of log_writes to log_blocks? Would 22 be unreasonable? And, how to use xfs_stats.pl per xfs partion? Thanks, andy From owner-linux-xfs@oss.sgi.com Fri Mar 7 06:43:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:44:03 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Ehvq9004991 for ; Fri, 7 Mar 2003 06:43:59 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h27EhuX28541; Fri, 7 Mar 2003 15:43:57 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h27Ehv032671; Fri, 7 Mar 2003 15:43:57 +0100 Date: Fri, 7 Mar 2003 15:43:57 +0100 (CET) From: Bogdan Costescu To: Eric Sandeen cc: Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3101 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1990 Lines: 52 On Fri, 7 Mar 2003, Eric Sandeen wrote: > I think it's important to remember that XFS has been in use for -many- > years on irix, Yes, we use it there as well. It's just that it came a bit as a surprise that the choice of a FS would affect the lifetime of the disk... I guess that we'll soon see disk-savers that save the oxide from our disks as the screen-savers saved the phosphor from our monitors :-))) > (And, I can think of other disk usages patterns which could result in > disproportional use of one area of a disk - /var/log partitions, for > example). Swap partitions might be hit even harder... > I think you're asking too much here... Well, I should have enclosed the whole block within quotes or something. But there _are_ performane freaks that pay attention to these details... Even more the problem might become hard when thinking about relocated sectors in which case the FS has no idea what is the real location. > I think each individual disk would need to be profiled to even know > where the "fast" spots are. Oh, I thought that this is common knowledge. Look at http://www.storagereview.com or http://www.hardware.fr/articles/448/page1.html (in French) and you'll see that there are drives which provide at the end of the disk close to half of reading speed from the beginning of the disk, while writes are even more affected. So, would you place the journal at the end of such a disk ? Of course, seek times also count... > And then technically, the log could go anywhere, but I think that for > the effort involved, the returns would not be that great. No, you'r right, possibly the fastest solution is to have a fast SCSI disk only for the journal and a replacement disk at hand. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Fri Mar 7 06:57:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:57:07 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27EuJq9006232 for ; Fri, 7 Mar 2003 06:57:00 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h27EuIX28896; Fri, 7 Mar 2003 15:56:18 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h27EuFZ00305; Fri, 7 Mar 2003 15:56:15 +0100 Date: Fri, 7 Mar 2003 15:56:15 +0100 (CET) From: Bogdan Costescu To: Michael Sinz cc: Eric Sandeen , Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: <3E68A99D.4060301@wgate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 737 Lines: 19 On Fri, 7 Mar 2003, Michael Sinz wrote: > That is not to say that we should not look at the fact that there > are hot zones in where writing happens. The fact that there are > hot zones (multiple) means that there is more seeking going on than > you might want (albeit it may be needed). (And each seek does > cause some mechanical wear and poses potential mechanical failure) You are absolutely right and I think that the above paragraph expresses better what I wanted to say... -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:17:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:17:50 -0800 (PST) Received: from muaddib.localnet (mail@port-212-202-170-13.reverse.qdsl-home.de [212.202.170.13]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FHeq9009352 for ; Fri, 7 Mar 2003 07:17:42 -0800 Received: from ij by muaddib.localnet with local (Exim 3.36 #1 (Debian)) id 18rJbI-0006gW-00; Fri, 07 Mar 2003 16:17:32 +0100 Date: Fri, 7 Mar 2003 16:17:32 +0100 To: Michael Sinz Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030307151732.GO1446@spice.cologne.de> References: <3E68A99D.4060301@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E68A99D.4060301@wgate.com> User-Agent: Mutt/1.5.3i From: Ingo Juergensmann X-archive-position: 3103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ij@spice.cologne.de Precedence: bulk X-list: linux-xfs Content-Length: 5347 Lines: 100 On Fri, Mar 07, 2003 at 09:15:57AM -0500, Michael Sinz wrote: > >No, not only for them. The frequent access exists for all drives and > >will destroy a high-end SCSI disk just as well, but maybe not as fast. > I would think that all of this "worry" is not a major issue. One > of the reasons you may find more "remapped" blocks in the highly used > areas is that they drive had more chance to notice a questionable > sector. (That is a sector where error correction was needed to > recover the data beyond the norm and thus it chose to relocate the > sector) Hmm, well, I have some disks with large grown defects tables and others without any grown defect at all, regardless of how old the disks are. But I had as well more failing IDE disks than SCSI disks. Only one SCA disk failed in an array the last days, but some IDE disks died just after a few days (yes, IBM ones ;). The failing SCA disk instead was an old 2 GB Seagate Barracuda, just to mention how old this disk was... > If you are worried that such usage patterns can be a problem, just look > at filesystems such as FAT/FAT32/VFAT/etc. They always must write to > the front of the disk (fat table) and read from that same area (except > when cached) There is no noticable higher failure rate of drives due > to FAT file system usage (don't count Windows re-install and file > corruption as disk failures :-) > NTFS also has the central allocation bitmap and control structures. Most users will re-install Windows anyway on broken disks as well, until they realises that actually the disk is broken and not Windows... ;) > The main problem with the "low end" IDE drives is that they are very > fragile bits of mechanical equipment. Very small head to disk spacing > and very high rotational rates and very high bit density means that > failures will happen due to mechanical reasons. As you cut your costs > and try to pump out millions of these units, the MTBF will tend to > drop until you get some new technique to make them more reliable. > Then then push the limits and make the drives double their bit > density and half the head flying height and the cycle starts over. Try and error or "public betatesting"... There is no time anymore to test the hard-/software inhouse, instead many uses the crowd out there as public betatesters... *sigh* IBM disks are a good example for this QA problems. > Given the track record of XFS and other file systems and usage > patterns that cause certain areas of disks to be used much more > often than others, I have not seen a major failure mode in many > years. (There was the lubrication failure mode from many > years ago, but that has long since been solved) > > That is not to say that we should not look at the fact that there > are hot zones in where writing happens. The fact that there are > hot zones (multiple) means that there is more seeking going on than > you might want (albeit it may be needed). (And each seek does > cause some mechanical wear and poses potential mechanical failure) For me as a user it's something like this: I don't bother about the filesystem internals as long as I can get my data back in some way. I know that each filesystem can and certainly will fail at some time. I made this experiences with Amiga OFS and FFS, with Amiga AFS (now SFS), FAT, NTFS, ext2/ext3 and XFS (both Irix and x86). As you might now FFS has a certain manner in accessing data, which make it easy to regain data after a disk error (disk validating error): quick format it and let some undelete tools do their job (such as DiskSalv from Dave H.). Back then I tried AFS (Advanced FileSystem), which worked fine for some time, until it failed. The delivered AFS salvage tools failed in validating the disk and 400 MB of data (back in 1995 that was a big block of data ;). My experiences with FAT and NTFS are not as deep as with others operating systems or file systems, but it's similar: as long as there are tools that are doing their job excellent, you don't worry much about your data - as long the operating/file systems doesn't try to be very clever and doing stuff it better shouldn't do. Ext2/3 is doing some fscking regularly, but when fsck stumbles about an error it can't solve at its own, you're doomed as an average user. XFS instead is somewhat different. Not that I haven't had failing disks under XFS usage - indeed I had the most failing disks (IBMs that is ;) under XFS, but I was always able to recover my data (with the help of esandeen and others from #xfs). The reason is simple (for me): I can make a diskimage of that filesystem and try to salvage the data from that "backup"... if dd stumbles across an error on hardware, I can skip that block and XFS is robust enough to get a clean file system with this missing block. And because XFS is on disk compatible I can use XFS tools on my SGI to exclude bugs in Linux XFS tools. To make it short: A good file system is not the fastest one or the newest one, but the one that gives me my data back after an error happened - errors will happen for sure! Regardless of FS errors or hardware errors on disk. So, the FS tools are somewhat more important than the FS itself. For me XFS and Amiga FFS are the most robust file systems I came across over the years... :-) -- Ciao... // Ingo \X/ From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:18:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:18:09 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FI5q9009472 for ; Fri, 7 Mar 2003 07:18:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27FHxnH014765 for ; Fri, 7 Mar 2003 07:18:00 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA69404; Fri, 7 Mar 2003 09:17:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27FHuwX24947160; Fri, 7 Mar 2003 09:17:56 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27FHtf28660; Fri, 7 Mar 2003 09:17:55 -0600 Subject: Re: LBA to File? From: Steve Lord To: Bogdan Costescu Cc: Eric Sandeen , Andi Kleen , "Buzbee, James" , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047050275.26370.2197.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 09:17:55 -0600 X-archive-position: 3104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 623 Lines: 19 On Fri, 2003-03-07 at 08:43, Bogdan Costescu wrote: > > No, you'r right, possibly the fastest solution is to have a fast SCSI disk > only for the journal and a replacement disk at hand. Actually the fastest solution is to have a partitioned solid state device you use for logs - battery backed ram, definitely not flash. Unfortunately xfs cannot share logs between filesystems so if you put several on a drive dedicated to logs you are in for a lot of head seeking. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:18:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:18:45 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FIgq9009934 for ; Fri, 7 Mar 2003 07:18:43 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 08:19:07 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 08:18:35 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHSJAG8H; Fri, 7 Mar 2003 08:18:32 -0700 From: "Buzbee, James" To: Stephen Lord Cc: Eric Sandeen , linux-xfs@oss.sgi.com Message-ID: <3E68B848.2040509@echostar.com> Date: Fri, 07 Mar 2003 08:18:32 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 1612 Lines: 50 Stephen Lord wrote: > On Thu, 2003-03-06 at 16:50, Buzbee, James wrote: > >>The scary thing about what we are seeing is that the "grown defect list" >>on the disk is showing a lot of sectors in these two areas. It's almost >>as if we are wearing out the sectors in these areas by writing them so >>often. Strange but true ;-( >> >>Jim >> > > > Ugh, yes these will be continually written to, the log in particular, > I like Eric's idea, but the scope of that is fairly drastic and it > will only postpone the inevitable - you can probably do the math to > work out how long the drive will run before it runs out of bad > blocks to remap to. All running with alternating logs would do is > delay the drive becoming scrap metal. The reliability of these > devices may not be up to the load you are placing on them. > Not all ide drives are this bad, I have been running xfs on > the same ide drive for about 3 years now - but then I am > not running a PVR. Some of these units are never turned off. The user turns off the TV and leaves the Set Top box on. They are running 24/7 recording at least one video stream, maybe two. > I suspect also you may have the write cache > turned off to avoid errors after a crash. > > Possibly the way your app runs is making things worse. There is a script > in the cmd/misc directory called xfsstats.pl you can watch log activity > with this. In particular xs_log_writes and xs_log_blocks. If log_blocks > is not a reasonable multiple of log_writes then you are doing a lot of > very small writes. Thanks - We'll take a look at it. Jim > > Steve > > From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:19:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:19:49 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FJkq9010730 for ; Fri, 7 Mar 2003 07:19:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27FJfnH014919 for ; Fri, 7 Mar 2003 07:19:41 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA91040 for ; Fri, 7 Mar 2003 09:19:39 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27FJdvw6917239 for ; Fri, 7 Mar 2003 09:19:39 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h27FJfkY446772 for ; Fri, 7 Mar 2003 09:19:41 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h27FJe6C446638 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 09:19:40 -0600 (CST) Date: Fri, 7 Mar 2003 09:19:40 -0600 (CST) From: Dean Roehrich Message-Id: <200303071519.h27FJe6C446638@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - allow dmapi test tools get/set_dmattr to take handle or pathname X-archive-position: 3106 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 437 Lines: 17 allow dmapi test tools get/set_dmattr to take handle or pathname Date: Fri Mar 7 07:19:18 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:141196a src/suite1/cmd/get_dmattr.c - 1.7 - allow pathname or handle src/suite1/cmd/set_dmattr.c - 1.7 - allow pathname or handle From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:34:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:34:06 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FY3q9012150 for ; Fri, 7 Mar 2003 07:34:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27FXwnH015894 for ; Fri, 7 Mar 2003 07:33:58 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA96555; Fri, 7 Mar 2003 09:33:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27FXvwX24967945; Fri, 7 Mar 2003 09:33:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27FXvG28690; Fri, 7 Mar 2003 09:33:57 -0600 Subject: Re: LBA to File? From: Steve Lord To: Andy Skunza Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E68ACFD.20702@dynamix-ltd.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> <3E68ACFD.20702@dynamix-ltd.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047051236.26370.2238.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 09:33:57 -0600 X-archive-position: 3107 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1205 Lines: 37 On Fri, 2003-03-07 at 08:30, Andy Skunza wrote: > Stephen Lord wrote: > > > >Possibly the way your app runs is making things worse. There is a script > >in the cmd/misc directory called xfsstats.pl you can watch log activity > >with this. In particular xs_log_writes and xs_log_blocks. If log_blocks > >is not a reasonable multiple of log_writes then you are doing a lot of > >very small writes. > > > >Steve > > > What is a "reasonable multiple" of log_writes to log_blocks? Would 22 be > unreasonable? And, how to use xfs_stats.pl per xfs partion? > > Thanks, > andy The stats are global and not available on a per fs basis. You can clear the stats with echo 1 > /proc/sys/fs/xfs/stats_clear So you can measure more controlled periods of time. Perfection is 64, the more recent your code the closer you should get, we have been removing synchronous transactions from the code. My workstation which has been up 27 days is averaging a ratio of 52. It also depends on what you run, something which does O_SYNC writes all the time can hammer it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:46:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:46:58 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e14d.dsl.mediaWays.net [213.20.225.77]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Fkmq9016886 for ; Fri, 7 Mar 2003 07:46:52 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18rK3W-0006gy-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 16:46:42 +0100 Received: from 192.168.1.1 ( [192.168.1.1]) as user be@ente.berdmann.de by apollo.berdmann.de with HTTP; Fri, 7 Mar 2003 16:46:42 +0100 Message-ID: <1047052002.3e68bee241784@apollo.berdmann.de> Date: Fri, 7 Mar 2003 16:46:42 +0100 From: Bernhard Erdmann To: linux-xfs@oss.sgi.com Subject: suppressing syncs on spools MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 192.168.1.1 X-archive-position: 3108 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 443 Lines: 15 Hi, for a spool/scratch filesystem I'm only interested in speed. Disk I/O should be as minimal as possible. Files will be deleted some 1/10 sec or some secs later. It won't hurt if files are lost if the box crashes. This filesystem can even be mkfs'd at system boot. Just speed, like a ram disk, but I don't want to spend 1-2 GB to a ram disk. Are there mount options or mkfs.xfs options which can help to reduce disk I/O? Regards Bernie From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:48:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:48:47 -0800 (PST) Received: from deepstrike.nameip.net (IDENT:aMrWp9KwxmMH4lnd1G6jepmqKoyV6c37@[211.49.14.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Fmhq9017336 for ; Fri, 7 Mar 2003 07:48:45 -0800 Received: (qmail 8247 invoked by uid 500); 7 Mar 2003 15:48:39 -0000 Subject: latest RH + XFS kernel From: Seung-yeong Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047052119.6227.4.camel@deepstrike.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2003 00:48:39 +0900 X-archive-position: 3109 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: so1713@orgio.net Precedence: bulk X-list: linux-xfs Content-Length: 82 Lines: 7 Should anyone is interested; http://www.withseha.net/~so1713 Have a nice day. From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:56:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:56:56 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Furq9017831 for ; Fri, 7 Mar 2003 07:56:54 -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 ZBLDPSAY; Fri, 7 Mar 2003 10:57:21 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h27Ftnfj027846; Fri, 7 Mar 2003 10:55:49 -0500 Message-ID: <3E68C105.6060805@wgate.com> Date: Fri, 07 Mar 2003 10:55:49 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ingo Juergensmann CC: linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: <3E68A99D.4060301@wgate.com> <20030307151732.GO1446@spice.cologne.de> In-Reply-To: <20030307151732.GO1446@spice.cologne.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3110 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 2112 Lines: 50 Ingo Juergensmann wrote: > On Fri, Mar 07, 2003 at 09:15:57AM -0500, Michael Sinz wrote: [...] >>That is not to say that we should not look at the fact that there >>are hot zones in where writing happens. The fact that there are >>hot zones (multiple) means that there is more seeking going on than >>you might want (albeit it may be needed). (And each seek does >>cause some mechanical wear and poses potential mechanical failure) > > > For me as a user it's something like this: > I don't bother about the filesystem internals as long as I can get my data > back in some way. I know that each filesystem can and certainly will fail > at some time. > I made this experiences with Amiga OFS and FFS, with Amiga AFS (now SFS), > FAT, NTFS, ext2/ext3 and XFS (both Irix and x86). Ahh, the Amiga FFS - it would not scale to very large disks very well (bitmap rather than extents is a major limiting factor) but it did have a lot going for it. (so says an ex-Amiga OS Systems Engineer/Architect - we are talking 10 years ago here...) [...] > To make it short: > A good file system is not the fastest one or the newest one, but the one > that gives me my data back after an error happened - errors will happen for > sure! Regardless of FS errors or hardware errors on disk. So, the FS tools > are somewhat more important than the FS itself. > > For me XFS and Amiga FFS are the most robust file systems I came across over > the years... :-) Yes, high reliability and recoverability are key aspects of filesystem design (well, good filesystem design... Don't look at FAT as a good design) However, that does not mean you should not look at issues that can cause performance hits or long-term hardware wear. They may be non-solveable but the point is not to just ignore them. If you can get both the high quality and high performance, so much the better. (And I think that XFS does provide a very good balance in this respect...) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications 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 Fri Mar 7 08:00:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 08:00:10 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27G07q9018325 for ; Fri, 7 Mar 2003 08:00:08 -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 ZBLDPSCR; Fri, 7 Mar 2003 11:00:36 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h27Fx4fj027856; Fri, 7 Mar 2003 10:59:04 -0500 Message-ID: <3E68C1C8.6090606@wgate.com> Date: Fri, 07 Mar 2003 10:59:04 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Andy Skunza , linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> <3E68ACFD.20702@dynamix-ltd.com> <1047051236.26370.2238.camel@jen.americas.sgi.com> In-Reply-To: <1047051236.26370.2238.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3111 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1575 Lines: 44 Steve Lord wrote: > On Fri, 2003-03-07 at 08:30, Andy Skunza wrote: > >>Stephen Lord wrote: >> >>>Possibly the way your app runs is making things worse. There is a script >>>in the cmd/misc directory called xfsstats.pl you can watch log activity >>>with this. In particular xs_log_writes and xs_log_blocks. If log_blocks >>>is not a reasonable multiple of log_writes then you are doing a lot of >>>very small writes. >>> >> >>What is a "reasonable multiple" of log_writes to log_blocks? Would 22 be >>unreasonable? And, how to use xfs_stats.pl per xfs partion? >> >>Thanks, >>andy > > The stats are global and not available on a per fs basis. You can clear > the stats with > > echo 1 > /proc/sys/fs/xfs/stats_clear > > So you can measure more controlled periods of time. > > Perfection is 64, the more recent your code the closer you should get, > we have been removing synchronous transactions from the code. My > workstation which has been up 27 days is averaging a ratio of 52. > It also depends on what you run, something which does O_SYNC writes > all the time can hammer it. So, for a workstation that has been up for 6 days (running relatively new XFS from CVS) seeing a value of around 20 to 21:1 is not there yet. Do you want us to monitor this for you and provide feedback? (This is a development system - that is, build/compile/edit/etc, and not a server - I will check on those later) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications 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 Fri Mar 7 08:33:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 08:33:39 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27GXZq9020165 for ; Fri, 7 Mar 2003 08:33:36 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27GXU9n020436 for ; Fri, 7 Mar 2003 08:33:30 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA58250 for ; Fri, 7 Mar 2003 10:33:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27GXTwX24760342 for ; Fri, 7 Mar 2003 10:33:29 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h27GX2923479; Fri, 7 Mar 2003 10:33:02 -0600 Message-Id: <200303071633.h27GX2923479@stout.americas.sgi.com> Date: Fri, 7 Mar 2003 10:33:02 -0600 Subject: TAKE - Turn on random() if INDUCE_IO_ERROR is defined X-archive-position: 3112 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 419 Lines: 16 This is really just for debugging... allow error injection without a full debug kernel. Turn on random() if INDUCE_IO_ERROR is defined Date: Fri Mar 7 08:31:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs-dev/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-dev Modid: 2.4.x-xfs-dev:slinx:141200a linux/fs/xfs/support/debug.c - 1.23 From owner-linux-xfs@oss.sgi.com Fri Mar 7 09:41:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 09:41:36 -0800 (PST) Received: from imf13bis.bellsouth.net (mail213.mail.bellsouth.net [205.152.58.153]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27HfRq9024307 for ; Fri, 7 Mar 2003 09:41:28 -0800 Received: from tiger2 ([67.35.81.4]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030307174325.SKSJ2682.imf13bis.bellsouth.net@tiger2>; Fri, 7 Mar 2003 12:43:25 -0500 Date: Fri, 7 Mar 2003 12:45:10 -0500 From: Greg Freemyer Subject: re[2]: LBA to File? To: Bogdan Costescu cc: Mime-Version: 1.0 Organization: Norcross Group X-Mailer: GoldMine [6.00.21021] Content-Type: Text/plain Message-Id: <20030307174325.SKSJ2682.imf13bis.bellsouth.net@tiger2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27HfTq9024313 X-archive-position: 3113 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1051 Lines: 23 >> On Fri, 7 Mar 2003, Michael Sinz wrote: >> > That is not to say that we should not look at the fact that there >> > are hot zones in where writing happens. The fact that there are >> > hot zones (multiple) means that there is more seeking going on than >> > you might want (albeit it may be needed). (And each seek does >> > cause some mechanical wear and poses potential mechanical failure) Performance: What is the failure rate of the log sectors on these drives? Is even possible to tell from the Linux kernel? If possible to tell, then maybe the journal itself should be created a little on the large size, then when an underlying sector is re-mapped, simply quit using that sector in the journal. This would eliminate time wasting seeks out to the remapped sectors. Longevity: Even if your losing 1% of sectors/month, allocating a spare 100% of log space as above would allow the drive to last 100 months before it was trashed and would ensure high log speed access for the duration of that 100 months. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Fri Mar 7 10:30:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 10:31:58 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27IThq9026497 for ; Fri, 7 Mar 2003 10:30:25 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18rFYB-0007U0-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 11:58:03 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18rFUx-0008VA-00; Fri, 07 Mar 2003 11:54:43 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Chris Wedgwood Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Fri, 7 Mar 2003 11:54:44 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: <200303051048.54271.juergen.sauer@automatix.de> <200303052022.38108.juergen.sauer@automatix.de> <20030305210513.GA427@f00f.org> In-Reply-To: <20030305210513.GA427@f00f.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303071154.44584.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27IUQq9026556 X-archive-position: 3114 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1173 Lines: 39 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 22:05 schrieb Chris Wedgwood: > On Wed, Mar 05, 2003 at 08:22:34PM +0100, Juergen Sauer wrote: > > > The XFS Kernel 2.4.20-xfs out of the SGI/CVS Repository does not > > know about the the nforce2 ide and gives errors, if I enable > > DMA/UDMA modes. > > I knows about the nv/amd driver though > > > The amd7xx driver is not in the kernel visible here. Should it be > > visible? (Error in config.in ?) > > CONFIG_BLK_DEV_AMD74XX=y > > actually, i think you need an -ac tree for this, i was looking at the > 2.5.x where the nv ide and amd ide are unified - -ac Kernel tree is not avaible in the KErnel-2.4-xfs CVS by SGI. Exactly that is the problem ! mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aHp0W7UKI9EqarERAsIhAJ9uhPQ43Ywzaxd/X/qB4/umBt/pdgCeI59B gth1BDDemL/YKPEseJ7VNng= =cxzf -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 7 10:31:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 10:32:14 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27IUQq9026558 for ; Fri, 7 Mar 2003 10:31:07 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18rFUR-0007Tb-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 11:54:11 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18rFTi-0008Uf-00; Fri, 07 Mar 2003 11:53:26 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com, Florin Andrei Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Fri, 7 Mar 2003 11:53:27 +0100 User-Agent: KMail/1.5 References: <200303051048.54271.juergen.sauer@automatix.de> <1046897437.31215.43.camel@stantz.corp.sgi.com> In-Reply-To: <1046897437.31215.43.camel@stantz.corp.sgi.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303071153.27690.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27IV7q9026644 X-archive-position: 3115 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1153 Lines: 37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 21:50 schrieb Florin Andrei: > Is it related just to IDE for the CD-ROM, or for all devices? > If it's just for CD-ROMs, here's an excerpt from the RELEASE-NOTES for > RH8.0: > > ########################### > DMA is disabled on CD-ROM drives in this release in a different but more > reliable way than previously. If you are sure that your CD-ROM drive is > capable of IDE DMA, place the following line in the /etc/modules.conf > file: > options ide-cd dma=1 > ############################ RedHat is not standard. RH is only one distri. The base problem is that the cvs/2.4-xfs kernel does not complain to the common nforec2 Patches. mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aHonW7UKI9EqarERAiibAJsHefk4FRkm1qqlYby9yotIe+CixgCguE6T zfq2vp22Df/RKpl6349Ao9A= =h4nd -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 7 10:32:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 10:33:34 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27IVjq9026711 for ; Fri, 7 Mar 2003 10:32:26 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18rFYB-0007U4-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 11:58:03 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18rFWe-0008VL-00; Fri, 07 Mar 2003 11:56:28 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Thomas Bittermann Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Fri, 7 Mar 2003 11:56:29 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: <200303051048.54271.juergen.sauer@automatix.de> <200303052022.38108.juergen.sauer@automatix.de> <200303052309.51984.t.bittermann@online.de> In-Reply-To: <200303052309.51984.t.bittermann@online.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303071156.29730.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27IWQq9026981 X-archive-position: 3116 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 837 Lines: 29 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 23:09 schrieb Thomas Bittermann: > Hallo Juergen, > > I'm using a "home-grown" 2.4.21-pre5-ac1 with XFS (CVS-2003-03-05). > Alan's patch removes nvidia.* from drivers/ide/pci (pre5). It includes > nForce(2) support in drivers/ide/pci/amd74xx.* so be sure to activate "AMD > Viper support". Which CVS Source do you use ? mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aHrdW7UKI9EqarERAvPiAKCx5a2/uLG+/YrzDiayF1FNnzmPIgCdFvTm 7H9/Sx6UGfVHzzpBqCasga4= =/hhP -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 7 12:42:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 12:42:27 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27KgMq9002107 for ; Fri, 7 Mar 2003 12:42:22 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27KgG9n005893 for ; Fri, 7 Mar 2003 12:42:16 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA85879 for ; Fri, 7 Mar 2003 14:42:15 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27KgDwX24738099 for ; Fri, 7 Mar 2003 14:42:14 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h283vp908421 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 22:57:51 -0500 Resent-Message-Id: <200303080357.h283vp908421@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27KciwX24536320 for ; Fri, 7 Mar 2003 14:38:45 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h283sMZ08411 for hch@sgi.com; Fri, 7 Mar 2003 22:54:22 -0500 Date: Fri, 7 Mar 2003 22:54:22 -0500 From: Christoph Hellwig Message-Id: <200303080354.h283sMZ08411@taclab54.munich.sgi.com> Subject: TAKE - time_after takes an unsigned long Resent-From: hch@sgi.com Resent-Date: Fri, 7 Mar 2003 22:57:51 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 328 Lines: 13 This has been cought by the stricter typechecking in 2.5 mainline. Date: Fri Mar 7 12:36:49 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/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:141237a linux/fs/xfs/xfs_buf_item.c - 1.137 From owner-linux-xfs@oss.sgi.com Fri Mar 7 12:46:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 12:46:34 -0800 (PST) Received: from loki (firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27KkTq9002520 for ; Fri, 7 Mar 2003 12:46:30 -0800 Received: from conet.cz (liborwin [192.168.1.130]) by loki (8.12.8/8.12.5) with ESMTP id h27KI8O4014220 for ; Fri, 7 Mar 2003 21:18:08 +0100 Message-ID: <3E68FCB8.4050505@conet.cz> Date: Fri, 07 Mar 2003 21:10:32 +0100 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_repair produces 990 error Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: libor@conet.cz Precedence: bulk X-list: linux-xfs Content-Length: 3498 Lines: 129 Hi, I've had disk failure in my SW RAID, which was quite OK since it was only 1 of 3 disks. But system was halted so I rebooted it and afterthat I was unable to mount XFS system so I run xfs_repair with this result: [root@Discobolos_2 root]# xfs_repair /dev/md0 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 no .. entry for directory 196669223 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 no .. entry for directory 486539427 - agno = 30 - agno = 31 - agno = 32 entry contains offset out of order in shortform dir 537155859 corrected entry offsets in directory 537155859 - agno = 33 - agno = 34 - agno = 35 no .. entry for directory 587629607 - agno = 36 - agno = 37 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 no .. entry for directory 196669223 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 no .. entry for directory 486539427 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 no .. entry for directory 587629607 - agno = 36 - agno = 37 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 134386441, moving to lost+found disconnected inode 134386465, moving to lost+found disconnected inode 134386469, moving to lost+found corrupt inode 134386469 (btree). Unmount and run xfs_repair. fatal error -- 990 - couldn't iget disconnected inode Any suggestions? Thanks a LOT, Libor Vanek From owner-linux-xfs@oss.sgi.com Fri Mar 7 13:22:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 13:22:52 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e14d.dsl.mediaWays.net [213.20.225.77]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27LM2q9005147 for ; Fri, 7 Mar 2003 13:22:43 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18rPHw-0007FQ-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 22:21:56 +0100 Message-ID: <3E690D72.5080801@berdmann.de> Date: Fri, 07 Mar 2003 22:21:54 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4a) Gecko/20030307 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: rsync://oss.sgi.com with a very low timeout value? "unexpected EOF in read_timeout" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 1142 Lines: 37 Hi, I'm trying to rsync on rsync://oss.sgi.com/xfsftp/Release-1.0.2, but every time rsync stops at the file RH7.2-SGI-XFS-1.0.2a.iso: "unexpected EOF in read_timeout" This file is on my local hard disk (320 MB). The local rsync seems to calculate a checksum (as I see hard disk activity while waiting for "unexpected EOF in read_timeout") and does not finish within the timeout of the rsync server. Using -vvv I get the following output: $ pwd /net/software/xfs/oss.sgi.com/projects/xfs $ rsync --progress --delete -vvv -aH rsync://oss.sgi.com/xfsftp/Release-1.0.2 . local_version=24 remote_version=24 receiving file list ... recv_file_name(Release-1.0.2) recv_file_name(Release-1.0.2/cmd_rpms) [...] recv_generator(Release-1.0.2/installer/i386/RH7.2-SGI-XFS-1.0.2a.iso,159) unexpected EOF in read_timeout sending sums for 159 unexpected EOF in read_timeout It takes 20 sec from the last line "recv_generator" to "unexpected EOF in read_timeout". If I exclude this file (--exclude=RH7.2-SGI-XFS-1.0.2a.iso), rsync properly syncs down the tree. Is there some timeout value on the rsync server being that small? Regards Bernie From owner-linux-xfs@oss.sgi.com Fri Mar 7 13:26:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 13:26:13 -0800 (PST) Received: from hotmail.com (f66.sea2.hotmail.com [207.68.165.66]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27LQAq9012472 for ; Fri, 7 Mar 2003 13:26:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Mar 2003 13:26:05 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Fri, 07 Mar 2003 21:26:05 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: unwritten extents vs. fragmentation Date: Fri, 07 Mar 2003 13:26:05 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Mar 2003 21:26:05.0566 (UTC) FILETIME=[2947F1E0:01C2E4F0] X-archive-position: 3120 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 398 Lines: 12 A couple questions. Does enabling unwritten extent flagging in XFS ultimately reduce filesystem fragmentation? What is the downside of enabling unwritten extents other than slower write performance? Thanks. Rick Smith _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Fri Mar 7 13:33:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 13:33:04 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27LX1q9013762 for ; Fri, 7 Mar 2003 13:33:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27LhYkq001625 for ; Fri, 7 Mar 2003 15:43:34 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA55206; Fri, 7 Mar 2003 15:32:55 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27LWswX25031681; Fri, 7 Mar 2003 15:32:54 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27LWs620670; Fri, 7 Mar 2003 15:32:54 -0600 Subject: Re: unwritten extents vs. fragmentation From: Steve Lord To: Rick Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047072773.1864.60.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 15:32:54 -0600 X-archive-position: 3121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 810 Lines: 19 On Fri, 2003-03-07 at 15:26, Rick Smith wrote: > A couple questions. Does enabling unwritten extent flagging in XFS > ultimately reduce filesystem fragmentation? What is the downside of enabling > unwritten extents other than slower write performance? Thanks. It should make no difference to physical fragmentation, and in the normal I/O path unwritten extents should not be used. They only come into play with space preallocation. In this case they will slow down I/O somewhat, but provide more security in that you cannot use unwritten extents to read old data. This is why the prealloc calls on -d unwritten=0 filesystems are restricted to root. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 14:05:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 14:05:46 -0800 (PST) Received: from hotmail.com (f46.sea2.hotmail.com [207.68.165.46]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27M5cq9018536 for ; Fri, 7 Mar 2003 14:05:39 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Mar 2003 14:05:33 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Fri, 07 Mar 2003 22:05:32 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: unwritten extents vs. fragmentation Date: Fri, 07 Mar 2003 14:05:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Mar 2003 22:05:33.0073 (UTC) FILETIME=[AC6CD810:01C2E4F5] X-archive-position: 3122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1888 Lines: 45 By preallocation are you referring to an ioctl after opening a file with XFS_IOC_RESVSP64? If so, does this only have an effect with unwritten=1? Does using the XFS_IOC_RESVSP64 ioctl guarantee contiguous extents when the file is written, or at least make more of an effort to ensure contiguous extent allocation? As you may remember from some of my previous emails, my goal is to have each file written as contiguous as possible and have each consecutive file as close to the previous file as possible. I have been experimenting with the realtime subvolume (due to the limited documentation speaking of reduced fragmentation), but I have not had much success so far. Thanks. Rick >From: Steve Lord >To: Rick Smith >CC: linux-xfs@oss.sgi.com >Subject: Re: unwritten extents vs. fragmentation >Date: 07 Mar 2003 15:32:54 -0600 > >On Fri, 2003-03-07 at 15:26, Rick Smith wrote: > > A couple questions. Does enabling unwritten extent flagging in XFS > > ultimately reduce filesystem fragmentation? What is the downside of >enabling > > unwritten extents other than slower write performance? Thanks. > >It should make no difference to physical fragmentation, and in the >normal I/O path unwritten extents should not be used. They only come >into play with space preallocation. In this case they will slow >down I/O somewhat, but provide more security in that you cannot >use unwritten extents to read old data. This is why the prealloc >calls on -d unwritten=0 filesystems are restricted to root. > >Steve > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Fri Mar 7 14:12:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 14:12:05 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27MC0q9019229 for ; Fri, 7 Mar 2003 14:12:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27MMXkq003107 for ; Fri, 7 Mar 2003 16:22:33 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA51513; Fri, 7 Mar 2003 16:11:51 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27MBrwX24985840; Fri, 7 Mar 2003 16:11:53 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27MBrx25054; Fri, 7 Mar 2003 16:11:53 -0600 Subject: Re: unwritten extents vs. fragmentation From: Steve Lord To: Rick Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047075112.6402.64.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 16:11:52 -0600 X-archive-position: 3123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2492 Lines: 59 On Fri, 2003-03-07 at 16:05, Rick Smith wrote: > By preallocation are you referring to an ioctl after opening a file > with XFS_IOC_RESVSP64? If so, does this only have an effect with > unwritten=1? > Does using the XFS_IOC_RESVSP64 ioctl guarantee contiguous extents when > the file is written, or at least make more of an effort to ensure contiguous > extent allocation? As you may remember from some of my previous emails, my > goal is to have each file written as contiguous as possible and have each > consecutive file as close to the previous file as possible. I have been > experimenting with the realtime subvolume (due to the limited documentation > speaking of reduced fragmentation), but I have not had much success so far. > Thanks. They do not guarantee continuous space, but they go to the allocator and ask for it all in one go. If it is available, you will get continuous space. I did not realize you had control over the app writing the data. The calls are always available, but with unwritten extent support off, they are restricted to root. Steve > > Rick > > >From: Steve Lord > >To: Rick Smith > >CC: linux-xfs@oss.sgi.com > >Subject: Re: unwritten extents vs. fragmentation > >Date: 07 Mar 2003 15:32:54 -0600 > > > >On Fri, 2003-03-07 at 15:26, Rick Smith wrote: > > > A couple questions. Does enabling unwritten extent flagging in XFS > > > ultimately reduce filesystem fragmentation? What is the downside of > >enabling > > > unwritten extents other than slower write performance? Thanks. > > > >It should make no difference to physical fragmentation, and in the > >normal I/O path unwritten extents should not be used. They only come > >into play with space preallocation. In this case they will slow > >down I/O somewhat, but provide more security in that you cannot > >use unwritten extents to read old data. This is why the prealloc > >calls on -d unwritten=0 filesystems are restricted to root. > > > >Steve > > > >-- > > > >Steve Lord voice: +1-651-683-3511 > >Principal Engineer, Filesystem Software email: lord@sgi.com > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 14:48:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 14:48:58 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Mmnq9021388 for ; Fri, 7 Mar 2003 14:48:50 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h27LdnY2006934; Fri, 7 Mar 2003 13:39:49 -0800 From: "l.a walsh" To: "'Eric Sandeen'" Cc: Subject: RE: Just some odd questions out of the blue... Date: Fri, 7 Mar 2003 13:39:49 -0800 Message-ID: <000001c2e4f2$14753780$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 3124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 3901 Lines: 96 > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eric Sandeen > Sent: Thu, Mar 06, 2003 6:00p > To: l.a walsh > Cc: linux-xfs@oss.sgi.com > Subject: Re: Just some odd questions out of the blue... > > > On Thu, 6 Mar 2003, l.a walsh wrote: > > > So lets say you had 2 disks...would it make sense to put the log > > of disk1 on disk2 and the log of disk2 on disk1? This would be > > Yes, external logs are available for this reason. > > Your cross-log scenario would probably only help if you were > really only > writing to 1 fs at a time. --- Yes...but say you have 1 disk setup with system and home dir where home dir is mainly docs and email, and second disk is setup mainly to do builds on.... > > Second question ... suppose one disk was faster than the other -- > > or one was a sda and the other hda. How much metadata is written > > compared to file data, i.e. is there some average ratio or range? > > You can look at the stats with the xfs_stats.pl script in cvs. > It really depends on the nature of your workload. ---- CVS again...everything is CVS...seems like every piece of software I'm interested in I've got to pull down the whole bloomin CVS tree...grumble. I don't suppose such scripts could be put into xfsprogs or xfsprogs-devel? (not right this second...but just in general)... > > On the assumption that metadata is smaller, seem like one could use > > a slower log disk for a primary work disk, and the slower log disk > > is mostly archival things that aren't written alot, but more read > > alot -- like mp3's, or CD images....things where the slower > read isn't > > going to be a big problem. > > True, for reads the log speed isn't critical, but for writes again > it will depend on your workload. --- Yeah, if I think of builds / mail-read/browse as separate workloads that may overlap, but mail-read/browsing isn't usually that disk intensive...compared to a parallel build. > > When writing to disks with a cache, does XFS force any flushes (like > > on log data?) Seem like even if you had a slower disk but an 8Mb > > cache you could keep up with a fairly good write speed on the faster > > disk. > > Which is great until you crash, if the cached data is lost... --- Well...xfs's delayed writes are exactly this type of operation: grouping writes in hopes of decreasing fragmentation. If your system is stable and stays up for many days except for planned reboots, and you're on UPS, one might trade off speed for risk. On the other hand, if you are testing a new kernel or a new patch, you might want to disable some of those features -- it's like syslog, normally many log messages are written asynchronously, but if I'm expecting trouble, I'll change them to synchronous and mount disks as synchronous, though drive caching is usually ok unless I'm also expecting a power outage :-). > I don't think xfs explicitly does any IDE cache flushing. > > > But here's another Q...if you don't flush the on disk cache after > > a log write, then it is 'granted' that the potential for metadata > > loss is at least the size of the on-disk cache. That could beg > > the question -- would it be of any benefit to write a pseudo-block > > device that lives on top of a disk that just does read-write > > caching -- maybe it lives with a 64Mb Buffer and attempts to use > > geometry knowledge of the disk to optimize head motion, whatever. > > Ick. :) I think the drive mfgr is the only one who has the > knowledge --- Hmm....I thought that info was available for some drives in scsiinfo, though for IDE drives the best you could do would be to section up the disk by "logical track", assuming that a logical track would normally map to a group physical sectors that are physically (barring defect management) located near each other, though that is an assumption, admittedly. -l From owner-linux-xfs@oss.sgi.com Fri Mar 7 17:49:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 17:49:33 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h281nPq9027586 for ; Fri, 7 Mar 2003 17:49:26 -0800 Received: from [209.96.189.100] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18rTSl-000L7j-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 20:49:24 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h281Jjr14337 for ; Fri, 7 Mar 2003 20:19:46 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h281JjUY003810 for ; Fri, 7 Mar 2003 20:19:45 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h281JjnB003809 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 20:19:45 -0500 Date: Fri, 7 Mar 2003 20:19:45 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308011942.GH1102@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 3125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shannon@widomaker.com Precedence: bulk X-list: linux-xfs Content-Length: 1076 Lines: 28 On Fri, Mar 07, 2003 at 07:55:32AM -0600, Eric Sandeen wrote: > I think it's important to remember that XFS has been in use for -many- > years on irix, on everything from personal desktops to huge servers > with filesystems on the order of tens of terabytes. While I'm > sure that usage patterns will affect the life of any device, I don't think > that this has been a problem in general. I think this is mostly a matter of IDE disks often not being very high quality. So far, I've not had SCSI disks which died show a particular excessive defect pattern in places like the superblock, swap spaces, and other high-use areas. Of course, I usually don't look. I _have_ seen it on IDE. > (And, I can think of other disk usages patterns which could result in > disproportional use of one area of a disk - /var/log partitions, for > example). I would imagine that programs which access raw partitions would have usage patterns which would hit certain areas very hard in comparison to others. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 17:49:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 17:49:33 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h281nQq9027589 for ; Fri, 7 Mar 2003 17:49:27 -0800 Received: from [209.96.189.100] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18rTSn-000L7j-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 20:49:26 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h281Emr13833 for ; Fri, 7 Mar 2003 20:14:48 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h281EiUY003537 for ; Fri, 7 Mar 2003 20:14:44 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h281EdmB003536 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 20:14:39 -0500 Date: Fri, 7 Mar 2003 20:14:39 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308011435.GG1102@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046992493.1388.235.camel@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046992493.1388.235.camel@averell> User-Agent: Mutt/1.4i X-archive-position: 3125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shannon@widomaker.com Precedence: bulk X-list: linux-xfs Content-Length: 1042 Lines: 25 On Fri, Mar 07, 2003 at 12:14:53AM +0100, Andi Kleen wrote: > It was long suspected that journaling FS are bad for cheap IDE disks, > but you're probably the first to really verify it using an IDE analyzer. > There were also some informal experiences on that collected by the > reiserfs people. Thanks for verify this. I've thought about this too, as I once found damage in superblocks even on other drives, across about 5 different IDE drives that had "gone bad". I found error patterns, and it appeard to me it was occuring in superblocks and in one case, a journal. Does this mean that these areas are also wearing out even good disks, just not as fast? I know over the last 10 years, I've replaced IDE drives at a rate several times higher than SCSI drives, even for "good" IDE drives. They don't seem to last very well. Seems like the high-end Seagates and IBMs aren't too bad so far, but I've not run the IDE versions long enough to see problems yet. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Sat Mar 8 06:31:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 06:31:12 -0800 (PST) Received: from smtp.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28EV3q9006048 for ; Sat, 8 Mar 2003 06:31:04 -0800 Received: from apal-192.ii.uib.no ([129.177.192.27] helo=apal.ii.uib.no) by smtp.ii.uib.no with esmtp (Exim 4.12) id 18re6Z-0000xs-00; Sat, 08 Mar 2003 14:11:11 +0100 Received: (from janfrode@localhost) by apal.ii.uib.no (8.11.6+Sun/8.11.6) id h28DBBp20999; Sat, 8 Mar 2003 14:11:11 +0100 (MET) Date: Sat, 8 Mar 2003 14:11:10 +0100 From: Jan-Frode Myklebust To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: suppressing syncs on spools Message-ID: <20030308141110.B19567@ii.uib.no> References: <1047052002.3e68bee241784@apollo.berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1047052002.3e68bee241784@apollo.berdmann.de>; from be@berdmann.de on Fri, Mar 07, 2003 at 04:46:42PM +0100 X-Spam-Score: -8.9 (--------) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18re6Z-0000xs-00*PyKkwmX7oEM* X-archive-position: 3126 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.no Precedence: bulk X-list: linux-xfs Content-Length: 726 Lines: 22 On Fri, Mar 07, 2003 at 04:46:42PM +0100, Bernhard Erdmann wrote: > > for a spool/scratch filesystem I'm only interested in speed. Disk I/O > should be as minimal as possible. Files will be deleted some 1/10 sec or > some secs later. It won't hurt if files are lost if the box crashes. > This filesystem can even be mkfs'd at system boot. > > Just speed, like a ram disk, but I don't want to spend 1-2 GB to a ram disk. Have you considered tmpfs? tmpfs can live in both ram and disk (swap). Read linux/Documentation/filesystems/tmpfs.txt. > > Are there mount options or mkfs.xfs options which can help to reduce > disk I/O? Don't know of any, except maybe putting the log on a ramdisk? And of course 'noatime'. -jf From owner-linux-xfs@oss.sgi.com Sat Mar 8 06:54:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 06:54:30 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28Eriq9006593 for ; Sat, 8 Mar 2003 06:54:25 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h28ErgZr018269 for ; Sat, 8 Mar 2003 15:53:42 +0100 Received: (qmail 13534 invoked from network); 8 Mar 2003 15:53:41 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 8 Mar 2003 15:53:41 +0100 Date: Sat, 8 Mar 2003 15:53:41 +0100 From: Christian Guggenberger To: "l.a walsh" Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: Just some odd questions out of the blue... Message-ID: <20030308155341.A5088@pc9391.uni-regensburg.de> References: <000001c2e4f2$14753780$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <000001c2e4f2$14753780$1403a8c0@sc.tlinx.org>; from xfs@tlinx.org on Fri, Mar 07, 2003 at 22:39:49 +0100 X-Mailer: Balsa 1.2.4 X-archive-position: 3127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1717 Lines: 47 On 07.03.2003 22:39 l.a walsh wrote: > > > -----Original Message----- > > From: linux-xfs-bounce@oss.sgi.com > > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eric Sandeen > > Sent: Thu, Mar 06, 2003 6:00p > > To: l.a walsh > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: Just some odd questions out of the blue... > > > > > > On Thu, 6 Mar 2003, l.a walsh wrote: > > > > > So lets say you had 2 disks...would it make sense to put the log > > > of disk1 on disk2 and the log of disk2 on disk1? This would be > > > > Yes, external logs are available for this reason. > > > > Your cross-log scenario would probably only help if you were > > really only > > writing to 1 fs at a time. > --- > Yes...but say you have 1 disk setup with system and home > dir where home dir is mainly docs and email, and second disk is > setup mainly to do builds on.... > > > > Second question ... suppose one disk was faster than the other -- > > > or one was a sda and the other hda. How much metadata is written > > > compared to file data, i.e. is there some average ratio or range? > > > > You can look at the stats with the xfs_stats.pl script in cvs. > > It really depends on the nature of your workload. > ---- > CVS again...everything is CVS...seems like every piece of > software I'm interested in I've got to pull down the whole bloomin > CVS tree...grumble. I don't suppose such scripts could be put into > xfsprogs or xfsprogs-devel? (not right this second...but just in > general)... > You probably want to browse the cvs web-tree, and download the script you are looking for.... There's no need for a full cvs-checkout, I think. http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsmisc/ Christian From owner-linux-xfs@oss.sgi.com Sat Mar 8 07:08:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 07:08:57 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28F8Bq9007167 for ; Sat, 8 Mar 2003 07:08:52 -0800 Received: from wsmichel (titanio.k8.com.br [200.185.109.31]) (authenticated (0 bits)) by silver.digirati.com.br (8.11.6/8.11.6) with ESMTP id h28F89C19020 for ; Sat, 8 Mar 2003 12:08:09 -0300 Message-ID: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> From: "Michel Machado" To: Subject: Re: LBA to File? Date: Sat, 8 Mar 2003 12:08:37 -0300 Organization: Digirati MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 3128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Content-Length: 107 Lines: 7 Dears, How do I can to get the defect list of a IDE or/and SCSI disk on Linux? [ ]'s Michel Machado From owner-linux-xfs@oss.sgi.com Sat Mar 8 13:37:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 13:38:01 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28LbAq9012113 for ; Sat, 8 Mar 2003 13:37:51 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 64FFC1833FF7; Sat, 8 Mar 2003 13:37:08 -0800 (PST) Date: Sat, 8 Mar 2003 13:37:08 -0800 From: Chris Wedgwood To: Michel Machado Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308213708.GA17656@f00f.org> References: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3129 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 245 Lines: 11 On Sat, Mar 08, 2003 at 12:08:37PM -0300, Michel Machado wrote: > How do I can to get the defect list of a IDE or/and SCSI disk on > Linux? for scsi for 'scsiinfo' ... i'm not sure if there is any standardized way to do this for IDE --cw From owner-linux-xfs@oss.sgi.com Sat Mar 8 14:53:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 14:53:37 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e12a.dsl.mediaWays.net [213.20.225.42]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28Mqoq9012891 for ; Sat, 8 Mar 2003 14:53:34 -0800 Received: from ente.berdmann.de ([192.168.1.6] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18rnBM-0001xj-00; Sat, 08 Mar 2003 23:52:44 +0100 Message-ID: <3E6A743C.3080603@berdmann.de> Date: Sat, 08 Mar 2003 23:52:44 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4a) Gecko/20030308 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Jan-Frode Myklebust CC: linux-xfs@oss.sgi.com Subject: Re: suppressing syncs on spools References: <1047052002.3e68bee241784@apollo.berdmann.de> <20030308141110.B19567@ii.uib.no> In-Reply-To: <20030308141110.B19567@ii.uib.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3130 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 391 Lines: 12 > Have you considered tmpfs? tmpfs can live in both ram and disk (swap). > Read linux/Documentation/filesystems/tmpfs.txt. I already read the article on IBM developernetworks about it in the meanwhile. Seems it can do what I want when tmpfs' size is limited to say 500 MB. > Don't know of any, except maybe putting the log on a ramdisk? And of > course 'noatime'. Thanks for the hint! From owner-linux-xfs@oss.sgi.com Sat Mar 8 18:33:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 18:33:19 -0800 (PST) Received: from sparrow.stearns.org (101.24.177.216.inaddr.g4.Net [216.177.24.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h292XAq9014477; Sat, 8 Mar 2003 18:33:11 -0800 Received: from localhost (localhost [127.0.0.1]) by sparrow.stearns.org (8.11.6/8.11.6) with ESMTP id h292X1X19395; Sat, 8 Mar 2003 21:33:02 -0500 Date: Sat, 8 Mar 2003 21:33:01 -0500 (EST) From: William Stearns X-X-Sender: wstearns@sparrow Reply-To: William Stearns To: owner-xfs@oss.sgi.com, , cc: William Stearns , ML-uml-devel Subject: XFS in 2.5.64-bk3, compile problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wstearns@pobox.com Precedence: bulk X-list: linux-xfs Content-Length: 2666 Lines: 56 Good day, all, My _sincere_ apologies if this a known issue; I haven't followed xfs development. In compiling a 2.5.64-bk3 uml kernel, I found this error when xfs was compiled in: xfs: gcc -Wp,-MD,fs/xfs/.xfs_mount.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -U__i386__ -Ui386 -g -D__arch_um__ -DSUBARCH=\"i386\" -D_LARGEFILE64_SOURCE -Iarch/um/include -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask -I/usr/src/uml-linux/linux-2.5.64-bk3-63um1/arch/um/kernel/tt/include -I/usr/src/uml-linux/linux-2.5.64-bk3-63um1/arch/um/kernel/skas/include -nostdinc -iwithprefix include -Ifs/xfs -funsigned-char -DKBUILD_BASENAME=xfs_mount -DKBUILD_MODNAME=xfs -c -o fs/xfs/xfs_mount.o fs/xfs/xfs_mount.c fs/xfs/xfs_mount.c: In function `xfs_initialize_perag': fs/xfs/xfs_mount.c:339: Unrecognizable insn: (insn/i 164 594 597 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("fs/xfs/linux/xfs_linux.h") 255)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("fs/xfs/linux/xfs_linux.h") 255)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (insn_list 163 (nil)) (nil)) fs/xfs/xfs_mount.c:339: confused by earlier errors, bailing out make[2]: *** [fs/xfs/xfs_mount.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 The compile options used are almost identical to http://www.stearns.org/uml/config-2.5.64-bk3-63um1-3 , except - of course: CONFIG_XFS_FS=y Compiler is gcc-c++-2.96-113, gcc-2.96-113, base system is Redhat 7.3. If there are more details I can provide, please let me know. Again, I'm sorry if this is a known problem. Cheers, - Bill --------------------------------------------------------------------------- "Nothing scares me. Except Pepsi. That stuff will keep me awake at night." (Courtesy of Allaria on Slashdot) -------------------------------------------------------------------------- William Stearns (wstearns@pobox.com). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org Linux articles at: http://www.opensourcedigest.com -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Mar 9 02:42:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 02:42:26 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29AgHq9020837 for ; Sun, 9 Mar 2003 02:42:19 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h29AgFX13505; Sun, 9 Mar 2003 11:42:15 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h29AgE732731; Sun, 9 Mar 2003 11:42:14 +0100 Date: Sun, 9 Mar 2003 11:42:14 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: Michel Machado , Subject: Re: LBA to File? In-Reply-To: <20030308213708.GA17656@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 653 Lines: 20 On Sat, 8 Mar 2003, Chris Wedgwood wrote: > On Sat, Mar 08, 2003 at 12:08:37PM -0300, Michel Machado wrote: > > How do I can to get the defect list of a IDE or/and SCSI disk on > > Linux? > for scsi for 'scsiinfo' ... i'm not sure if there is any standardized > way to do this for IDE S.M.A.R.T. is supposed to provide this kind of info for IDE. See: http://sourceforge.net/projects/smartmontools/ -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Sun Mar 9 03:05:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 03:05:23 -0800 (PST) Received: from jello277.jellocom.de (root@jello277.jellocom.de [217.17.194.152]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29B5Gq9021400 for ; Sun, 9 Mar 2003 03:05:18 -0800 Received: from cobonote.intranet.cobonet.de (pD903268F.dip0.t-ipconnect.de [217.3.38.143]) (authenticated bits=0) by jello277.jellocom.de (8.12.8/8.12.1) with ESMTP id h29B5AWb030120; Sun, 9 Mar 2003 12:05:12 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Thomas Bittermann To: juergen.sauer@automatix.de Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Sun, 9 Mar 2003 12:02:50 +0100 User-Agent: KMail/1.4.3 References: <200303051048.54271.juergen.sauer@automatix.de> <200303052309.51984.t.bittermann@online.de> <200303071156.29730.juergen.sauer@automatix.de> In-Reply-To: <200303071156.29730.juergen.sauer@automatix.de> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <200303091202.50542.pufferbrater@cobonet.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h29B5Jq9021401 X-archive-position: 3133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pufferbrater@cobonet.de Precedence: bulk X-list: linux-xfs Content-Length: 323 Lines: 11 [...] > Which CVS Source do you use ? I'm using CVSROOT=':pserver:cvs@oss.sgi.com:/cvs', but when I started off, (2.4.21-pre4-ac1 and CVS from feb) there was quite a lot of merging necessary. From then I'm doing "cvs diff" and get all the XFS related changes this way. I can send you my patch if you like. cheers Thomas From owner-linux-xfs@oss.sgi.com Sun Mar 9 06:18:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 06:18:48 -0800 (PST) Received: from fruit.eu.org (qmailr@c3607d26.cable.wanadoo.nl [195.96.125.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29EIYq9027961 for ; Sun, 9 Mar 2003 06:18:38 -0800 Received: (qmail 6551 invoked by uid 500); 9 Mar 2003 14:18:32 -0000 Date: Sun, 9 Mar 2003 15:18:32 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem Message-ID: <20030309141832.GT13846@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 In-Reply-To: X-oi: oi User-Agent: Mutt/1.5.3i X-archive-position: 3134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs Content-Length: 731 Lines: 23 On 2003-03-08 21:33:01-0500, William Stearns wrote: > Good day, all, > My _sincere_ apologies if this a known issue; I haven't followed > xfs development. > In compiling a 2.5.64-bk3 uml kernel, I found this error when xfs > was compiled in: > [snip] > fs/xfs/xfs_mount.c:339: Unrecognizable insn: [snip] > Compiler is gcc-c++-2.96-113, gcc-2.96-113, base system is Redhat 7.3. The problem is in gcc, not in the kernel. Red Hat ships with a broken, unofficial beta gcc. Please replace that gcc with gcc 3.2.2 (and while you're at it, replace Red Hat with a competent distribution that provides a working compiler). You'll find that your kernel compiles fine. It does here ;) Cheers, -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Sun Mar 9 07:54:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 07:55:04 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29FsFq9030506 for ; Sun, 9 Mar 2003 07:54:56 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id h29FtA56023482 for ; Sun, 9 Mar 2003 16:55:10 +0100 Message-ID: <3E6B63DE.9040308@stesmi.com> Date: Sun, 09 Mar 2003 16:55:10 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem References: <20030309141832.GT13846@fruit.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 3135 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 14 Hi. > The problem is in gcc, not in the kernel. Red Hat ships with a broken, > unofficial beta gcc. Please replace that gcc with gcc 3.2.2 (and while > you're at it, replace Red Hat with a competent distribution that provides > a working compiler). You'll find that your kernel compiles fine. > It does here ;) I'm sorry, I missed the sign around your neck saying "Troll". You could put that in your sig for instance so that it's readily apparent. // Stefan From owner-linux-xfs@oss.sgi.com Sun Mar 9 08:24:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 08:24:40 -0800 (PST) Received: from fruit.eu.org (qmailr@c3607d26.cable.wanadoo.nl [195.96.125.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29GNtq9032100 for ; Sun, 9 Mar 2003 08:24:36 -0800 Received: (qmail 6728 invoked by uid 500); 9 Mar 2003 16:23:55 -0000 Date: Sun, 9 Mar 2003 17:23:55 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem Message-ID: <20030309162355.GU13846@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030309141832.GT13846@fruit.eu.org> <3E6B63DE.9040308@stesmi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E6B63DE.9040308@stesmi.com> X-oi: oi User-Agent: Mutt/1.5.3i X-archive-position: 3136 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs Content-Length: 735 Lines: 19 On 2003-03-09 16:55:10+0100, Stefan Smietanowski wrote: > I'm sorry, I missed the sign around your neck saying "Troll". > > You could put that in your sig for instance so that it's readily apparent. Funny, I don't see a useful reply to his question from you on the list. Perhaps it got lost somewhere? Pardon me for being harsh towards Red Hat for shipping a broken compiler, but if you have such a problem with the tone of my reply, may I kindly suggest that you answer such questions about the infamous gcc 2.96 "release" yourself next time? If you feel a need for additional argumentation, please follow up in private; discussions like this are a waste of mailing list bandwidth. Thanks, -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Sun Mar 9 12:45:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 12:45:31 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29KjLq9002904 for ; Sun, 9 Mar 2003 12:45:23 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id C71FF1834559; Sun, 9 Mar 2003 12:45:21 -0800 (PST) Date: Sun, 9 Mar 2003 12:45:21 -0800 From: Chris Wedgwood To: Bogdan Costescu Cc: Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030309204521.GA22210@f00f.org> References: <20030308213708.GA17656@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3137 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 11 On Sun, Mar 09, 2003 at 11:42:14AM +0100, Bogdan Costescu wrote: > S.M.A.R.T. is supposed to provide this kind of info for IDE. See: > > http://sourceforge.net/projects/smartmontools/ Alas, it seems it doesnt work for lots of (cheap) drives... --cw From owner-linux-xfs@oss.sgi.com Sun Mar 9 13:19:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 13:19:32 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29LJJq9003654 for ; Sun, 9 Mar 2003 13:19:21 -0800 Received: (qmail 15467 invoked by uid 777); 9 Mar 2003 21:19:24 -0000 Date: Sun, 9 Mar 2003 22:19:24 +0100 From: Karol Kozimor To: Chris Wedgwood Cc: Bogdan Costescu , Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030309211924.GA31809@hell.org.pl> Mail-Followup-To: Chris Wedgwood , Bogdan Costescu , Michel Machado , linux-xfs@oss.sgi.com References: <20030308213708.GA17656@f00f.org> <20030309204521.GA22210@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20030309204521.GA22210@f00f.org> User-Agent: Mutt/1.4i X-archive-position: 3138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 412 Lines: 13 Thus wrote Chris Wedgwood: > > S.M.A.R.T. is supposed to provide this kind of info for IDE. See: > > http://sourceforge.net/projects/smartmontools/ > Alas, it seems it doesnt work for lots of (cheap) drives... Seriously? Are there any recent drives that don't support S.M.A.R.T? Perhaps it just hasn't been enabled (either in BIOS, or by smartctl)? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Sun Mar 9 13:30:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 13:30:43 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29LULq9004162 for ; Sun, 9 Mar 2003 13:30:22 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 57E181834558; Sun, 9 Mar 2003 13:30:21 -0800 (PST) Date: Sun, 9 Mar 2003 13:30:21 -0800 From: Chris Wedgwood To: Bogdan Costescu , Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030309213021.GA22398@f00f.org> References: <20030308213708.GA17656@f00f.org> <20030309204521.GA22210@f00f.org> <20030309211924.GA31809@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030309211924.GA31809@hell.org.pl> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3139 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 384 Lines: 15 On Sun, Mar 09, 2003 at 10:19:24PM +0100, Karol Kozimor wrote: > Seriously? Are there any recent drives that don't support S.M.A.R.T? I've not checked super recent drives, but some about a year or so old do support SMART but it seems in a limitied (ie. broken) capacity. > Perhaps it just hasn't been enabled (either in BIOS, or by > smartctl)? Nope, just cheap drives. --cw From owner-linux-xfs@oss.sgi.com Mon Mar 10 02:02:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 02:02:11 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AA1Kq9015805 for ; Mon, 10 Mar 2003 02:02:05 -0800 Received: from [209.96.179.160] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18ro47-00055L-00 for linux-xfs@oss.sgi.com; Sat, 08 Mar 2003 18:49:19 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h28NA2r14147 for ; Sat, 8 Mar 2003 18:10:02 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h28N9xUY007886 for ; Sat, 8 Mar 2003 18:09:59 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h28N9sAe007885 for linux-xfs@oss.sgi.com; Sat, 8 Mar 2003 18:09:54 -0500 Date: Sat, 8 Mar 2003 18:09:54 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308230950.GA7882@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> <20030308213708.GA17656@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030308213708.GA17656@f00f.org> User-Agent: Mutt/1.4i X-archive-position: 3140 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shannon@widomaker.com Precedence: bulk X-list: linux-xfs Content-Length: 486 Lines: 15 On Sat, Mar 08, 2003 at 01:37:08PM -0800, Chris Wedgwood wrote: > On Sat, Mar 08, 2003 at 12:08:37PM -0300, Michel Machado wrote: > > > How do I can to get the defect list of a IDE or/and SCSI disk on > > Linux? > > for scsi for 'scsiinfo' ... i'm not sure if there is any standardized > way to do this for IDE You can get the S.M.A.R.T. tools to query SCSI and IDE drives, to varying degrees of success. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Mon Mar 10 02:49:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 02:49:43 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AAnXq9019161 for ; Mon, 10 Mar 2003 02:49:35 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h2AAnWX07554; Mon, 10 Mar 2003 11:49:32 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h2AAnVZ12033; Mon, 10 Mar 2003 11:49:31 +0100 Date: Mon, 10 Mar 2003 11:49:30 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: Michel Machado , Subject: Re: LBA to File? In-Reply-To: <20030309213021.GA22398@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3141 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1198 Lines: 26 On Sun, 9 Mar 2003, Chris Wedgwood wrote: > I've not checked super recent drives, but some about a year or so old > do support SMART but it seems in a limitied (ie. broken) capacity. S.M.A.R.T. is supposed to be an industry standard. Now, disk manufacturers can on one hand implement only a part of the parameters or introduce extensions to this standard; some other times they might have their own interpretation of what a parameter should mean. My impression is that it doesn't depend on whether they are cheap drives or not, but more on the manufacturer - f.e. I got almost the same parameters for IBM drives from different drive families of various ages (last 2 years or so). IDE controllers cards or mainboards have had S.M.A.R.T. related functions for several years - I have Intel 440BX based mainboards from 1998 that offer the option of enabling it and give a warning message if something is wrong with the disk at boot time. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Mon Mar 10 04:54:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 04:54:15 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ACrPq9022242 for ; Mon, 10 Mar 2003 04:54:06 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id h2ACsR56029523 for ; Mon, 10 Mar 2003 13:54:27 +0100 Message-ID: <3E6C8B03.1060603@stesmi.com> Date: Mon, 10 Mar 2003 13:54:27 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem References: <20030309141832.GT13846@fruit.eu.org> <3E6B63DE.9040308@stesmi.com> <20030309162355.GU13846@fruit.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 3142 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1332 Lines: 29 Wessel Dankers wrote: > On 2003-03-09 16:55:10+0100, Stefan Smietanowski wrote: > >>I'm sorry, I missed the sign around your neck saying "Troll". >> >>You could put that in your sig for instance so that it's readily apparent. > > > Funny, I don't see a useful reply to his question from you on the list. > Perhaps it got lost somewhere? Pardon me for being harsh towards Red Hat > for shipping a broken compiler, but if you have such a problem with the > tone of my reply, may I kindly suggest that you answer such questions about > the infamous gcc 2.96 "release" yourself next time? > > If you feel a need for additional argumentation, please follow up in > private; discussions like this are a waste of mailing list bandwidth. 2.96 was a beta compiler, granted. However RedHat went far to make sure it produced code that was production worthy. The first release didn't have a good compiler (7.0) but subsequent compilers were. I'm sick and tired of people racking down on RedHat distributions and compilers all the time. Any compiler has bugs. It is not anything special (as you seem to be believe) with 2.96. Also, a more useful reply would perhaps be "Switch to RedHat 8.0, it's got GCC 3.2" if in fact the bug is caused by a bug in the compiler, but alas, you rack down on RedHat instead. That is trolling. // Stefan From owner-linux-xfs@oss.sgi.com Mon Mar 10 05:07:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 05:07:49 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AD6wq9022856 for ; Mon, 10 Mar 2003 05:07:38 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id EE2251830676; Mon, 10 Mar 2003 05:06:57 -0800 (PST) Date: Mon, 10 Mar 2003 05:06:57 -0800 From: Chris Wedgwood To: Bogdan Costescu Cc: Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030310130657.GA25467@f00f.org> References: <20030309213021.GA22398@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1331 Lines: 33 On Mon, Mar 10, 2003 at 11:49:30AM +0100, Bogdan Costescu wrote: > S.M.A.R.T. is supposed to be an industry standard. Now, disk > manufacturers can on one hand implement only a part of the > parameters or introduce extensions to this standard; some other > times they might have their own interpretation of what a parameter > should mean. There a vendor-specific and vendor-neutral things you can poll. Mostly the interesting ones are vendor-specific and I've not found a source for information about these. > My impression is that it doesn't depend on whether they are cheap > drives or not, but more on the manufacturer - f.e. I got almost the > same parameters for IBM drives from different drive families of > various ages (last 2 years or so). I get different values for almost identical Maxtor drives on the same age.... > IDE controllers cards or mainboards have had S.M.A.R.T. related > functions for several years - I have Intel 440BX based mainboards > from 1998 that offer the option of enabling it and give a warning > message if something is wrong with the disk at boot time. I'm not 100% sure about this, but I don't think controllers and/or mainboards need to know anything about SMART at all... presumably the BIOS knowledge here allows you to disable it in case the OS gets confused or something. --cw From owner-linux-xfs@oss.sgi.com Mon Mar 10 05:25:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 05:25:41 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ADPVq9024058 for ; Mon, 10 Mar 2003 05:25:33 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h2ADPUX11851; Mon, 10 Mar 2003 14:25:30 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h2ADPTO12815; Mon, 10 Mar 2003 14:25:29 +0100 Date: Mon, 10 Mar 2003 14:25:29 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: Bogdan Costescu , Michel Machado , Subject: SMART (was Re: LBA to File?) In-Reply-To: <20030310130657.GA25467@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3144 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1565 Lines: 36 On Mon, 10 Mar 2003, Chris Wedgwood wrote: > There a vendor-specific and vendor-neutral things you can poll. But that's the best you can get while online... Offline, I think that each manufacturer provides some diagnostic tool that can go and test each sector (and destroy any data that was there before :-)) and report if there are problems. 'badblocks' is also useful while offline, although it only reports the present situation and doesn't know about transparent remapping done by the drive firmware. > I'm not 100% sure about this, but I don't think controllers and/or > mainboards need to know anything about SMART at all... They need to know how to read and interpret a bunch of parameters which give the health status of the drive. If some warning value is triggered, you get when you boot some message like: Warning: Disk failure. Please backup and replace disk 1. Press any key to continue. (this is all from memory, so I might get it wrong). When BIOS does the checking it's also supposed to leave the drive with SMART enabled, so more sofisticated tools can read parameters and logs after the OS is loaded. I did however used safely (= no data loss) such drives for months, so it might be that because of some combination of BIOS and drive firmware the early warning was too early... -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Mon Mar 10 08:02:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 08:02:26 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AG2Fq9027855 for ; Mon, 10 Mar 2003 08:02:21 -0800 Received: (qmail 17708 invoked by uid 777); 10 Mar 2003 16:02:16 -0000 Date: Mon, 10 Mar 2003 17:02:16 +0100 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: Internal errors Message-ID: <20030310160216.GA4183@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 3145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 802 Lines: 19 Hello, Many thanks for the new code debugging the 990 error. I had these since I ever started *trying* to use 2.5.x, that is 2.5.59. Here's what I did: I patched vanilla 2.5.64 with linux-2.5.64-xfs-2003-03-09.patch.bz2, and rebooted the system. As usual, it barfed buring ldconfig state (libraries in /usr/lib). Got about 50 kB of logs. Then I did "ls -l /usr/lib", and got about another 50 kB. Then, as usual, I got the fs/buffer.c error during shutdown, with some xfs functions in call trace. The log is quite largish, so I put it here instead: http://hell.org.pl/~sziwan/xfs-errors My .config is at http://hell.org.pl/~sziwan/config , if it's of any relevance. Is it really so rare that nobody has encountered these errors except me? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Mon Mar 10 09:05:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 09:05:55 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AH5jq9005237 for ; Mon, 10 Mar 2003 09:05:47 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2AH5dnH014152 for ; Mon, 10 Mar 2003 09:05:40 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA81521 for ; Mon, 10 Mar 2003 11:05:39 -0600 (CST) Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2AH5dwX26857114 for ; Mon, 10 Mar 2003 11:05:39 -0600 (CST) From: Dean Roehrich Received: by chewtoy.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id LAA25491; Mon, 10 Mar 2003 11:05:38 -0600 (CST) Message-Id: <200303101705.LAA25491@chewtoy.americas.sgi.com> Date: Mon, 10 Mar 2003 11:05:38 -0600 (CST) To: linux-xfs@oss.sgi.com Subject: TAKE - fix invis I/O X-archive-position: 3146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 514 Lines: 16 Date: Mon Mar 10 09:02:33 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141339a linux/fs/xfs/linux/xfs_lrw.c - 1.179 - generic_file_read() and generic_file_write_nolock() will update linux inode timestamps. For Invis I/O we have to undo those timestamp updates. Also, in xfs_write, do the xfs_inode timestamp update _after_ the write, rather than before. From owner-linux-xfs@oss.sgi.com Mon Mar 10 10:21:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 10:21:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2AILEq9006485 for ; Mon, 10 Mar 2003 10:21:14 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2AILEWU006483 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 10:21:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2AILBqB006470 for ; Mon, 10 Mar 2003 10:21:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2AHloEl005915; Mon, 10 Mar 2003 09:47:50 -0800 Date: Mon, 10 Mar 2003 09:47:50 -0800 Message-Id: <200303101747.h2AHloEl005915@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 228] xfs_repair can't deal with small (agcount==1) filesystems X-Bugzilla-Reason: AssignedTo X-archive-position: 3147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 889 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=228 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From cattelan@thebarn.com 2003-03-10 09:47 ------- While 1 AG FSs are valid the lack of redundant info (i.e. no backup SuperBlocks) makes them a bit dangerous. While repair could try to do a some more processing it would require some effort. xfs_repair is currently going through some rewrites to fix some scaling issues, so it's possible to look into the reverse scaling as well. Marking this bug as a later. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 10 12:10:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 12:10:43 -0800 (PST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AK9uq9008405 for ; Mon, 10 Mar 2003 12:10:36 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id AEA471C0149C; Mon, 10 Mar 2003 15:09:55 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 7FF211C009E8; Mon, 10 Mar 2003 15:09:55 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Mar 2003 15:09:55 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Cc: "'nathans@snort.melbourne.sgi.com'" Subject: re: TAKE - pagebuf Date: Mon, 10 Mar 2003 15:09:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 1271 Lines: 46 When applying this patch from March 3rd, creating a file system, and then unmounting and remounting xfs filesystems gives me the following error: Mar 10 13:04:07 localhost kernel: XFS mounting filesystem lvm(58,1) Mar 10 13:04:07 localhost kernel: Filesystem "lvm(58,1)": Failed to initialize disk quotas. We're using the -o rw,nodev,noatime,quota mount options. Mounting without the quota option doesn't generate the error. Using a CVS take from March 6th does the same thing, but dumps a stack trace as well. Any ideas? Thanks, Erik Habbinga Hewlett Packard Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. Date: Mon Mar 3 18:17:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140809a linux/fs/xfs/pagebuf/page_buf.c - 1.100 - Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. linux/fs/xfs/pagebuf/page_buf.h - 1.59 linux/fs/xfs/linux/xfs_aops.c - 1.19 - Remove an unused parameter from pagebuf_lookup. From owner-linux-xfs@oss.sgi.com Mon Mar 10 14:48:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 14:48:52 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AMmiq9031092 for ; Mon, 10 Mar 2003 14:48:45 -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 h2AMmZnH005995 for ; Mon, 10 Mar 2003 14:48:36 -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 JAA27408; Tue, 11 Mar 2003 09:47:19 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA70982; Tue, 11 Mar 2003 09:47:19 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2AMijqM001555; Tue, 11 Mar 2003 09:44:45 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2AMiix6001553; Tue, 11 Mar 2003 09:44:44 +1100 Date: Tue, 11 Mar 2003 09:44:44 +1100 From: Nathan Scott To: "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - pagebuf Message-ID: <20030310224444.GA1470@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1943 Lines: 61 hi Erik, On Mon, Mar 10, 2003 at 03:09:47PM -0500, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > When applying this patch from March 3rd, creating a file system, and then > unmounting and remounting xfs filesystems gives me the following error: > > Mar 10 13:04:07 localhost kernel: XFS mounting filesystem lvm(58,1) > Mar 10 13:04:07 localhost kernel: Filesystem "lvm(58,1)": Failed to > initialize disk quotas. > > We're using the -o rw,nodev,noatime,quota mount options. Mounting without > the quota option doesn't generate the error. Using a CVS take from March > 6th does the same thing, but dumps a stack trace as well. > > Any ideas? > Hmm... not really. I just tried a mkfs & mount with those options and it worked correctly for me. A few suggestions - try adding a few printk's in xfs_qm_mount_quotas and friends, to pinpoint where the error is really coming from (there are several potential error sources in that routine). You might also want to try turning XFS debugging on, see if you trip an assert earlier on. Also what pagesize and blocksize are you using here? If you back this mod out (and just this mod), does it start working again? thanks. > > Remove an unused parameter from pagebuf_lookup. Ensure we don't mark > a page uptodate in the bsize==pgsize case when we didn't do IO to the > entire page. > > > Date: Mon Mar 3 18:17:57 PST 2003 > Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:140809a > linux/fs/xfs/pagebuf/page_buf.c - 1.100 > - Remove an unused parameter from pagebuf_lookup. Ensure we don't > mark > a page uptodate in the bsize==pgsize case when we didn't do IO to > the > entire page. > > linux/fs/xfs/pagebuf/page_buf.h - 1.59 > linux/fs/xfs/linux/xfs_aops.c - 1.19 > - Remove an unused parameter from pagebuf_lookup. > > > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 10 17:21:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 17:21:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B1LFq9000397 for ; Mon, 10 Mar 2003 17:21:15 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B1LFYW000395 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 17:21:15 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B1LCqB000381 for ; Mon, 10 Mar 2003 17:21:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B0wgDt032685; Mon, 10 Mar 2003 16:58:42 -0800 Date: Mon, 10 Mar 2003 16:58:42 -0800 Message-Id: <200303110058.h2B0wgDt032685@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 229] New: xfs_repair unable to repair system X-Bugzilla-Reason: AssignedTo X-archive-position: 3150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 7107 Lines: 481 http://oss.sgi.com/bugzilla/show_bug.cgi?id=229 Summary: xfs_repair unable to repair system Product: Linux XFS Version: Current Platform: All OS/Version: All Status: NEW Severity: critical Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: alde@alde.com If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20-xfs Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS Description of Problem: Using wget to mirror a website, certain invalid files were created. Some of these files are created with absurdly large filesizes. For example: # find . -size +500k -ls 64459932 8 -rw-r--r-- 1 alde alde 35184372094294 Aug 23 2002 . /www/adrianne/tn_ad12829.jpg This is just one of many. However this doesn't seem to the the big problem. The big problem is that xfs allows some files to be created with a / as the first character. # find . -size +500k -ls find: ./portrait//imi: No such file or directory # cd portrait # ls /imi # ls -l ls: /imi: No such file or directory And as you know, any file name starting with a / is considered a full pathname for the file. So, any type of rm -f ?imi or rm -f *imi or rm -f ???? still results in the / getting expanded and the shell looking for the file /imi. If I touch /imi, and try to remove /foo/portrait/\/imi, it will delete the root directory /imi. When running xfs_repair to fix this problem, I beleive it crashes due to both problems listed above. # xfs_repair /dev/hda4 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 entry "/." at block 0 offset 32 in directory inode 4327089 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 4327089 has illegal name "/.": no .. entry for directory 4327089 - agno = 2 - agno = 3 - agno = 4 entry "/." at block 0 offset 32 in directory inode 16970686 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 16970686 has illegal name "/.": no .. entry for directory 16970686 entry "/rs096am08" at block 2 offset 1824 in directory inode 17028818 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1824... entry at block 2 offset 1824 in directory inode 17028818 has illegal name "/rs096am08": invalid inode 18374686479671623679 clearing inode number in entry at offset 1824... entry at block 2 offset 1824 in directory inode 17028818 has illegal name "/rs096am08": - agno = 5 - agno = 6 entry "/." at block 0 offset 968 in directory inode 25279432 references invalid inode 18374686479671623679 clearing inode number in entry at offset 968... entry at block 0 offset 968 in directory inode 25279432 has illegal name "/.": no .. entry for directory 25279432 entry "/." at block 0 offset 32 in directory inode 25847335 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 25847335 has illegal name "/.": no .. entry for directory 25847335 - agno = 7 - agno = 8 entry "/." at block 0 offset 584 in directory inode 33798096 references invalid inode 18374686479671623679 clearing inode number in entry at offset 584... entry at block 0 offset 584 in directory inode 33798096 has illegal name "/.": no .. entry for directory 33798096 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 entry "/imi" at block 0 offset 288 in directory inode 68882319 references invalid inode 18374686479671623679 clearing inode number in entry at offset 288... entry at block 0 offset 288 in directory inode 68882319 has illegal name "/imi": - agno = 17 - agno = 18 - agno = 19 entry "/." at block 0 offset 584 in directory inode 80188330 references invalid inode 18374686479671623679 clearing inode number in entry at offset 584... entry at block 0 offset 584 in directory inode 80188330 has illegal name "/.": no .. entry for directory 80188330 - agno = 20 entry "/." at block 0 offset 32 in directory inode 86492409 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 86492409 has illegal name "/.": no .. entry for directory 86492409 - agno = 21 - agno = 22 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 no .. entry for directory 4327089 - agno = 2 - agno = 3 - agno = 4 no .. entry for directory 16970686 - agno = 5 - agno = 6 no .. entry for directory 25279432 no .. entry for directory 25847335 - agno = 7 - agno = 8 no .. entry for directory 33798096 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 no .. entry for directory 80188330 - agno = 20 no .. entry for directory 86492409 - agno = 21 - agno = 22 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 / ... fatal error -- malloc failed in longform_dir2_entry_check (1073741844 bytes) # How Reproducible: Anytime a file gets a corrupted filesize & a file with a / as its first character is created. A website with alot of php calls with /'s in the file name. Steps to Reproduce: 1. wget -r http://www.aol.com 2. wget -r http://www.php.net 3. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 10 18:26:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 18:26:52 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2B2Qmq9003231 for ; Mon, 10 Mar 2003 18:26:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2B2QgnH020012 for ; Mon, 10 Mar 2003 18:26:43 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2B2PP7L1339487 for ; Tue, 11 Mar 2003 13:25:25 +1100 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2B2PODN924612 for linux-xfs@oss.sgi.com; Tue, 11 Mar 2003 13:25:24 +1100 (EST) Date: Tue, 11 Mar 2003 13:25:24 +1100 (EST) From: Timothy Shimmin Message-Id: <200303110225.h2B2PODN924612@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - CREDITS update X-archive-position: 3151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 327 Lines: 14 update some Connex details Date: Mon Mar 10 18:23:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/tes/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141397a cmd/xfsprogs/doc/CREDITS - 1.12 - update John Trostel details and connex details From owner-linux-xfs@oss.sgi.com Mon Mar 10 20:21:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 20:21:23 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B4LHq9006573 for ; Mon, 10 Mar 2003 20:21:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B4LHmk006571 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 20:21:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B4LFqB006558 for ; Mon, 10 Mar 2003 20:21:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B3NvfS005922; Mon, 10 Mar 2003 19:23:57 -0800 Date: Mon, 10 Mar 2003 19:23:57 -0800 Message-Id: <200303110323.h2B3NvfS005922@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 229] xfs_repair unable to repair system X-Bugzilla-Reason: AssignedTo X-archive-position: 3152 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 356 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=229 ------- Additional Comments From lord@sgi.com 2003-03-10 19:23 ------- Can you report the wget command line you used? I have used wget on XFS, but without odd occurences like this. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 10 20:52:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 20:52:08 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2B4pPq9007207 for ; Mon, 10 Mar 2003 20:52:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2B4pI9n020190 for ; Mon, 10 Mar 2003 20:51:19 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2B4o17L1363938 for ; Tue, 11 Mar 2003 15:50:01 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2B4o1cX1363775 for linux-xfs@oss.sgi.com; Tue, 11 Mar 2003 15:50:01 +1100 (EST) Date: Tue, 11 Mar 2003 15:50:01 +1100 (EST) From: Nathan Scott Message-Id: <200303110450.h2B4o1cX1363775@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bhv code cleanup X-archive-position: 3153 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1023 Lines: 31 First stage of behavior code cleanup - removes a bunch of unused macros related to read/write locking the behavior list. Date: Mon Mar 10 20:37:23 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141401a linux/fs/xfs/xfsidbg.c - 1.214 linux/fs/xfs/xfs_dmapi.c - 1.89 linux/fs/xfs/xfs_dfrag.c - 1.36 linux/fs/xfs/linux/xfs_behavior.c - 1.16 linux/fs/xfs/linux/xfs_ioctl.c - 1.86 linux/fs/xfs/dmapi/dmapi_attr.c - 1.7 linux/fs/xfs/dmapi/dmapi_bulkattr.c - 1.7 linux/fs/xfs/dmapi/dmapi_config.c - 1.8 linux/fs/xfs/dmapi/dmapi_dmattr.c - 1.7 linux/fs/xfs/dmapi/dmapi_handle.c - 1.7 linux/fs/xfs/dmapi/dmapi_hole.c - 1.7 linux/fs/xfs/dmapi/dmapi_io.c - 1.7 linux/fs/xfs/dmapi/dmapi_region.c - 1.7 linux/fs/xfs/dmapi/dmapi_register.c - 1.21 linux/fs/xfs/dmapi/dmapi_right.c - 1.15 linux/fs/xfs/linux/xfs_vnode.h - 1.75 linux/fs/xfs/linux/xfs_vfs.h - 1.32 linux/fs/xfs/linux/xfs_behavior.h - 1.12 From owner-linux-xfs@oss.sgi.com Mon Mar 10 21:21:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 21:21:18 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B5LFq9007833 for ; Mon, 10 Mar 2003 21:21:15 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B5LF6W007831 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 21:21:15 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B5LDqB007818 for ; Mon, 10 Mar 2003 21:21:13 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B4vqYQ007675; Mon, 10 Mar 2003 20:57:52 -0800 Date: Mon, 10 Mar 2003 20:57:52 -0800 Message-Id: <200303110457.h2B4vqYQ007675@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 229] xfs_repair unable to repair system X-Bugzilla-Reason: AssignedTo X-archive-position: 3154 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 880 Lines: 38 http://oss.sgi.com/bugzilla/show_bug.cgi?id=229 ------- Additional Comments From alde@alde.com 2003-03-10 20:57 ------- Sure... But you'll want to wget a large site with lots of php links... wget --load-cookies=cookies.txt --save-cookies=cookies.txt -r -l 0 -p -nc -np --follow-ftp --user-agent="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; Q312461)" site.com $ wget -V GNU Wget 1.8.2 I get things like: 38947690 drwxr-xr-x 2 alde alde 1099511640064 Mar 10 21:11 pt2 directories that I can't remove. or files like: # find . -size +50000k -ls 76342129 132 -rw-r--r-- 1 alde alde 17592186177711 Dec 13 15:34 ./www.site.com/jial/jjial.jpg problem is, neither Inode even shows up in the xfs_repair as having a problem. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 11 06:44:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 06:44:10 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BEi0q9024941 for ; Tue, 11 Mar 2003 06:44:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2BEslkq016628 for ; Tue, 11 Mar 2003 08:54:47 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA39786; Tue, 11 Mar 2003 08:43:54 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2BEhqwX27101486; Tue, 11 Mar 2003 08:43:53 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2BLxOA25022; Tue, 11 Mar 2003 16:59:24 -0500 Date: Tue, 11 Mar 2003 16:59:23 -0500 From: Christoph Hellwig To: torvalds@transmeta.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: [PATCH] fix kmem_cache_size() for new slab poisoning Message-ID: <20030311165923.A25018@sgi.com> Mail-Followup-To: Christoph Hellwig , torvalds@transmeta.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 3156 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 875 Lines: 30 The new slab poisoning code broke kmem_cache_size(), it now returns a too large size as the poisoning area after the object is includes. XFS's kmem_zone_zalloc thus overwrites exactly that area and triggers the new checks everytime such an object is freed again. I don't recommend using XFS on BK-current without this patch applied :) --- 1.68/mm/slab.c Sat Mar 8 23:50:36 2003 +++ edited/mm/slab.c Tue Mar 11 15:15:44 2003 @@ -2041,11 +2041,16 @@ unsigned int kmem_cache_size(kmem_cache_t *cachep) { + unsigned int objlen = cachep->objsize; + #if DEBUG if (cachep->flags & SLAB_RED_ZONE) - return (cachep->objsize - 2*BYTES_PER_WORD); + objlen -= 2*BYTES_PER_WORD; + if (cachep->flags & SLAB_STORE_USER) + objlen -= BYTES_PER_WORD; #endif - return cachep->objsize; + + return objlen; } kmem_cache_t * kmem_find_general_cachep (size_t size, int gfpflags) From owner-linux-xfs@oss.sgi.com Tue Mar 11 09:17:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 09:17:38 -0800 (PST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BHHUq9005742 for ; Tue, 11 Mar 2003 09:17:31 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id B94E51C0144E; Tue, 11 Mar 2003 12:17:29 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 86BD81C000BD; Tue, 11 Mar 2003 12:17:29 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Mar 2003 12:17:29 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'Nathan Scott'" , "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: linux-xfs@oss.sgi.com Subject: RE: TAKE - pagebuf Date: Tue, 11 Mar 2003 12:17:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3157 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 2686 Lines: 92 Nathan, When I pull out this particular take, everything works fine. The volumes that fail to initialize quotas are on LVM devices, not standard scsi devices. The scsi devices mount correctly. I'm not consciously changing the pagesize and blocksize, so I assume I'm using the defaults. I'll work on adding the printks/debugging enablement later on today. Thanks, Erik > -----Original Message----- > From: Nathan Scott [mailto:nathans@sgi.com] > Sent: Monday, March 10, 2003 3:45 PM > To: HABBINGA,ERIK (HP-Loveland,ex1) > Cc: linux-xfs@oss.sgi.com > Subject: Re: TAKE - pagebuf > > > hi Erik, > > On Mon, Mar 10, 2003 at 03:09:47PM -0500, HABBINGA,ERIK > (HP-Loveland,ex1) wrote: > > When applying this patch from March 3rd, creating a file > system, and then > > unmounting and remounting xfs filesystems gives me the > following error: > > > > Mar 10 13:04:07 localhost kernel: XFS mounting filesystem lvm(58,1) > > Mar 10 13:04:07 localhost kernel: Filesystem "lvm(58,1)": Failed to > > initialize disk quotas. > > > > We're using the -o rw,nodev,noatime,quota mount options. > Mounting without > > the quota option doesn't generate the error. Using a CVS > take from March > > 6th does the same thing, but dumps a stack trace as well. > > > > Any ideas? > > > > Hmm... not really. I just tried a mkfs & mount with those options > and it worked correctly for me. A few suggestions - try adding a > few printk's in xfs_qm_mount_quotas and friends, to pinpoint where > the error is really coming from (there are several potential error > sources in that routine). You might also want to try turning XFS > debugging on, see if you trip an assert earlier on. > > Also what pagesize and blocksize are you using here? If you back > this mod out (and just this mod), does it start working again? > > thanks. > > > > > Remove an unused parameter from pagebuf_lookup. Ensure we > don't mark > > a page uptodate in the bsize==pgsize case when we didn't do > IO to the > > entire page. > > > > > > Date: Mon Mar 3 18:17:57 PST 2003 > > Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > > > Modid: 2.4.x-xfs:slinx:140809a > > linux/fs/xfs/pagebuf/page_buf.c - 1.100 > > - Remove an unused parameter from pagebuf_lookup. > Ensure we don't > > mark > > a page uptodate in the bsize==pgsize case when we > didn't do IO to > > the > > entire page. > > > > linux/fs/xfs/pagebuf/page_buf.h - 1.59 > > linux/fs/xfs/linux/xfs_aops.c - 1.19 > > - Remove an unused parameter from pagebuf_lookup. > > > > > > > > > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:07:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:08:00 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BM7Dq9012359 for ; Tue, 11 Mar 2003 14:07:53 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2BM78uX032005 for ; Tue, 11 Mar 2003 14:07:08 -0800 From: "l.a walsh" To: Subject: RE: XFS in 2.5.64-bk3, compile problem Date: Tue, 11 Mar 2003 14:07:06 -0800 Message-ID: <000401c2e81a$8dde1210$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E6B63DE.9040308@stesmi.com> Importance: Normal X-archive-position: 3158 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 904 Lines: 22 ...*scribble* *scribble* *scribble*...note to self. "Troll" = someone who provides helpful answers to repeated questions. *scribble* *scribble* more *scribbling* Stephan smomethingski (I know, it's probably the equivalent of Smith in Polish) has short fuse, probably won't like scribblings....:-/ sigh nobody has a sense of humor anymore, least of all, me!....:-| > -----Original Message----- > From: Stefan Smietanowski > > The problem is in gcc, not in the kernel. Red Hat ships with a broken, > > unofficial beta gcc. Please replace that gcc with gcc 3.2.2 (and while > > you're at it, replace Red Hat with a competent distribution that provides > > a working compiler). You'll find that your kernel compiles fine. > > It does here ;) > > I'm sorry, I missed the sign around your neck saying "Troll". > You could put that in your sig for instance so that it's > readily apparent. > > // Stefan From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:10:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:11:00 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BMAGq9012605 for ; Tue, 11 Mar 2003 14:10:56 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2BMABuX032017 for ; Tue, 11 Mar 2003 14:10:11 -0800 From: "l.a walsh" To: Subject: mount options... Date: Tue, 11 Mar 2003 14:10:09 -0800 Message-ID: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 3159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 401 Lines: 10 I'm not sure who maintains options to mount, its man page or error messages, but it would really be helpful if the error message for mounting a fs. that is the same UUID instead of a generic can't mount message. It would also be useful to document the -nouuid flag in the mount manpage (the one on my SuSE81 system is deficient -- dunnow if it is just them or source farther up the line.... -linda From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:16:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:16:33 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BMGSq9013908 for ; Tue, 11 Mar 2003 14:16:29 -0800 Received: from [10.0.0.3] (sandeen.net [209.173.210.139]) by sandeen.net (Postfix) with ESMTP id CD5432800FF; Tue, 11 Mar 2003 16:21:09 -0600 (CST) Subject: Re: mount options... From: Eric Sandeen To: "l.a walsh" Cc: linux-xfs@oss.sgi.com In-Reply-To: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> References: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 11 Mar 2003 16:17:52 -0600 Message-Id: <1047421073.17614.18.camel@porter> Mime-Version: 1.0 X-archive-position: 3160 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 696 Lines: 21 Mount almost always gives you a generic message on failure; I always make a habit of looking at the syslogs to see what went wrong. also, FWIW, all xfs mount options are documented in Documentation/filesystems/xfs.txt -Eric On Tue, 2003-03-11 at 16:10, l.a walsh wrote: > I'm not sure who maintains options to mount, its man page or error messages, > but it would really be helpful if the error message for mounting a fs. > that is the same UUID instead of a generic can't mount message. > It would also be useful to document the -nouuid flag in the mount manpage > (the one on my SuSE81 system is deficient -- dunnow if it is just them > or source farther up the line.... > > -linda > > From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:24:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:24:10 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BMNQq9014406 for ; Tue, 11 Mar 2003 14:24:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2BJfYnH012407 for ; Tue, 11 Mar 2003 11:41:34 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA51744 for ; Tue, 11 Mar 2003 13:41:33 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2BJfYvw7375677 for ; Tue, 11 Mar 2003 13:41:34 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h2BJg0oG1096960 for ; Tue, 11 Mar 2003 13:42:00 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2BJg0vW1093343 for linux-xfs@oss.sgi.com; Tue, 11 Mar 2003 13:42:00 -0600 (CST) Date: Tue, 11 Mar 2003 13:42:00 -0600 (CST) From: Dean Roehrich Message-Id: <200303111942.h2BJg0vW1093343@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Use a dynamic minor number for dmapi device X-archive-position: 3161 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 379 Lines: 16 Date: Tue Mar 11 11:41:16 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141450a linux/include/linux/miscdevice.h - 1.13 - remove DMAPI_MINOR linux/fs/xfs/dmapi/dmapi_sysent.c - 1.19 - Use a dynamic minor number for dmapi device From owner-linux-xfs@oss.sgi.com Tue Mar 11 15:18:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 15:18:08 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BNI0q9015563 for ; Tue, 11 Mar 2003 15:18:01 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2BNHsnH028080 for ; Tue, 11 Mar 2003 15:17:55 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2BNGc7L1320520 for ; Wed, 12 Mar 2003 10:16:38 +1100 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2BNGbT11436628 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 10:16:37 +1100 (EST) Date: Wed, 12 Mar 2003 10:16:37 +1100 (EST) From: Timothy Shimmin Message-Id: <200303112316.h2BNGbT11436628@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - update CREDITS X-archive-position: 3162 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 189 Lines: 7 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141483a cmd/xfsprogs/doc/CREDITS - 1.13 - Update for Danny Cox email address. From owner-linux-xfs@oss.sgi.com Tue Mar 11 17:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 17:08:44 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C17vq9022954 for ; Tue, 11 Mar 2003 17:08:37 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C17p9n027329 for ; Tue, 11 Mar 2003 17:07:52 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA04415 for ; Tue, 11 Mar 2003 19:07:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2C17pwX27494658 for ; Tue, 11 Mar 2003 19:07:51 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2C16gF04323; Tue, 11 Mar 2003 19:06:42 -0600 Message-Id: <200303120106.h2C16gF04323@stout.americas.sgi.com> Date: Tue, 11 Mar 2003 19:06:42 -0600 Subject: TAKE 879670 - unaligned access warnings on ia64 X-archive-position: 3163 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 371 Lines: 14 use get/put_unaligned() to avoid unaligned accesses in the extents code on 64-bit machines Date: Tue Mar 11 17:05:21 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141495a linux/fs/xfs/xfs_inode.c - 1.364 From owner-linux-xfs@oss.sgi.com Tue Mar 11 17:14:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 17:14:19 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C1ECq9023463 for ; Tue, 11 Mar 2003 17:14:13 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2C1E7uX000616; Tue, 11 Mar 2003 17:14:07 -0800 From: "l.a walsh" To: "'Eric Sandeen'" Cc: Subject: RE: mount options... Date: Tue, 11 Mar 2003 17:14:03 -0800 Message-ID: <000001c2e834$abd32480$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <1047421073.17614.18.camel@porter> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 3164 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1114 Lines: 50 > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Tue, Mar 11, 2003 2:18p > To: l.a walsh > Cc: linux-xfs@oss.sgi.com > Subject: Re: mount options... > > > Mount almost always gives you a generic message on failure; I always > make a habit of looking at the syslogs to see what went wrong. > > also, FWIW, all xfs mount options are documented in > Documentation/filesystems/xfs.txt --- That's nice. Are you saying it wouldn't be helpful to have a more clear error message or that it wouldn't be useful to have all the options documented in the manpages? -l > > -Eric > > On Tue, 2003-03-11 at 16:10, l.a walsh wrote: > > I'm not sure who maintains options to mount, its man page > or error messages, > > but it would really be helpful if the error message for > mounting a fs. > > that is the same UUID instead of a generic can't mount message. > > It would also be useful to document the -nouuid flag in the > mount manpage > > (the one on my SuSE81 system is deficient -- dunnow if it > is just them > > or source farther up the line.... > > > > -linda > > > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 11 19:03:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 19:03:59 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C33pq9027969 for ; Tue, 11 Mar 2003 19:03:54 -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 h2C33inH008915 for ; Tue, 11 Mar 2003 19:03:45 -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 OAA10703; Wed, 12 Mar 2003 14:02:28 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA73921; Wed, 12 Mar 2003 14:02:27 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2C2xnP9003615; Wed, 12 Mar 2003 13:59:49 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2C2xmKc003613; Wed, 12 Mar 2003 13:59:48 +1100 Date: Wed, 12 Mar 2003 13:59:48 +1100 From: Nathan Scott To: "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - pagebuf Message-ID: <20030312025948.GC1412@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3165 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 827 Lines: 25 On Tue, Mar 11, 2003 at 12:17:22PM -0500, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Nathan, > When I pull out this particular take, everything works fine. The volumes > that fail to initialize quotas are on LVM devices, not standard scsi > devices. The scsi devices mount correctly. OK, thats convincing enough for me - I'll back that change out for now and ponder it for awhile, see if I can see why this is happening. > I'm not consciously changing the pagesize and blocksize, so I assume I'm > using the defaults. Is this on an IA32 machine (i.e. 4K pagesize)? The default XFS blocksize is always 4K. I'm sure your machine is IA32, cos this change only affects the case whether the blocksize is the same as the pagesize. > I'll work on adding the printks/debugging enablement later on today. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 11 20:08:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 20:08:15 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C47Pq9031518 for ; Tue, 11 Mar 2003 20:08:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C47J9n003663 for ; Tue, 11 Mar 2003 20:07:20 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C4627L1484076 for ; Wed, 12 Mar 2003 15:06:02 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C462CE1484989 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:06:02 +1100 (EST) Date: Wed, 12 Mar 2003 15:06:02 +1100 (EST) From: Nathan Scott Message-Id: <200303120406.h2C462CE1484989@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bhv cleanup X-archive-position: 3166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1790 Lines: 57 Trivial aops.c change to keep 2.4 and 2.5 a little more in sync. Date: Thu Mar 6 15:03:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141144a linux/fs/xfs/linux/xfs_aops.c - 1.23 Next step in bhv code cleanup - this is a start on moving quota and dmapi into behavior layers, purging several points where these sit slap bang in the middle of XFS code (esp. read_super). Also removes numerous #ifdef's and a bunch of unused #define's from all over the place. More to come. Date: Tue Mar 11 19:33:01 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141499a linux/fs/xfs/xfs_dmops.c - 1.1 linux/fs/xfs/xfs_qmops.c - 1.1 linux/fs/xfs/xfs_macros.c - 1.48 linux/fs/xfs/xfs_dmapi.h - 1.34 linux/fs/xfs/xfs_dmapi.c - 1.90 linux/fs/xfs/Makefile - 1.153 linux/fs/xfs/xfs_iocore.c - 1.38 linux/fs/xfs/xfs_qm_syscalls.c - 1.73 linux/fs/xfs/xfs_vfsops.c - 1.408 linux/fs/xfs/xfs_mount.h - 1.166 linux/fs/xfs/xfs_mount.c - 1.319 linux/fs/xfs/xfs_qm.h - 1.26 linux/fs/xfs/xfs_inode.c - 1.365 linux/fs/xfs/linux/xfs_lrw.h - 1.32 linux/fs/xfs/linux/xfs_lrw.c - 1.180 linux/fs/xfs/linux/xfs_vfs.c - 1.39 linux/fs/xfs/linux/xfs_linux.h - 1.99 linux/fs/xfs/linux/Makefile - 1.69 linux/fs/xfs/linux/xfs_file.c - 1.86 linux/fs/xfs/linux/xfs_super.h - 1.37 linux/fs/xfs/linux/xfs_super.c - 1.240 linux/fs/xfs/linux/xfs_behavior.c - 1.17 linux/fs/xfs/linux/xfs_ioctl.c - 1.87 linux/fs/xfs/dmapi/dmapi_mountinfo.c - 1.12 linux/fs/xfs/linux/xfs_vnode.h - 1.76 linux/fs/xfs/linux/xfs_vfs.h - 1.33 linux/fs/xfs/linux/xfs_behavior.h - 1.13 From owner-linux-xfs@oss.sgi.com Tue Mar 11 20:49:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 20:49:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C4nkq9000420 for ; Tue, 11 Mar 2003 20:49:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C50Xkq002213 for ; Tue, 11 Mar 2003 23:00:34 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C4mM7L1498889 for ; Wed, 12 Mar 2003 15:48:22 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C4mLr21498828 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:48:21 +1100 (EST) Date: Wed, 12 Mar 2003 15:48:21 +1100 (EST) From: Nathan Scott Message-Id: <200303120448.h2C4mLr21498828@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 3167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 462 Lines: 16 Revert last part of recent IO completion changes - folks at HP have reported problems on top of LVM devices with this change. Something to come back to. Let me know if this doesn't help, Erik -- thanks. Date: Tue Mar 11 20:47:15 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141504a linux/fs/xfs/pagebuf/page_buf.c - 1.104 From owner-linux-xfs@oss.sgi.com Tue Mar 11 20:53:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 20:53:36 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C4rYq9000903 for ; Tue, 11 Mar 2003 20:53:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C54Lkq002248 for ; Tue, 11 Mar 2003 23:04:22 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C4qA7L1495822 for ; Wed, 12 Mar 2003 15:52:10 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C4qANV1478139 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:52:10 +1100 (EST) Date: Wed, 12 Mar 2003 15:52:10 +1100 (EST) From: Nathan Scott Message-Id: <200303120452.h2C4qANV1478139@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - aops.c X-archive-position: 3168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 469 Lines: 16 Christoph suggests some of the unwritten extent defines relating to buffer_header state should be out in a header somewhere - make it so. Date: Tue Mar 11 20:51:42 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141505a linux/fs/xfs/linux/xfs_linux.h - 1.100 linux/fs/xfs/linux/xfs_iops.h - 1.18 linux/fs/xfs/linux/xfs_aops.c - 1.24 From owner-linux-xfs@oss.sgi.com Tue Mar 11 21:40:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 21:40:52 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C5enq9004040 for ; Tue, 11 Mar 2003 21:40:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C5ehnH016150 for ; Tue, 11 Mar 2003 21:40:44 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C5dP7L1505321 for ; Wed, 12 Mar 2003 16:39:26 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C5dPcI1513586 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 16:39:25 +1100 (EST) Date: Wed, 12 Mar 2003 16:39:25 +1100 (EST) From: Nathan Scott Message-Id: <200303120539.h2C5dPcI1513586@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 2.5 unwritten extents X-archive-position: 3169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1219 Lines: 46 Doesn't yet work for direct IO into an unwritten extent (on my TODO list), but works correctly for buffered IO. cheers. Export end_buffer_async_write, needed for unwritten extent support in XFS. Date: Tue Mar 11 21:32:02 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:141507a linux/kernel/ksyms.c - 1.184 linux/fs/buffer.c - 1.151 linux/include/linux/buffer_head.h - 1.19 Implement support for unwritten extents in XFS. Date: Tue Mar 11 21:37:01 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:141508a linux/fs/xfs/pagebuf/page_buf.c - 1.101 - Create separate IO completion work queues in pagebuf for log/data IO, to prevent deadlocks when scheduling iclog/unwritten extent IO completion handlers. linux/fs/xfs/xfs_buf.h - 1.106 linux/fs/xfs/linux/xfs_linux.h - 1.100 linux/fs/xfs/linux/xfs_iops.h - 1.18 linux/fs/xfs/pagebuf/page_buf.h - 1.67 linux/fs/xfs/linux/xfs_aops.c - 1.29 - Implement support for unwritten extents in XFS. From owner-linux-xfs@oss.sgi.com Wed Mar 12 00:22:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 00:22:25 -0800 (PST) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C8LZq9013203 for ; Wed, 12 Mar 2003 00:22:16 -0800 Received: from erbenson.alaska.net (120-pm30.nwc.alaska.net [209.112.158.120]) by hermod.slb.nwc.acsalaska.net (8.12.8/8.12.8) with ESMTP id h2C8LX18083268 for ; Tue, 11 Mar 2003 23:21:33 -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 BDDD73A04 for ; Tue, 11 Mar 2003 23:21:30 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 6569A4104E2; Tue, 11 Mar 2003 23:21:30 -0900 (AKST) Date: Tue, 11 Mar 2003 23:21:30 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: mount options... Message-ID: <20030312082130.GC20925@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1047421073.17614.18.camel@porter> <000001c2e834$abd32480$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <000001c2e834$abd32480$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3170 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 4326 Lines: 125 --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 11, 2003 at 05:14:03PM -0800, l.a walsh wrote: >=20 >=20 > > -----Original Message----- > > From: Eric Sandeen [mailto:sandeen@sgi.com] > > Sent: Tue, Mar 11, 2003 2:18p > > To: l.a walsh > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: mount options... > > > > > > Mount almost always gives you a generic message on failure; I always > > make a habit of looking at the syslogs to see what went wrong. > > > > also, FWIW, all xfs mount options are documented in > > Documentation/filesystems/xfs.txt > --- > That's nice. >=20 > Are you saying it wouldn't be helpful to have a more clear > error message or that it wouldn't be useful to have all the options > documented in the manpages? not at all. the problem with mount is its just a wrapper around mount() (the system call), /bin/mount itself doesn't have any idea why the mount failed past mount()'s return value and the contents of errno, from the mount(2) man page: RETURN VALUE On success, zero is returned. On error, -1 is returned, and errno is set appropriately. ERRORS The error values given below result from filesystem type independent errors. Each filesystem type may have its own special errors and its own special behavior. See the ker- nel source code for details. EPERM The user is not the super-user. ENODEV Filesystemtype not configured in the kernel. ENOTBLK Specialfile is not a block device (if a device was required). EBUSY Specialfile is already mounted. Or, it cannot be remounted read-only, because it still holds files open for writing. Or, it cannot be mounted on dir because dir is still busy (it is the working direc- tory of some task, the mount point of another device, has open files, etc.). EINVAL Specialfile had an invalid superblock. Or, a remount was attempted, while specialfile was not already mounted on dir. Or, an umount was attempted, while dir was not a mount point. EFAULT One of the pointer arguments points outside the user address space. ENOMEM The kernel could not allocate a free page to copy filenames or data into. ENAMETOOLONG A pathname was longer than MAXPATHLEN. ENOENT A pathname was empty or had a nonexistent compo- nent. ENOTDIR The second argument, or a prefix of the first argu- ment, is not a directory. EACCES A component of a path was not searchable. Or, mounting a read-only filesystem was attempted without giving the MS_RDONLY flag. Or, the block device Specialfile is located on a filesystem mounted with the MS_NODEV option. ENXIO The major number of the block device specialfile is out of range. EMFILE (In case no block device is required:) Table of dummy devices is full. In general there isn't going to be an errno for all the various ways specific filesystems can fail, so mount is probably just going to end up getting ENODEV most of the time, thus it can't tell you much about what went wrong. you could fix this by adding new errno values to accomidate all the various filesystem mount failure conditions, then make sure /bin/mount just uses perror() to inform the user of failure. this however requires both kernel and glibc modification, and thus will likly be difficult politically (and there are perhaps portability issues, though thats not so important with something like mount() which is never portable anyway). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --eHhjakXzOLJAF9wJ 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 iEYEARECAAYFAj5u7goACgkQJKx7GixEevz2PwCePhofkDSNc1woy3w11ZezkOYf VmgAniSYpPp7RAiOvF2OJPCeJyvgNkJh =n7Or -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- From owner-linux-xfs@oss.sgi.com Wed Mar 12 01:34:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 01:34:30 -0800 (PST) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C9YJq9018594 for ; Wed, 12 Mar 2003 01:34:20 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18t2co-0002KJ-00; Wed, 12 Mar 2003 09:34:14 +0000 Date: Wed, 12 Mar 2003 09:34:13 +0000 From: Christoph Hellwig To: "l.a walsh" Cc: linux-xfs@oss.sgi.com Subject: Re: mount options... Message-ID: <20030312093413.A8850@infradead.org> References: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org>; from xfs@tlinx.org on Tue, Mar 11, 2003 at 02:10:09PM -0800 X-archive-position: 3171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 558 Lines: 11 On Tue, Mar 11, 2003 at 02:10:09PM -0800, l.a walsh wrote: > I'm not sure who maintains options to mount, its man page or error messages, > but it would really be helpful if the error message for mounting a fs. > that is the same UUID instead of a generic can't mount message. > It would also be useful to document the -nouuid flag in the mount manpage > (the one on my SuSE81 system is deficient -- dunnow if it is just them > or source farther up the line.... mount(8) is part of util-linux. Send any updates / comments to Andries Brouwer . From owner-linux-xfs@oss.sgi.com Wed Mar 12 02:29:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 02:29:23 -0800 (PST) Received: from mario.zsu.edu.cn ([61.144.54.55]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CATBq9024080 for ; Wed, 12 Mar 2003 02:29:13 -0800 Received: from zsulink.zsu.edu.cn (zsulink.zsu.edu.cn [202.116.64.1]) by mario.zsu.edu.cn (8.11.5/8.11.5) with ESMTP id h2CAgW398738 for ; Wed, 12 Mar 2003 18:42:32 +0800 (CST) Received: from mc011.zd.zsu.edu.cn ([202.116.86.49]) by zsulink.zsu.edu.cn (8.11.5/8.11.5) with ESMTP id h2CAWBJ24689 for ; Wed, 12 Mar 2003 18:32:11 +0800 (CST) Subject: How can I patch my Phoebe-3's kernel with XFS patch? From: ihwbox To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1047464916.2241.4.camel@mc011.zd.zsu.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 12 Mar 2003 18:29:04 +0800 Content-Transfer-Encoding: 7bit X-Filter-Version: 1.7 (fw.zsu.edu.cn) X-archive-position: 3172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ihwbox@21cn.com Precedence: bulk X-list: linux-xfs Content-Length: 148 Lines: 8 I'm using Redhat 8.0.94 beta. And I also want to use XFS filesystem. How can I patch redhat's kernel-2.4.20-2.48 . -- ihwbox From owner-linux-xfs@oss.sgi.com Wed Mar 12 02:36:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 02:36:20 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CAZUq9027103 for ; Wed, 12 Mar 2003 02:36:11 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18t3Zz-0002Um-00; Wed, 12 Mar 2003 10:35:23 +0000 Date: Wed, 12 Mar 2003 10:35:22 +0000 From: Christoph Hellwig To: ihwbox Cc: linux-xfs@oss.sgi.com Subject: Re: How can I patch my Phoebe-3's kernel with XFS patch? Message-ID: <20030312103522.A9562@infradead.org> References: <1047464916.2241.4.camel@mc011.zd.zsu.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1047464916.2241.4.camel@mc011.zd.zsu.edu.cn>; from ihwbox@21cn.com on Wed, Mar 12, 2003 at 06:29:04PM +0800 X-archive-position: 3173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 448 Lines: 9 On Wed, Mar 12, 2003 at 06:29:04PM +0800, ihwbox wrote: > I'm using Redhat 8.0.94 beta. And I also want to use XFS filesystem. How > can I patch redhat's kernel-2.4.20-2.48 . Given the way you ask you probably can't as it's nontrivial. I'll do a XFS-enabled RPM for RH8.1 once it's out, but until then just stick to the RRH8-errata based RPMS, they should work under phoebe but you won't get all of it's features (notably the threading changes) From owner-linux-xfs@oss.sgi.com Wed Mar 12 07:15:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 07:15:23 -0800 (PST) Received: from obelix.wu-wien.ac.at (obelix.wu-wien.ac.at [137.208.3.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CFFCq9028710 for ; Wed, 12 Mar 2003 07:15:14 -0800 Received: from ekelhardt ([137.208.224.91]) by obelix.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id QAA19586 for ; emf h9351252@obelix.wu-wien.ac.at; Wed, 12 Mar 2003 16:15:03 +0100 From: "Peter Alberer" To: Subject: nfs and number of open files Date: Wed, 12 Mar 2003 16:12:57 +0100 Message-ID: <001201c2e8a9$dd402200$5be0d089@ekelhardt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 3174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: h9351252@obelix.wu-wien.ac.at Precedence: bulk X-list: linux-xfs Content-Length: 1501 Lines: 34 Hi all, First of, i am not sure whether this is really an xfs issue, but as most of you are experts with filesystems, i hope someone can help here. i am using redhat 8 with a linux 2.4.19 kernel patched with the xfs patches. A 350GB drive has been formatted with xfs and one directory hierarchie on that fs (with 130.000 files) is nfs exported to another server. Besides, the machine is only running the postgresql database (Postgres data files are also on the xfs-drive) The nfs-client is a web server machine that delivers some files from the nfs-drive (only huge downloads) Today and yesterday that web server has crashed due to network problems. today I got the following error message on the nfs server: "too many open files in system". First I increased the limit (/proc/sys/fs/file-max) to 12000 (was 8192) files, to get things running again. But now I want to find out why so many files are open and I would like to know which files are open. Our web service is not so popular that more than a hundred files should be open at the same time over the nfs link. I tried to find open files with "lsof -N" (tried that on client and server) but did not get any result. "lsof" lists only about 600 open files. So my questions are: - how do I find out which files are open - can the crash of the webserver (nfs-client) be part of the problem - is this a "normal" situation (that one has to increase file-max) when exporting so many files or could there be something bad going on? TIA, peter From owner-linux-xfs@oss.sgi.com Wed Mar 12 10:48:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 10:49:01 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CImtq9031415 for ; Wed, 12 Mar 2003 10:48:56 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J8V20CH>; Wed, 12 Mar 2003 13:48:50 -0500 Message-ID: From: "Miro, Felix" To: "'linux-xfs@oss.sgi.com'" Subject: XFS root filesystem Date: Wed, 12 Mar 2003 13:48:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 165 Lines: 6 What is the procedure for making XFS my root filesystem under redhat 8.0+ ? Your web page mentioned a working document but the link was broken. Thanks, Felix Miro From owner-linux-xfs@oss.sgi.com Wed Mar 12 10:44:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 10:44:37 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CIiSq9031180 for ; Wed, 12 Mar 2003 10:44:29 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J8V20AY>; Wed, 12 Mar 2003 13:44:15 -0500 Message-ID: From: "Miro, Felix" To: "'linux-xfs@oss.sgi.com'" Subject: XFS file extent size Date: Wed, 12 Mar 2003 13:44:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 112 Lines: 6 How do you specify a file's extent size? Your web page says use fcntl but what parameters. Thanks, Felix Miro From owner-linux-xfs@oss.sgi.com Wed Mar 12 13:17:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 13:17:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CLHPq9002543 for ; Wed, 12 Mar 2003 13:17:26 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2CLSFkq021846 for ; Wed, 12 Mar 2003 15:28:16 -0600 Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h2CLHJh0024586 for ; Wed, 12 Mar 2003 15:17:19 -0600 Received: (from cattelan@localhost) by naboo.americas.sgi.com (8.12.5/8.12.5/Submit) id h2CLHFZL024584 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:17:15 -0600 Date: Wed, 12 Mar 2003 15:17:15 -0600 From: Rusell Cattelan Message-Id: <200303122117.h2CLHFZL024584@naboo.americas.sgi.com> Subject: TAKE - Make XFS LBD ready X-archive-position: 3177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 560 Lines: 20 Date: Wed Mar 12 13:16:52 PST 2003 Workarea: naboo.americas.sgi.com:/misc/xfs1/rsrc/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141587a linux/fs/xfs/xfs_types.h - 1.65 - Add typedef for sector_t here for now once sector_t is defined in the core kernel remove Also turn on XFS_BIG_FILESYSTEMS if LBD is enabled linux/fs/xfs/linux/xfs_iops.h - 1.19 linux/fs/xfs/linux/xfs_aops.c - 1.25 - change params to sector_t Make ready for LBD (Large Block Device) support From owner-linux-xfs@oss.sgi.com Wed Mar 12 14:17:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 14:17:33 -0800 (PST) Received: from webcube3.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CMHOq9003738 for ; Wed, 12 Mar 2003 14:17:26 -0800 Received: from jupiter.solar.com (host10-33-153-216.knightwave.com [216.153.33.10] (may be forged)) by webcube3.volstate.net (8.11.6/8.11.6) with ESMTP id h2CMHNL21379 for ; Wed, 12 Mar 2003 17:17:23 -0500 Content-Type: text/plain; charset="us-ascii" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: Permission problems with attr and setfattr Date: Wed, 12 Mar 2003 16:16:44 -0600 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200303121616.44771.joebacom@volstate.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2CMHQq9003740 X-archive-position: 3178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joebacom@volstate.net Precedence: bulk X-list: linux-xfs Content-Length: 430 Lines: 21 Hi Folks; I am trying to set an extended attribute value to a symbolic link with attr -s some.name -V "some value" some_file and get attr_set: Operation not permitted but if I su up to root and do the same command the attribute is set. I could not find a reference that required root access is required to set extended attributes anywhere except for rootspace. Also, I get the same results using setfattr. Thanks; Joe From owner-linux-xfs@oss.sgi.com Wed Mar 12 14:41:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 14:41:57 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CMfoq9004300 for ; Wed, 12 Mar 2003 14:41:51 -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 h2CMfh9n013154 for ; Wed, 12 Mar 2003 14:41:44 -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 JAA20110; Thu, 13 Mar 2003 09:40:27 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA64259; Thu, 13 Mar 2003 09:40:25 +1100 (EST) Date: Thu, 13 Mar 2003 09:40:24 +1100 From: Nathan Scott To: Joe Bacom Cc: linux-xfs@oss.sgi.com Subject: Re: Permission problems with attr and setfattr Message-ID: <20030313094024.A967615@wobbly.melbourne.sgi.com> References: <200303121616.44771.joebacom@volstate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200303121616.44771.joebacom@volstate.net>; from joebacom@volstate.net on Wed, Mar 12, 2003 at 04:16:44PM -0600 X-archive-position: 3179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 352 Lines: 14 On Wed, Mar 12, 2003 at 04:16:44PM -0600, Joe Bacom wrote: > > I am trying to set an extended attribute value to a symbolic link with > ... > I could not find a reference that required root access is required to set > extended attributes anywhere except for rootspace. attr(5) discusses this in the section on user attributes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 12 17:51:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 17:51:10 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2D1oQq9015247 for ; Wed, 12 Mar 2003 17:51:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2D1oJnH001040 for ; Wed, 12 Mar 2003 17:50:20 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2D1n27L1605523 for ; Thu, 13 Mar 2003 12:49:02 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2D1n0tv1618501 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 12:49:00 +1100 (EST) Date: Thu, 13 Mar 2003 12:49:00 +1100 (EST) From: Nathan Scott Message-Id: <200303130149.h2D1n0tv1618501@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - unwritten extents tweak X-archive-position: 3180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 572 Lines: 18 Add back the pagebuf flag for scheduling on the data daemon. Moving this into just a pagebuf_iodone parameter was broken as we don't have sufficient state in all the places we need it to make the decision. Date: Wed Mar 12 17:47:51 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141626a linux/fs/xfs/xfs_buf.h - 1.106 linux/fs/xfs/pagebuf/page_buf.c - 1.105 linux/fs/xfs/pagebuf/page_buf.h - 1.62 linux/fs/xfs/linux/xfs_aops.c - 1.27 From owner-linux-xfs@oss.sgi.com Thu Mar 13 04:36:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 04:36:54 -0800 (PST) Received: from smtp1.work.ro ([213.157.160.179]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DCa2q9026787 for ; Thu, 13 Mar 2003 04:36:45 -0800 Received: (qmail 29649 invoked by uid 7789); 13 Mar 2003 14:05:36 -0000 Received: from unknown (HELO work.ro) (office@dakorom.ro@192.168.1.21) by 0 with SMTP; 13 Mar 2003 14:05:36 -0000 Message-ID: <3E7073D6.2040207@work.ro> Date: Thu, 13 Mar 2003 14:04:38 +0200 From: Dovli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: problem with XFS 1.2 and linux kernel 2.4.18 and 2.4.19 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dovli@work.ro Precedence: bulk X-list: linux-xfs Content-Length: 976 Lines: 24 Hello! I have a high traffic web server running slackware linux 8.1. The most used filesystem on the server which hosts a free web mail application has xfs on it. Until recently the server had been running smoothly with the 2.4.18 kernel but for the last two weeks the server hangs every now and then with an xfs error. I upgraded the kernel to 2.4.19 but the problem persists. This is the dmesg message on the server when the error last occured: xfs_inotobp: xfs_imap() returned an error 22 on ide0(3,8). Returning error.xfs_iunlink_remove: xfs_inotobp() returned an error 22 on ide0(3,8). Returning error.xfs_inactive: xfs_ifree() returned an error = 22 on ide0(3,8) xfs_force_shutdown(ide0(3,8),0x1) called from line 1845 of file xfs_vnodeops.c. Return address = 0xc01e0c14 I/O Error Detected. Shutting down filesystem: ide0(3,8) Please umount the filesystem, and rectify the problem(s) Any help would be appreciated Thank you very much for your support From owner-linux-xfs@oss.sgi.com Thu Mar 13 04:55:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 04:55:50 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DCt6q9027332 for ; Thu, 13 Mar 2003 04:55:47 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-165-123.quicknet.nl [212.58.165.123]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2DCt2j0047919; Thu, 13 Mar 2003 13:55:03 +0100 (CET) Message-Id: <4.3.2.7.2.20030313135406.0402a068@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 13:54:26 +0100 To: "Miro, Felix" , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: XFS root filesystem In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3182 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 305 Lines: 12 At 13:48 12-3-2003 -0500, Miro, Felix wrote: >What is the procedure for making XFS my root filesystem under redhat 8.0+ ? >Your web page mentioned a working document but the link was broken. The easiest way is using the 8.0 installer. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Mar 13 05:04:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 05:04:24 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DD4Jq9027808 for ; Thu, 13 Mar 2003 05:04:21 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-165-123.quicknet.nl [212.58.165.123]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2DD4IUV072464; Thu, 13 Mar 2003 14:04:18 +0100 (CET) Message-Id: <4.3.2.7.2.20030313135945.034419d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 14:03:40 +0100 To: Dovli , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: problem with XFS 1.2 and linux kernel 2.4.18 and 2.4.19 In-Reply-To: <3E7073D6.2040207@work.ro> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 990 Lines: 28 At 14:04 13-3-2003 +0200, Dovli wrote: >Hello! > >xfs_inotobp: xfs_imap() returned an error 22 on ide0(3,8). Returning >error.xfs_iunlink_remove: xfs_inotobp() returned an error 22 on >ide0(3,8). Returning error.xfs_inactive: xfs_ifree() returned an >error = 22 on ide0(3,8) >xfs_force_shutdown(ide0(3,8),0x1) called from line 1845 of file >xfs_vnodeops.c. Return address = 0xc01e0c14 >I/O Error Detected. Shutting down filesystem: ide0(3,8) >Please umount the filesystem, and rectify the problem(s) IIRC Linda Walsh had the exact same error message on her root filesystem while she tried to dump it with xfsdump. In this case I think there is either a stray file or directory on the filesystem which is confusing the xfs layer. You may want find find the thread using the searchable mailing list archive. You can find the link on the mailinglist page. It lists the way to find the problem and correct it. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Mar 13 05:10:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 05:10:20 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DD9bq9028310 for ; Thu, 13 Mar 2003 05:10:18 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-165-123.quicknet.nl [212.58.165.123]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2DD9WZ4099927; Thu, 13 Mar 2003 14:09:33 +0100 (CET) Message-Id: <4.3.2.7.2.20030313140702.036dc338@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 14:08:54 +0100 To: "Peter Alberer" , From: Seth Mos Subject: Re: nfs and number of open files In-Reply-To: <001201c2e8a9$dd402200$5be0d089@ekelhardt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 584 Lines: 20 At 16:12 12-3-2003 +0100, Peter Alberer wrote: >Hi all, > >today I got the following error message on the nfs server: "too many >open files in system". First I increased the limit >(/proc/sys/fs/file-max) to 12000 (was 8192) files, to get things running >again. But now I want to find out why so many files are open and I would >like to know which files are open. It might be that the NFS client or webserver is no closing the file handles the way it should. This might be related to the crash of the webserver. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Mar 13 06:13:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 06:13:42 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.114.72.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DEDaq9029259 for ; Thu, 13 Mar 2003 06:13:37 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.12.8/8.12.5) with ESMTP id h2DEDZAW007868 for ; Thu, 13 Mar 2003 09:13:35 -0500 Subject: XFS 1.2.0 release for linux-2.4.20? From: Jeremy Jackson To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1047564814.2704.41.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Mar 2003 09:13:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 224 Lines: 8 I have just finished merging linux-2.4.19-core-xfs-1.2.0.patch.gz into linux-2.4.20. I am wondering if there might be a forthcoming official release of same, or if the merging I have done might be useful. Cheers, Jeremy From owner-linux-xfs@oss.sgi.com Thu Mar 13 06:37:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 06:37:53 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DEb4q9029877 for ; Thu, 13 Mar 2003 06:37:44 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.8/8.12.6) with ESMTP id h2DEax97038529; Thu, 13 Mar 2003 08:37:00 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: XFS 1.2.0 release for linux-2.4.20? From: Russell Cattelan To: Jeremy Jackson Cc: linux-xfs@oss.sgi.com In-Reply-To: <1047564814.2704.41.camel@contact.skynet.coplanar.net> References: <1047564814.2704.41.camel@contact.skynet.coplanar.net> Content-Type: text/plain Organization: Message-Id: <1047566218.36078.12.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Mar 2003 08:36:59 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 3186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 527 Lines: 16 On Thu, 2003-03-13 at 08:13, Jeremy Jackson wrote: > I have just finished merging linux-2.4.19-core-xfs-1.2.0.patch.gz into > linux-2.4.20. I am wondering if there might be a forthcoming official > release of same, or if the merging I have done might be useful. We probably are not going to do anything "official" i.e. fully tested. But you want to send us the patch, we can look it over and put it on the ftp site in case other people want to grab it. > > Cheers, > > Jeremy -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Thu Mar 13 07:21:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 07:21:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DFLRq9030703 for ; Thu, 13 Mar 2003 07:21:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DFLQ8a030701 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 07:21:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DFLOqB030688 for ; Thu, 13 Mar 2003 07:21:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DENa2U029773; Thu, 13 Mar 2003 06:23:36 -0800 Date: Thu, 13 Mar 2003 06:23:36 -0800 Message-Id: <200303131423.h2DENa2U029773@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] New: umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3187 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1308 Lines: 36 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 Summary: umount hangs after high disk load Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: atu@dmeti.dp.ua kernel: 2.4.20+xfs(some modern snapshots up to 2003-03-09, from SGI FTP)+netfiler+openwall build by gcc 3.2.(1-2), XFS in kernel, not in modules. All linux partitions is XFS: /=hda5(300M), /usr=hda8(7G), /var=hda9(2G), /home=hda10(12G). swap=hda7(1G). 256M RAM. Redhat-like initscripts. If afer boot run some disk-using program (I use updatedb), and than try to reboot or halt, shutdown hangs in /etc/rc.d/init.d/halt while first umount loop. Using -v as umount, I found, that hang occured while umounting /usr. fuser shows no processes, using /usr. The same result can be created by: mount /usr -o remount,ro or Alt-PrintScreen-u Alt-PrintScreen-P shows, shows, that current process in swapper. Before hang essenshial disk activity (by LED, approx 10-20s). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 13 11:45:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 11:45:11 -0800 (PST) Received: from hotmail.com (f41.sea2.hotmail.com [207.68.165.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DJj3q9003775 for ; Thu, 13 Mar 2003 11:45:03 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Mar 2003 11:43:22 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 13 Mar 2003 19:43:21 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: reserving contiguous files Date: Thu, 13 Mar 2003 11:43:21 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2003 19:43:22.0138 (UTC) FILETIME=[CE11F7A0:01C2E998] X-archive-position: 3188 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1290 Lines: 24 Hello, I am trying to write sequences of contiguous files in XFS to minimize the drive head seeks that must occur during file reads. Using the XFS_RESVSP64 ioctl to reserve the set of files ahead of time, I am able to get individual files allocated with contiguous extents. However, the allocation of one file versus another (reserved immediately after each other) seems to be somewhat erratic. Is there a way to guarantee or further lock the allocation of one file with respect to another in a contiguous manner? Looking at xfs_vnodeops.c and xfs_bmap.c could this be possibly be achieved by initializing the firstfsb structure in xfs_alloc_file_space() only in the first reserve call for a group allocation? The value of this structure could be maintained for consecutive calls to allow the contiguous allocation of a group of files based on the preceeding reserve ioctl. This behavior could be added as an additional ioctl call (RESVSP64CONTIG?) to maintain the current working code. I am going to experiment with this, but I would appreciate suggestions/comments. Thanks. Rick Smith _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:05:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:05:08 -0800 (PST) Received: from fed1mtao08.cox.net (fed1mtao08.cox.net [68.6.19.123]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DK54q9004326 for ; Thu, 13 Mar 2003 12:05:05 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao08.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313200457.JVEM29278.fed1mtao08.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 15:04:57 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tYwk-0001AI-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 13:04:59 -0700 Message-ID: <3E70E46A.20901@cox.net> Date: Thu, 13 Mar 2003 13:04:58 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [NEWBIE] Why aren't directory mtimes updated like other filesystems? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 742 Lines: 13 I've just set up my first XFS system, using kernel 2.5.64-bk7. So far so good, got three XFS volumes on an LVM2 volume group and everything seems to be working well. However, I noticed a behavior that I didn't expect. I've googled, and checked the FAQ, and checked the XFS Bugzilla and I haven't come across it. On my XFS filesystems, when I make changes within a directory (create/remove subdirectory, create/remove/touch files), the mtime (modification time) of the parent directory is not updated. On my other filesystems (ext2 and ext3) it is. I am working on a Makefile that depends on this behavior, so I'm wondering if this is a bug in XFS, or if updating the parent directory's mtime is not mandataory Unix/POSIX behavior? From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:11:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:11:46 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DKB4q9004853 for ; Thu, 13 Mar 2003 12:11:44 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DKLwkq012460 for ; Thu, 13 Mar 2003 14:21:58 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (8.12.8/americas-smart-nospam1.1) with ESMTP id h2DKAv4H16286747; Thu, 13 Mar 2003 14:10:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2DKAvwX28572372; Thu, 13 Mar 2003 14:10:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2DKAvK12183; Thu, 13 Mar 2003 14:10:57 -0600 Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? From: Steve Lord To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E70E46A.20901@cox.net> References: <3E70E46A.20901@cox.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047586257.30836.58.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Mar 2003 14:10:57 -0600 X-archive-position: 3190 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1745 Lines: 43 On Thu, 2003-03-13 at 14:04, Kevin P. Fleming wrote: > I've just set up my first XFS system, using kernel 2.5.64-bk7. So far so good, > got three XFS volumes on an LVM2 volume group and everything seems to be working > well. > > However, I noticed a behavior that I didn't expect. I've googled, and checked > the FAQ, and checked the XFS Bugzilla and I haven't come across it. On my XFS > filesystems, when I make changes within a directory (create/remove subdirectory, > create/remove/touch files), the mtime (modification time) of the parent > directory is not updated. On my other filesystems (ext2 and ext3) it is. I am > working on a Makefile that depends on this behavior, so I'm wondering if this is > a bug in XFS, or if updating the parent directory's mtime is not mandataory > Unix/POSIX behavior? Well, the code is there to do this, and, when I modify a directory it does change the times: jen{lord}: stat . File: "." Size: 4096 Blocks: 8 IO Block: 4096 Directory Device: 804h/2052d Inode: 131 Links: 28 Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) Access: Thu Mar 13 14:08:25 2003 Modify: Thu Mar 13 10:50:35 2003 Change: Thu Mar 13 10:50:35 2003 jen{lord}: touch foo jen{lord}: stat . File: "." Size: 4096 Blocks: 8 IO Block: 4096 Directory Device: 804h/2052d Inode: 131 Links: 28 Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) Access: Thu Mar 13 14:08:25 2003 Modify: Thu Mar 13 14:10:28 2003 Change: Thu Mar 13 14:10:28 2003 Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:41:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:41:34 -0800 (PST) Received: from fed1mtao05.cox.net (fed1mtao05.cox.net [68.6.19.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DKf3q9014480 for ; Thu, 13 Mar 2003 12:41:31 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao05.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313204055.KDBJ1559.fed1mtao05.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 15:40:55 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tZVZ-0001EU-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 13:40:58 -0700 Message-ID: <3E70ECD9.2080008@cox.net> Date: Thu, 13 Mar 2003 13:40:57 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> In-Reply-To: <1047586257.30836.58.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 955 Lines: 27 Steve Lord wrote: > Well, the code is there to do this, and, when I modify a directory it > does change the times: > > jen{lord}: stat . > File: "." > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 804h/2052d Inode: 131 Links: 28 > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > Access: Thu Mar 13 14:08:25 2003 > Modify: Thu Mar 13 10:50:35 2003 > Change: Thu Mar 13 10:50:35 2003 > > jen{lord}: touch foo > jen{lord}: stat . > File: "." > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 804h/2052d Inode: 131 Links: 28 > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > Access: Thu Mar 13 14:08:25 2003 > Modify: Thu Mar 13 14:10:28 2003 > Change: Thu Mar 13 14:10:28 2003 > Strange, I try exactly the same commands and the ctime gets updated but the mtime does not. Are you running on 2.5? From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:57:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:57:34 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DKvWq9015004 for ; Thu, 13 Mar 2003 12:57:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DKvQ9n031051 for ; Thu, 13 Mar 2003 12:57:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (8.12.8/americas-smart-nospam1.1) with ESMTP id h2DKvQ4H16367896; Thu, 13 Mar 2003 14:57:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2DKvPwX28005102; Thu, 13 Mar 2003 14:57:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2DKvPt12834; Thu, 13 Mar 2003 14:57:25 -0600 Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? From: Steve Lord To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E70ECD9.2080008@cox.net> References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047589045.12814.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Mar 2003 14:57:25 -0600 X-archive-position: 3192 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1436 Lines: 40 On Thu, 2003-03-13 at 14:40, Kevin P. Fleming wrote: > Steve Lord wrote: > > Well, the code is there to do this, and, when I modify a directory it > > does change the times: > > > > jen{lord}: stat . > > File: "." > > Size: 4096 Blocks: 8 IO Block: 4096 Directory > > Device: 804h/2052d Inode: 131 Links: 28 > > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > > Access: Thu Mar 13 14:08:25 2003 > > Modify: Thu Mar 13 10:50:35 2003 > > Change: Thu Mar 13 10:50:35 2003 > > > > jen{lord}: touch foo > > jen{lord}: stat . > > File: "." > > Size: 4096 Blocks: 8 IO Block: 4096 Directory > > Device: 804h/2052d Inode: 131 Links: 28 > > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > > Access: Thu Mar 13 14:08:25 2003 > > Modify: Thu Mar 13 14:10:28 2003 > > Change: Thu Mar 13 14:10:28 2003 > > > > Strange, I try exactly the same commands and the ctime gets updated but the > mtime does not. Are you running on 2.5? Ah, this is 2.4, I don't have a spare box for 2.5 here right now, but I know someone who does. The core xfs code is the same, and it is updating the timestamp fields in the inode. Possibly it is something in the stat path. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:10:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:10:56 -0800 (PST) Received: from fed1mtao05.cox.net (fed1mtao05.cox.net [68.6.19.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLAAq9015568 for ; Thu, 13 Mar 2003 13:10:50 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao05.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313211002.KIEG1559.fed1mtao05.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 16:10:02 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tZxl-0001H8-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 14:10:05 -0700 Message-ID: <3E70F3AD.5090209@cox.net> Date: Thu, 13 Mar 2003 14:10:05 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> In-Reply-To: <1047589045.12814.2.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 701 Lines: 16 Steve Lord wrote: >>Strange, I try exactly the same commands and the ctime gets updated but the >>mtime does not. Are you running on 2.5? > > > Ah, this is 2.4, I don't have a spare box for 2.5 here right now, > but I know someone who does. The core xfs code is the same, and it > is updating the timestamp fields in the inode. Possibly it is > something in the stat path. > Actually, it may be more insidious than that. When I did some testing over a 30 minute period, at one point making a new subdirectory caused the parent's mtime to update, but it updated to a time of about 10 minutes previous, when I had mad other changes. So it did change, but not to the current time. Very strange. From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:16:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:16:39 -0800 (PST) Received: from pip (c-24-98-62-33.atl.client2.attbi.com [24.98.62.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLGZq9016046 for ; Thu, 13 Mar 2003 13:16:37 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by pip (8.11.6/8.11.6) with ESMTP id h2DLGYQ02172; Thu, 13 Mar 2003 16:16:34 -0500 Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? From: Danny Cox To: "Kevin P. Fleming" Cc: XFS Mailing List In-Reply-To: <3E70F3AD.5090209@cox.net> References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> Content-Type: text/plain Organization: No Organization at ALL Message-Id: <1047590194.1306.28.camel@pip> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Mar 2003 16:16:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danscox@mindspring.com Precedence: bulk X-list: linux-xfs Content-Length: 617 Lines: 20 Kevin, On Thu, 2003-03-13 at 16:10, Kevin P. Fleming wrote: > Actually, it may be more insidious than that. When I did some testing over a 30 > minute period, at one point making a new subdirectory caused the parent's mtime > to update, but it updated to a time of about 10 minutes previous, when I had mad > other changes. So it did change, but not to the current time. Very strange. Does running 'sync' after changes make any difference? -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:30:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:30:50 -0800 (PST) Received: from fed1mtao08.cox.net (fed1mtao08.cox.net [68.6.19.123]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLUlq9016578 for ; Thu, 13 Mar 2003 13:30:48 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao08.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313213041.KLJW29278.fed1mtao08.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 16:30:41 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18taHi-0001K7-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 14:30:42 -0700 Message-ID: <3E70F881.7040605@cox.net> Date: Thu, 13 Mar 2003 14:30:41 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> In-Reply-To: <1047590194.1306.28.camel@pip> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 611 Lines: 20 Danny Cox wrote: > Kevin, > > On Thu, 2003-03-13 at 16:10, Kevin P. Fleming wrote: > >>Actually, it may be more insidious than that. When I did some testing over a 30 >>minute period, at one point making a new subdirectory caused the parent's mtime >>to update, but it updated to a time of about 10 minutes previous, when I had mad >>other changes. So it did change, but not to the current time. Very strange. > > > > > Does running 'sync' after changes make any difference? > > > Doesn't appear to, no. No change before and after the sync command. From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:54:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:54:44 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLs1q9017931 for ; Thu, 13 Mar 2003 13:54:42 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DM4ukq015650 for ; Thu, 13 Mar 2003 16:04:56 -0600 Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h2DLruWg016699 for ; Thu, 13 Mar 2003 15:53:56 -0600 Received: (from cattelan@localhost) by naboo.americas.sgi.com (8.12.5/8.12.5/Submit) id h2DLrtqS016697 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:53:55 -0600 Date: Thu, 13 Mar 2003 15:53:55 -0600 From: Rusell Cattelan Message-Id: <200303132153.h2DLrtqS016697@naboo.americas.sgi.com> Subject: TAKE - Move sector_t def to a more appropriate spot X-archive-position: 3196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 294 Lines: 12 Date: Thu Mar 13 13:53:42 PST 2003 Workarea: naboo.americas.sgi.com:/misc/xfs1/rsrc/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141692a linux/fs/xfs/xfs_types.h - 1.66 linux/fs/xfs/linux/xfs_linux.h - 1.101 From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:57:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:57:20 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLvIq9018389 for ; Thu, 13 Mar 2003 13:57:18 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DLvCnH009692 for ; Thu, 13 Mar 2003 13:57:13 -0800 Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h2DLvCWg017209 for ; Thu, 13 Mar 2003 15:57:12 -0600 Received: (from cattelan@localhost) by naboo.americas.sgi.com (8.12.5/8.12.5/Submit) id h2DLvCFm017207 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:57:12 -0600 Date: Thu, 13 Mar 2003 15:57:12 -0600 From: Rusell Cattelan Message-Id: <200303132157.h2DLvCFm017207@naboo.americas.sgi.com> Subject: TAKE - More kdb info for requests X-archive-position: 3197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 300 Lines: 13 Date: Thu Mar 13 13:56:52 PST 2003 Workarea: naboo.americas.sgi.com:/misc/xfs1/rsrc/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141693a linux/kdb/modules/kdbm_pg.c - 1.64 - print out the number of free requests From owner-linux-xfs@oss.sgi.com Thu Mar 13 14:23:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 14:23:10 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DMMKq9019925 for ; Thu, 13 Mar 2003 14:23:07 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 8A55B100714 for ; Thu, 13 Mar 2003 23:22:19 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E7F29E.dip.t-dialin.net [217.231.242.158]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 4B649100133 for ; Thu, 13 Mar 2003 23:22:19 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id A846FBC for ; Thu, 13 Mar 2003 23:22:16 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 7A693B8 for ; Thu, 13 Mar 2003 23:22:16 +0100 (CET) Message-ID: <3E710497.8030208@koschikode.com> Date: Thu, 13 Mar 2003 23:22:15 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> <3E70F881.7040605@cox.net> In-Reply-To: <3E70F881.7040605@cox.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3198 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 906 Lines: 27 Kevin P. Fleming wrote: > Danny Cox wrote: >> On Thu, 2003-03-13 at 16:10, Kevin P. Fleming wrote: >> >>>Actually, it may be more insidious than that. When I did some testing over a 30 >>>minute period, at one point making a new subdirectory caused the parent's mtime >>>to update, but it updated to a time of about 10 minutes previous, when I had mad >>>other changes. So it did change, but not to the current time. Very strange. >> >> >> >> Does running 'sync' after changes make any difference? >> >> >> > Doesn't appear to, no. No change before and after the sync command. Maybe it's a more generic problem and related to the following bug Ted Ts'o just found: "[PATCH] BUGFIX: Ext2/3 noatime and dirsync sometimes ignored" http://marc.theaimsgroup.com/?l=linux-kernel&m=104754557025362&w=2 Just a(nother) shot in the dark... Regards, Juri From owner-linux-xfs@oss.sgi.com Thu Mar 13 14:28:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 14:28:21 -0800 (PST) Received: from fed1mtao08.cox.net (fed1mtao08.cox.net [68.6.19.123]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DMSIq9020394 for ; Thu, 13 Mar 2003 14:28:19 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao08.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313222812.KXST29278.fed1mtao08.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 17:28:12 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tbBN-0001RJ-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:28:13 -0700 Message-ID: <3E7105FC.2060508@cox.net> Date: Thu, 13 Mar 2003 15:28:12 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> <3E70F881.7040605@cox.net> <3E710497.8030208@koschikode.com> In-Reply-To: <3E710497.8030208@koschikode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 391 Lines: 15 Juri Haberland wrote: > Maybe it's a more generic problem and related to the following bug Ted > Ts'o just found: > "[PATCH] BUGFIX: Ext2/3 noatime and dirsync sometimes ignored" > http://marc.theaimsgroup.com/?l=linux-kernel&m=104754557025362&w=2 > > Just a(nother) shot in the dark... > > Regards, > Juri > > I don't think so; my ext2 filesystem on the same machine works just fine. From owner-linux-xfs@oss.sgi.com Thu Mar 13 15:05:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 15:05:56 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DN4wq9021045 for ; Thu, 13 Mar 2003 15:05:39 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id F1CCB100714 for ; Thu, 13 Mar 2003 23:33:23 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E7F29E.dip.t-dialin.net [217.231.242.158]) by batleth.sapienti-sat.org (Postfix) with ESMTP id A912E100133 for ; Thu, 13 Mar 2003 23:33:23 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id A2352BC for ; Thu, 13 Mar 2003 23:33:20 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 30298AA for ; Thu, 13 Mar 2003 23:33:20 +0100 (CET) Message-ID: <3E71072F.8010100@koschikode.com> Date: Thu, 13 Mar 2003 23:33:19 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> <3E70F881.7040605@cox.net> <3E710497.8030208@koschikode.com> <3E7105FC.2060508@cox.net> In-Reply-To: <3E7105FC.2060508@cox.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 499 Lines: 17 Kevin P. Fleming wrote: > Juri Haberland wrote: >> Maybe it's a more generic problem and related to the following bug Ted >> Ts'o just found: >> "[PATCH] BUGFIX: Ext2/3 noatime and dirsync sometimes ignored" >> http://marc.theaimsgroup.com/?l=linux-kernel&m=104754557025362&w=2 >> >> Just a(nother) shot in the dark... > I don't think so; my ext2 filesystem on the same machine works just fine. Yes, you mentioned it. And this bug is only in connection with DIRSYNC... Back to lurking ;) Juri From owner-linux-xfs@oss.sgi.com Thu Mar 13 15:21:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 15:21:35 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DNLTq9021637 for ; Thu, 13 Mar 2003 15:21:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DNLTCG021635 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:21:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DNLQqF021618 for ; Thu, 13 Mar 2003 15:21:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DMkXX5020941; Thu, 13 Mar 2003 14:46:34 -0800 Date: Thu, 13 Mar 2003 14:46:34 -0800 Message-Id: <200303132246.h2DMkXX5020941@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 3201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 563 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From cattelan@thebarn.com 2003-03-13 14:46 ------- The last patch fixed the problem ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 13 15:26:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 15:26:44 -0800 (PST) Received: from mail.rjmx.net (root@khufu.ne.client2.attbi.com [24.218.135.94]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DNQeq9022082 for ; Thu, 13 Mar 2003 15:26:41 -0800 Received: from cleopatra.rjmx.net.rjmx.net (ron@cleopatra.rjmx.net [192.168.17.2]) by mail.rjmx.net (8.12.8/8.12.8) with ESMTP id h2DNQW4V023673 for ; Thu, 13 Mar 2003 18:26:32 -0500 Date: Thu, 13 Mar 2003 18:26:31 -0500 Message-ID: <871y1ax2zc.wl@PurpleTram.Com> From: Ron Murray To: linux-xfs@oss.sgi.com Subject: Re: [Bug 230] New: umount hangs after high disk load In-Reply-To: <200303131423.h2DENa2U029773@oss.sgi.com> References: <200303131423.h2DENa2U029773@oss.sgi.com> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) Reply-To: rjmx@rjmx.net MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 3202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjmx@rjmx.net Precedence: bulk X-list: linux-xfs Content-Length: 2807 Lines: 69 I've been experiencing the same problem for several months now, on my Debian-sarge system (1.2G Athlon/512M RAM). I have xfs partitions on /usr (30G), /home (20G), /var (7.5G) (but not on /, too lazy to go through the conversion). Kernel versions I've had it happen with are 2.4.18 and 2.4.19, xfs versions uncertain but at least 1.2, perhaps 1.1 (but I may have been using one of the pre-1.2 versions). Again it's /usr that umount hangs on -- but not all the time. Sometimes it boots clean, sometimes it writes to disk for upwards of two minutes (!) and *then* boots clean. And sometimes it writes to disk for upwards of two minutes, or not at all, and then hangs. I haven't been able to correlate it with any particular disk usage pattern, unlike the person filing this bug. I might go a week or two without rebooting the thing and it'll boot clean, then reboot into Linux for five minutes, reboot again, and watch it lock up. The opposite is equally likely. I have tried reversing the mount order (which reverses the umount order) from having /usr first to having it last, and it still hangs on /usr, never the others. I've waited for the system to show no activity for 5-10 minutes and then rebooted, and still had it write to disk for a long time and then lock up. Suggestions for further troubleshooting welcome. .....Ron At Thu, 13 Mar 2003 06:23:36 -0800, bugzilla-daemon@oss.sgi.com wrote: > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 > > Summary: umount hangs after high disk load > Product: Linux XFS > Version: Current > Platform: IA32 > OS/Version: Linux > Status: NEW > Severity: major > Priority: Medium > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: atu@dmeti.dp.ua > > > kernel: 2.4.20+xfs(some modern snapshots up to 2003-03-09, from SGI FTP)+netfiler+openwall > build by gcc 3.2.(1-2), XFS in kernel, not in modules. > > All linux partitions is XFS: /=hda5(300M), /usr=hda8(7G), /var=hda9(2G), /home=hda10(12G). > swap=hda7(1G). 256M RAM. > Redhat-like initscripts. > > If afer boot run some disk-using program (I use updatedb), and than try to reboot or halt, > shutdown hangs in /etc/rc.d/init.d/halt while first umount loop. > Using -v as umount, I found, that hang occured while umounting /usr. > fuser shows no processes, using /usr. > The same result can be created by: > mount /usr -o remount,ro or Alt-PrintScreen-u > Alt-PrintScreen-P shows, shows, that current process in swapper. > Before hang essenshial disk activity (by LED, approx 10-20s). -- Ron Murray (rjmx@rjmx.net) http://www.rjmx.net/~ron GPG Public Key Fingerprint: F2C1 FC47 5EF7 0317 133C D66B 8ADA A3C4 D86C 74DE From owner-linux-xfs@oss.sgi.com Thu Mar 13 17:21:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 17:21:36 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2E1LUq9031174 for ; Thu, 13 Mar 2003 17:21:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2E1LT0l031172 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 17:21:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2E1LRqB031158 for ; Thu, 13 Mar 2003 17:21:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2E0Vgis022895; Thu, 13 Mar 2003 16:31:42 -0800 Date: Thu, 13 Mar 2003 16:31:42 -0800 Message-Id: <200303140031.h2E0Vgis022895@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 315 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From cattelan@thebarn.com 2003-03-13 16:31 ------- Can you drop the system into kdb and btp the umount process? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 14 01:59:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 01:59:57 -0800 (PST) Received: from obelix.wu-wien.ac.at (obelix.wu-wien.ac.at [137.208.3.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2E9x8q9012688 for ; Fri, 14 Mar 2003 01:59:49 -0800 Received: from ekelhardt ([137.208.224.91]) by obelix.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id KAA51996emf h9351252@obelix.wu-wien.ac.at; Fri, 14 Mar 2003 10:58:59 +0100 From: "Peter Alberer" To: "'Seth Mos'" , Subject: AW: nfs and number of open files Date: Fri, 14 Mar 2003 10:58:59 +0100 Message-ID: <000e01c2ea10$559c5400$5be0d089@ekelhardt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4.3.2.7.2.20030313140702.036dc338@pop.xs4all.nl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 3204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: h9351252@obelix.wu-wien.ac.at Precedence: bulk X-list: linux-xfs Content-Length: 764 Lines: 25 >At 16:12 12-3-2003 +0100, Peter Alberer wrote: >>Hi all, >> >>today I got the following error message on the nfs server: "too many >>open files in system". First I increased the limit >>(/proc/sys/fs/file-max) to 12000 (was 8192) files, to get things running >>again. But now I want to find out why so many files are open and I would >>like to know which files are open. > >It might be that the NFS client or webserver is no closing the file handles >the way it should. > >This might be related to the crash of the webserver. This might of course be a possibility... Do you know how I can find out which files are open via nfs? I tried lsof -N (which did not show anything) and nfsstat but could not find any info on files currently open via nfs? Tia, peter From owner-linux-xfs@oss.sgi.com Fri Mar 14 06:02:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 06:02:31 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EE2Kq9032039 for ; Fri, 14 Mar 2003 06:02:22 -0800 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 18tplF-0001qB-00 for linux-xfs@oss.sgi.com; Fri, 14 Mar 2003 14:02:13 +0000 Message-ID: <3E71E0E5.19053656@moving-picture.com> Date: Fri, 14 Mar 2003 14:02:13 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Fast/light weight XFS find utility? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 3205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 383 Lines: 14 Is there some sort of find like utility that is optimised for XFS file systems? i.e. something that can use the internals of XFS to be fast and have a low CPU overhead. I'm not necessarily looking for a full blown 'fast' find utility, but something that can at least return lists of files based on type, owner, date etc. Is there anything that can do this? Thanks James Pearson From owner-linux-xfs@oss.sgi.com Fri Mar 14 06:48:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 06:48:50 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EEmfq9002351 for ; Fri, 14 Mar 2003 06:48:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2EEmanH002050 for ; Fri, 14 Mar 2003 06:48:36 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA94640; Fri, 14 Mar 2003 08:48:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2EEmZwX29099238; Fri, 14 Mar 2003 08:48:35 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2EEmYv05267; Fri, 14 Mar 2003 08:48:34 -0600 Subject: Re: Fast/light weight XFS find utility? From: Steve Lord To: James Pearson Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E71E0E5.19053656@moving-picture.com> References: <3E71E0E5.19053656@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047653222.13590.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Mar 2003 08:48:31 -0600 X-archive-position: 3206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 693 Lines: 22 On Fri, 2003-03-14 at 08:02, James Pearson wrote: > Is there some sort of find like utility that is optimised for XFS file > systems? i.e. something that can use the internals of XFS to be fast and > have a low CPU overhead. > > I'm not necessarily looking for a full blown 'fast' find utility, but > something that can at least return lists of files based on type, owner, > date etc. > > Is there anything that can do this? > > Thanks > > James Pearson Take a look at xfs_ncheck as a starting point, there is a man page it uses some features of xfs_db, not necessarily that fast though. There is the bulkstat call which can walk all the inodes in the fs, see man 5 xfs for that. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 14 07:44:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 07:44:18 -0800 (PST) Received: from sweeney.demon.co.uk (213-152-33-154.dsl.eclipse.net.uk [213.152.33.154]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EFhxq9005514 for ; Fri, 14 Mar 2003 07:44:11 -0800 Received: from arequipa.sweeney.demon.co.uk (arequipa.sweeney.demon.co.uk [10.0.0.180]) by sweeney.demon.co.uk (Postfix) with SMTP id CD5721710E for ; Fri, 14 Mar 2003 15:43:42 +0000 (GMT) Date: Fri, 14 Mar 2003 15:46:09 +0000 From: Keith Matthews To: linux-xfs Subject: OT: Migration costs and problems Message-Id: <20030314154609.10be6b59.keith_m@sweeney.demon.co.uk> Organization: Frequentous Consultants Ltd X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: keith_m@sweeney.demon.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 2635 Lines: 54 People, I would like to use the list for a request that has little or nothing to do with xfs, but a lot to do with moves to open-source products. One task I am currently involved in is putting together a document defining the problems and costs of moving from proprietary platforms to FREE/OSS. The client wanted us to extract most of our input data from what is already available on the web, but (as any of you who have made such a study will be aware) there is much exhortation, much claiming that there will be cost savings, some TCO studies (which often have undocumented bases and hence must be regarded as useless) and not a lot else in any useful detail. We have produced a document which details the likely moves and the mapping of proprietary and OSS products involved and are producing some estimates of the costs - both transition and ongoing. We now need to try and find organisations that have done such a change and are prepared to talk to us and help us validate our statements. How much of the result will get published for general public use is up to the client, not us, as the contract specifies that they have copyright. If confidentiality is required then there should be no problem, but all parties will probably want to discusss terms. Note that we are talking all OSS products, not just Linux. Any product whose licence conforms to the OSI definition will be examined, although we have a preference list (primarily to reduce the excessive choice available in some areas). We are also talking moves from green screen mainframe environments as well as from MS server/desktop environments and proprietary Unix based solutions. Since the document covers all non-specialist application areas we have broken the recommendations down by functional areas (e.g.mail servers) and are happy to talk at that level. Our brief is to cover public administration but everyone involved recognises that private sector admin usage is just as valid. Development shops and such like are not being considered. The only cost to you will be time, we will send someone to you. We are prepared to travel to anywhere in Europe or the Mediterranean area plus the East Coast USA/Canada. The client's budget does not allow to travel further without special need. We will allow half to one day for each visit unless you advise that the discussions might take longer. We do not currently see dealing with things by email as appropriate due to the volume of discussion that might well be required. If anyone has appropriate experience and their management is willing for them to help would they please contact me directly. Thank you. From owner-linux-xfs@oss.sgi.com Fri Mar 14 08:40:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 08:40:08 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EGdMq9006277 for ; Fri, 14 Mar 2003 08:40:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2EGoKkq004963 for ; Fri, 14 Mar 2003 10:50:20 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA19588 for ; Fri, 14 Mar 2003 10:39:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2EGdGwX29113500 for ; Fri, 14 Mar 2003 10:39:16 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2EGd2C28571; Fri, 14 Mar 2003 10:39:02 -0600 Message-Id: <200303141639.h2EGd2C28571@stout.americas.sgi.com> Date: Fri, 14 Mar 2003 10:39:02 -0600 Subject: TAKE - Tone down some error reports X-archive-position: 3208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 426 Lines: 14 Bump the reporting threshold on calls to XFS_ERROR_REPORT which are most likely due to a simple user error. Date: Fri Mar 14 08:38:44 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141751a linux/fs/xfs/xfs_log_recover.c - 1.259 linux/fs/xfs/xfs_mount.c - 1.320 From owner-linux-xfs@oss.sgi.com Fri Mar 14 09:01:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 09:01:24 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EH1Kq9006855 for ; Fri, 14 Mar 2003 09:01:21 -0800 Received: (qmail 5101 invoked by uid 500); 14 Mar 2003 16:58:48 -0000 Subject: Oddity when upgrading from 2.4.10 to 2.4.20 xfs kernels. From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1047661127.4678.25.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Mar 2003 10:58:48 -0600 X-archive-position: 3209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 577 Lines: 17 Using the snapshot from Dec 18 2002 for 2.4.20 and upgrading a few systems from 2.4.10 to 2.4.20, we noticed some file corruption. It has been rather easily repairable, but it is quite odd. The actions we took are like any other kernel upgrade. Install the new kernel, add entries to grub or lilo, reboot. The one thing that we noted was different though was xfsprogs hadn't been upgraded on the boxes. I was curious if something like that would cause this behavior or if it is a 2.4.10->2.4.20 problem? TIA. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Mar 14 11:02:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 11:03:05 -0800 (PST) Received: from hqntws.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EJ2vq9008803 for ; Fri, 14 Mar 2003 11:02:58 -0800 Received: From hqntws.ciprico.com ([127.0.0.1]) by hqntws.ciprico.com (WebShield SMTP v4.5 MR1a); id 1047668567261; Fri, 14 Mar 2003 13:02:47 -0600 Received: from hqntex1.ciprico.com [172.20.0.8] by hqntws.ciprico.com - SurfControl E-mail Filter (4.5); Friday, 14 March 2003, 13:02:46 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 13:02:49 -0600 Message-ID: From: Antonio Ciorri To: "'linux-xfs@oss.sgi.com'" Date: Fri, 14 Mar 2003 13:02:48 -0600 Subject: Quota enable & disable. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 3210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aciorri@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 750 Lines: 20 Using quotas on our file systems: - We automatically enable the user quota enforcer in a file system when mounting with flag usrquota. - When the enforcer has to be disabled, we send a quotactl cmd with the option Q_XQUOTAOFF, later on when trying to enforce user quota, we have tried two ways: 1) sending quotactl cmd with the option Q_XQUOTAON, which is not working for us since it does not failed but the enforce is not being enabled or 2) by issuing a FS remount with flag usrquota, neither one of the above have been successful on enabling the user quota enforcer. So far unmounting the FS and mounting it again with flag usrquota is the only wait it has proven to be successful. Does anyone of you run into this before?. Thanks, Antonio. From owner-linux-xfs@oss.sgi.com Fri Mar 14 12:44:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 12:45:01 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EKipq9011410 for ; Fri, 14 Mar 2003 12:44:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2EKtnkq011940 for ; Fri, 14 Mar 2003 14:55:49 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA23353; Fri, 14 Mar 2003 14:44:45 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2EKijwX28822404; Fri, 14 Mar 2003 14:44:45 -0600 (CST) Subject: Re: Oddity when upgrading from 2.4.10 to 2.4.20 xfs kernels. From: Rusell Cattelan To: Austin Gonyou Cc: XFS List In-Reply-To: <1047661127.4678.25.camel@UberGeek> References: <1047661127.4678.25.camel@UberGeek> Content-Type: text/plain Organization: Message-Id: <1047674819.14962.7.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 14 Mar 2003 14:46:59 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 3211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 879 Lines: 23 On Fri, 2003-03-14 at 10:58, Austin Gonyou wrote: > Using the snapshot from Dec 18 2002 for 2.4.20 and upgrading a few > systems from 2.4.10 to 2.4.20, we noticed some file corruption. It has > been rather easily repairable, but it is quite odd. did you happen to save the output? Was the problem on multiple FSs or primarily the root FSs A problem was fixed in 1.2 that was related to the remount ro that happens to the root FS at shutdown time. > > The actions we took are like any other kernel upgrade. Install the new > kernel, add entries to grub or lilo, reboot. > > The one thing that we noted was different though was xfsprogs hadn't > been upgraded on the boxes. I was curious if something like that would > cause this behavior or if it is a 2.4.10->2.4.20 problem? No it shouldn't, but you should have the latest tools to do repair dump, attr etc... > > TIA. From owner-linux-xfs@oss.sgi.com Fri Mar 14 15:40:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 15:40:09 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ENdIq9026284 for ; Fri, 14 Mar 2003 15:40:01 -0800 Received: (qmail 6905 invoked by uid 500); 14 Mar 2003 23:36:46 -0000 Subject: Re: Oddity when upgrading from 2.4.10 to 2.4.20 xfs kernels. From: Austin Gonyou To: Rusell Cattelan Cc: XFS List In-Reply-To: <1047674819.14962.7.camel@rose.americas.sgi.com> References: <1047674819.14962.7.camel@rose.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1047685005.4678.57.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Mar 2003 17:36:45 -0600 X-archive-position: 3212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 20 On Fri, 2003-03-14 at 14:46, Rusell Cattelan wrote: > On Fri, 2003-03-14 at 10:58, Austin Gonyou wrote: > > Using the snapshot from Dec 18 2002 for 2.4.20 and upgrading a few > > systems from 2.4.10 to 2.4.20, we noticed some file corruption. It > has > > been rather easily repairable, but it is quite odd. > did you happen to save the output? > > Was the problem on multiple FSs or primarily the root FSs > A problem was fixed in 1.2 that was related to the remount ro > that happens to the root FS at shutdown time. > Yes...primarily root. I will update our patch with the latest snap if the fix is in there. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Mar 14 15:45:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 15:45:39 -0800 (PST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ENjYq9026747 for ; Fri, 14 Mar 2003 15:45:35 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 81C021C01A3D; Fri, 14 Mar 2003 18:45:34 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 48D8A1C000B9; Fri, 14 Mar 2003 18:45:34 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 14 Mar 2003 18:45:34 -0500 Message-ID: From: "DICKENS,CARY (HP-Loveland,ex2)" To: "'Antonio Ciorri'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Quota enable & disable. Date: Fri, 14 Mar 2003 18:45:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-archive-position: 3213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cary.dickens2@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 1904 Lines: 54 Antonio, I'm no expert, but I have been able to turn enforcement on and off without any problems. I can't remember when it happened, but there were some changes to the quota system that made it impossible to remount a volume and turn quotas on. Earlier xfs versions allowed this, the current versions do not. The volume in question must be mounted with quotas enabled and then you toggle enforcement on and off. What mount options do you use? I know that I _might_ want to have quotas on a file volume I am using, so I mount it with the following quota options: quota,qnoenforce,grpquota,gqnoenforce This way when I need to turn quota enforcement on, I can. The filesystem has been keeping the quotas calculated and all I have to do is send the quotactl command with Q_XQUOTAON. Example: quotactl(QCMD(Q_XQUOTAON,USRQUOTA), deviceFile, 0, (caddr_t) XFS_QUOTA_UDQ_ENFD); I hope this helps. Cary > -----Original Message----- > From: Antonio Ciorri [mailto:aciorri@ciprico.com] > Sent: Friday, March 14, 2003 12:03 PM > To: 'linux-xfs@oss.sgi.com' > Subject: Quota enable & disable. > > > Using quotas on our file systems: > > - We automatically enable the user quota enforcer in a file > system when mounting with flag usrquota. > - When the enforcer has to be disabled, we send a quotactl > cmd with the option Q_XQUOTAOFF, later on when trying to > enforce user quota, we have tried two ways: > 1) sending quotactl cmd with the option Q_XQUOTAON, which is > not working for us since it does not failed but the enforce > is not being enabled or 2) by issuing a FS remount with flag > usrquota, neither one of the above have been successful on > enabling the user quota enforcer. So far unmounting the FS > and mounting it again with flag usrquota is the only wait it > has proven to be successful. > > Does anyone of you run into this before?. > > Thanks, > > Antonio. > > From owner-linux-xfs@oss.sgi.com Sat Mar 15 13:05:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Mar 2003 13:05:22 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2FL59q9006583 for ; Sat, 15 Mar 2003 13:05:10 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2FL50uX025821 for ; Sat, 15 Mar 2003 13:05:04 -0800 From: "l.a walsh" To: Subject: extsize in data? Date: Sat, 15 Mar 2003 13:05:00 -0800 Message-ID: <001501c2eb36$8cacee60$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 3214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2560 Lines: 54 I notice you can specify extent sizes as a sub-option to the realtime section, but it doesn't seem to be an option for the normal data subsection....a bit of a bummer. Is there a reason why? With a maximum block size of 4k (assuming the man page about linux limitations to page size are still accurate and assuming, I think, Linux uses a 4k pagesize) and 64K max extent, that's 256k. Many of my files are > 256k, on one of my larger disks, >15000 files. Is this a temporary limitation or is this sorta a fixed quality of the fs? Also, there was a case of someone making IMAX films writing 4x48Mb or close to 200Mb/second to an XFS disk over SMBFS for 12+hours. Quick math ~> 2 terabytes/file. Does that imply the files were composed of over 8 million extents each? If you had 4 separate streams writing to disk at the same time, what would be the likely placement of the extents for each stream? interleaving with the streams or contiguous/stream, or what? Or is it likely undefined/semi-random -- I guess I'd assume starting with an empty disk for best case. Background/why I'm asking: I'm having a discussion on the relative merits of NTFS that seems to need constant defragmentation vs. Unix file systems that seem to need (or have) little (xfs_defrag ~once a week by default), or no defragmentation process (assumption generally being that fragmentation stays below 5-10% if disk space is kept below 90 or 95% usage -- (is that the "common wisdom"? Is it even valid?)). I somehow got into this by proposing that instead of all these companies writing custom, run-in-the-background, or centrally controlled defragmenting utilities, they could just invest in porting over some of the linux file systems to NT, and make money off support, GUI and network management (XFS was one I suggested, of course). Then started getting into a discussion that is starting to be on the edge of my knowledge -- and, while pointing to the ancient XFS white paper, it also says that fragmentation is expected to be a long-term issue with files like outlook .pst files, since they are written and rewritten in small chunks over a large file with the large file being extended as necessary, in small bits over time (the one corresponding to my main mail folder is >148M...it might be painful, but I'm tempted to put it on smbfs so the file would be on xfs for a while and turn off the xfs-defragger for a week or so (I run mine nightly...but I'm a bit more fanatical about optimizing layout). Any benchmark studies on NTFS/XFS relative speed? Thanks, Linda From owner-linux-xfs@oss.sgi.com Sat Mar 15 13:21:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Mar 2003 13:21:48 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLcq9007171 for ; Sat, 15 Mar 2003 13:21:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FLLcKq007167 for linux-xfs@oss.sgi.com; Sat, 15 Mar 2003 13:21:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLaqD007141 for ; Sat, 15 Mar 2003 13:21:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FL5tRB006657; Sat, 15 Mar 2003 13:05:55 -0800 Date: Sat, 15 Mar 2003 13:05:55 -0800 Message-Id: <200303152105.h2FL5tRB006657@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-15 13:05 ------- Created an attachment (id=68) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=68&action=view) result of btp(mount) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Mar 15 13:21:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Mar 2003 13:21:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLcq9007172 for ; Sat, 15 Mar 2003 13:21:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FLLcEk007168 for linux-xfs@oss.sgi.com; Sat, 15 Mar 2003 13:21:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLaqF007141 for ; Sat, 15 Mar 2003 13:21:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FLGEiO007080; Sat, 15 Mar 2003 13:16:14 -0800 Date: Sat, 15 Mar 2003 13:16:14 -0800 Message-Id: <200303152116.h2FLGEiO007080@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1594 Lines: 42 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From rjmx@rjmx.net 2003-03-15 13:16 ------- I've been experiencing the same problem for several months now, on my Debian-sarge system (1.2G Athlon/512M RAM). I have xfs partitions on /usr (30G), /home (20G), /var (7.5G) (but not on /, too lazy to go through the conversion). Kernel versions I've had it happen with are 2.4.18 and 2.4.19, xfs versions uncertain but at least 1.2, perhaps 1.1 (but I may have been using one of the pre-1.2 versions). Again it's /usr that umount hangs on -- but not all the time. Sometimes it boots clean, sometimes it writes to disk for upwards of two minutes (!) and *then* boots clean. And sometimes it writes to disk for upwards of two minutes, or not at all, and then hangs. I haven't been able to correlate it with any particular disk usage pattern, unlike the person filing this bug. I might go a week or two without rebooting the thing and it'll boot clean, then reboot into Linux for five minutes, reboot again, and watch it lock up. The opposite is equally likely. I have tried reversing the mount order (which reverses the umount order) from having /usr first to having it last, and it still hangs on /usr, never the others. I've waited for the system to show no activity for 5-10 minutes and then rebooted, and still had it write to disk for a long time and then lock up. Suggestions for further troubleshooting welcome. .....Ron ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Mar 16 09:21:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 09:21:49 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2GHLgq9022577 for ; Sun, 16 Mar 2003 09:21:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2GHLgSS022574 for linux-xfs@oss.sgi.com; Sun, 16 Mar 2003 09:21:42 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2GHLeqB022561 for ; Sun, 16 Mar 2003 09:21:40 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2GGqiSX022315; Sun, 16 Mar 2003 08:52:45 -0800 Date: Sun, 16 Mar 2003 08:52:45 -0800 Message-Id: <200303161652.h2GGqiSX022315@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 345 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-16 08:52 ------- bta shows no processes with pagebuf_lock (exept mount), and no processes in __down at all. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Mar 16 16:46:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 16:46:28 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H0kFq9025256 for ; Sun, 16 Mar 2003 16:46:16 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H0k99n023528 for ; Sun, 16 Mar 2003 16:46:09 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H0iq7L2000314 for ; Mon, 17 Mar 2003 11:44:52 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H0ipXk2002954 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 11:44:51 +1100 (EST) Date: Mon, 17 Mar 2003 11:44:51 +1100 (EST) From: Nathan Scott Message-Id: <200303170044.h2H0ipXk2002954@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - types X-archive-position: 3218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 432 Lines: 16 Find more appropriate homes for uuid_t, timespec_t and xfs_dirent_t defs. Date: Sun Mar 16 16:44:06 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141837a linux/fs/xfs/xfs_types.h - 1.67 linux/fs/xfs/linux/xfs_linux.h - 1.102 linux/fs/xfs/support/uuid.h - 1.8 linux/fs/xfs/support/time.h - 1.10 From owner-linux-xfs@oss.sgi.com Sun Mar 16 17:46:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 17:47:05 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H1kxq9027782 for ; Sun, 16 Mar 2003 17:46:59 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H1krnH006628 for ; Sun, 16 Mar 2003 17:46:53 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H1ja7L2005420 for ; Mon, 17 Mar 2003 12:45:36 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H1jZ5w2003739 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 12:45:35 +1100 (EST) Date: Mon, 17 Mar 2003 12:45:35 +1100 (EST) From: Nathan Scott Message-Id: <200303170145.h2H1jZ5w2003739@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor iops.c cleanup X-archive-position: 3219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 15 Remove unneeded initialisations to zero, formatting cleanups, remove a no-longer-correct-comment, fix up symlink error path code, several minor changes to help keep this code a little more in sync with 2.5. Date: Sun Mar 16 16:58:22 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141838a linux/fs/xfs/linux/xfs_iops.c - 1.187 From owner-linux-xfs@oss.sgi.com Sun Mar 16 18:11:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 18:11:27 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H2BKq9028337 for ; Sun, 16 Mar 2003 18:11:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H2BE9n028002 for ; Sun, 16 Mar 2003 18:11:14 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H29v7L2002809 for ; Mon, 17 Mar 2003 13:09:57 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H29vOJ2005685 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 13:09:57 +1100 (EST) Date: Mon, 17 Mar 2003 13:09:57 +1100 (EST) From: Nathan Scott Message-Id: <200303170209.h2H29vOJ2005685@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor header shuffling X-archive-position: 3220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 482 Lines: 17 Minor header shuffling, removing a bunch of already-included files and allowing 2.4/2.5 to be slightly more in sync. Date: Sun Mar 16 17:55:13 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141841a linux/fs/xfs/linux/xfs_lrw.h - 1.33 linux/fs/xfs/linux/xfs_lrw.c - 1.181 linux/fs/xfs/linux/xfs_file.c - 1.87 linux/fs/xfs/linux/xfs_aops.c - 1.28 From owner-linux-xfs@oss.sgi.com Sun Mar 16 18:24:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 18:24:04 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H2NLq9028862 for ; Sun, 16 Mar 2003 18:24:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H2YQkq028695 for ; Sun, 16 Mar 2003 20:34:27 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H2Lw7L2008916 for ; Mon, 17 Mar 2003 13:21:58 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H2LwD12004996 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 13:21:58 +1100 (EST) Date: Mon, 17 Mar 2003 13:21:58 +1100 (EST) From: Nathan Scott Message-Id: <200303170221.h2H2LwD12004996@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ioctl permissions X-archive-position: 3221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 534 Lines: 16 Fix permission checks for some ioctls. Its now possible for ordinary users to use the preallocation calls if unwritten extents are enabled, and a couple of places where we were allowing operations if unwritten extents are enabled, but shouldn't have been, have been closed up. Date: Sun Mar 16 18:18:19 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141842a linux/fs/xfs/linux/xfs_ioctl.c - 1.88 From owner-linux-xfs@oss.sgi.com Sun Mar 16 19:00:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 19:00:09 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H301q9031042 for ; Sun, 16 Mar 2003 19:00:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H3B2kq029146 for ; Sun, 16 Mar 2003 21:11:07 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H2wY7L1985727 for ; Mon, 17 Mar 2003 13:58:34 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H2wX922010952 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 13:58:33 +1100 (EST) Date: Mon, 17 Mar 2003 13:58:33 +1100 (EST) From: Nathan Scott Message-Id: <200303170258.h2H2wX922010952@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - iget+init code tidyup X-archive-position: 3222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 725 Lines: 22 Move some of the Linux-specific iget code out of the XFS core code, move some of the initialisation code to a better spot (super.c -> vfs.c), fix up some whitespace abuse and some more code formatting inconsistencies, esp. in xfs_vnode.c and xfs_vfs.c. Date: Sun Mar 16 18:46:55 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141844a linux/fs/xfs/xfs_vfsops.c - 1.409 linux/fs/xfs/xfs_iget.c - 1.182 linux/fs/xfs/linux/xfs_vfs.c - 1.40 linux/fs/xfs/linux/xfs_vnode.c - 1.110 linux/fs/xfs/linux/xfs_super.h - 1.39 linux/fs/xfs/linux/xfs_super.c - 1.243 linux/fs/xfs/linux/xfs_vfs.h - 1.34 From owner-linux-xfs@oss.sgi.com Sun Mar 16 19:09:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 19:09:57 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H39Aq9031534 for ; Sun, 16 Mar 2003 19:09:51 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H3949n030895 for ; Sun, 16 Mar 2003 19:09:05 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H37m7L2008266 for ; Mon, 17 Mar 2003 14:07:48 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H37mYJ2006915 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 14:07:48 +1100 (EST) Date: Mon, 17 Mar 2003 14:07:48 +1100 (EST) From: Nathan Scott Message-Id: <200303170307.h2H37mYJ2006915@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bmap man page X-archive-position: 3223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 465 Lines: 16 Remove an incorrect statement from the xfs_bmap(8) man page. Date: Sun Mar 16 19:07:16 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141845a cmd/xfsprogs/man/man8/xfs_bmap.8 - 1.3 - Remove an incorrect statement from the xfs_bmap(8) man page - we have done a filesystem-type check before issuing any ioctls for some time. From owner-linux-xfs@oss.sgi.com Sun Mar 16 19:17:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 19:17:34 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H3HOq9031987 for ; Sun, 16 Mar 2003 19:17:24 -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 h2H3HH9n031258 for ; Sun, 16 Mar 2003 19:17:18 -0800 Received: from elmo.melbourne.sgi.com (elmo.melbourne.sgi.com [134.14.55.238]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA28013; Mon, 17 Mar 2003 14:16:01 +1100 Received: from elmo.melbourne.sgi.com (localhost [127.0.0.1]) by elmo.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA01629; Mon, 17 Mar 2003 14:16:00 +1100 (AEDT) Message-Id: <200303170316.OAA01629@elmo.melbourne.sgi.com> X-Mailer: exmh version 2.5 05/28/2002 with nmh-1.0.4 To: "l.a walsh" cc: linux-xfs@oss.sgi.com Subject: Re: extsize in data? In-Reply-To: Message from "l.a walsh" of "Sat, 15 Mar 2003 13:05:00 -0800." <001501c2eb36$8cacee60$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Mar 2003 14:16:00 +1100 From: Daniel Moore X-archive-position: 3224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dxm@elmo.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1565 Lines: 35 "l.a walsh" writes: => I notice you can specify extent sizes as a sub-option to the realtime => section, but it doesn't seem to be an option for the normal data => subsection....a bit of a bummer. Is there a reason why? With a maximum => block size of 4k (assuming the man page about linux limitations to page => size are still accurate and assuming, I think, Linux uses a 4k pagesize) an => d => 64K max extent, that's 256k. The real time partition generally uses much larger datablocks and uses a different allocation scheme to ensure fast access to blocks. There's no option to set extent size on a normal XFS filesystem because XFS tries to allocate your files in as large extents as possible (using delayed allocation). How effective this is depends on the write patterns, preallocation and free space/fragmentation on your disk. Try out 'xfs_bmap' on a file to see how it's actually layed out in extents. => Many of my files are > 256k, on one of my larger disks, >15000 files. => => Is this a temporary limitation or is this sorta a fixed quality of => the fs? IRIX allows FSB sizes between 512 bytes and 64k. Linux XFS only allows <= PAGE_SIZE FSB sizes due to a limitiation of the linux memory allocator which would make support for large block sizes inefficient. ------------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Australian Software Group Fax: +61-3-98132378 ------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Mar 16 20:29:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 20:29:50 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H4Tgq9002083 for ; Sun, 16 Mar 2003 20:29:43 -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 h2H4Ta9n002177 for ; Sun, 16 Mar 2003 20:29:37 -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 PAA28555; Mon, 17 Mar 2003 15:28:20 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA74364; Mon, 17 Mar 2003 15:28:19 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2H4PVom000892; Mon, 17 Mar 2003 15:25:31 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2H4PULd000890; Mon, 17 Mar 2003 15:25:30 +1100 Date: Mon, 17 Mar 2003 15:25:30 +1100 From: Nathan Scott To: Antonio Ciorri Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Quota enable & disable. Message-ID: <20030317042530.GA855@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 703 Lines: 22 On Fri, Mar 14, 2003 at 01:02:48PM -0600, Antonio Ciorri wrote: > Using quotas on our file systems: > > - We automatically enable the user quota enforcer in a file system when > mounting with flag usrquota. > - When the enforcer has to be disabled, we send a quotactl cmd with the > option Q_XQUOTAOFF, later on when trying to enforce user quota, we have > tried two ways: As suggested, it sounds like you should use Q_XQUOTAON and change state from ENFD (quota enforced) to ACCT (accounting only). Using Q_XQUOTAOFF results in the complete quota state for the filesystem being tossed, and a quotacheck (expensive) will need to be done during the next mount with quota enabled. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 16 20:34:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 20:34:38 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H4Yaq9002659 for ; Sun, 16 Mar 2003 20:34:36 -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 h2H4YT9n002468 for ; Sun, 16 Mar 2003 20:34:30 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28604; Mon, 17 Mar 2003 15:33:13 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA51199; Mon, 17 Mar 2003 15:33:13 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2H4UPom000929; Mon, 17 Mar 2003 15:30:25 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2H4UO4x000927; Mon, 17 Mar 2003 15:30:24 +1100 Date: Mon, 17 Mar 2003 15:30:24 +1100 From: Nathan Scott To: "DICKENS,CARY (HP-Loveland,ex2)" Cc: "'Antonio Ciorri'" , "'linux-xfs@oss.sgi.com'" Subject: Re: Quota enable & disable. Message-ID: <20030317043024.GB855@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 979 Lines: 30 hi, On Fri, Mar 14, 2003 at 06:45:28PM -0500, DICKENS,CARY (HP-Loveland,ex2) wrote: > Antonio, > > I'm no expert, but I have been able to turn enforcement on and off without > any problems. I can't remember when it happened, but there were some > changes to the quota system that made it impossible to remount a volume and > turn quotas on. Earlier xfs versions allowed this, the current versions do Enabling quota during remount has never been implemented in XFS. > not. The volume in question must be mounted with quotas enabled and then > you toggle enforcement on and off. *nod* > What mount options do you use? I know that I _might_ want to have quotas on > a file volume I am using, so I mount it with the following quota options: > quota,qnoenforce,grpquota,gqnoenforce Your *noenforce options will be ignored because you have also given the enforce options (quota,grpquota). I think what you intended was just "uqnoenforce,gqnoenforce". cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 16 22:19:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 22:19:16 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H6J9q9004075 for ; Sun, 16 Mar 2003 22:19:09 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H6J29n008068 for ; Sun, 16 Mar 2003 22:19:03 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H6Hk7L1768763 for ; Mon, 17 Mar 2003 17:17:46 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H6HkMo2032311 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 17:17:46 +1100 (EST) Date: Mon, 17 Mar 2003 17:17:46 +1100 (EST) From: Nathan Scott Message-Id: <200303170617.h2H6HkMo2032311@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota/dmapi layering rejigged X-archive-position: 3227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2936 Lines: 74 Separates the quota source into its own subdirectory ala dmapi. Pushes a bunch of quota- and dmapi-specific code down into these subdirs which previously was compiled into the core XFS code, and don't descend into these subdirs if options config'd off. cheers. Date: Sun Mar 16 22:02:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141850a linux/fs/xfs/quota/xfs_qm_bhv.c - 1.1 linux/fs/xfs/quota/xfs_qm_stats.h - 1.1 linux/fs/xfs/quota/xfs_qm_stats.c - 1.1 linux/fs/xfs/dmapi/dmapi_xfs.c - 1.1 linux/fs/xfs/quota/Makefile - 1.1 linux/fs/xfs/xfs_trans_dquot.c 1.41 renamed to linux/fs/xfs/quota/xfs_trans_dquot.c 1.1 linux/fs/xfs/xfsidbg.c - 1.215 linux/fs/xfs/xfs_quota_priv.h 1.24 renamed to linux/fs/xfs/quota/xfs_quota_priv.h 1.1 linux/fs/xfs/xfs_vnodeops.c - 1.586 linux/fs/xfs/xfs_dqblk.h - 1.9 linux/fs/xfs/xfs_dmapi.h - 1.35 linux/fs/xfs/Makefile - 1.154 linux/fs/xfs/xfs_qm_syscalls.c 1.74 renamed to linux/fs/xfs/quota/xfs_qm_syscalls.c 1.1 linux/fs/xfs/xfs_log_recover.c - 1.260 linux/fs/xfs/xfs_dquot_item.h 1.9 renamed to linux/fs/xfs/quota/xfs_dquot_item.h 1.1 linux/fs/xfs/xfs_dquot_item.c 1.34 renamed to linux/fs/xfs/quota/xfs_dquot_item.c 1.1 linux/fs/xfs/xfs_vfsops.c - 1.410 linux/fs/xfs/xfs_iget.c - 1.183 linux/fs/xfs/xfs_bmap_btree.c - 1.134 linux/fs/xfs/xfs_dquot.h 1.23 renamed to linux/fs/xfs/quota/xfs_dquot.h 1.1 linux/fs/xfs/xfs_dquot.c 1.74 renamed to linux/fs/xfs/quota/xfs_dquot.c 1.1 linux/fs/xfs/xfs_mount.h - 1.167 linux/fs/xfs/xfs_mount.c - 1.321 linux/fs/xfs/xfs_qm.h 1.27 renamed to linux/fs/xfs/quota/xfs_qm.h 1.1 linux/fs/xfs/xfs_qm.c 1.95 renamed to linux/fs/xfs/quota/xfs_qm.c 1.1 linux/fs/xfs/xfs_trans.c - 1.141 linux/fs/xfs/xfs_utils.c - 1.58 linux/fs/xfs/xfs_bmap.c - 1.301 linux/fs/xfs/xfs_quota.h - 1.30 linux/fs/xfs/xfs_rename.c - 1.48 linux/fs/xfs/xfs_attr.c - 1.102 linux/fs/xfs/linux/xfs_lrw.c - 1.182 linux/fs/xfs/linux/xfs_vfs.c - 1.41 linux/fs/xfs/linux/xfs_globals.c - 1.42 linux/fs/xfs/linux/xfs_file.c - 1.88 linux/fs/xfs/linux/xfs_super.h - 1.40 linux/fs/xfs/linux/xfs_super.c - 1.244 linux/fs/xfs/dmapi/dmapi_private.h - 1.9 linux/fs/xfs/linux/xfs_globals.h - 1.15 linux/fs/xfs/xfs.h - 1.35 linux/fs/xfs/linux/xfs_vfs.h - 1.36 linux/fs/xfs/linux/xfs_stats.c - 1.10 linux/fs/xfs/linux/xfs_stats.h - 1.6 linux/fs/xfs/dmapi/dmapi.h - 1.2 linux/fs/xfs/linux/xfs_iomap.c - 1.7 linux/fs/xfs/xfs_dmops.c - 1.2 linux/fs/xfs/xfs_qmops.c - 1.3 - Separate the quota source into its own subdirectory ala dmapi. Push a bunch of quota- and dmapi-specific code down into these subdirs which previously was compiled into the core XFS code, and don't descend into these subdirs if options config'd off. linux/fs/xfs/dmapi/Makefile - 1.19 linux/fs/xfs/dmapi/dmapi_mountinfo.c - 1.13 linux/fs/xfs/dmapi/dmapi_sysent.c - 1.20 - Trivial cleanup. From owner-linux-xfs@oss.sgi.com Sun Mar 16 23:39:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 23:39:17 -0800 (PST) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H7cTq9004856 for ; Sun, 16 Mar 2003 23:39:09 -0800 Received: from erbenson.alaska.net (110-pm14.nwc.alaska.net [209.112.141.110]) by iris.acsalaska.net (8.12.8/8.12.8) with ESMTP id h2H7cRB4084300 for ; Sun, 16 Mar 2003 22:38:27 -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 75B433A0B for ; Sun, 16 Mar 2003 22:38:24 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 607C84104E2; Sun, 16 Mar 2003 22:38:24 -0900 (AKST) Date: Sun, 16 Mar 2003 22:38:24 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] libdisk: add check for Mac (Apple) partition tables Message-ID: <20030317073824.GA1079@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2895 Lines: 101 --cvVnyQ+4j833TQvp Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable mkfs.xfs checks for known filesystems and partition types so it can warn the user if they may be overwriting existing data, this check does not include Apple partition tables. the following patch adds a check for mac partition tables to libdisk. i have tested it on both big and little endian systems, it works as expected. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_libdisk.diff" Content-Transfer-Encoding: quoted-printable Index: libdisk/pttype.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/libdisk/pttype.c,v retrieving revision 1.5 diff -u -r1.5 pttype.c --- libdisk/pttype.c 12 Nov 2002 04:01:08 -0000 1.5 +++ libdisk/pttype.c 17 Mar 2003 07:34:38 -0000 @@ -93,6 +93,14 @@ return !csum; } =20 +static int +mac_parttable(char *base) +{ + return (ntohs(maclabel(base)->magic) =3D=3D MAC_LABEL_MAGIC || + ntohs(maclabel(base)->magic) =3D=3D MAC_PARTITION_MAGIC || + ntohs(maclabel(base)->magic) =3D=3D MAC_OLD_PARTITION_MAGIC); +} + =20 char * pttype(char *device) @@ -114,6 +122,8 @@ type =3D "AIX"; else if (dos_parttable(buf)) type =3D "DOS"; + else if (mac_parttable(buf)) + type =3D "Mac"; } =20 if (fd >=3D 0) Index: libdisk/pttype.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/libdisk/pttype.h,v retrieving revision 1.2 diff -u -r1.2 pttype.h --- libdisk/pttype.h 12 Nov 2002 04:01:08 -0000 1.2 +++ libdisk/pttype.h 17 Mar 2003 07:34:38 -0000 @@ -39,3 +39,13 @@ #define AIX_LABEL_MAGIC 0xc9c2d4c1 #define AIX_LABEL_MAGIC_SWAPPED 0xc1d4c2c9 #define aixlabel(x) ((aix_partition *)x) + +typedef struct { + unsigned short magic; + /* ... */ +} mac_partition; + +#define MAC_LABEL_MAGIC 0x4552 +#define MAC_PARTITION_MAGIC 0x504d +#define MAC_OLD_PARTITION_MAGIC 0x5453 +#define maclabel(x) ((mac_partition *)x) --mP3DRpeJDSE+ciuQ-- --cvVnyQ+4j833TQvp 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 iEYEARECAAYFAj51e3AACgkQJKx7GixEevx7CgCeIvK9ZmXZdpjs0dgKgOb2sUQT X8QAn2pBHvorAFTgeoSOrkTACTlk4gXT =dydj -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From owner-linux-xfs@oss.sgi.com Mon Mar 17 00:22:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 00:22:57 -0800 (PST) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H8M7q9014921 for ; Mon, 17 Mar 2003 00:22:48 -0800 Received: from erbenson.alaska.net (110-pm14.nwc.alaska.net [209.112.141.110]) by hermod.slb.nwc.acsalaska.net (8.12.8/8.12.8) with ESMTP id h2H8M5i1052434 for ; Sun, 16 Mar 2003 23:22:06 -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 AD4E93A0B for ; Sun, 16 Mar 2003 23:22:04 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 517864104E2; Sun, 16 Mar 2003 23:22:04 -0900 (AKST) Date: Sun, 16 Mar 2003 23:22:04 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] libdisk: fix broken HFS filesystem check Message-ID: <20030317082204.GC1079@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GdbWtwDHkcXqP16f" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1783 Lines: 60 --GdbWtwDHkcXqP16f Content-Type: multipart/mixed; boundary="m1UC1K4AOz1Ywdkx" Content-Disposition: inline --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable the test for HFS filesystems is broken, the attached patch fixes it. also the endianess handling in this file appears to be completly insane, but i am not going to address this issue... --=20 Ethan Benson http://www.alaska.net/~erbenson/ --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fstype.c.diff" Content-Transfer-Encoding: quoted-printable Index: libdisk/fstype.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/libdisk/fstype.c,v retrieving revision 1.5 diff -u -r1.5 fstype.c --- libdisk/fstype.c 28 Aug 2002 22:31:45 -0000 1.5 +++ libdisk/fstype.c 17 Mar 2003 08:19:54 -0000 @@ -313,7 +313,7 @@ if ((hfsmagic(hfssb) =3D=3D HFS_SUPER_MAGIC && hfsblksize(hfssb) =3D=3D 0x20000) || (swapped(hfsmagic(hfssb)) =3D=3D HFS_SUPER_MAGIC && - hfsblksize(hfssb) =3D=3D 0x200)) + hfsblksize(hfssb) =3D=3D 0x20000)) type =3D "hfs"; } =20 --m1UC1K4AOz1Ywdkx-- --GdbWtwDHkcXqP16f 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 iEYEARECAAYFAj51hawACgkQJKx7GixEevw53ACdEyJ1yn2q9kvxmnQlHcd17tyE wI0AoJGatm9Wg3Ja25hiGYLO39bUl7E7 =Q43C -----END PGP SIGNATURE----- --GdbWtwDHkcXqP16f-- From owner-linux-xfs@oss.sgi.com Mon Mar 17 00:44:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 00:44:20 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H8iBq9015528 for ; Mon, 17 Mar 2003 00:44:13 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18uqE4-0000zB-00 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 08:44:08 +0000 Date: Mon, 17 Mar 2003 08:44:08 +0000 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] libdisk: fix broken HFS filesystem check Message-ID: <20030317084407.A3766@infradead.org> References: <20030317082204.GC1079@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030317082204.GC1079@plato.local.lan>; from erbenson@alaska.net on Sun, Mar 16, 2003 at 11:22:04PM -0900 X-archive-position: 3230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 403 Lines: 10 On Sun, Mar 16, 2003 at 11:22:04PM -0900, Ethan Benson wrote: > > the test for HFS filesystems is broken, the attached patch fixes it. > > also the endianess handling in this file appears to be completly > insane, but i am not going to address this issue... fstype.c is taken verbatim from the mount source in util-linux. Please submit a patch to Andries and drop us a note to resync once it's in. From owner-linux-xfs@oss.sgi.com Mon Mar 17 08:21:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 08:21:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HGLlq9027548 for ; Mon, 17 Mar 2003 08:21:47 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HGLlQk027545 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 08:21:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HGLiqB027531 for ; Mon, 17 Mar 2003 08:21:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HG1dr2027357; Mon, 17 Mar 2003 08:01:39 -0800 Date: Mon, 17 Mar 2003 08:01:39 -0800 Message-Id: <200303171601.h2HG1dr2027357@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 431 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From cattelan@thebarn.com 2003-03-17 08:01 ------- Argghh this bit of code again! XFS_log_write_unmount_ro Calls 3 times... can you toss in some printk's in to find out which of the 3 calls is hanging, dump the pincount also. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 09:21:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 09:21:50 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HHLjq9001374 for ; Mon, 17 Mar 2003 09:21:45 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HHLjxL001372 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 09:21:45 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HHLhqB001359 for ; Mon, 17 Mar 2003 09:21:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HH7qtO001022; Mon, 17 Mar 2003 09:07:52 -0800 Date: Mon, 17 Mar 2003 09:07:52 -0800 Message-Id: <200303171707.h2HH7qtO001022@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 231] New: XFS does not update directory mtime when changes made in directory X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1180 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=231 Summary: XFS does not update directory mtime when changes made in directory Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: kpfleming@cox.net What kernel are you using: 2.5.64-bk7 Where did the XFS code come from? (CVS, Linus, your distribution, etc): Linus Description of Problem: Create a directory on an XFS filesystem. stat the directory and note the mtime and ctime. touch a file in the directory (creating a new file). stat the directory again. The ctime will have been updated, but not the mtime. "sync" has no effect. Repeatedly creating/removing files and/or directories will _sometimes_ update the mtime, but when it does update it changes to a time still in the past, not the time of the most recent change in the directory. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 14:21:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 14:21:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HMLkq9011644 for ; Mon, 17 Mar 2003 14:21:46 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HMLkZi011642 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 14:21:46 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HMLiqB011629 for ; Mon, 17 Mar 2003 14:21:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HLO2dF011208; Mon, 17 Mar 2003 13:24:02 -0800 Date: Mon, 17 Mar 2003 13:24:02 -0800 Message-Id: <200303172124.h2HLO2dF011208@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 232] New: mkfs.xfs from xfsprogs-2.3.5 fails on 1.1TB partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1589 Lines: 61 http://oss.sgi.com/bugzilla/show_bug.cgi?id=232 Summary: mkfs.xfs from xfsprogs-2.3.5 fails on 1.1TB partition Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: yocum@fnal.gov If this is a userspace bug, what version of the package are you using: xfsprogs-2.3.5 What kernel are you using: RH2.4.18-18 w/ xfs1.2 Where did the XFS code come from? (CVS, Linus, your distribution, etc): SGI Description of Problem: # mkfs.xfs -f -i size /dev/md0 log stripe unit (4194304 bytes) is too large for kernel to handle (max 256k) Downgrading to v2.0.1 allows me to mkfs.xfs How Reproducible: Every time, multiple machines. Steps to Reproduce: 1. git yerself a 1.1TB box... 2. install xfsprogs 2.3.5 3. try to mkfs.xfs Actual Results: See above. Expected Results: ]# mkfs.xfs -f /dev/md1 meta-data=/dev/md1 isize=256 agcount=266, agsize=1048576 blks data = bsize=4096 blocks=278605824, imaxpct=25 = sunit=1024 swidth=2048 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768 realtime =none extsz=8388608 blocks=0, rtextents=0 Additional Information: Toodles, Dan ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 14:42:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 14:42:34 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2HMgNq9012236 for ; Mon, 17 Mar 2003 14:42:25 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18v3HQ-0006HS-00 for ; Mon, 17 Mar 2003 23:40:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18v3AR-0005mW-00 for ; Mon, 17 Mar 2003 23:33:15 +0100 From: Nicholas Wourms Subject: What happened to the linux-2.4-xfs cvs tree? Date: Mon, 17 Mar 2003 17:31:04 -0500 Message-ID: <3E764CA8.5050404@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nwourms@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 178 Lines: 9 Hi, I just went to pull the sources from the linux-2.4-xfs tree and I noticed it is gone for both cvs and cvsweb. Was this intentional? Will it be back? Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Mon Mar 17 14:58:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 14:58:21 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2HMwHq9012771 for ; Mon, 17 Mar 2003 14:58:18 -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 h2HMwB9n012501 for ; Mon, 17 Mar 2003 14:58:11 -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 JAA06332 for ; Tue, 18 Mar 2003 09:56:55 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA13175 for ; Tue, 18 Mar 2003 09:56:54 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2HMs5SO000998 for ; Tue, 18 Mar 2003 09:54:05 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2HMs5hV000996 for linux-xfs@oss.sgi.com; Tue, 18 Mar 2003 09:54:05 +1100 Date: Tue, 18 Mar 2003 09:54:05 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] libdisk: add check for Mac (Apple) partition tables Message-ID: <20030317225405.GA948@frodo> References: <20030317073824.GA1079@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030317073824.GA1079@plato.local.lan> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 495 Lines: 18 On Sun, Mar 16, 2003 at 10:38:24PM -0900, Ethan Benson wrote: > > mkfs.xfs checks for known filesystems and partition types so it can > warn the user if they may be overwriting existing data, this check > does not include Apple partition tables. the following patch adds a > check for mac partition tables to libdisk. > > i have tested it on both big and little endian systems, it works as > expected. > Thanks Ethan - looks fine to me, I'll check it in later today. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 17 15:21:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 15:21:49 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HNLlq9013398 for ; Mon, 17 Mar 2003 15:21:47 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HNLlmK013396 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 15:21:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HNLjqB013383 for ; Mon, 17 Mar 2003 15:21:45 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HMnxEr012720; Mon, 17 Mar 2003 14:49:59 -0800 Date: Mon, 17 Mar 2003 14:49:59 -0800 Message-Id: <200303172249.h2HMnxEr012720@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 462 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-17 14:49 ------- Hang observed while first call to pagebuf_delwri_flush from XFS_log_write_remount_ro, before loop, (in case of remount ro), and while single call to pagebuf_delwri_flush from XFS_bflush in case of umount. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 15:33:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 15:33:34 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2HNXVq9013897 for ; Mon, 17 Mar 2003 15:33:32 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2HNXP0L021826 for ; Mon, 17 Mar 2003 15:33:25 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id PAA17059 for ; Mon, 17 Mar 2003 15:33:25 -0800 (PST) Date: Mon, 17 Mar 2003 15:33:25 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: xfs_fsr Seg faults Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 2363 Lines: 60 Hi, I ran xfs_fsr when I had about 70 gigs of files in a 1 TB file system and all was fine. Since then we have added another 100 gigs of files and xfs_fsr Seg faults. Here's what i see in the logs: $ xfs_fsr /mnt/x3 /mnt/x3 start inode=0 Segmentation fault Mar 17 15:27:55 dragon kernel: <1>Unable to handle kernel paging request at virtual address 654b0911 Mar 17 15:27:55 dragon kernel: printing eip: Mar 17 15:27:55 dragon kernel: c01ef8a1 Mar 17 15:27:55 dragon kernel: *pde = 00000000 Mar 17 15:27:55 dragon kernel: Oops: 0000 Mar 17 15:27:55 dragon kernel: Mar 17 15:27:55 dragon kernel: CPU: 0 Mar 17 15:27:55 dragon kernel: EIP: 0010:[map_blocks+129/288] Not tainted Mar 17 15:27:55 dragon kernel: EIP: 0010:[] Not tainted Mar 17 15:27:55 dragon kernel: EFLAGS: 00010283 Mar 17 15:27:55 dragon kernel: eax: 654b0909 ebx: 00020002 ecx: f5859d84 edx: f66bb2e0 Mar 17 15:27:55 dragon kernel: esi: 00000000 edi: 00000000 ebp: 00000000 esp: f5859d7c Mar 17 15:27:55 dragon kernel: ds: 0018 es: 0018 ss: 0018 Mar 17 15:27:55 dragon kernel: Process xfs_fsr (pid: 709, stackpage=f5859000) Mar 17 15:27:55 dragon kernel: Stack: f5859d84 f66bb2e0 00000001 f66bb300 00000000 00000000 0001b000 c01f0e78 Mar 17 15:27:55 dragon kernel: f66bb300 00000000 00000000 0001b000 f5859df8 00020002 01080002 00020002 Mar 17 15:27:55 dragon kernel: 0804f000 f66bb2e0 f7127f80 00000000 00000000 0001b000 0001b000 00000000 Mar 17 15:27:55 dragon kernel: Call Trace: [linvfs_direct_IO+840/890] [map_user_kiobuf+180/256] [generic_file_direct_IO+423/544] [generic_file_write_nolock+1744/1904] [xfs_write+1012/1696] [xfs_read+411/464] [linvfs_wri te+177/240] [sys_write+150/272] [sys_ioctl+647/657] [system_call+51/56] Mar 17 15:27:55 dragon kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] Mar 17 15:27:55 dragon kernel: Code: 8b 50 08 51 8b 74 24 34 56 53 8b 4c 24 38 51 55 57 50 ff 52 Any ideas to the problem? Thanks, -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:01:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:01:59 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I01pq9014468 for ; Mon, 17 Mar 2003 16:01:52 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2I01k0L021986 for ; Mon, 17 Mar 2003 16:01:46 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id QAA17085 for ; Mon, 17 Mar 2003 16:01:46 -0800 (PST) Date: Mon, 17 Mar 2003 16:01:46 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr Seg faults In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 3047 Lines: 81 Forgot: I'm running 2.4.20 with linux-2.4.20-xfs-2003-02-23.patch and the latest cmds from the CVS tree. -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Mon, 17 Mar 2003, Scott Jepson wrote: > Date: Mon, 17 Mar 2003 15:33:25 -0800 > From: Scott Jepson > To: linux-xfs@oss.sgi.com > Subject: xfs_fsr Seg faults > > Hi, > I ran xfs_fsr when I had about 70 gigs of files in a 1 TB file > system and all was fine. Since then we have added another 100 gigs of > files and xfs_fsr Seg faults. Here's what i see in the logs: > > $ xfs_fsr /mnt/x3 > /mnt/x3 start inode=0 > Segmentation fault > > Mar 17 15:27:55 dragon kernel: <1>Unable to handle kernel paging request > at virtual address 654b0911 > Mar 17 15:27:55 dragon kernel: printing eip: > Mar 17 15:27:55 dragon kernel: c01ef8a1 > Mar 17 15:27:55 dragon kernel: *pde = 00000000 > Mar 17 15:27:55 dragon kernel: Oops: 0000 > Mar 17 15:27:55 dragon kernel: > Mar 17 15:27:55 dragon kernel: CPU: 0 > Mar 17 15:27:55 dragon kernel: EIP: 0010:[map_blocks+129/288] Not > tainted > Mar 17 15:27:55 dragon kernel: EIP: 0010:[] Not tainted > Mar 17 15:27:55 dragon kernel: EFLAGS: 00010283 > Mar 17 15:27:55 dragon kernel: eax: 654b0909 ebx: 00020002 ecx: > f5859d84 edx: f66bb2e0 > Mar 17 15:27:55 dragon kernel: esi: 00000000 edi: 00000000 ebp: > 00000000 esp: f5859d7c > Mar 17 15:27:55 dragon kernel: ds: 0018 es: 0018 ss: 0018 > Mar 17 15:27:55 dragon kernel: Process xfs_fsr (pid: 709, > stackpage=f5859000) > Mar 17 15:27:55 dragon kernel: Stack: f5859d84 f66bb2e0 00000001 f66bb300 > 00000000 00000000 0001b000 c01f0e78 > Mar 17 15:27:55 dragon kernel: f66bb300 00000000 00000000 0001b000 > f5859df8 00020002 01080002 00020002 > Mar 17 15:27:55 dragon kernel: 0804f000 f66bb2e0 f7127f80 00000000 > 00000000 0001b000 0001b000 00000000 > Mar 17 15:27:55 dragon kernel: Call Trace: [linvfs_direct_IO+840/890] > [map_user_kiobuf+180/256] [generic_file_direct_IO+423/544] > [generic_file_write_nolock+1744/1904] [xfs_write+1012/1696] > [xfs_read+411/464] [linvfs_wri > te+177/240] [sys_write+150/272] [sys_ioctl+647/657] [system_call+51/56] > Mar 17 15:27:55 dragon kernel: Call Trace: [] [] > [] [] [] [] [] > [] [] [] > Mar 17 15:27:55 dragon kernel: Code: 8b 50 08 51 8b 74 24 34 56 53 8b 4c > 24 38 51 55 57 50 ff 52 > > Any ideas to the problem? > > Thanks, > > -Scott > > > > > ---------------------------------------------------------------- > Scott Jepson, Managing Partner Email: scott@cnes.com > Creative Network Services, LLC http://www.cnes.com > (310)470-6140 > ---------------------------------------------------------------- > > > From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:42:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:43:01 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I0gsq9015336 for ; Mon, 17 Mar 2003 16:42:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2I0s2kq026006 for ; Mon, 17 Mar 2003 18:54:03 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2I0fV7L2095887 for ; Tue, 18 Mar 2003 11:41:31 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2I0fUFj2101716 for linux-xfs@oss.sgi.com; Tue, 18 Mar 2003 11:41:30 +1100 (EST) Date: Tue, 18 Mar 2003 11:41:30 +1100 (EST) From: Nathan Scott Message-Id: <200303180041.h2I0fUFj2101716@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - misc minor cleanup X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2505 Lines: 99 Keep 2.4 and 2.5 get_inode implementations a bit more in sync (wrt flags). Date: Sun Mar 16 19:36:27 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141847a linux/fs/xfs/linux/xfs_vnode.c - 1.111 linux/fs/xfs/linux/xfs_vfs.h - 1.35 Merge change back from 2.5 - need to include init.h for __init/__exit. Date: Sun Mar 16 23:11:13 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141855a linux/fs/xfs/quota/xfs_qm_bhv.c - 1.2 linux/fs/xfs/dmapi/dmapi_xfs.c - 1.2 Remove xfs_dmapi.c - this now lives below fs/xfs/dmapi, effectively. Date: Mon Mar 17 15:02:58 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141911a linux/fs/xfs/xfs_dmapi.c - 1.91 Cleanup/remove a bunch of macros, comments and code. Date: Mon Mar 17 16:39:31 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141925a linux/fs/xfs/xfsidbg.c - 1.216 - Cleanup some of the vnode flags, remove use of bogus macros, extend the vnode command with a couple more fields. linux/fs/xfs/xfs_iocore.c - 1.39 - Remove several unused macros. linux/fs/xfs/xfs_iget.c - 1.184 - Refine a comment. linux/fs/xfs/xfs_clnt.h - 1.37 - Remove several unused macros and some unused fields from mount_args. linux/fs/xfs/xfs_inode.h - 1.177 - Remove several unused macros. linux/fs/xfs/xfs_trans.h - 1.117 - Remove an unused macro and forward declarations of several routines which do not actually exist. linux/fs/xfs/xfs_bmap.h - 1.79 - Remove an unused XFS_BMAPI flag. linux/fs/xfs/linux/xfs_globals.c - 1.43 linux/fs/xfs/linux/xfs_globals.h - 1.16 linux/fs/xfs/support/atomic.h - 1.7 - Rename Atomic_spin to xfs_atomic_spin. linux/fs/xfs/support/debug.c - 1.20 - Refine macro magic around random routine to allow it to be compiled out more easily. linux/fs/xfs/support/mutex.h - 1.10 - Remove second, different and unused mutex initialisation macro. linux/fs/xfs/support/mrlock.h - 1.8 linux/fs/xfs/support/mrlock.c - 1.13 - Turn a couple of routines into macros rather than routines. From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:49:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:49:59 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I0ntq9016352 for ; Mon, 17 Mar 2003 16:49:55 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2I0no0L022305 for ; Mon, 17 Mar 2003 16:49:50 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id QAA17127 for ; Mon, 17 Mar 2003 16:49:49 -0800 (PST) Date: Mon, 17 Mar 2003 16:49:49 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr Seg faults In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 3828 Lines: 103 Hmmmm... I think it might have found a fix. It looks like someone else had the problem and opened a bug report [Bug 195]. I will have to check it out. -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Mon, 17 Mar 2003, Scott Jepson wrote: > Date: Mon, 17 Mar 2003 16:01:46 -0800 > From: Scott Jepson > To: linux-xfs@oss.sgi.com > Subject: Re: xfs_fsr Seg faults > > Forgot: I'm running 2.4.20 with linux-2.4.20-xfs-2003-02-23.patch > and the latest cmds from the CVS tree. > > -Scott > > ---------------------------------------------------------------- > Scott Jepson, Managing Partner Email: scott@cnes.com > Creative Network Services, LLC http://www.cnes.com > (310)470-6140 > ---------------------------------------------------------------- > > On Mon, 17 Mar 2003, Scott Jepson wrote: > > > Date: Mon, 17 Mar 2003 15:33:25 -0800 > > From: Scott Jepson > > To: linux-xfs@oss.sgi.com > > Subject: xfs_fsr Seg faults > > > > Hi, > > I ran xfs_fsr when I had about 70 gigs of files in a 1 TB file > > system and all was fine. Since then we have added another 100 gigs of > > files and xfs_fsr Seg faults. Here's what i see in the logs: > > > > $ xfs_fsr /mnt/x3 > > /mnt/x3 start inode=0 > > Segmentation fault > > > > Mar 17 15:27:55 dragon kernel: <1>Unable to handle kernel paging request > > at virtual address 654b0911 > > Mar 17 15:27:55 dragon kernel: printing eip: > > Mar 17 15:27:55 dragon kernel: c01ef8a1 > > Mar 17 15:27:55 dragon kernel: *pde = 00000000 > > Mar 17 15:27:55 dragon kernel: Oops: 0000 > > Mar 17 15:27:55 dragon kernel: > > Mar 17 15:27:55 dragon kernel: CPU: 0 > > Mar 17 15:27:55 dragon kernel: EIP: 0010:[map_blocks+129/288] Not > > tainted > > Mar 17 15:27:55 dragon kernel: EIP: 0010:[] Not tainted > > Mar 17 15:27:55 dragon kernel: EFLAGS: 00010283 > > Mar 17 15:27:55 dragon kernel: eax: 654b0909 ebx: 00020002 ecx: > > f5859d84 edx: f66bb2e0 > > Mar 17 15:27:55 dragon kernel: esi: 00000000 edi: 00000000 ebp: > > 00000000 esp: f5859d7c > > Mar 17 15:27:55 dragon kernel: ds: 0018 es: 0018 ss: 0018 > > Mar 17 15:27:55 dragon kernel: Process xfs_fsr (pid: 709, > > stackpage=f5859000) > > Mar 17 15:27:55 dragon kernel: Stack: f5859d84 f66bb2e0 00000001 f66bb300 > > 00000000 00000000 0001b000 c01f0e78 > > Mar 17 15:27:55 dragon kernel: f66bb300 00000000 00000000 0001b000 > > f5859df8 00020002 01080002 00020002 > > Mar 17 15:27:55 dragon kernel: 0804f000 f66bb2e0 f7127f80 00000000 > > 00000000 0001b000 0001b000 00000000 > > Mar 17 15:27:55 dragon kernel: Call Trace: [linvfs_direct_IO+840/890] > > [map_user_kiobuf+180/256] [generic_file_direct_IO+423/544] > > [generic_file_write_nolock+1744/1904] [xfs_write+1012/1696] > > [xfs_read+411/464] [linvfs_wri > > te+177/240] [sys_write+150/272] [sys_ioctl+647/657] [system_call+51/56] > > Mar 17 15:27:55 dragon kernel: Call Trace: [] [] > > [] [] [] [] [] > > [] [] [] > > Mar 17 15:27:55 dragon kernel: Code: 8b 50 08 51 8b 74 24 34 56 53 8b 4c > > 24 38 51 55 57 50 ff 52 > > > > Any ideas to the problem? > > > > Thanks, > > > > -Scott > > > > > > > > > > ---------------------------------------------------------------- > > Scott Jepson, Managing Partner Email: scott@cnes.com > > Creative Network Services, LLC http://www.cnes.com > > (310)470-6140 > > ---------------------------------------------------------------- > > > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:49:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:49:48 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I0njq9016312 for ; Mon, 17 Mar 2003 16:49:46 -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 h2I0ndnH004150 for ; Mon, 17 Mar 2003 16:49:39 -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 LAA07573; Tue, 18 Mar 2003 11:48:22 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA00989; Tue, 18 Mar 2003 11:48:21 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2I0jVSO001780; Tue, 18 Mar 2003 11:45:31 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2I0jUfo001778; Tue, 18 Mar 2003 11:45:30 +1100 Date: Tue, 18 Mar 2003 11:45:30 +1100 From: Nathan Scott To: Nicholas Wourms Cc: linux-xfs@oss.sgi.com Subject: Re: What happened to the linux-2.4-xfs cvs tree? Message-ID: <20030318004530.GC948@frodo> References: <3E764CA8.5050404@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E764CA8.5050404@myrealbox.com> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 536 Lines: 20 On Mon, Mar 17, 2003 at 05:31:04PM -0500, Nicholas Wourms wrote: > Hi, > > I just went to pull the sources from the linux-2.4-xfs tree > and I noticed it is gone for both cvs and cvsweb. Was this > intentional? Will it be back? > Pfft - not sure what's happened there. I sure hope it comes back, we'll probably have to wait for Russell to do his magic though. The latest commands code is also mirrored below the 2.5.x-xfs part of the CVS tree, so you can at least still get access to that in the interim. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 17 21:34:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 21:34:23 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I5YCq9003459 for ; Mon, 17 Mar 2003 21:34:13 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2I5jMkq032416 for ; Mon, 17 Mar 2003 23:45:22 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA08571 for ; Mon, 17 Mar 2003 23:34:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2I5Y6wX30194781 for ; Mon, 17 Mar 2003 23:34:06 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2I5XJg31921; Mon, 17 Mar 2003 23:33:19 -0600 Message-Id: <200303180533.h2I5XJg31921@stout.americas.sgi.com> Date: Mon, 17 Mar 2003 23:33:19 -0600 Subject: TAKE - Fix up repair a bit for realtime. X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 529 Lines: 17 (I still can't repair the realtime fs breakage I have, but this is part of the fix). Remove do_error after libxfs_device_zero, this is left over from when irix could return an error from dev_zero, the do_error was supposed to be in a conditional. Date: Mon Mar 17 21:33:14 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141952a cmd/xfsprogs/repair/phase6.c - 1.13 From owner-linux-xfs@oss.sgi.com Mon Mar 17 21:47:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 21:47:35 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I5lUq9003954 for ; Mon, 17 Mar 2003 21:47:31 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2I5wdkq032605 for ; Mon, 17 Mar 2003 23:58:40 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2I5k77L2168988 for ; Tue, 18 Mar 2003 16:46:07 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2I5k7iL2168801 for linux-xfs@oss.sgi.com; Tue, 18 Mar 2003 16:46:07 +1100 (EST) Date: Tue, 18 Mar 2003 16:46:07 +1100 (EST) From: Nathan Scott Message-Id: <200303180546.h2I5k7iL2168801@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1768 Lines: 62 Header shuffling to try and keep several source trees aligned - move the realtime inode detection macro somewhere more appropriate. Date: Mon Mar 17 21:31:02 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141951a linux/fs/xfs/xfs_rtalloc.h - 1.23 linux/fs/xfs/xfs_quota.h - 1.31 xfsprogs update - kernel/user sync up and Ethan's Mac partition code. CONTRIBUTED: erbenson@alaska.net. Date: Mon Mar 17 21:44:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141953a cmd/xfsprogs/db/command.c - 1.7 - Remove a useless forward declaration. cmd/xfsprogs/Makefile - 1.16 - Add configure : configure.in dependency, as Mandy suggests. cmd/xfsprogs/doc/CHANGES - 1.93 cmd/xfsprogs/debian/changelog - 1.61 - Bump minor version to 2.4.1. cmd/xfsprogs/libdisk/pttype.c - 1.6 cmd/xfsprogs/libdisk/pttype.h - 1.3 - Add a check for Apple Mac partition tables. cmd/xfsprogs/include/xfs_dqblk.h - 1.7 cmd/xfsprogs/include/libxfs.h - 1.23 cmd/xfsprogs/include/xfs_rtalloc.h - 1.8 cmd/xfsprogs/include/Makefile - 1.16 cmd/xfsprogs/include/xfs_dquot_item.h - 1.7 cmd/xfsprogs/include/libxlog.h - 1.6 cmd/xfsprogs/include/xfs_mount.h - 1.33 cmd/xfsprogs/include/xfs_inode.h - 1.29 cmd/xfsprogs/include/xfs_types.h - 1.17 cmd/xfsprogs/include/xfs_trans.h - 1.12 cmd/xfsprogs/include/xfs_bmap.h - 1.8 cmd/xfsprogs/include/xfs_quota.h - 1.12 cmd/xfsprogs/libxfs/xfs.h - 1.31 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.15 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.19 - Sync up user/kernel code after recent changes. From owner-linux-xfs@oss.sgi.com Tue Mar 18 03:49:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 03:50:08 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IBnuq9020983 for ; Tue, 18 Mar 2003 03:49:58 -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 GZVLXR5H; Tue, 18 Mar 2003 06:49:57 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h2IBlEfj021972; Tue, 18 Mar 2003 06:47:14 -0500 Message-ID: <3E770742.4040904@wgate.com> Date: Tue, 18 Mar 2003 06:47:14 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Nicholas Wourms , linux-xfs@oss.sgi.com, Bruce Bauman Subject: Re: What happened to the linux-2.4-xfs cvs tree? References: <3E764CA8.5050404@myrealbox.com> <20030318004530.GC948@frodo> In-Reply-To: <20030318004530.GC948@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1112 Lines: 32 Nathan Scott wrote: > On Mon, Mar 17, 2003 at 05:31:04PM -0500, Nicholas Wourms wrote: > >>Hi, >> >>I just went to pull the sources from the linux-2.4-xfs tree >>and I noticed it is gone for both cvs and cvsweb. Was this >>intentional? Will it be back? >> > > > Pfft - not sure what's happened there. I sure hope it comes back, > we'll probably have to wait for Russell to do his magic though. > > The latest commands code is also mirrored below the 2.5.x-xfs part > of the CVS tree, so you can at least still get access to that in > the interim. I run a local (for our use) mirror using rsync from your CVS tree and a whole bunch of the 2.4 tree has been blown away - specifically, all of the linux/fs, net, kdb, include, lib, mm, and scripts directories are empty (there are no ",v" files in them, just sub directories.) The 2.5 tree seems to still be ok for now... (Looks like someone forgot the "pixi-dust" that I saw on TV :-) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications 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 Tue Mar 18 06:10:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 06:10:39 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IE9dq9024561 for ; Tue, 18 Mar 2003 06:10:20 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 39CBCAC4C for ; Tue, 18 Mar 2003 15:22:25 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id E06E9190C2 for ; Tue, 18 Mar 2003 15:22:26 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id DB1DA30881E for ; Tue, 18 Mar 2003 15:09:35 +0100 (CET) Message-ID: <3E77289F.960BF744@ch.sauter-bc.com> Date: Tue, 18 Mar 2003 15:09:35 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Updated RedHat errata kernel with XFS 1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 366 Lines: 9 I have created XFS enabled versions of todays RedHat errata kernel. I have only compiled them on RedHat 7.3 which is suitable for RedHat 7.1-7.3 but it should compile fine on RedHat 8.0 too. For now the rpms can be downloaded from http://www.sauter-bc.com/XFS/ but maybe I have to remove them soon. Can someone from SGI put them into contrib section on OSS? Simon From owner-linux-xfs@oss.sgi.com Tue Mar 18 06:15:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 06:15:27 -0800 (PST) Received: from xanthie.baobab.home (ABoulogne-106-1-2-109.abo.wanadoo.fr [80.11.103.109]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IEFLq9025003 for ; Tue, 18 Mar 2003 06:15:23 -0800 Received: from amavis by xanthie.baobab.home with scanned-ok (Exim 3.35 #1 (Debian)) id 18vHrm-0000cW-00 for ; Tue, 18 Mar 2003 15:14:58 +0100 Received: from localhost ([127.0.0.1] helo=xanthie.baobab.home) by xanthie.baobab.home with esmtp (Exim 3.35 #1 (Debian)) id 18vHrm-0000cO-00 for ; Tue, 18 Mar 2003 15:14:58 +0100 To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.2.0 release for linux-2.4.20? References: <1047564814.2704.41.camel@contact.skynet.coplanar.net> <1047566218.36078.12.camel@lupo.thebarn.com> From: Frederic Saincy Organization: GNU/Linux Date: 18 Mar 2003 15:14:57 +0100 In-Reply-To: <1047566218.36078.12.camel@lupo.thebarn.com> Message-ID: <87bs08ep7i.fsf@xanthie.baobab.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS new-20020517 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freddy@lovelinux.org Precedence: bulk X-list: linux-xfs Content-Length: 259 Lines: 12 Hi, Russell Cattelan writes: > we can look it over and put it > on the ftp site in case other people want to grab it. I think so: http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.2/0226.html Tank you and bye. -- Frederic Saincy From owner-linux-xfs@oss.sgi.com Tue Mar 18 06:25:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 06:25:30 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IEOlq9025478 for ; Tue, 18 Mar 2003 06:25:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2IEZwkq009757 for ; Tue, 18 Mar 2003 08:35:58 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA14612; Tue, 18 Mar 2003 08:24:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2IEOewX23593438; Tue, 18 Mar 2003 08:24:41 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2IEOeh22208; Tue, 18 Mar 2003 08:24:40 -0600 Subject: Re: What happened to the linux-2.4-xfs cvs tree? From: Steve Lord To: Michael Sinz Cc: Nathan Scott , Nicholas Wourms , linux-xfs@oss.sgi.com, Bruce Bauman In-Reply-To: <3E770742.4040904@wgate.com> References: <3E764CA8.5050404@myrealbox.com> <20030318004530.GC948@frodo> <3E770742.4040904@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047997479.16800.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 18 Mar 2003 08:24:40 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1385 Lines: 40 On Tue, 2003-03-18 at 05:47, Michael Sinz wrote: > Nathan Scott wrote: > > On Mon, Mar 17, 2003 at 05:31:04PM -0500, Nicholas Wourms wrote: > > > >>Hi, > >> > >>I just went to pull the sources from the linux-2.4-xfs tree > >>and I noticed it is gone for both cvs and cvsweb. Was this > >>intentional? Will it be back? > >> > > > > > > Pfft - not sure what's happened there. I sure hope it comes back, > > we'll probably have to wait for Russell to do his magic though. > > > > The latest commands code is also mirrored below the 2.5.x-xfs part > > of the CVS tree, so you can at least still get access to that in > > the interim. > > I run a local (for our use) mirror using rsync from your CVS tree and > a whole bunch of the 2.4 tree has been blown away - specifically, > all of the linux/fs, net, kdb, include, lib, mm, and scripts directories > are empty (there are no ",v" files in them, just sub directories.) > > The 2.5 tree seems to still be ok for now... These CVS trees are actually recreated from scratch everytime they are updated. The originals of all this stuff are still here, just something in the process of pushing it out to oss is badly broken by the sound of it. Hopefully it will get fixed today. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 18 14:20:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 14:21:10 -0800 (PST) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IMKtq9014308 for ; Tue, 18 Mar 2003 14:20:56 -0800 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id h2IMKrFC034296; Tue, 18 Mar 2003 23:20:53 +0100 (CET) Received: from xs1.xs4all.nl (knuffie@localhost.xs4all.nl [127.0.0.1]) by xs1.xs4all.nl (8.12.8/8.11.6) with ESMTP id h2IMKrkD052298; Tue, 18 Mar 2003 23:20:53 +0100 (CET) (envelope-from knuffie@xs1.xs4all.nl) Received: from localhost (Unknown UID 104317@localhost) by xs1.xs4all.nl (8.12.8/8.12.8/Submit) with ESMTP id h2IMKqdq052295; Tue, 18 Mar 2003 23:20:52 +0100 (CET) (envelope-from knuffie@xs1.xs4all.nl) X-Authentication-Warning: xs1.xs4all.nl: Unknown UID 104317 owned process doing -bs Date: Tue, 18 Mar 2003 23:20:52 +0100 (CET) From: Seth Mos To: Simon Matter cc: linux-xfs Subject: Re: Updated RedHat errata kernel with XFS 1.2 In-Reply-To: <3E77289F.960BF744@ch.sauter-bc.com> Message-ID: <20030318231811.P52057-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 759 Lines: 23 On Tue, 18 Mar 2003, Simon Matter wrote: > I have created XFS enabled versions of todays RedHat errata kernel. I > have only compiled them on RedHat 7.3 which is suitable for RedHat > 7.1-7.3 but it should compile fine on RedHat 8.0 too. For now the rpms > can be downloaded from http://www.sauter-bc.com/XFS/ but maybe I have to > remove them soon. Can someone from SGI put them into contrib section on > OSS? Ah, I just created a similar source rpm as well, it seems to compile but by sheer lack of time and approaching bedtime I have not tested any of these. Binary rpms will come later. And like Simon, these are compiled on 7.3 as well. Because of the bandwidth I only have the source rpm for now. http://iserv.nl/files/xfs/2.4.18-27/ Cheers Seth From owner-linux-xfs@oss.sgi.com Tue Mar 18 20:00:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 20:00:28 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2J40Jq9016780 for ; Tue, 18 Mar 2003 20:00:20 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2J40CnH002884 for ; Tue, 18 Mar 2003 20:00:13 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h2J3xCu02418; Wed, 19 Mar 2003 14:59:12 +1100 Date: Wed, 19 Mar 2003 14:59:12 +1100 From: Keith Owens Message-Id: <200303190359.h2J3xCu02418@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade xfs to kdb v4.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 748 Lines: 26 Upgrade xfs to kdb v4.0 Date: Tue Mar 18 19:57:56 PST 2003 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:142080a linux/drivers/char/serial.c - 1.60 linux/kdb/kdb_bt.c - 1.15 linux/kdb/kdb_bp.c - 1.16 linux/include/linux/kdbprivate.h - 1.23 linux/include/linux/kdb.h - 1.29 linux/kdb/kdbsupport.c - 1.17 linux/kdb/kdbmain.c - 1.36 linux/kdb/kdb_io.c - 1.18 linux/include/asm-i386/kdbprivate.h - 1.19 linux/Documentation/kdb/kdb_bt.man - 1.10 linux/arch/i386/kdb/kdbasupport.c - 1.25 linux/arch/i386/kdb/kdba_io.c - 1.20 linux/arch/i386/kdb/kdba_bt.c - 1.19 linux/kdb/ChangeLog - 1.28 linux/arch/i386/kdb/ChangeLog - 1.17 From owner-linux-xfs@oss.sgi.com Tue Mar 18 21:05:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 21:05:43 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2J54pq9017620 for ; Tue, 18 Mar 2003 21:05:31 -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 h2J54inH005681 for ; Tue, 18 Mar 2003 21:04:44 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21081; Wed, 19 Mar 2003 16:03:28 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 16D01300087; Wed, 19 Mar 2003 16:03:26 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 498668F; Wed, 19 Mar 2003 16:03:26 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.20 - respin Date: Wed, 19 Mar 2003 16:03:20 +1100 Message-ID: <15510.1048050200@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 988 Lines: 29 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20. The xfs patches for 2.4.20 have been respun as of 2003-03-19 04:55 UTC, including kdb v4.0. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.21/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE+d/oWi4UHNye0ZOoRAgzmAJ4vD9+rDiv+eK/AlxlOqgcELFJVJQCg4Ktm h2q80Zvu3amOD/fQVNKn1I4= =EP8P -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 19 01:15:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 01:15:29 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2J9Ecq9023072 for ; Wed, 19 Mar 2003 01:15:20 -0800 Received: (qmail 30036 invoked by uid 1000); 19 Mar 2003 09:37:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Mar 2003 09:37:08 -0000 Date: Wed, 19 Mar 2003 11:37:08 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: kernel from CVS doesnt compile Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 505 Lines: 14 Hi I just checked out from cvs@oss.sgi.com:/cvs linux-2.4-xfs module and I think it misses Rules.make file (any make {clean|config|mrproper} I try it gives me: No rule to make target Rules.make ). find . -name Rules.make doest find anything in the checked out directory. :) ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Wed Mar 19 03:29:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 03:29:45 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JBTYq9027468 for ; Wed, 19 Mar 2003 03:29:35 -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 GZVLX5ZG; Wed, 19 Mar 2003 06:29:35 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h2JBQhfj024422; Wed, 19 Mar 2003 06:26:43 -0500 Message-ID: <3E7853F3.1090406@wgate.com> Date: Wed, 19 Mar 2003 06:26:43 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mihai RUSU CC: Linux XFS List Subject: Re: kernel from CVS doesnt compile References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 691 Lines: 18 Mihai RUSU wrote: > Hi > > I just checked out from cvs@oss.sgi.com:/cvs linux-2.4-xfs module and I > think it misses Rules.make file (any make {clean|config|mrproper} I try it > gives me: No rule to make target Rules.make ). find . -name Rules.make > doest find anything in the checked out directory. :) Something is currently broken in the CVS export of SGI's internal system. They good folks at SGI are very busy and may not have had a chance to look at/fix the problem yet. I am sure that it will be addressed soon. -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications 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 Wed Mar 19 05:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 05:22:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JDLsq9000743 for ; Wed, 19 Mar 2003 05:21:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDLsmJ000741 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 05:21:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JDLqq9000730 for ; Wed, 19 Mar 2003 05:21:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDHBW7000689; Wed, 19 Mar 2003 05:17:11 -0800 Date: Wed, 19 Mar 2003 05:17:11 -0800 Message-Id: <200303191317.h2JDHBW7000689@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] New: Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1987 Lines: 62 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 Summary: Close system call hangs on creating large files on XFS partition Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: armin.schoisswohl@med.ge.com CC: armin.schoisswohl@med.ge.com If this is a userspace bug, what version of the package are you using: attr-2.1.1-1 acl-2.1.1-1 dmapi-2.0.5-1 xfsprogs-2.3.5-1 kernel-source-2.4.18-18SGI_XFS_1.2.0 What kernel are you using: 2.4.18-18SGI_XFS_1.2.0custom (=2.4.18-18SGI_XFS_1.2.0 + NTFS ro module support) Where did the XFS code come from? (CVS, Linus, your distribution, etc): kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm from SGI website ftp://oss.sgi.com/projects/xfs/download/latest/kernel_rpms/2.4.18-18-RH/SRPMS/kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm Description of Problem: When creating large files (approx. > 700MB) on a XFS partition the creating process hangs in the close system call. How Reproducible: Completely Steps to Reproduce: 1. dd if=/dev/zero of=/some/file/on/a/XFS/partition bs=512 count=1400000 Actual Results: When the file is created completely (full size 716800000 bytes), dd hangs for about 10 minutes and more (maximum was 220 min) using the whole CPU power in kernel mode. Expected Results: No hang. Additional Information: I dumped the registers during the hang and found out that the kernel spends most of the time in the function invalidate_inode_pages (mm/filemap.c), mostly at 1aa and 315; also 175,177,1b4,17c,1ae, and 175 were found sometimes. I will attach a disassambly of invalidate_inode_pages as well as the source and the output of SysRq. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 06:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 06:22:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELsq9001723 for ; Wed, 19 Mar 2003 06:21:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JELsiI001719 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 06:21:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELqqB001697 for ; Wed, 19 Mar 2003 06:21:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDRpu6001235; Wed, 19 Mar 2003 05:27:51 -0800 Date: Wed, 19 Mar 2003 05:27:51 -0800 Message-Id: <200303191327.h2JDRpu6001235@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 406 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From armin.schoisswohl@med.ge.com 2003-03-19 05:27 ------- Created an attachment (id=70) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=70&action=view) Sample Alt-SysReq-P and Alt-SysReq-M output. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 06:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 06:22:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELsq9001722 for ; Wed, 19 Mar 2003 06:21:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JELsnB001718 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 06:21:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELqq9001697 for ; Wed, 19 Mar 2003 06:21:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDQAbo001173; Wed, 19 Mar 2003 05:26:10 -0800 Date: Wed, 19 Mar 2003 05:26:10 -0800 Message-Id: <200303191326.h2JDQAbo001173@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 546 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From armin.schoisswohl@med.ge.com 2003-03-19 05:26 ------- Created an attachment (id=69) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=69&action=view) Disassembly of mm/filemap.c::truncate_list_pages The EIP positions we obtained by pressing Alt-SysReq-P are marked with asterisks (more asterisks mean a higher number of observations). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 06:34:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 06:34:16 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JEY9q9003100 for ; Wed, 19 Mar 2003 06:34:12 -0800 Received: (qmail 19909 invoked from network); 19 Mar 2003 14:46:19 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 19 Mar 2003 14:46:19 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18vedu-00018x-00 for ; Wed, 19 Mar 2003 15:34:10 +0100 Date: Wed, 19 Mar 2003 15:34:10 +0100 To: linux-xfs@oss.sgi.com Subject: xfs cpu usage Message-ID: <20030319143410.GA4333@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 746 Lines: 34 hi, when coping/deleting files (both small and very large) the cpu usage reaches 100% so that it's hardly possible to do anything else at the same time what could possibly be the reason? i use linux 2.5.65 (though same goes for 2.4.20) debian sid i use the following hdparm settings: #hdparm -d1 c1 -u1 -m8 /dev/hda which results in #hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 23989/16/63, sectors = 156301488, start = 0 -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Wed Mar 19 09:56:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 09:56:43 -0800 (PST) Received: from imf58bis.bellsouth.net (mail145.mail.bellsouth.net [205.152.58.105]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JHuTq9009254 for ; Wed, 19 Mar 2003 09:56:32 -0800 Received: from tiger2 ([66.156.1.57]) by imf58bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2>; Wed, 19 Mar 2003 12:50:11 -0500 Date: Wed, 19 Mar 2003 13:00:44 -0500 From: Greg Freemyer Subject: re: xfs cpu usage To: Michal Adamczak , Mime-Version: 1.0 Organization: Norcross Group X-Mailer: GoldMine [6.00.21021] Content-Type: Text/plain Message-Id: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2JHuXq9009256 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1619 Lines: 51 I thought this was the very reason people used SCSI in preference to IDE. i.e. IDE uses the CPU to control seeks, SCSI just tells the controller, and the controller interrupts the CPU when the seek is done. Obviously you could upgrade to SCSI. Alternatively, the 3ware controllers present the CPU with a SCSI interface, but talk to IDE drives on the back-end. I assume there are other controllers that do this as well. I know that some of the Promise controllers imply they do this, but in reality they don't reduce CPU load. Other Promise controllers may do the job right. FYI: A 2-port 3ware card (IIRC 7000-2) only costs a little over $100 (US) and they are supported in the vanilla kernel. Greg >> hi, >> when coping/deleting files (both small and very large) >> the cpu usage reaches 100% so that it's hardly possible to do anything >> else at the same time >> what could possibly be the reason? >> i use linux 2.5.65 (though same goes for 2.4.20) >> debian sid >> i use the following hdparm settings: >> #hdparm -d1 c1 -u1 -m8 /dev/hda >> which results in >> #hdparm /dev/hda >> >> /dev/hda: >> multcount = 16 (on) >> IO_support = 1 (32-bit) >> unmaskirq = 1 (on) >> using_dma = 1 (on) >> keepsettings = 0 (off) >> readonly = 0 (off) >> readahead = 256 (on) >> geometry = 23989/16/63, sectors = 156301488, start = 0 >> >> -- >> Michal Adamczak >> pokryfka @ druid.if.uj.edu.pl >> GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* >> I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Wed Mar 19 10:17:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 10:17:39 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JIGjq9009779 for ; Wed, 19 Mar 2003 10:17:32 -0800 Received: (qmail 25560 invoked from network); 19 Mar 2003 18:28:56 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 19 Mar 2003 18:28:56 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18vi7O-0001xV-00; Wed, 19 Mar 2003 19:16:50 +0100 Date: Wed, 19 Mar 2003 19:16:50 +0100 To: Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030319181650.GA7459@localhost> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> User-Agent: Mutt/1.5.3i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 2367 Lines: 74 thanks for prompt answer k, i know scsi devices are generally more independent and as such less cpu consuming but this drive is on my desktop and i really apprectiate buying 80GB for $100 on a production host (where there are both scsi and ide drives for less critical information) i still use ext3 i thought about switching to xfs and wanted to make some preliminary tests on my desktop unfortunately the way it works right now is unacceptable On Wed, Mar 19, 2003 at 01:00:44PM -0500, Greg Freemyer wrote: > I thought this was the very reason people used SCSI in preference to IDE. > > i.e. IDE uses the CPU to control seeks, SCSI just tells the controller, and the controller interrupts the CPU when the seek is done. > > Obviously you could upgrade to SCSI. > > Alternatively, the 3ware controllers present the CPU with a SCSI interface, but talk to IDE drives on the back-end. > > I assume there are other controllers that do this as well. > > I know that some of the Promise controllers imply they do this, but in reality they don't reduce CPU load. > > Other Promise controllers may do the job right. > > FYI: A 2-port 3ware card (IIRC 7000-2) only costs a little over $100 (US) and they are supported in the vanilla kernel. > > Greg > >> hi, > >> when coping/deleting files (both small and very large) > >> the cpu usage reaches 100% so that it's hardly possible to do anything > >> else at the same time > > >> what could possibly be the reason? > > >> i use linux 2.5.65 (though same goes for 2.4.20) > >> debian sid > > >> i use the following hdparm settings: > >> #hdparm -d1 c1 -u1 -m8 /dev/hda > > >> which results in > > >> #hdparm /dev/hda > >> > >> /dev/hda: > >> multcount = 16 (on) > >> IO_support = 1 (32-bit) > >> unmaskirq = 1 (on) > >> using_dma = 1 (on) > >> keepsettings = 0 (off) > >> readonly = 0 (off) > >> readahead = 256 (on) > >> geometry = 23989/16/63, sectors = 156301488, start = 0 > >> > > >> -- > >> Michal Adamczak > >> pokryfka @ druid.if.uj.edu.pl > >> GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* > >> I code AND I bathe. (seen on slashdot) -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Wed Mar 19 11:28:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 11:28:19 -0800 (PST) Received: from wiglaf.cs-i.brandeis.edu ([129.64.46.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JJS7q9011260 for ; Wed, 19 Mar 2003 11:28:10 -0800 Received: (from aaronm@localhost) by wiglaf.cs-i.brandeis.edu (8.11.6/8.11.6) id h2JJS6X11408 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 14:28:06 -0500 Date: Wed, 19 Mar 2003 14:28:06 -0500 From: Aaron Macks To: linux-xfs@oss.sgi.com Subject: Reserve area for Suid? Message-ID: <20030319192806.GA11189@cs.brandeis.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aaronm@cs.brandeis.edu Precedence: bulk X-list: linux-xfs Content-Length: 300 Lines: 6 In the back of my mind I seem to remember that in formatting an XFS drive, one can reserve some percentage for Suid. Is this possible, or have I confused it with something else? aaron -- Aaron Macks(aaronm@cs.brandeis.edu) My sheep has seven gall bladders, that makes me the King of the Universe! From owner-linux-xfs@oss.sgi.com Wed Mar 19 11:49:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 11:49:07 -0800 (PST) Received: from ns1.scripps.edu (ns1.scripps.edu [192.42.82.59]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JJn2q9011852 for ; Wed, 19 Mar 2003 11:49:02 -0800 Received: from antigen.scripps.edu (antigen.scripps.edu [137.131.200.100]) by ns1.scripps.edu (8.11.6/TSRI-4.1rx) with SMTP id h2JJn2L03827 for ; Wed, 19 Mar 2003 11:49:02 -0800 (PST) Received: from relay1.scripps.edu(137.131.200.29) by antigen.scripps.edu via csmap id 17903; Wed, 19 Mar 2003 11:40:15 -0800 (PST) Received: from astra.scripps.edu (astra.scripps.edu [137.131.108.81]) by relay1.scripps.edu (8.11.6/TSRI-4.2rAV) with ESMTP id h2JJmwB29793 for ; Wed, 19 Mar 2003 11:48:58 -0800 (PST) Received: (from arvai@localhost) by astra.scripps.edu (8.9.2/TSRI-3.0.1) id LAA21241 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 11:48:57 -0800 (PST) Date: Wed, 19 Mar 2003 11:48:57 -0800 (PST) From: Andy Arvai Message-Id: <200303191948.LAA21241@astra.scripps.edu> To: linux-xfs@oss.sgi.com Subject: optimizing raid performance with xfs X-Sun-Charset: US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: arvai@scripps.edu Precedence: bulk X-list: linux-xfs Content-Length: 591 Lines: 14 Hi, In the next few weeks I will be building a linux server with a large (1.2TB) raid array. There will be two 3ware 7850 cards (running hardware raid5) and a software raid0 across these two cards. I plan to benchmark three different filesystems (ext3, reiser and xfs) to determine which performs the best. The main thing I am interested in is sequential i/o with large files and I've heard that xfs should be the best choice for this. I am wondering if anyone has recommendations for mkfs.xfs or mount options to maximize performance in this situation. Thanks for any suggestions, Andy From owner-linux-xfs@oss.sgi.com Wed Mar 19 12:31:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 12:31:11 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JKV0q9012525 for ; Wed, 19 Mar 2003 12:31:01 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h2JKUwN09501; Wed, 19 Mar 2003 15:30:58 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 19 Mar 2003 15:30:58 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Andy Arvai cc: linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs In-Reply-To: <200303191948.LAA21241@astra.scripps.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 1595 Lines: 33 On Wed, 19 Mar 2003 at 11:48am, Andy Arvai wrote > In the next few weeks I will be building a linux server with a large > (1.2TB) raid array. There will be two 3ware 7850 cards (running > hardware raid5) and a software raid0 across these two cards. I plan to > benchmark three different filesystems (ext3, reiser and xfs) to > determine which performs the best. The main thing I am interested in is > sequential i/o with large files and I've heard that xfs should be the > best choice for this. I am wondering if anyone has recommendations for > mkfs.xfs or mount options to maximize performance in this situation. During recent testing on a single 3ware card, I found XFS to have twice the write speed of ext3, with a similar read speed (this is all with bonnie++ and the default mkfs options (except for log size)). I didn't test Reiser. If the server has lots of memory, make sure that your kernel supports HIGH I/O and that you're using 3ware drivers that support it -- it makes a *big* difference. I'm using the RH based XFS 1.2 release kernel and the 7.5.3 3ware driver set. I've got another 3ware based system that's similar to yours (two cards with a software stripe), and I found that increasing the chunk-size of the stripe increased performance (at the cost of CPU load) -- I'm using 4096k in production. mkfs.xfs will automatically tune swidth and sunit for the software stripe. On the hardware side, make sure your cards are on separate PCI busses. You'll be bus limited otherwise. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Mar 19 12:40:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 12:40:47 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JKdWq9013693 for ; Wed, 19 Mar 2003 12:40:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JKdRnH026392 for ; Wed, 19 Mar 2003 12:39:27 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA42956; Wed, 19 Mar 2003 14:39:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JKdQwX29810319; Wed, 19 Mar 2003 14:39:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2JKdQa22631; Wed, 19 Mar 2003 14:39:26 -0600 Subject: Re: optimizing raid performance with xfs From: Steve Lord To: Andy Arvai Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048106365.19339.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 19 Mar 2003 14:39:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2304 Lines: 48 On Wed, 2003-03-19 at 14:30, Joshua Baker-LePain wrote: > On Wed, 19 Mar 2003 at 11:48am, Andy Arvai wrote > > > In the next few weeks I will be building a linux server with a large > > (1.2TB) raid array. There will be two 3ware 7850 cards (running > > hardware raid5) and a software raid0 across these two cards. I plan to > > benchmark three different filesystems (ext3, reiser and xfs) to > > determine which performs the best. The main thing I am interested in is > > sequential i/o with large files and I've heard that xfs should be the > > best choice for this. I am wondering if anyone has recommendations for > > mkfs.xfs or mount options to maximize performance in this situation. > > During recent testing on a single 3ware card, I found XFS to have twice > the write speed of ext3, with a similar read speed (this is all with > bonnie++ and the default mkfs options (except for log size)). I didn't > test Reiser. If the server has lots of memory, make sure that your kernel > supports HIGH I/O and that you're using 3ware drivers that support it -- > it makes a *big* difference. I'm using the RH based XFS 1.2 release > kernel and the 7.5.3 3ware driver set. > > I've got another 3ware based system that's similar to yours (two cards > with a software stripe), and I found that increasing the chunk-size of the > stripe increased performance (at the cost of CPU load) -- I'm using 4096k > in production. mkfs.xfs will automatically tune swidth and sunit for the > software stripe. > > On the hardware side, make sure your cards are on separate PCI busses. > You'll be bus limited otherwise. One thing which came up recently was how inodes get placed once you cross the 1 Tbyte boundary. Policy changes to avoid 33 bit inode numbers. You can avoid this policy change with mkfs -t xfs -f -i size=512 /dev/xxx Also, pay attention to the mkfs output, the sunit and swidth lines, these control how data will get layed out. You want to make sure they line up with your device configuration. This may or may not happen automatically depending on your setup. Read the mkfs.xfs man page for how to control them yourself. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 19 12:57:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 12:57:16 -0800 (PST) Received: from fruit.eu.org (qmailr@d5112018.cable.wanadoo.nl [213.17.32.24]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JKv6q9015773 for ; Wed, 19 Mar 2003 12:57:13 -0800 Received: (qmail 5073 invoked by uid 500); 19 Mar 2003 20:57:01 -0000 Date: Wed, 19 Mar 2003 21:57:01 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs Message-ID: <20030319205701.GI29548@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200303191948.LAA21241@astra.scripps.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-oi: oi User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs Content-Length: 645 Lines: 16 On 2003-03-19 15:30:58-0500, Joshua Baker-LePain wrote: > I've got another 3ware based system that's similar to yours (two cards > with a software stripe), and I found that increasing the chunk-size of the > stripe increased performance (at the cost of CPU load) -- I'm using 4096k > in production. In theory you should use a small stripe size for large files (parallellism for sequential access patterns) and a large stripe size for small files (low latency for random access). Of course YMMV so do test it out with your own specific workload (as opposed to a generic benchmark like Bonnie++). HTH, -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Wed Mar 19 13:12:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 13:13:08 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JLCIq9019546 for ; Wed, 19 Mar 2003 13:12:59 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JLNYkq017422 for ; Wed, 19 Mar 2003 15:23:34 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA60079; Wed, 19 Mar 2003 15:12:12 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JLCCwX31476015; Wed, 19 Mar 2003 15:12:12 -0600 (CST) Subject: Re: kernel from CVS doesnt compile From: Rusell Cattelan To: Mihai RUSU Cc: Linux XFS List In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1048108368.25121.43.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 19 Mar 2003 15:12:48 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 934 Lines: 28 We have been having some problems with the machine that does the conversion/push to oss. Everything appears to be functioning normally now so the tree should be complete. NOTE NOTE NOTE the cmds have been moved to it's own repository (actually it's been this internally for quite some time) The xfs commands can now be obtained via cvs co xfs-cmds On Wed, 2003-03-19 at 03:37, Mihai RUSU wrote: > Hi > > I just checked out from cvs@oss.sgi.com:/cvs linux-2.4-xfs module and I > think it misses Rules.make file (any make {clean|config|mrproper} I try it > gives me: No rule to make target Rules.make ). find . -name Rules.make > doest find anything in the checked out directory. :) > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. > From owner-linux-xfs@oss.sgi.com Wed Mar 19 13:39:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 13:39:14 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JLTTqF020156 for ; Wed, 19 Mar 2003 13:39:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JK6mnH023941 for ; Wed, 19 Mar 2003 12:06:48 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA13196; Wed, 19 Mar 2003 14:06:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JK6lCI5724084; Wed, 19 Mar 2003 14:06:47 -0600 (CST) Subject: Re: Reserve area for Suid? From: Eric Sandeen To: Aaron Macks Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030319192806.GA11189@cs.brandeis.edu> References: <20030319192806.GA11189@cs.brandeis.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Mar 2003 14:06:29 -0600 Message-Id: <1048104389.5112.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 15 ext[2,3] can do this, xfs has never had that feature. -Eric On Wed, 2003-03-19 at 13:28, Aaron Macks wrote: > In the back of my mind I seem to remember that in formatting an XFS drive, one can reserve some percentage for Suid. Is this possible, or have I confused it with something else? > aaron > -- > Aaron Macks(aaronm@cs.brandeis.edu) > My sheep has seven gall bladders, that makes me the King of the Universe! > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:21:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:22:05 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JMLtq9023180 for ; Wed, 19 Mar 2003 14:21:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JMLtbL023178 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 14:21:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JMLsq9023165 for ; Wed, 19 Mar 2003 14:21:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JLpJfO022234; Wed, 19 Mar 2003 13:51:19 -0800 Date: Wed, 19 Mar 2003 13:51:19 -0800 Message-Id: <200303192151.h2JLpJfO022234@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 318 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From cattelan@thebarn.com 2003-03-19 13:51 ------- Is this a desktop system or a server with no gui stuff running? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:26:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:26:59 -0800 (PST) Received: from rayen.face.ubiobio.cl (rayen.face.ubiobio.cl [146.83.194.131]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JMQGq9023673 for ; Wed, 19 Mar 2003 14:26:57 -0800 Received: by rayen.face.ubiobio.cl (Postfix, from userid 500) id 083A41BE16; Wed, 19 Mar 2003 18:24:46 -0400 (CLT) Received: from localhost (localhost [127.0.0.1]) by rayen.face.ubiobio.cl (Postfix) with ESMTP id 04469407D for ; Wed, 19 Mar 2003 18:24:46 -0400 (CLT) Date: Wed, 19 Mar 2003 18:24:45 -0400 (CLT) From: Leonardo Saavedra Henriquez X-X-Sender: leo@rayen.face.ubiobio.cl To: linux-xfs@oss.sgi.com Subject: 2.4.20 and ptrace xploit In-Reply-To: <1048106365.19339.32.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leo@ubiobio.cl Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 19 Hi all I've noticed that xfs patch from ftp : -rw-r--r-- 855192 mar 19 00:54 xfs-2.4.20-all-i386.bz2 has today's date, Has this file been patched for ptrace exploit? I wouldn't like to have to patch with 2.4.21-pre5 plus XFS. TIA -- +----------------------------------------------+ ,''`. | Leonardo Saavedra Henriquez |leo@ubiobio.cl | : :' : | Est. Ing Civil en Informatica|U. del Bio-Bio | `. `' +----------------------------------------------+ `- [leo-> ~ $] cd pub && more beer From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:32:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:32:07 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JMW4q9024124 for ; Wed, 19 Mar 2003 14:32:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JMVwnH002558 for ; Wed, 19 Mar 2003 14:31:58 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA36350; Wed, 19 Mar 2003 16:31:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JMVvwX28747778; Wed, 19 Mar 2003 16:31:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2JMVvR26522; Wed, 19 Mar 2003 16:31:57 -0600 Subject: Re: 2.4.20 and ptrace xploit From: Steve Lord To: Leonardo Saavedra Henriquez Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048113117.25898.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 19 Mar 2003 16:31:57 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 716 Lines: 23 On Wed, 2003-03-19 at 16:24, Leonardo Saavedra Henriquez wrote: > Hi all > > I've noticed that xfs patch from ftp : > -rw-r--r-- 855192 mar 19 00:54 xfs-2.4.20-all-i386.bz2 > has today's date, > Has this file been patched for ptrace exploit? > > I wouldn't like to have to patch with 2.4.21-pre5 plus XFS. > Nope, it has not, but applying the ptrace fix to 2.4.20 should not be a problem. We cannot be in the business of doing a distribution and providing fixes to all and sundry with XFS. Unless you all want to start paying us lots of money ;-). Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:44:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:44:12 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JMi5q9024622 for ; Wed, 19 Mar 2003 14:44:07 -0800 Received: from rx3227.cip.uni-regensburg.de (rx3227.cip.uni-regensburg.de [132.199.221.32]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id h2JMhwX20615; Wed, 19 Mar 2003 23:43:58 +0100 (MET) Subject: Re: 2.4.20 and ptrace xploit From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Steve Lord Cc: Leonardo Saavedra Henriquez , linux-xfs@oss.sgi.com In-Reply-To: <1048113117.25898.1.camel@jen.americas.sgi.com> References: <1048113117.25898.1.camel@jen.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1048113838.1317.14.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 23:43:58 +0100 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 20 On Wed, 2003-03-19 at 23:31, Steve Lord wrote: > On Wed, 2003-03-19 at 16:24, Leonardo Saavedra Henriquez wrote: > > Hi all > > > > I've noticed that xfs patch from ftp : > > -rw-r--r-- 855192 mar 19 00:54 xfs-2.4.20-all-i386.bz2 > > has today's date, > > Has this file been patched for ptrace exploit? > > > > I wouldn't like to have to patch with 2.4.21-pre5 plus XFS. > > > there has been a post on lkml, maybe you'll have a look at it. http://marc.theaimsgroup.com/?l=linux-kernel&m=104792708117519&w=2 cheers. Christian From owner-linux-xfs@oss.sgi.com Wed Mar 19 17:34:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 17:35:09 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2K1Ysq9026582 for ; Wed, 19 Mar 2003 17:34:55 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 168C7183C88D; Wed, 19 Mar 2003 17:34:54 -0800 (PST) Date: Wed, 19 Mar 2003 17:34:54 -0800 From: Chris Wedgwood To: Michal Adamczak Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030320013454.GA6989@f00f.org> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030319181650.GA7459@localhost> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 203 Lines: 9 On Wed, Mar 19, 2003 at 07:16:50PM +0100, Michal Adamczak wrote: > unfortunately the way it works right now is unacceptable can you run oprofile and see where the time is baing taken please? --cw From owner-linux-xfs@oss.sgi.com Wed Mar 19 20:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 20:58:24 -0800 (PST) Received: from vnode.vmunix.com (eb0b9b39cfc5bc56aee036c4a3a399ec@vnode.vmunix.com [64.7.135.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2K4wEq9030535 for ; Wed, 19 Mar 2003 20:58:16 -0800 Received: by vnode.vmunix.com (Postfix, from userid 1000) id 9D763A1806; Thu, 20 Mar 2003 05:04:44 +0000 (GMT) Date: Thu, 20 Mar 2003 05:04:44 +0000 From: Mark Mayo To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs Message-ID: <20030320050444.GA52276@vmunix.com> References: <1048106365.19339.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048106365.19339.32.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mark@vmunix.com Precedence: bulk X-list: linux-xfs Content-Length: 2871 Lines: 69 On Wed, Mar 19, 2003 at 02:39:26PM -0600, Steve Lord wrote: > > Also, pay attention to the mkfs output, the sunit and swidth lines, > these control how data will get layed out. You want to make sure they > line up with your device configuration. This may or may not happen > automatically depending on your setup. Read the mkfs.xfs man page for > how to control them yourself. Ah. I'm just trying XFS for the first time and also have some tuning questions! Is the general recommendation to set sunit/su and swidth/sw when running on a hardware RAID system? In my case, I have a bunch of volumes created on an IBM FAStT700 SAN (rebranded LSI 4884, like the SGI SAN Server 1000). The RAID controller lets me adjust "segment size" from 8-256K, with a default of 64KB on a RAID5 volume. The docs say "A segment is the amount of data, in kilobytes, that the controller writes on a single drive in a logical drive before writing data on the next drive." Am I correct when I interpret this as the "strip unit size" defined in the mkfs.xfs man page? Assuming I'm on the right track then, since I have 512 byte data blocks, the 64KB stripe takes up 128 blocks. I have 12 drives in the stripe, so to create a XFS FS I'd run: mkfs.xfs -d sunit=128,swidth=1536 or mkfs.xfs -d su=64k,sw=768k When I create a FS like this, I get: # mkfs.xfs -f -i size=512 -d sunit=128,swidth=1536 /dev/sdb1 meta-data=/dev/sdb1 isize=512 agcount=188, agsize=1048576 blks data = bsize=4096 blocks=197025168, imaxpct=25 = sunit=16 swidth=192 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=24064, version=1 = sunit=16 blks realtime =none extsz=65536 blocks=0, rtextents=0 Am I going about this the right way, or have I gone wrong somewhere along the way in my logic? :) On a related note, I'm wondering what happens when I grow volumes. In this particular volume, it's 752GB right now but what if I add 2 more drives to the volume to grow it by another 120GB? Can I respecify the swidth value somehow or should I simply not specify sunit/swidth on volumes I know will be growing and leave them at the default 0 values? Finally, anything I should be looking out for on 1.7TB volumes? Regards, -Mark > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > -- Mark Mayo http://www.vmunix.com/~mark PGP Fingerprint: 32BA C076 D78C 109B 2558 25E5 0CCE C6C1 262E 28AF Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. From owner-linux-xfs@oss.sgi.com Thu Mar 20 00:21:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 00:22:11 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2K8Lwq9006161 for ; Thu, 20 Mar 2003 00:21:58 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2K8LvBw006159 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 00:21:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2K8Luq9006148 for ; Thu, 20 Mar 2003 00:21:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2K7vM4Q002667; Wed, 19 Mar 2003 23:57:22 -0800 Date: Wed, 19 Mar 2003 23:57:22 -0800 Message-Id: <200303200757.h2K7vM4Q002667@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 365 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From armin.schoisswohl@med.ge.com 2003-03-19 23:57 ------- It's a desktop system, however it also appears when running in single user mode without any GUI stuff. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 20 01:23:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 01:24:03 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2K9NEq9007399 for ; Thu, 20 Mar 2003 01:23:55 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h2K9NCcx031257 for ; Thu, 20 Mar 2003 10:23:12 +0100 Received: (qmail 7301 invoked from network); 20 Mar 2003 10:23:12 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 20 Mar 2003 10:23:12 +0100 Date: Thu, 20 Mar 2003 10:23:12 +0100 From: Christian Guggenberger To: Mark Mayo Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs Message-ID: <20030320102312.A7211@pc9391.uni-regensburg.de> References: <1048106365.19339.32.camel@jen.americas.sgi.com> <20030320050444.GA52276@vmunix.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030320050444.GA52276@vmunix.com>; from mark@vmunix.com on Thu, Mar 20, 2003 at 06:04:44 +0100 X-Mailer: Balsa 1.2.4 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1506 Lines: 35 On 20.03.2003 06:04 Mark Mayo wrote: > On Wed, Mar 19, 2003 at 02:39:26PM -0600, Steve Lord wrote: > > > > Also, pay attention to the mkfs output, the sunit and swidth lines, > > these control how data will get layed out. You want to make sure they > > line up with your device configuration. This may or may not happen > > automatically depending on your setup. Read the mkfs.xfs man page for > > how to control them yourself. > > Ah. I'm just trying XFS for the first time and also have some tuning > questions! > > Is the general recommendation to set sunit/su and swidth/sw when running > on a hardware RAID system? In my case, I have a bunch of volumes created > on an IBM FAStT700 SAN (rebranded LSI 4884, like the SGI SAN Server > 1000). The RAID controller lets me adjust "segment size" from 8-256K, > with a default of 64KB on a RAID5 volume. The docs say "A segment is the > amount of data, in kilobytes, that the controller writes on a single > drive in a logical drive before writing data on the next drive." Am I > correct when I interpret this as the "strip unit size" defined in the > mkfs.xfs man page? > > Assuming I'm on the right track then, since I have 512 byte data > blocks, the 64KB stripe takes up 128 blocks. I have 12 drives in the > stripe, so to create a XFS FS I'd run: > > mkfs.xfs -d sunit=128,swidth=1536 > or > mkfs.xfs -d su=64k,sw=768k > > On Raid5 setups switdh should be (n-1)*sunit, I think. In your case that would be 11*128, not 12*128. Christian From owner-linux-xfs@oss.sgi.com Thu Mar 20 08:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 08:08:47 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KG7vq9029587 for ; Thu, 20 Mar 2003 08:08:37 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KG7pnH005732 for ; Thu, 20 Mar 2003 08:07:51 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA24489 for ; Thu, 20 Mar 2003 10:07:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KG7owX31787458 for ; Thu, 20 Mar 2003 10:07:51 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2KG7PG18076; Thu, 20 Mar 2003 10:07:25 -0600 Message-Id: <200303201607.h2KG7PG18076@stout.americas.sgi.com> Date: Thu, 20 Mar 2003 10:07:25 -0600 Subject: TAKE - Un-race-ify timer manipulation in pagebuf X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 578 Lines: 20 I don't think we've ever seen problems, but this should be safer. Use mod_timer in place of del/modify/add (can race) Also use del_timer_sync when we're done. Date: Thu Mar 20 08:07:06 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean Author: sandeen Merged by: sandeen Merged mods: 2.4.x-xfs-dev:slinx:142197a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142197a linux/fs/xfs/pagebuf/page_buf.c - 1.106 - Merge of 2.4.x-xfs-dev:slinx:142197a by sandeen. From owner-linux-xfs@oss.sgi.com Thu Mar 20 08:56:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 08:57:15 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KGuJq9002395 for ; Thu, 20 Mar 2003 08:56:59 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KGuEnH012332 for ; Thu, 20 Mar 2003 08:56:14 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2KGtD4L22208652 for ; Thu, 20 Mar 2003 08:55:13 -0800 (PST) Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA01483 for ; Thu, 20 Mar 2003 10:55:10 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KGt8wX32124233 for ; Thu, 20 Mar 2003 10:55:08 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2L0ARE26839 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 19:10:27 -0500 Resent-Message-Id: <200303210010.h2L0ARE26839@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KGpTwX13238838 for ; Thu, 20 Mar 2003 10:51:29 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2KGpQ4L24080577 for ; Thu, 20 Mar 2003 08:51:27 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h2KGmCxD020457 for ; Thu, 20 Mar 2003 17:48:13 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h2KGmCwn020456 for hch@sgi.com; Thu, 20 Mar 2003 17:48:12 +0100 Date: Thu, 20 Mar 2003 17:48:12 +0100 From: Christoph Hellwig Message-Id: <200303201648.h2KGmCwn020456@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.65 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 20 Mar 2003 19:10:26 -0500 Resent-To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 49357 Lines: 1283 Date: Thu Mar 20 08:45:25 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142205a linux/arch/arm/kernel/apm.c - 1.1 linux/drivers/i2c/busses/i2c-ali15x3.c - 1.1 linux/drivers/pci/bus.c - 1.1 linux/scripts/kconfig/gconf.glade - 1.1 linux/include/asm-ia64/sn/geo.h - 1.1 linux/arch/i386/boot/mtools.conf.in - 1.1 linux/scripts/kconfig/gconf.c - 1.1 linux/arch/ia64/sn/io/sn2/ml_iograph.c - 1.1 linux/Documentation/basic_profiling.txt - 1.1 linux/include/asm-generic/pci.h - 1.1 linux/include/asm-ia64/sn/ioconfig_bus.h - 1.1 linux/include/asm-ia64/sn/pci/pic.h - 1.1 linux/include/net/esp.h - 1.1 linux/include/media/audiochip.h - 1.1 linux/arch/ia64/sn/io/sn2/module.c - 1.1 linux/net/compat.c - 1.1 linux/drivers/char/hw_random.c - 1.1 linux/arch/ia64/sn/io/sn2/pci_bus_cvlink.c - 1.1 linux/include/net/compat_socket.h - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/Makefile - 1.1 linux/include/media/id.h - 1.1 linux/Documentation/eisa.txt - 1.1 linux/arch/ia64/sn/io/sn2/pciio.c - 1.1 linux/include/asm-ia64/sn/rw_mmr.h - 1.1 linux/include/media/tuner.h - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/Makefile - 1.1 linux/include/asm-ia64/rwsem.h - 1.1 linux/arch/x86_64/ia32/tls32.c - 1.1 linux/Documentation/hw_random.txt - 1.1 linux/arch/arm/mach-sa1100/ssp.c - 1.1 linux/arch/arm/kernel/pm.c - 1.1 linux/net/ipv6/ah6.c - 1.1 linux/include/net/ah.h - 1.1 linux/arch/ia64/sn/io/sn2/pic.c - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/Makefile - 1.1 linux/arch/ia64/sn/io/sn2/sgi_io_init.c - 1.1 linux/arch/ia64/sn/io/ioconfig_bus.c - 1.1 linux/arch/ia64/sn/io/sn2/Makefile - 1.1 linux/include/media/video-buf.h - 1.1 linux/arch/ia64/sn/io/sn2/geo_op.c - 1.1 linux/arch/ia64/sn/io/sn2/shub.c - 1.1 linux/drivers/i2c/busses/i2c-piix4.c - 1.1 linux/drivers/i2c/busses/i2c-i801.c - 1.1 linux/drivers/video/leo.c - 1.1 linux/arch/ia64/sn/io/sn2/shubio.c - 1.1 linux/arch/ia64/sn/io/sn2/xbow.c - 1.1 linux/net/ipv6/esp6.c - 1.1 linux/include/asm-ia64/sn/sn2/geo.h - 1.1 linux/arch/ia64/sn/io/sn2/klconflib.c - 1.1 linux/arch/ia64/sn/io/sn2/klgraph.c - 1.1 linux/arch/ia64/sn/kernel/sn2/sn_proc_fs.c - 1.1 linux/arch/ia64/sn/io/sn2/xtalk.c - 1.1 linux/arch/ia64/sn/io/sn2/l1.c - 1.1 linux/arch/ia64/sn/kernel/iomv.c - 1.1 linux/arch/ia64/sn/io/sn2/ml_SN_init.c - 1.1 linux/arch/ia64/sn/kernel/sn2/ptc_deadlock.S - 1.1 linux/arch/ia64/sn/io/sn2/l1_command.c - 1.1 linux/arch/m68knommu/platform/5307/timers.c - 1.1 linux/scripts/lxdialog/Makefile - 1.10 linux/scripts/Makefile - 1.18 linux/net/x25/x25_timer.c - 1.10 linux/net/x25/x25_subr.c - 1.9 linux/net/x25/x25_in.c - 1.13 linux/net/x25/af_x25.c - 1.33 linux/net/unix/af_unix.c - 1.53 linux/net/sunrpc/xprt.c - 1.40 linux/net/sunrpc/svcsock.c - 1.29 linux/net/sunrpc/sched.c - 1.37 linux/net/sunrpc/clnt.c - 1.29 linux/net/socket.c - 1.52 linux/net/rose/rose_timer.c - 1.8 linux/net/rose/rose_subr.c - 1.8 linux/net/rose/rose_route.c - 1.11 linux/net/rose/rose_in.c - 1.7 linux/net/rose/af_rose.c - 1.29 linux/net/packet/af_packet.c - 1.39 linux/net/netsyms.c - 1.63 linux/net/netrom/nr_timer.c - 1.8 linux/net/netrom/nr_subr.c - 1.7 linux/net/netrom/nr_in.c - 1.6 linux/net/netrom/af_netrom.c - 1.28 linux/net/netlink/af_netlink.c - 1.26 linux/net/irda/af_irda.c - 1.44 linux/net/ipx/af_ipx.c - 1.34 linux/net/ipv6/udp.c - 1.36 linux/net/ipv6/tcp_ipv6.c - 1.47 linux/net/ipv6/route.c - 1.30 linux/net/ipv6/raw.c - 1.31 linux/net/ipv6/ndisc.c - 1.30 linux/net/ipv6/ip6_output.c - 1.18 linux/net/ipv6/ip6_input.c - 1.14 linux/net/ipv6/icmp.c - 1.25 linux/net/ipv6/Makefile - 1.13 linux/net/ipv4/udp.c - 1.39 linux/net/ipv4/tcp_timer.c - 1.28 linux/net/ipv4/tcp_output.c - 1.36 linux/net/ipv4/tcp_ipv4.c - 1.59 linux/net/ipv4/tcp_input.c - 1.48 linux/net/ipv4/tcp.c - 1.52 linux/net/ipv4/route.c - 1.45 linux/net/ipv4/raw.c - 1.31 linux/net/ipv4/igmp.c - 1.23 linux/net/ipv4/icmp.c - 1.38 linux/net/ipv4/af_inet.c - 1.49 linux/net/core/sock.c - 1.31 linux/net/core/skbuff.c - 1.30 linux/net/core/scm.c - 1.10 linux/net/ax25/ax25_subr.c - 1.9 linux/net/ax25/ax25_std_timer.c - 1.6 linux/net/ax25/ax25_std_in.c - 1.6 linux/net/ax25/ax25_in.c - 1.13 linux/net/ax25/ax25_ds_timer.c - 1.7 linux/net/ax25/ax25_ds_in.c - 1.7 linux/net/ax25/af_ax25.c - 1.30 linux/net/appletalk/ddp.c - 1.26 linux/net/Makefile - 1.31 linux/mm/slab.c - 1.53 linux/mm/mremap.c - 1.42 linux/mm/mmap.c - 1.73 linux/mm/memory.c - 1.102 linux/mm/filemap.c - 1.151 linux/kernel/sysctl.c - 1.63 linux/kernel/sys.c - 1.49 linux/kernel/softirq.c - 1.34 linux/kernel/signal.c - 1.51 linux/kernel/sched.c - 1.96 linux/kernel/printk.c - 1.30 linux/kernel/ksyms.c - 1.185 linux/kernel/fork.c - 1.86 linux/init/main.c - 1.103 linux/include/net/tcp.h - 1.42 linux/include/net/sock.h - 1.43 linux/include/net/snmp.h - 1.12 linux/include/net/scm.h - 1.5 linux/include/net/ip6_route.h - 1.9 linux/include/net/inet_common.h - 1.7 linux/include/net/dst.h - 1.12 linux/include/linux/wanrouter.h - 1.11 linux/include/linux/wanpipe.h - 1.10 linux/include/linux/tty.h - 1.21 linux/include/linux/socket.h - 1.13 linux/include/linux/slab.h - 1.29 linux/include/linux/sdladrv.h - 1.5 linux/include/linux/sched.h - 1.100 linux/include/linux/pci.h - 1.74 linux/include/linux/nfsd/export.h - 1.17 linux/include/linux/net.h - 1.14 linux/include/linux/mm.h - 1.115 linux/include/linux/list.h - 1.25 linux/include/linux/kernel.h - 1.44 linux/include/linux/ipv6.h - 1.5 linux/include/linux/init.h - 1.26 linux/include/linux/if_shaper.h - 1.5 linux/include/linux/i2c.h - 1.20 linux/include/linux/genhd.h - 1.34 linux/include/linux/fs.h - 1.209 linux/include/linux/elf.h - 1.24 linux/include/linux/amigaffs.h - 1.14 linux/include/asm-sparc64/termios.h - 1.7 linux/include/asm-sparc64/processor.h - 1.29 linux/include/asm-sparc64/pgtable.h - 1.40 linux/include/asm-sparc64/fcntl.h - 1.17 linux/include/asm-sparc/termios.h - 1.7 linux/include/asm-sparc/processor.h - 1.22 linux/include/asm-ppc/processor.h - 1.41 linux/include/asm-ppc/pgtable.h - 1.41 linux/include/asm-mips/processor.h - 1.22 linux/include/asm-mips/pci.h - 1.15 linux/include/asm-m68k/processor.h - 1.18 linux/include/asm-i386/serial.h - 1.6 linux/include/asm-i386/processor.h - 1.50 linux/include/asm-i386/pgtable.h - 1.44 linux/include/asm-i386/msr.h - 1.19 linux/include/asm-arm/system.h - 1.26 linux/include/asm-arm/processor.h - 1.27 linux/include/asm-arm/proc-fns.h - 1.14 linux/include/asm-arm/posix_types.h - 1.6 linux/include/asm-arm/pgtable.h - 1.30 linux/include/asm-arm/ide.h - 1.10 linux/include/asm-arm/ecard.h - 1.8 linux/include/asm-alpha/processor.h - 1.19 linux/include/asm-alpha/pgtable.h - 1.39 linux/include/asm-alpha/pci.h - 1.19 linux/include/asm-alpha/core_cia.h - 1.13 linux/fs/super.c - 1.98 linux/fs/smbfs/sock.c - 1.18 linux/fs/readdir.c - 1.20 linux/fs/nfsd/vfs.c - 1.64 linux/fs/nfsd/export.c - 1.50 linux/fs/nfs/file.c - 1.41 linux/fs/ncpfs/ioctl.c - 1.19 linux/fs/namei.c - 1.67 linux/fs/locks.c - 1.38 linux/fs/lockd/svclock.c - 1.17 linux/fs/inode.c - 1.92 linux/fs/filesystems.c - 1.27 linux/fs/file_table.c - 1.30 linux/fs/ext2/super.c - 1.44 linux/fs/ext2/ioctl.c - 1.14 linux/fs/ext2/inode.c - 1.66 linux/fs/ext2/ialloc.c - 1.36 linux/fs/ext2/dir.c - 1.28 linux/fs/ext2/balloc.c - 1.28 linux/fs/dcache.c - 1.48 linux/fs/block_dev.c - 1.73 linux/fs/binfmt_elf.c - 1.52 linux/fs/affs/symlink.c - 1.17 linux/fs/affs/super.c - 1.31 linux/fs/affs/namei.c - 1.23 linux/fs/affs/inode.c - 1.25 linux/fs/affs/dir.c - 1.17 linux/fs/affs/bitmap.c - 1.12 linux/fs/affs/Changes - 1.9 linux/drivers/video/leofb.c - 1.14 linux/drivers/video/fbmem.c - 1.60 linux/drivers/video/Makefile - 1.52 linux/drivers/sgi/char/sgiserial.c - 1.15 linux/drivers/scsi/sym53c8xx.h - 1.14 linux/drivers/scsi/sym53c8xx.c - 1.42 linux/drivers/scsi/sr.c - 1.63 linux/drivers/scsi/sg.c - 1.50 linux/drivers/scsi/sd.c - 1.84 linux/drivers/scsi/scsi_error.c - 1.41 linux/drivers/scsi/scsi_debug.h - 1.13 linux/drivers/scsi/scsi_debug.c - 1.31 linux/drivers/scsi/scsi.h - 1.46 linux/drivers/scsi/scsi.c - 1.72 linux/drivers/scsi/qlogicfc.c - 1.36 linux/drivers/scsi/qlogicfas.h - 1.7 linux/drivers/scsi/qlogicfas.c - 1.21 linux/drivers/scsi/ncr53c8xx.h - 1.10 linux/drivers/scsi/ncr53c8xx.c - 1.33 linux/drivers/scsi/inia100.h - 1.15 linux/drivers/scsi/inia100.c - 1.26 linux/drivers/scsi/imm.c - 1.23 linux/drivers/scsi/i91uscsi.h - 1.5 linux/drivers/scsi/hosts.h - 1.37 linux/drivers/scsi/fdomain.h - 1.9 linux/drivers/scsi/fdomain.c - 1.30 linux/drivers/pnp/Makefile - 1.20 linux/drivers/pci/quirks.c - 1.36 linux/drivers/pci/Makefile - 1.31 linux/drivers/net/shaper.c - 1.24 linux/drivers/net/eth16i.c - 1.25 linux/drivers/net/eepro100.c - 1.57 linux/drivers/net/dgrs.c - 1.24 linux/drivers/macintosh/macserial.c - 1.26 linux/drivers/isdn/hisax/teles3.c - 1.20 linux/drivers/isdn/hisax/teles0.c - 1.17 linux/drivers/isdn/hisax/teleint.c - 1.16 linux/drivers/isdn/hisax/sportster.c - 1.16 linux/drivers/isdn/hisax/sedlbauer.c - 1.24 linux/drivers/isdn/hisax/niccy.c - 1.22 linux/drivers/isdn/hisax/mic.c - 1.15 linux/drivers/isdn/hisax/ix1_micro.c - 1.17 linux/drivers/isdn/hisax/isdnl1.h - 1.9 linux/drivers/isdn/hisax/isdnl1.c - 1.21 linux/drivers/isdn/hisax/hisax.h - 1.34 linux/drivers/isdn/hisax/elsa.c - 1.25 linux/drivers/isdn/hisax/diva.c - 1.21 linux/drivers/isdn/hisax/config.c - 1.37 linux/drivers/isdn/hisax/avm_a1.c - 1.16 linux/drivers/isdn/hisax/asuscom.c - 1.20 linux/drivers/isdn/hisax/amd7930.c - 1.17 linux/drivers/char/vt.c - 1.34 linux/drivers/char/tty_io.c - 1.65 linux/drivers/char/serial167.c - 1.18 linux/drivers/char/rtc.c - 1.38 linux/drivers/char/random.c - 1.39 linux/drivers/char/Makefile - 1.83 linux/drivers/cdrom/sonycd535.c - 1.35 linux/drivers/cdrom/sjcd.c - 1.29 linux/drivers/cdrom/sbpcd.c - 1.36 linux/drivers/cdrom/optcd.c - 1.30 linux/drivers/cdrom/mcdx.c - 1.25 linux/drivers/cdrom/mcd.c - 1.30 linux/drivers/cdrom/gscd.c - 1.30 linux/drivers/cdrom/cm206.c - 1.31 linux/drivers/cdrom/cdu31a.c - 1.27 linux/drivers/cdrom/aztcd.c - 1.32 linux/drivers/block/z2ram.c - 1.27 linux/drivers/block/xd.c - 1.52 linux/drivers/block/swim3.c - 1.27 linux/drivers/block/rd.c - 1.70 linux/drivers/block/ps2esdi.c - 1.56 linux/drivers/block/paride/pf.c - 1.35 linux/drivers/block/paride/pd.c - 1.43 linux/drivers/block/paride/pcd.c - 1.31 linux/drivers/block/nbd.c - 1.52 linux/drivers/block/loop.c - 1.80 linux/drivers/block/ll_rw_blk.c - 1.129 linux/drivers/block/genhd.c - 1.49 linux/drivers/block/floppy.c - 1.63 linux/drivers/block/ataflop.c - 1.37 linux/drivers/block/amiflop.c - 1.37 linux/drivers/block/acsi.c - 1.46 linux/drivers/acorn/net/etherh.c - 1.20 linux/drivers/acorn/net/ether3.c - 1.18 linux/drivers/acorn/net/ether1.c - 1.17 linux/drivers/acorn/block/mfmhd.c - 1.38 linux/drivers/acorn/block/fd1772.c - 1.34 linux/drivers/Makefile - 1.43 linux/arch/sparc64/solaris/socket.c - 1.12 linux/arch/sparc64/kernel/systbls.S - 1.42 linux/arch/sparc64/kernel/sys_sunos32.c - 1.45 linux/arch/sparc64/kernel/sys_sparc32.c - 1.71 linux/arch/sparc64/kernel/sys32.S - 1.9 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.54 linux/arch/sparc64/kernel/smp.c - 1.53 linux/arch/sparc64/kernel/ioctl32.c - 1.69 linux/arch/sparc64/kernel/Makefile - 1.32 linux/arch/sparc64/defconfig - 1.88 linux/arch/sparc64/boot/Makefile - 1.6 linux/arch/sparc/kernel/systbls.S - 1.30 linux/arch/sparc/kernel/sys_sunos.c - 1.41 linux/arch/sparc/kernel/pcic.c - 1.27 linux/arch/sparc/kernel/irq.c - 1.27 linux/arch/sparc/kernel/Makefile - 1.23 linux/arch/sparc/boot/Makefile - 1.14 linux/arch/sparc/Makefile - 1.25 linux/arch/ppc/mm/init.c - 1.48 linux/arch/ppc/mm/fault.c - 1.25 linux/arch/ppc/kernel/process.c - 1.49 linux/arch/ppc/kernel/ppc-stub.c - 1.13 linux/arch/ppc/kernel/pci.c - 1.33 linux/arch/ppc/kernel/irq.c - 1.44 linux/arch/ppc/kernel/Makefile - 1.38 linux/arch/ppc/Makefile - 1.38 linux/arch/ppc/8xx_io/uart.c - 1.26 linux/arch/mips/sni/pci.c - 1.13 linux/arch/mips/kernel/pci.c - 1.12 linux/arch/mips/kernel/irq.c - 1.16 linux/arch/mips/kernel/Makefile - 1.15 linux/arch/m68k/kernel/Makefile - 1.15 linux/arch/m68k/atari/stram.c - 1.25 linux/arch/i386/mm/ioremap.c - 1.21 linux/arch/i386/mm/init.c - 1.53 linux/arch/i386/mm/fault.c - 1.32 linux/arch/i386/kernel/vm86.c - 1.26 linux/arch/i386/kernel/traps.c - 1.74 linux/arch/i386/kernel/setup.c - 1.90 linux/arch/i386/kernel/process.c - 1.68 linux/arch/i386/kernel/irq.c - 1.55 linux/arch/i386/kernel/io_apic.c - 1.56 linux/arch/i386/kernel/i386_ksyms.c - 1.68 linux/arch/i386/kernel/head.S - 1.32 linux/arch/i386/kernel/entry.S - 1.76 linux/arch/i386/kernel/Makefile - 1.47 linux/arch/i386/boot/tools/build.c - 1.6 linux/arch/i386/boot/compressed/Makefile - 1.15 linux/arch/i386/boot/bootsect.S - 1.18 linux/arch/i386/boot/Makefile - 1.22 linux/arch/i386/Makefile - 1.49 linux/arch/arm/mm/fault-common.c - 1.26 linux/arch/arm/kernel/time.c - 1.24 linux/arch/arm/kernel/irq.c - 1.29 linux/arch/arm/kernel/entry-common.S - 1.24 linux/arch/arm/kernel/entry-armv.S - 1.40 linux/arch/arm/kernel/ecard.c - 1.28 linux/arch/arm/kernel/Makefile - 1.26 linux/arch/arm/boot/compressed/Makefile - 1.28 linux/arch/arm/boot/Makefile - 1.24 linux/arch/arm/Makefile - 1.43 linux/arch/alpha/mm/fault.c - 1.22 linux/arch/alpha/kernel/irq.c - 1.30 linux/arch/alpha/kernel/Makefile - 1.32 linux/arch/alpha/boot/Makefile - 1.16 linux/arch/alpha/Makefile - 1.30 linux/Makefile - 1.242 linux/MAINTAINERS - 1.135 linux/Documentation/specialix.txt - 1.3 linux/Documentation/oops-tracing.txt - 1.10 linux/Documentation/networking/wanpipe.txt - 1.6 linux/Documentation/networking/wan-router.txt - 1.6 linux/Documentation/md.txt - 1.6 linux/Documentation/magic-number.txt - 1.6 linux/Documentation/kernel-docs.txt - 1.10 linux/Documentation/isdn/INTERFACE - 1.7 linux/Documentation/ide.txt - 1.11 linux/Documentation/devices.txt - 1.15 linux/Documentation/cdrom/cdrom-standard.tex - 1.4 linux/CREDITS - 1.98 linux/net/decnet/dn_nsp_in.c - 1.19 linux/net/decnet/af_decnet.c - 1.37 linux/include/net/dn_route.h - 1.8 linux/include/linux/efs_fs.h - 1.13 linux/include/asm-i386/hdreg.h - 1.3 linux/drivers/net/sk_mca.c - 1.17 linux/drivers/isdn/hisax/telespci.c - 1.15 linux/drivers/isdn/hisax/s0box.c - 1.13 linux/drivers/isdn/hisax/avm_pci.c - 1.21 linux/drivers/isdn/hisax/avm_a1p.c - 1.13 linux/arch/i386/vmlinux.lds.S - 1.18 linux/Documentation/kernel-parameters.txt - 1.23 linux/arch/mips/dec/irq.c - 1.11 linux/arch/mips/baget/irq.c - 1.12 linux/drivers/block/cpqarray.c - 1.66 linux/Documentation/cpqarray.txt - 1.5 linux/drivers/parport/ieee1284_ops.c - 1.18 linux/drivers/parport/ieee1284.c - 1.15 linux/drivers/char/raw.c - 1.36 linux/fs/partitions/check.c - 1.65 linux/drivers/isdn/hisax/saphir.c - 1.14 linux/drivers/isdn/hisax/isurf.c - 1.17 linux/drivers/isdn/hisax/hfcscard.c - 1.14 linux/drivers/isdn/hisax/hfc_pci.c - 1.29 linux/drivers/isdn/hisax/gazel.c - 1.18 linux/drivers/isdn/hisax/bkm_a4t.c - 1.17 linux/drivers/net/sis900.c - 1.43 linux/drivers/atm/Makefile - 1.25 linux/Documentation/computone.txt - 1.8 linux/net/atm/signaling.c - 1.10 linux/net/atm/resources.h - 1.3 linux/net/atm/resources.c - 1.10 linux/net/atm/raw.c - 1.7 linux/net/atm/proc.c - 1.19 linux/net/atm/mpc.c - 1.13 linux/net/atm/lec.c - 1.19 linux/net/atm/common.h - 1.5 linux/net/atm/common.c - 1.21 linux/net/atm/clip.c - 1.15 linux/net/atm/atm_misc.c - 1.5 linux/include/linux/atmdev.h - 1.14 linux/arch/arm/vmlinux-armv.lds.in - 1.26 linux/arch/arm/vmlinux-armo.lds.in - 1.23 linux/arch/arm/kernel/bios32.c - 1.35 linux/arch/alpha/kernel/pci.c - 1.31 linux/drivers/block/DAC960.c - 1.66 linux/arch/sparc64/kernel/pci_common.c - 1.21 linux/arch/sparc64/kernel/pci.c - 1.34 linux/arch/sh/vmlinux.lds.S - 1.18 linux/arch/sh/kernel/irq.c - 1.18 linux/arch/sh/kernel/Makefile - 1.19 linux/net/irda/ircomm/ircomm_core.c - 1.19 linux/include/asm-sh/processor.h - 1.21 linux/include/asm-sh/pgtable.h - 1.27 linux/include/asm-i386/pci.h - 1.21 linux/drivers/pcmcia/tcic.c - 1.22 linux/drivers/pcmcia/i82365.c - 1.35 linux/drivers/block/swim_iop.c - 1.24 linux/arch/m68k/vmlinux-sun3.lds - 1.15 linux/include/asm-sparc64/pci.h - 1.15 linux/include/asm-ppc/pci.h - 1.18 linux/Documentation/filesystems/proc.txt - 1.18 linux/arch/i386/kernel/smpboot.c - 1.59 linux/include/linux/pci_ids.h - 1.86 linux/drivers/net/wan/sdlamain.c - 1.16 linux/drivers/net/wan/sdladrv.c - 1.10 linux/drivers/net/wan/sdla_x25.c - 1.17 linux/drivers/net/wan/sdla_ppp.c - 1.22 linux/drivers/net/wan/sdla_fr.c - 1.22 linux/Documentation/arm/Setup - 1.3 linux/include/asm-i386/pgtable-3level.h - 1.13 linux/include/asm-arm/pci.h - 1.24 linux/fs/proc/proc_misc.c - 1.57 linux/drivers/isdn/hisax/w6692.c - 1.18 linux/drivers/pci/pci.ids - 1.57 linux/Documentation/networking/sis900.txt - 1.6 linux/Documentation/networking/sk98lin.txt - 1.7 linux/drivers/net/sk98lin/h/skgepnm2.h - 1.5 linux/arch/alpha/kernel/sys_nautilus.c - 1.13 linux/Documentation/video4linux/zr36120.txt - 1.4 linux/drivers/scsi/scsi_lib.c - 1.60 linux/include/linux/i2c-id.h - 1.16 linux/drivers/i2c/i2c-algo-pcf.c - 1.14 linux/drivers/i2c/i2c-core.c - 1.23 linux/drivers/i2c/i2c-algo-bit.c - 1.16 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.11 linux/drivers/sbus/char/jsflash.c - 1.28 linux/Documentation/usb/URB.txt - 1.7 linux/Documentation/usb/scanner.txt - 1.9 linux/drivers/pci/setup-res.c - 1.14 linux/drivers/pci/setup-bus.c - 1.11 linux/drivers/scsi/scsi_scan.c - 1.42 linux/drivers/net/wan/sdla_chdlc.c - 1.22 linux/drivers/char/vme_scc.c - 1.14 linux/arch/ia64/kernel/gate.S - 1.14 linux/arch/ia64/kernel/entry.S - 1.35 linux/arch/ia64/kernel/acpi.c - 1.20 linux/arch/ia64/kernel/Makefile - 1.19 linux/arch/ia64/ia32/sys_ia32.c - 1.41 linux/arch/ia64/ia32/ia32_support.c - 1.9 linux/arch/ia64/ia32/ia32_entry.S - 1.21 linux/arch/ia64/vmlinux.lds.S - 1.23 linux/arch/ia64/tools/print_offsets.c - 1.16 linux/arch/ia64/boot/Makefile - 1.10 linux/arch/ia64/Makefile - 1.25 linux/arch/ia64/kernel/init_task.c - 1.7 linux/arch/ia64/kernel/irq.c - 1.27 linux/arch/ia64/kernel/setup.c - 1.24 linux/arch/ia64/kernel/signal.c - 1.23 linux/arch/ia64/kernel/smp.c - 1.22 linux/arch/ia64/kernel/sys_ia64.c - 1.19 linux/arch/ia64/kernel/time.c - 1.20 linux/arch/ia64/kernel/traps.c - 1.19 linux/arch/ia64/kernel/unwind.c - 1.13 linux/arch/ia64/kernel/ivt.S - 1.21 linux/arch/ia64/kernel/machvec.c - 1.6 linux/arch/ia64/kernel/ptrace.c - 1.22 linux/arch/ia64/kernel/process.c - 1.26 linux/arch/ia64/kernel/perfmon.c - 1.22 linux/arch/ia64/mm/tlb.c - 1.16 linux/arch/ia64/kernel/mca.c - 1.18 linux/arch/ia64/mm/fault.c - 1.14 linux/include/asm-ia64/iosapic.h - 1.8 linux/include/asm-ia64/ide.h - 1.15 linux/include/asm-ia64/hardirq.h - 1.17 linux/include/linux/raid/md_p.h - 1.5 linux/include/asm-ia64/siginfo.h - 1.17 linux/include/linux/raid/md_k.h - 1.32 linux/include/asm-ia64/sal.h - 1.13 linux/include/asm-ia64/processor.h - 1.31 linux/include/asm-ia64/posix_types.h - 1.2 linux/include/linux/raid/md.h - 1.22 linux/include/asm-ia64/pgtable.h - 1.21 linux/include/asm-ia64/machvec.h - 1.12 linux/include/asm-ia64/machvec_dig.h - 1.5 linux/include/asm-ia64/machvec_hpsim.h - 1.5 linux/include/asm-ia64/pci.h - 1.17 linux/include/asm-ia64/page.h - 1.21 linux/include/asm-ia64/ptrace.h - 1.12 linux/include/asm-ia64/machvec_sn1.h - 1.7 linux/include/asm-ia64/spinlock.h - 1.12 linux/include/asm-ia64/unistd.h - 1.30 linux/include/asm-ia64/unwind.h - 1.6 linux/include/asm-ia64/system.h - 1.24 linux/drivers/char/amiserial.c - 1.18 linux/drivers/isdn/hisax/hfc_sx.c - 1.19 linux/arch/i386/kernel/microcode.c - 1.23 linux/Documentation/filesystems/devfs/README - 1.18 linux/include/linux/devfs_fs_kernel.h - 1.18 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.12 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.13 linux/fs/devfs/base.c - 1.53 linux/arch/mips/ddb5074/pci.c - 1.11 linux/include/asm-mips64/processor.h - 1.15 linux/include/asm-mips64/pci.h - 1.11 linux/arch/mips64/sgi-ip22/ip22-int.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-pci.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-irq.c - 1.12 linux/arch/mips64/kernel/scall_o32.S - 1.11 linux/arch/mips64/kernel/linux32.c - 1.17 linux/arch/mips64/kernel/Makefile - 1.10 linux/drivers/net/bonding.c - 1.19 linux/include/asm-sh/pci.h - 1.15 linux/drivers/char/sh-sci.c - 1.21 linux/net/econet/af_econet.c - 1.18 linux/include/linux/usb.h - 1.57 linux/drivers/usb/serial/usb-serial.h - 1.30 linux/drivers/usb/serial/usb-serial.c - 1.15 linux/drivers/ide/ide-probe.c - 1.50 linux/drivers/ide/ide-floppy.c - 1.43 linux/drivers/ide/ide-dma.c - 1.37 linux/drivers/ide/ide-disk.c - 1.55 linux/drivers/ide/Makefile - 1.35 linux/net/ipv4/netfilter/iptable_mangle.c - 1.12 linux/net/ipv4/netfilter/iptable_filter.c - 1.7 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.21 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.10 linux/net/ipv4/netfilter/ip_fw_compat.c - 1.15 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.19 linux/include/linux/netfilter_ipv4/ipchains_core.h - 1.2 linux/include/asm-arm/arch-shark/time.h - 1.9 linux/drivers/video/sa1100fb.c - 1.22 linux/drivers/usb/serial/visor.h - 1.16 linux/drivers/usb/serial/visor.c - 1.51 linux/drivers/net/pppoe.c - 1.27 linux/drivers/char/rio/riotty.c - 1.8 linux/drivers/char/rio/riotable.c - 1.8 linux/drivers/char/rio/rioroute.c - 1.7 linux/drivers/char/rio/rioparam.c - 1.5 linux/drivers/char/rio/riointr.c - 1.6 linux/drivers/char/rio/rioinit.c - 1.7 linux/drivers/char/rio/rioctrl.c - 1.10 linux/drivers/char/rio/riocmd.c - 1.9 linux/drivers/char/rio/rioboot.c - 1.8 linux/drivers/char/rio/rio_linux.c - 1.20 linux/include/linux/raid/raid5.h - 1.12 linux/include/linux/raid/raid1.h - 1.14 linux/arch/s390/boot/Makefile - 1.12 linux/arch/s390/Makefile - 1.16 linux/arch/s390/kernel/Makefile - 1.13 linux/drivers/s390/char/con3215.c - 1.13 linux/include/asm-s390/processor.h - 1.14 linux/include/asm-s390/pgtable.h - 1.18 linux/Documentation/s390/cds.txt - 1.10 linux/include/asm-arm/arch-sa1100/time.h - 1.8 linux/net/ipv6/netfilter/ip6table_filter.c - 1.6 linux/Documentation/kernel-doc-nano-HOWTO.txt - 1.6 linux/include/linux/profile.h - 1.6 linux/drivers/char/i810_rng.c - 1.12 linux/drivers/usb/storage/transport.h - 1.17 linux/drivers/usb/storage/transport.c - 1.40 linux/arch/alpha/kernel/core_titan.c - 1.10 linux/drivers/usb/serial/keyspan_usa28msg.h - 1.5 linux/drivers/usb/serial/keyspan_usa26msg.h - 1.6 linux/include/asm-i386/i387.h - 1.8 linux/arch/i386/kernel/i387.c - 1.13 linux/arch/ia64/ia32/ia32_ioctl.c - 1.8 linux/arch/ia64/kernel/palinfo.c - 1.12 linux/arch/ia64/kernel/unwind_i.h - 1.6 linux/drivers/mtd/ftl.c - 1.33 linux/drivers/mtd/mtdblock.c - 1.31 linux/net/ipv4/tcp_minisocks.c - 1.23 linux/drivers/usb/storage/sddr09.c - 1.22 linux/drivers/media/video/zr36120.c - 1.17 linux/drivers/media/video/tvmixer.c - 1.13 linux/drivers/media/video/tuner.h - 1.10 linux/drivers/media/video/tuner.c - 1.15 linux/drivers/media/video/tuner-3036.c - 1.6 linux/drivers/media/video/tda9875.c - 1.11 linux/drivers/media/video/tda7432.c - 1.11 linux/drivers/media/video/planb.c - 1.14 linux/drivers/media/video/msp3400.c - 1.16 linux/Documentation/networking/tuntap.txt - 1.5 linux/drivers/media/video/bw-qcam.c - 1.12 linux/drivers/media/video/bttv-if.c - 1.10 linux/drivers/media/video/bttv-driver.c - 1.28 linux/drivers/media/video/bttv-cards.c - 1.18 linux/drivers/media/video/audiochip.h - 1.4 linux/drivers/isdn/hisax/nj_u.c - 1.14 linux/drivers/isdn/hisax/nj_s.c - 1.15 linux/arch/arm/boot/bootp/Makefile - 1.8 linux/arch/arm/tools/mach-types - 1.23 linux/drivers/md/raid1.c - 1.31 linux/drivers/md/raid5.c - 1.41 linux/Documentation/kbuild/makefiles.txt - 1.9 linux/arch/arm/mach-sa1100/Makefile - 1.19 linux/drivers/block/cciss.c - 1.53 linux/drivers/block/cciss.h - 1.19 linux/drivers/md/linear.c - 1.19 linux/drivers/md/md.c - 1.71 linux/drivers/md/raid0.c - 1.17 linux/drivers/usb/serial/belkin_sa.c - 1.29 linux/drivers/media/video/tvaudio.c - 1.15 linux/drivers/media/video/id.h - 1.4 linux/drivers/media/video/bttvp.h - 1.12 linux/include/asm-generic/xor.h - 1.3 linux/include/asm-i386/cpufeature.h - 1.6 linux/include/asm-i386/xor.h - 1.10 linux/Documentation/arm/SA1100/serial_UART - 1.3 linux/drivers/usb/serial/keyspan_usa49msg.h - 1.5 linux/include/asm-parisc/pci.h - 1.7 linux/include/asm-parisc/pgtable.h - 1.10 linux/include/asm-parisc/processor.h - 1.10 linux/arch/parisc/kernel/syscall.S - 1.8 linux/arch/i386/kernel/dmi_scan.c - 1.26 linux/include/asm-m68k/sun3_pgtable.h - 1.4 linux/arch/parisc/kernel/pci.c - 1.6 linux/arch/parisc/kernel/Makefile - 1.10 linux/arch/parisc/Makefile - 1.13 linux/drivers/atm/firestream.c - 1.15 linux/Documentation/DocBook/sis900.tmpl - 1.3 linux/drivers/scsi/osst.c - 1.24 linux/arch/ia64/kernel/iosapic.c - 1.15 linux/include/asm-ia64/sn/module.h - 1.5 linux/arch/ia64/sn/io/Makefile - 1.10 linux/fs/reiserfs/journal.c - 1.40 linux/net/ipv6/netfilter/ip6table_mangle.c - 1.6 linux/include/asm-s390x/processor.h - 1.11 linux/include/asm-s390x/pgtable.h - 1.15 linux/include/asm-s390x/fcntl.h - 1.3 linux/arch/s390x/kernel/linux32.h - 1.7 linux/arch/s390x/kernel/linux32.c - 1.26 linux/arch/cris/kernel/Makefile - 1.15 linux/arch/cris/kernel/irq.c - 1.11 linux/arch/s390x/kernel/entry.S - 1.22 linux/arch/s390x/kernel/Makefile - 1.13 linux/drivers/s390/block/xpram.c - 1.31 linux/arch/s390x/kernel/wrapper32.S - 1.14 linux/drivers/s390/block/dasd_3990_erp.c - 1.13 linux/drivers/pcmcia/hd64465_ss.c - 1.10 linux/include/asm-cris/processor.h - 1.13 linux/arch/s390x/boot/Makefile - 1.12 linux/arch/s390x/Makefile - 1.17 linux/Documentation/i810_rng.txt - 1.7 linux/drivers/usb/serial/io_ionsp.h - 1.3 linux/drivers/usb/serial/io_edgeport.c - 1.33 linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.7 linux/arch/arm/mach-integrator/Makefile - 1.7 linux/drivers/net/wan/sdla_ft1.c - 1.6 linux/drivers/net/wan/wanpipe_multppp.c - 1.10 linux/drivers/s390/char/tuball.c - 1.8 linux/net/wanrouter/af_wanpipe.c - 1.14 linux/Documentation/s390/Debugging390.txt - 1.9 linux/arch/sh/kernel/pci_st40.c - 1.7 linux/include/asm-ia64/perfmon.h - 1.9 linux/arch/mips/mips-boards/generic/pci.c - 1.6 linux/arch/mips/mips-boards/atlas/atlas_int.c - 1.5 linux/arch/mips/ite-boards/generic/it8172_pci.c - 1.5 linux/arch/mips/ite-boards/generic/irq.c - 1.7 linux/arch/mips/ddb5476/pci.c - 1.6 linux/arch/mips/arc/arc_con.c - 1.2 linux/include/linux/compiler.h - 1.9 linux/include/linux/if_wanpipe.h - 1.4 linux/include/linux/if_wanpipe_common.h - 1.4 linux/Documentation/usb/philips.txt - 1.7 linux/fs/char_dev.c - 1.7 linux/arch/ppc/boot/images/Makefile - 1.6 linux/include/net/bluetooth/bluetooth.h - 1.9 linux/net/bluetooth/af_bluetooth.c - 1.12 linux/net/bluetooth/hci_sock.c - 1.12 linux/drivers/mtd/nftlcore.c - 1.30 linux/drivers/mtd/mtdblock_ro.c - 1.17 linux/drivers/media/radio/miropcm20-rds.c - 1.5 linux/drivers/usb/serial/pl2303.h - 1.8 linux/drivers/usb/serial/cyberjack.c - 1.23 linux/drivers/usb/serial/pl2303.c - 1.29 linux/arch/sh/kernel/pci-sh7751.c - 1.7 linux/arch/sh/kernel/pci-dc.c - 1.5 linux/arch/mips/kernel/old-irq.c - 1.6 linux/drivers/media/video/zoran.h - 1.2 linux/Documentation/sonypi.txt - 1.11 linux/drivers/usb/usb-skeleton.c - 1.22 linux/fs/partitions/ldm.c - 1.11 linux/drivers/usb/storage/isd200.c - 1.14 linux/arch/ia64/kernel/sigframe.h - 1.4 linux/include/asm-arm/arch-anakin/time.h - 1.4 linux/arch/arm/mach-integrator/cpu.c - 1.12 linux/arch/arm/mach-sa1100/irq.c - 1.12 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.11 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.13 linux/arch/arm/mach-sa1100/generic.h - 1.6 linux/arch/arm/mach-sa1100/generic.c - 1.13 linux/drivers/char/serial_tx3912.c - 1.8 linux/arch/sh/kernel/pcibios.c - 1.3 linux/arch/mips64/sgi-ip32/ip32-pci.c - 1.4 linux/arch/mips/au1000/common/serial.c - 1.9 linux/arch/mips64/mips-boards/generic/pci.c - 1.4 linux/arch/mips64/sgi-ip32/Makefile - 1.6 linux/arch/mips/ddb5xxx/common/pci.c - 1.5 linux/arch/mips/gt64120/common/pci.c - 1.5 linux/arch/mips/philips/nino/irq.c - 1.5 linux/arch/mips64/mips-boards/malta/malta_int.c - 1.4 linux/arch/mips64/mips-boards/atlas/atlas_int.c - 1.4 linux/drivers/char/decserial.c - 1.2 linux/Documentation/input/ff.txt - 1.4 linux/Documentation/usb/hiddev.txt - 1.5 linux/include/linux/raid/multipath.h - 1.7 linux/drivers/md/multipath.c - 1.18 linux/drivers/usb/serial/ir-usb.c - 1.26 linux/drivers/pcmcia/sa1100_generic.c - 1.15 linux/drivers/i2c/i2c-proc.c - 1.12 linux/drivers/message/i2o/i2o_block.c - 1.31 linux/arch/arm/mach-sa1100/pm.c - 1.9 linux/net/8021q/vlanproc.c - 1.8 linux/Documentation/networking/ifenslave.c - 1.5 linux/Documentation/networking/bonding.txt - 1.8 linux/drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.7 linux/fs/ext3/ialloc.c - 1.23 linux/fs/ext3/inode.c - 1.34 linux/fs/ext3/ioctl.c - 1.7 linux/fs/ext3/super.c - 1.31 linux/fs/intermezzo/file.c - 1.7 linux/drivers/hotplug/cpqphp_pci.c - 1.10 linux/fs/intermezzo/methods.c - 1.8 linux/fs/intermezzo/super.c - 1.11 linux/include/linux/ext3_fs.h - 1.16 linux/fs/seq_file.c - 1.8 linux/fs/ext3/dir.c - 1.9 linux/fs/intermezzo/cache.c - 1.9 linux/fs/intermezzo/dir.c - 1.10 linux/include/linux/bio.h - 1.19 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.12 linux/include/linux/device.h - 1.29 linux/drivers/isdn/hisax/hisax_isac.h - 1.4 linux/drivers/isdn/hisax/hisax_isac.c - 1.5 linux/init/do_mounts.c - 1.26 linux/arch/arm/mach-sa1100/system3.c - 1.14 linux/arch/arm/mach-arc/Makefile - 1.6 linux/drivers/ide/ide-taskfile.c - 1.27 linux/fs/ext2/ext2.h - 1.11 linux/drivers/isdn/hisax/hisax_fcclassic.c - 1.3 linux/include/asm-i386/thread_info.h - 1.9 linux/Documentation/filesystems/directory-locking - 1.4 linux/sound/pci/intel8x0.c - 1.15 linux/arch/ppc/boot/common/util.S - 1.5 linux/sound/pci/ac97/ac97_codec.c - 1.14 linux/arch/ppc/boot/simple/head.S - 1.5 linux/arch/ppc/boot/simple/rw4/ppc_40x.h - 1.3 linux/sound/oss/trident.c - 1.12 linux/sound/oss/sb_card.c - 1.5 linux/arch/ppc/platforms/lopec_setup.c - 1.12 linux/arch/x86_64/Makefile - 1.16 linux/arch/x86_64/boot/Makefile - 1.13 linux/arch/x86_64/boot/compressed/Makefile - 1.7 linux/arch/x86_64/boot/setup.S - 1.4 linux/arch/x86_64/ia32/Makefile - 1.11 linux/arch/x86_64/ia32/ia32_signal.c - 1.11 linux/arch/x86_64/ia32/ia32entry.S - 1.10 linux/arch/x86_64/ia32/ptrace32.c - 1.5 linux/arch/x86_64/ia32/socket32.c - 1.4 linux/arch/x86_64/ia32/sys_ia32.c - 1.16 linux/arch/x86_64/kernel/Makefile - 1.16 linux/arch/x86_64/kernel/apic.c - 1.13 linux/arch/x86_64/kernel/head64.c - 1.6 linux/arch/x86_64/kernel/io_apic.c - 1.7 linux/arch/x86_64/kernel/irq.c - 1.9 linux/arch/x86_64/kernel/process.c - 1.16 linux/arch/x86_64/kernel/ptrace.c - 1.10 linux/arch/x86_64/kernel/setup64.c - 1.11 linux/arch/x86_64/kernel/signal.c - 1.12 linux/arch/x86_64/kernel/time.c - 1.11 linux/arch/x86_64/lib/getuser.S - 1.2 linux/sound/isa/als100.c - 1.8 linux/include/asm-x86_64/segment.h - 1.7 linux/include/asm-x86_64/ptrace.h - 1.7 linux/include/asm-x86_64/processor.h - 1.12 linux/include/asm-x86_64/pgtable.h - 1.13 linux/include/asm-x86_64/pci.h - 1.5 linux/include/asm-x86_64/ia32.h - 1.9 linux/include/asm-x86_64/fcntl.h - 1.2 linux/include/asm-x86_64/desc.h - 1.7 linux/include/asm-x86_64/socket32.h - 1.4 linux/include/asm-x86_64/unistd.h - 1.13 linux/include/asm-x86_64/uaccess.h - 1.7 linux/include/asm-ppc64/fcntl.h - 1.3 linux/arch/ppc64/Makefile - 1.17 linux/arch/ppc64/boot/Makefile - 1.10 linux/arch/ppc64/boot/main.c - 1.5 linux/arch/ppc64/kernel/Makefile - 1.16 linux/arch/ppc64/kernel/chrp_setup.c - 1.11 linux/arch/ppc64/kernel/eeh.c - 1.7 linux/arch/ppc64/kernel/entry.S - 1.16 linux/arch/ppc64/kernel/head.S - 1.12 linux/arch/ppc64/kernel/htab.c - 1.11 linux/arch/ppc64/kernel/irq.c - 1.10 linux/arch/ppc64/kernel/misc.S - 1.17 linux/arch/ppc64/kernel/pSeries_pci.c - 1.10 linux/arch/ppc64/kernel/pci.c - 1.11 linux/arch/ppc64/kernel/pci.h - 1.5 linux/arch/ppc64/kernel/pci_dma.c - 1.8 linux/arch/ppc64/kernel/prom.c - 1.11 linux/arch/ppc64/kernel/rtc.c - 1.6 linux/arch/ppc64/kernel/sys32.S - 1.9 linux/arch/ppc64/kernel/sys_ppc32.c - 1.18 linux/arch/ppc64/mm/extable.c - 1.6 linux/arch/ppc64/xmon/xmon.c - 1.11 linux/include/asm-ppc64/processor.h - 1.14 linux/include/asm-ppc64/pci.h - 1.4 linux/include/asm-ppc64/pci-bridge.h - 1.5 linux/Documentation/arm/mem_alignment - 1.2 linux/Documentation/networking/3c359.txt - 1.2 linux/drivers/hotplug/ibmphp_core.c - 1.12 linux/fs/jfs/jfs_logmgr.c - 1.25 linux/fs/jfs/jfs_txnmgr.c - 1.24 linux/drivers/net/e100/e100_main.c - 1.16 linux/Documentation/sound/oss/NEWS - 1.2 linux/Documentation/sound/oss/PSS-updates - 1.3 linux/Documentation/sound/oss/cs46xx - 1.2 linux/Documentation/ia64/IRQ-redir.txt - 1.2 linux/arch/ia64/sn/kernel/sn2/Makefile - 1.7 linux/arch/ia64/sn/kernel/setup.c - 1.7 linux/arch/ia64/sn/kernel/mca.c - 1.4 linux/include/asm-ia64/thread_info.h - 1.5 linux/include/asm-ia64/machvec_sn2.h - 1.4 linux/Documentation/networking/NAPI_HOWTO.txt - 1.4 linux/drivers/media/video/video-buf.h - 1.6 linux/net/ipv4/netfilter/arptable_filter.c - 1.3 linux/drivers/media/video/video-buf.c - 1.8 linux/drivers/net/wan/comx-hw-munich.c - 1.9 linux/drivers/usb/class/bluetty.c - 1.16 linux/drivers/usb/class/cdc-acm.c - 1.16 linux/drivers/usb/core/hub.c - 1.21 linux/drivers/usb/input/hid-core.c - 1.16 linux/drivers/usb/core/usb.c - 1.29 linux/drivers/usb/media/konicawc.c - 1.11 linux/drivers/usb/host/ohci-q.c - 1.21 linux/drivers/usb/image/hpusbscsi.c - 1.11 linux/drivers/usb/image/hpusbscsi.h - 1.4 linux/drivers/usb/image/scanner.c - 1.19 linux/drivers/usb/image/scanner.h - 1.13 linux/drivers/usb/input/hid-input.c - 1.8 linux/drivers/usb/input/hid.h - 1.8 linux/drivers/usb/media/dsbr100.c - 1.7 linux/drivers/usb/media/pwc-ctrl.c - 1.5 linux/drivers/usb/media/pwc-if.c - 1.9 linux/drivers/usb/media/pwc-uncompress.c - 1.3 linux/drivers/usb/media/pwc.h - 1.5 linux/drivers/usb/media/se401.c - 1.13 linux/drivers/usb/net/usbnet.c - 1.17 linux/drivers/usb/media/vicam.c - 1.11 linux/mm/readahead.c - 1.17 linux/mm/pdflush.c - 1.13 linux/drivers/usb/misc/auerswald.c - 1.14 linux/Documentation/filesystems/Exporting - 1.2 linux/include/asm-ia64/machvec_hpzx1.h - 1.4 linux/drivers/isdn/i4l/isdn_ppp.c - 1.13 linux/fs/exportfs/expfs.c - 1.8 linux/include/asm-arm/proc-armv/tlbflush.h - 1.3 linux/arch/ia64/hp/sim/simserial.c - 1.9 linux/arch/ia64/hp/sim/simscsi.c - 1.9 linux/drivers/isdn/hardware/avm/b1pci.c - 1.6 linux/scripts/mkcompile_h - 1.8 linux/drivers/block/umem.c - 1.19 linux/Documentation/networking/3c509.txt - 1.2 linux/drivers/usb/host/uhci-hcd.c - 1.17 linux/drivers/net/wan/pc300_tty.c - 1.5 linux/arch/i386/pci/common.c - 1.8 linux/arch/i386/pci/i386.c - 1.4 linux/arch/i386/pci/irq.c - 1.4 linux/drivers/pci/probe.c - 1.14 linux/net/bluetooth/sco.c - 1.7 linux/net/bluetooth/l2cap.c - 1.8 linux/mm/page-writeback.c - 1.20 linux/init/Makefile - 1.16 linux/include/linux/writeback.h - 1.12 linux/include/linux/jiffies.h - 1.5 linux/Documentation/block/biodoc.txt - 1.4 linux/Documentation/swsusp.txt - 1.4 linux/drivers/base/bus.c - 1.14 linux/drivers/usb/host/hc_simple.c - 1.7 linux/drivers/usb/host/hc_simple.h - 1.2 linux/drivers/usb/host/hc_sl811.h - 1.2 linux/drivers/char/hvc_console.c - 1.9 linux/drivers/usb/core/urb.c - 1.10 linux/drivers/usb/core/message.c - 1.15 linux/drivers/isdn/hisax/enternow_pci.c - 1.7 linux/drivers/usb/class/usb-midi.c - 1.10 linux/drivers/usb/class/usb-midi.h - 1.4 linux/drivers/usb/host/ohci-pci.c - 1.7 linux/arch/i386/kernel/cpu/proc.c - 1.7 linux/drivers/s390/block/dasd_genhd.c - 1.14 linux/arch/i386/kernel/cpu/centaur.c - 1.6 linux/arch/i386/kernel/cpu/common.c - 1.12 linux/arch/x86_64/pci/x86-64.c - 1.3 linux/arch/x86_64/pci/irq.c - 1.4 linux/arch/x86_64/pci/legacy.c - 1.3 linux/arch/x86_64/pci/pci.h - 1.4 linux/arch/x86_64/pci/direct.c - 1.4 linux/include/asm-x86_64/suspend.h - 1.3 linux/net/llc/llc_conn.c - 1.8 linux/drivers/message/fusion/lsi/mpi_raid.h - 1.3 linux/security/dummy.c - 1.9 linux/security/capability.c - 1.8 linux/drivers/serial/clps711x.c - 1.8 linux/drivers/usb/serial/io_ti.c - 1.9 linux/drivers/serial/uart00.c - 1.9 linux/drivers/serial/sa1100.c - 1.7 linux/drivers/serial/core.c - 1.10 linux/drivers/serial/anakin.c - 1.8 linux/drivers/serial/amba.c - 1.9 linux/drivers/serial/8250_pci.c - 1.7 linux/drivers/serial/8250.h - 1.3 linux/drivers/serial/8250.c - 1.14 linux/arch/i386/mm/pgtable.c - 1.7 linux/drivers/serial/21285.c - 1.8 linux/include/linux/serial_core.h - 1.11 linux/include/linux/security.h - 1.8 linux/drivers/usb/misc/speedtouch.c - 1.13 linux/fs/aio.c - 1.11 linux/arch/alpha/vmlinux.lds.S - 1.8 linux/drivers/i2c/i2c-algo-ibm_ocp.c - 1.5 linux/include/linux/aio.h - 1.4 linux/arch/mips64/vmlinux.lds.S - 1.3 linux/net/sctp/ulpqueue.c - 1.6 linux/arch/i386/mm/discontig.c - 1.7 linux/arch/i386/kernel/numaq.c - 1.6 linux/include/asm-i386/mmzone.h - 1.7 linux/include/asm-i386/numaq.h - 1.7 linux/drivers/ide/pci/via82cxxx.c - 1.7 linux/drivers/ide/pci/amd74xx.c - 1.11 linux/drivers/ide/legacy/hd.c - 1.11 linux/drivers/ide/ide-lib.c - 1.7 linux/arch/um/drivers/stdio_console.c - 1.6 linux/arch/um/drivers/ubd_kern.c - 1.10 linux/arch/um/kernel/mem.c - 1.8 linux/drivers/ide/ide-iops.c - 1.5 linux/include/asm-um/pgtable.h - 1.7 linux/arch/um/sys-i386/util/Makefile - 1.4 linux/arch/um/util/Makefile - 1.6 linux/arch/m68k/vmlinux-std.lds - 1.6 linux/arch/ppc64/vmlinux.lds.S - 1.6 linux/arch/x86_64/vmlinux.lds.S - 1.8 linux/arch/sparc64/vmlinux.lds.S - 1.8 linux/arch/sparc/vmlinux.lds.S - 1.9 linux/arch/s390x/vmlinux.lds.S - 1.9 linux/arch/cris/vmlinux.lds.S - 1.4 linux/arch/ppc/vmlinux.lds.S - 1.8 linux/arch/s390/vmlinux.lds.S - 1.9 linux/arch/mips/vmlinux.lds.S - 1.4 linux/arch/parisc/vmlinux.lds.S - 1.7 linux/Documentation/driver-model/driver.txt - 1.4 linux/Documentation/driver-model/platform.txt - 1.2 linux/net/bridge/netfilter/ebtables.c - 1.5 linux/net/bridge/netfilter/ebtable_nat.c - 1.3 linux/net/bridge/netfilter/ebtable_filter.c - 1.3 linux/net/bridge/netfilter/ebtable_broute.c - 1.3 linux/net/bridge/netfilter/ebt_vlan.c - 1.3 linux/net/bridge/netfilter/ebt_snat.c - 1.2 linux/net/bridge/netfilter/ebt_redirect.c - 1.2 linux/net/bridge/netfilter/ebt_mark_m.c - 1.2 linux/net/bridge/netfilter/ebt_mark.c - 1.2 linux/net/bridge/netfilter/ebt_log.c - 1.3 linux/net/bridge/netfilter/ebt_ip.c - 1.3 linux/drivers/base/platform.c - 1.5 linux/net/bridge/netfilter/ebt_dnat.c - 1.2 linux/net/bridge/netfilter/ebt_arp.c - 1.2 linux/arch/ia64/pci/pci.c - 1.4 linux/arch/ia64/mm/hugetlbpage.c - 1.7 linux/drivers/block/deadline-iosched.c - 1.8 linux/include/linux/netfilter_bridge/ebt_ip.h - 1.3 linux/include/linux/netfilter_bridge/ebt_log.h - 1.2 linux/include/linux/netfilter_bridge/ebt_redirect.h - 1.2 linux/include/linux/netfilter_bridge/ebtables.h - 1.3 linux/include/linux/netfilter_bridge/ebt_nat.h - 1.2 linux/include/linux/netfilter_bridge/ebt_mark_t.h - 1.2 linux/Documentation/vm/hugetlbpage.txt - 1.5 linux/include/asm-ia64/topology.h - 1.6 linux/include/asm-ppc64/topology.h - 1.5 linux/kernel/cpufreq.c - 1.10 linux/net/llc/af_llc.c - 1.5 linux/include/linux/cpufreq.h - 1.11 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.9 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.10 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.8 linux/Documentation/filesystems/ext3.txt - 1.3 linux/drivers/char/amd768_rng.c - 1.4 linux/drivers/scsi/aacraid/linit.c - 1.9 linux/drivers/isdn/i4l/isdn_net_lib.c - 1.6 linux/net/bluetooth/rfcomm/sock.c - 1.7 linux/net/bluetooth/rfcomm/core.c - 1.8 linux/net/bluetooth/bnep/core.c - 1.7 linux/Documentation/DocBook/journal-api.tmpl - 1.6 linux/fs/cifs/TODO - 1.4 linux/fs/cifs/cifs_debug.c - 1.6 linux/fs/cifs/cifs_fs_sb.h - 1.2 linux/net/sunrpc/svcauth_unix.c - 1.6 linux/fs/cifs/cifsfs.c - 1.7 linux/fs/cifs/cifssmb.c - 1.8 linux/fs/cifs/connect.c - 1.7 linux/fs/cifs/file.c - 1.7 linux/fs/cifs/misc.c - 1.5 linux/fs/cifs/CHANGES - 1.6 linux/fs/cifs/transport.c - 1.5 linux/include/linux/sunrpc/cache.h - 1.5 linux/drivers/oprofile/buffer_sync.c - 1.8 linux/drivers/oprofile/cpu_buffer.c - 1.5 linux/drivers/oprofile/cpu_buffer.h - 1.4 linux/drivers/oprofile/oprofile_stats.c - 1.3 linux/drivers/serial/8250_acorn.c - 1.3 linux/include/asm-x86_64/proto.h - 1.8 linux/arch/i386/oprofile/nmi_int.c - 1.7 linux/arch/i386/oprofile/op_model_athlon.c - 1.5 linux/arch/i386/oprofile/op_model_ppro.c - 1.5 linux/fs/intermezzo/replicator.c - 1.3 linux/fs/intermezzo/fileset.c - 1.3 linux/Documentation/filesystems/sysfs.txt - 1.4 linux/arch/x86_64/mm/pageattr.c - 1.4 linux/scripts/Makefile.clean - 1.5 linux/Documentation/pnp.txt - 1.3 linux/drivers/pnp/resource.c - 1.7 linux/drivers/pnp/driver.c - 1.7 linux/fs/sysfs/inode.c - 1.9 linux/drivers/pnp/system.c - 1.5 linux/drivers/pnp/isapnp/core.c - 1.8 linux/drivers/pnp/interface.c - 1.8 linux/include/linux/pnp.h - 1.8 linux/Documentation/crypto/api-intro.txt - 1.6 linux/Documentation/kobject.txt - 1.4 linux/arch/alpha/Kconfig - 1.9 linux/arch/arm/Kconfig - 1.8 linux/scripts/kconfig/zconf.y - 1.3 linux/scripts/kconfig/zconf.tab.c_shipped - 1.4 linux/scripts/kconfig/zconf.l - 1.4 linux/scripts/kconfig/symbol.c - 1.3 linux/scripts/kconfig/qconf.h - 1.3 linux/scripts/kconfig/qconf.cc - 1.4 linux/scripts/kconfig/menu.c - 1.3 linux/scripts/kconfig/mconf.c - 1.4 linux/arch/arm/mach-sa1100/Kconfig - 1.3 linux/arch/cris/Kconfig - 1.6 linux/arch/i386/Kconfig - 1.14 linux/scripts/kconfig/lex.zconf.c_shipped - 1.4 linux/scripts/kconfig/images.c - 1.2 linux/scripts/kconfig/expr.h - 1.4 linux/include/linux/crypto.h - 1.5 linux/arch/ia64/Kconfig - 1.7 linux/scripts/kconfig/Makefile - 1.5 linux/scripts/Makefile.lib - 1.6 linux/scripts/Makefile.build - 1.9 linux/drivers/char/Kconfig - 1.6 linux/arch/m68k/Kconfig - 1.9 linux/arch/mips/Kconfig - 1.7 linux/arch/mips64/Kconfig - 1.7 linux/arch/parisc/Kconfig - 1.8 linux/include/asm-ia64/mmzone.h - 1.4 linux/drivers/pnp/Kconfig - 1.4 linux/arch/parisc/kernel/sys_parisc32.c - 1.8 linux/drivers/md/dm.c - 1.5 linux/drivers/scsi/Kconfig - 1.9 linux/drivers/isdn/i4l/Kconfig - 1.3 linux/arch/ppc/Kconfig - 1.7 linux/arch/ppc64/Kconfig - 1.8 linux/arch/s390/Kconfig - 1.7 linux/net/ipv4/ah.c - 1.6 linux/arch/s390x/Kconfig - 1.8 linux/arch/sh/Kconfig - 1.7 linux/drivers/hotplug/acpiphp_glue.c - 1.7 linux/arch/sparc/Kconfig - 1.9 linux/drivers/scsi/pcmcia/Kconfig - 1.4 linux/drivers/isdn/i4l/isdn_ppp_mp.h - 1.2 linux/drivers/isdn/i4l/isdn_ppp_mp.c - 1.2 linux/arch/sparc64/Kconfig - 1.9 linux/arch/um/Kconfig - 1.5 linux/arch/x86_64/Kconfig - 1.11 linux/fs/Kconfig - 1.10 linux/crypto/api.c - 1.5 linux/crypto/cipher.c - 1.5 linux/crypto/digest.c - 1.5 linux/crypto/internal.h - 1.5 linux/net/ipv4/xfrm_policy.c - 1.7 linux/drivers/serial/Kconfig - 1.5 linux/net/ipv4/xfrm_input.c - 1.4 linux/net/ipv4/xfrm_state.c - 1.5 linux/net/ipv6/Kconfig - 1.3 linux/include/linux/usb_ch9.h - 1.2 linux/include/net/xfrm.h - 1.7 linux/init/Kconfig - 1.7 linux/usr/gen_init_cpio.c - 1.2 linux/usr/Makefile - 1.3 linux/fs/mbcache.c - 1.4 linux/fs/ext3/xattr.c - 1.5 linux/fs/ext2/xattr.c - 1.5 linux/mm/fremap.c - 1.4 linux/include/linux/hugetlb.h - 1.7 linux/drivers/net/mac8390.c - 1.5 linux/drivers/media/video/saa7134/saa7134.h - 1.4 linux/drivers/media/video/saa7134/saa7134-video.c - 1.4 linux/drivers/media/video/saa7134/saa7134-i2c.c - 1.5 linux/drivers/media/video/saa7134/saa7134-core.c - 1.3 linux/drivers/media/video/saa7134/saa7134-cards.c - 1.4 linux/include/asm-m68knommu/pci.h - 1.2 linux/include/asm-m68knommu/processor.h - 1.3 linux/arch/m68knommu/Kconfig - 1.7 linux/arch/m68knommu/Makefile - 1.4 linux/arch/m68knommu/kernel/comempci.c - 1.3 linux/arch/m68knommu/kernel/signal.c - 1.7 linux/arch/m68knommu/platform/5206/Makefile - 1.3 linux/arch/m68knommu/platform/5206/config.c - 1.2 linux/arch/m68knommu/platform/5206e/Makefile - 1.3 linux/arch/m68knommu/platform/5206e/config.c - 1.2 linux/arch/m68knommu/platform/5249/Makefile - 1.3 linux/arch/m68knommu/platform/5249/config.c - 1.2 linux/arch/m68knommu/platform/5272/Makefile - 1.3 linux/arch/m68knommu/platform/5272/config.c - 1.2 linux/arch/m68knommu/platform/5307/Makefile - 1.3 linux/arch/m68knommu/platform/5307/config.c - 1.2 linux/arch/m68knommu/platform/5407/Makefile - 1.3 linux/arch/m68knommu/platform/5407/config.c - 1.2 linux/arch/m68knommu/platform/68328/Makefile - 1.3 linux/arch/m68knommu/platform/68328/entry.S - 1.4 linux/arch/m68knommu/platform/68328/ints.c - 1.2 linux/arch/m68knommu/platform/68360/Makefile - 1.3 linux/arch/m68knommu/platform/68360/commproc.c - 1.3 linux/arch/m68knommu/platform/68360/entry.S - 1.4 linux/arch/m68knommu/platform/68360/ints.c - 1.3 linux/arch/m68knommu/platform/68EZ328/Makefile - 1.3 linux/arch/m68knommu/platform/68VZ328/Makefile - 1.3 linux/arch/m68knommu/platform/68VZ328/de2/config.c - 1.2 linux/arch/m68knommu/vmlinux.lds.S - 1.5 linux/arch/v850/kernel/rte_mb_a_pci.c - 1.4 linux/include/asm-v850/processor.h - 1.4 linux/arch/v850/kernel/irq.c - 1.6 linux/arch/v850/kernel/Makefile - 1.4 linux/arch/v850/Kconfig - 1.7 linux/arch/v850/Makefile - 1.5 linux/Documentation/kbuild/kconfig-language.txt - 1.2 linux/drivers/hotplug/cpci_hotplug_pci.c - 1.5 linux/drivers/serial/68328serial.c - 1.3 linux/drivers/serial/68328serial.h - 1.3 linux/drivers/serial/68360serial.c - 1.7 linux/drivers/serial/mcfserial.c - 1.4 linux/net/key/af_key.c - 1.7 linux/arch/ppc/syslib/open_pic.c - 1.3 linux/net/ipv4/esp.c - 1.5 linux/drivers/scsi/scsi_sysfs.c - 1.6 linux/scripts/per-cpu-check.awk - 1.4 linux/include/linux/compat.h - 1.4 linux/drivers/pnp/card.c - 1.6 linux/drivers/s390/char/sclp_con.c - 1.2 linux/drivers/s390/char/sclp_tty.c - 1.3 linux/drivers/s390/char/tape_block.c - 1.2 linux/Documentation/s390/driver-model.txt - 1.3 linux/Documentation/scsi/ChangeLog.ncr53c8xx - 1.2 linux/Documentation/scsi/ChangeLog.sym53c8xx - 1.3 linux/Documentation/scsi/ChangeLog.sym53c8xx_2 - 1.3 linux/Documentation/scsi/dpti.txt - 1.2 linux/Documentation/scsi/ibmmca.txt - 1.4 linux/Documentation/scsi/ncr53c8xx.txt - 1.2 linux/Documentation/scsi/sym53c8xx_2.txt - 1.2 linux/include/asm-sparc64/compat.h - 1.5 linux/drivers/usb/serial/kobil_sct.c - 1.4 linux/fs/compat.c - 1.3 linux/net/ipv4/xfrm_user.c - 1.4 linux/include/asm-ppc64/compat.h - 1.4 linux/drivers/ide/ide-io.c - 1.4 linux/fs/intermezzo/intermezzo_lib.h - 1.2 linux/arch/x86_64/kernel/suspend.c - 1.2 linux/Documentation/sound/alsa/ALSA-Configuration.txt - 1.3 linux/Documentation/uml/UserModeLinux-HOWTO.txt - 1.2 linux/include/asm-x86_64/compat.h - 1.5 linux/arch/um/kernel/tt/Makefile - 1.3 linux/drivers/i2c/busses/Kconfig - 1.3 linux/drivers/i2c/busses/Makefile - 1.2 linux/drivers/i2c/busses/i2c-amd756.c - 1.2 linux/drivers/i2c/busses/i2c-amd8111.c - 1.3 linux/include/asm-s390x/compat.h - 1.5 linux/arch/i386/kernel/sysenter.c - 1.5 linux/include/asm-ia64/intrinsics.h - 1.3 linux/Documentation/arm/Booting - 1.2 linux/drivers/scsi/zalon.h - 1.2 linux/drivers/scsi/zalon.c - 1.2 linux/net/ipv4/xfrm_algo.c - 1.2 linux/drivers/media/video/tda9887.c - 1.2 linux/include/asm-parisc/bug.h - 1.2 linux/include/asm-parisc/compat.h - 1.3 linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.5 linux/arch/m68knommu/kernel/entry.S - 1.2 linux/include/asm-i386/bug.h - 1.2 linux/include/linux/eisa.h - 1.3 linux/arch/alpha/kernel/core_marvel.c - 1.4 linux/arch/sparc64/kernel/us3_cpufreq.c - 1.3 linux/drivers/eisa/eisa-bus.c - 1.3 linux/Documentation/ia64/fsys.txt - 1.2 linux/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.3 linux/arch/i386/kernel/cpu/cpufreq/acpi.c - 1.3 linux/arch/ia64/kernel/fsys.S - 1.2 linux/arch/arm/common/sa1111.c - 1.4 linux/arch/i386/oprofile/op_model_p4.c - 1.2 linux/drivers/cpufreq/freq_table.c - 1.2 linux/scripts/modpost.c - 1.4 linux/scripts/Makefile.modpost - 1.3 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.3 linux/drivers/eisa/virtual_root.c - 1.2 linux/sound/oss/sb_card.h - 1.2 linux/kernel/posix-timers.c - 1.3 linux/drivers/pnp/manager.c - 1.2 linux/arch/alpha/oprofile/op_model_ev4.c - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/config.c - 1.2 linux/Documentation/arm/XScale/IOP3XX/dma.txt - 1.2 linux/Documentation/cpu-freq/core.txt - 1.2 linux/Documentation/cpu-freq/cpu-drivers.txt - 1.2 linux/Documentation/cpu-freq/governors.txt - 1.2 linux/Documentation/cpu-freq/user-guide.txt - 1.2 linux/drivers/char/watchdog/amd7xx_tco.c - 1.2 linux/drivers/cpufreq/userspace.c - 1.2 linux/scripts/genksyms/Makefile - 1.2 linux/net/ipv6/netfilter/ip6t_frag.c - 1.2 linux/fs/sysfs/bin.c - 1.2 linux/fs/sysfs/dir.c - 1.2 linux/net/ipv6/netfilter/ip6t_rt.c - 1.2 linux/net/ipv6/netfilter/ip6t_ipv6header.c - 1.2 linux/net/ipv6/netfilter/ip6t_hbh.c - 1.2 linux/drivers/video/cg14.c - 1.2 linux/drivers/video/bw2.c - 1.2 linux/net/ipv6/netfilter/ip6t_esp.c - 1.2 linux/drivers/video/cg3.c - 1.2 linux/drivers/video/cg6.c - 1.2 linux/net/ipv6/netfilter/ip6t_dst.c - 1.2 linux/drivers/video/ffb.c - 1.2 linux/drivers/video/p9100.c - 1.2 linux/net/ipv6/netfilter/ip6t_ah.c - 1.2 linux/drivers/video/sbuslib.c - 1.2 linux/drivers/video/sbuslib.h - 1.2 linux/arch/i386/kernel/srat.c - 1.2 linux/fs/sysfs/mount.c - 1.2 linux/drivers/video/tcx.c - 1.2 linux/init/do_mounts.h - 1.2 linux/init/do_mounts_rd.c - 1.2 linux/include/asm-i386/srat.h - 1.2 From owner-linux-xfs@oss.sgi.com Thu Mar 20 10:50:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 10:50:12 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KInJq9005107 for ; Thu, 20 Mar 2003 10:50:00 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KInDuY004851 for ; Thu, 20 Mar 2003 10:49:13 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA39353 for ; Thu, 20 Mar 2003 12:49:13 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KInBwX31450224 for ; Thu, 20 Mar 2003 12:49:12 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2L24Uj27120 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 21:04:30 -0500 Resent-Message-Id: <200303210204.h2L24Uj27120@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KImfwX30493708 for ; Thu, 20 Mar 2003 12:48:41 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2KIme4L24092669 for ; Thu, 20 Mar 2003 10:48:41 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h2KIjPxD022221 for ; Thu, 20 Mar 2003 19:45:25 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h2KIjPKe022220 for hch@sgi.com; Thu, 20 Mar 2003 19:45:25 +0100 Date: Thu, 20 Mar 2003 19:45:25 +0100 From: Christoph Hellwig Message-Id: <200303201845.h2KIjPKe022220@lab343.munich.sgi.com> Subject: TAKE - Fix DMAPI build To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 20 Mar 2003 21:04:30 -0500 Resent-To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 331 Lines: 12 Date: Thu Mar 20 10:47:48 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142218a linux/fs/xfs/dmapi/dmapi_xfs.c - 1.2 - bring back the 2.5 changes that got lost when moving the file around From owner-linux-xfs@oss.sgi.com Thu Mar 20 11:17:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 11:18:07 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KJHhq9002005 for ; Thu, 20 Mar 2003 11:17:47 -0800 Received: (qmail 30818 invoked from network); 20 Mar 2003 19:30:01 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 20 Mar 2003 19:30:01 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18w5Xi-0004hx-00; Thu, 20 Mar 2003 20:17:34 +0100 Date: Thu, 20 Mar 2003 20:17:34 +0100 To: Chris Wedgwood Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030320191734.GA18090@localhost> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320013454.GA6989@f00f.org> User-Agent: Mutt/1.5.3i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 554 Lines: 18 On Wed, Mar 19, 2003 at 05:34:54PM -0800, Chris Wedgwood wrote: > On Wed, Mar 19, 2003 at 07:16:50PM +0100, Michal Adamczak wrote: > > > unfortunately the way it works right now is unacceptable > > can you run oprofile and see where the time is baing taken please? i'm not very familiar with oprofile i know it is and can install it but could You please be more specific and tell what kinds of results You'd expect? -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Thu Mar 20 14:10:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 14:11:04 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KMADq9022690 for ; Thu, 20 Mar 2003 14:10:53 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KMA7uY019723 for ; Thu, 20 Mar 2003 14:10:07 -0800 Received: from zomba.sgi.com ([198.149.18.14]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA01432 for ; Thu, 20 Mar 2003 16:10:06 -0600 (CST) Received: from zomba.sgi.com (localhost.sgi.com [127.0.0.1]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-sendmail_sa_mtv-1.0) with ESMTP id h2KM9tjc047361 for ; Thu, 20 Mar 2003 16:10:09 -0600 (CST) X-Possible-Spam: the addition of this header was triggered by: localhost.localdomain.failing.dns.checks:helo Received: from localhost.localdomain (eagdhcp-233-140.americas.sgi.com [128.162.233.140]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-nospam-3.1) with ESMTP id h2KM8BVx047156 for ; Thu, 20 Mar 2003 16:08:11 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h2KCpl7X001393 for ; Thu, 20 Mar 2003 06:51:47 -0600 Received: (from lord@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h2KCpkE1001391; Thu, 20 Mar 2003 06:51:46 -0600 X-Authentication-Warning: localhost.localdomain: lord set sender to lord@sgi.com using -f Subject: [Fwd: Re: optimizing raid performance with xfs] From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Mar 2003 06:51:46 -0600 Message-Id: <1048164706.1204.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1873 Lines: 52 Forwarding this, as it contains some info useful for other folks. Steve -----Forwarded Message----- From: Steve Lord To: Andy Arvai Subject: Re: optimizing raid performance with xfs Date: 19 Mar 2003 20:54:32 -0600 On Wed, 2003-03-19 at 20:42, Andy Arvai wrote: > Hi, > > Thanks for the information. I looked at the man page for mkfs.xfs and > there is no "-f" option. Is this something I need? -f is needed to overwrite an existing filesystem on a disk. > > Also, according to the man page > > If an inode size is specified, or if a filesystem is > sufficiently large, mkfs.xfs will warn if this will create inode > numbers > 32 significant bits. > > What are the ramifications if I get a warning that inode numbers > are > 32 bits? Will this cause a problem as the disk gets full? An xfs inode number is an encoding of a disk address. The larger the filesystem, the larger the inode numbers can potentially be. With the default inode size of 256 bytes, it is possible for the inode numbers to overflow 32 bits at 1 Tbyte. This is a problem for linux where only 32 bits of inode space is available in system calls and in the vfs layer. XFS has an option to restrict inode placement to parts of the disk which will avoid overflowing 32 bits, this is on by default on linux. This policy can affect layout and performance. To avoid xfs operating in this mode, specifying inodes as being 512 bytes in size defers this policy switch over to a 2 Tbyte filesystem. XFS inodes contain a fixed component and a variable component, extent information can be held in the variable component, as can directory entries of small directories. This is one reason xfs supports different sizes of inodes. So there is no danger of overflowing 32 bits of inode space on xfs, but using this mkfs option may give better performance. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 20 14:17:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 14:18:00 -0800 (PST) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KMHmq9023178 for ; Thu, 20 Mar 2003 14:17:49 -0800 Received: from fwd03.sul.t-online.de by mailout10.sul.t-online.com with smtp id 18w8M4-0001Se-0B; Thu, 20 Mar 2003 23:17:44 +0100 Received: from puariko.homeip.net (520039812576-0001@[217.231.212.92]) by fmrl03.sul.t-online.com with esmtp id 18w8Lu-0RrREeC; Thu, 20 Mar 2003 23:17:34 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.8/8.12.5/Submit) id h2KMHKar002065; Thu, 20 Mar 2003 23:17:20 +0100 Date: Thu, 20 Mar 2003 23:17:20 +0100 From: Axel Thimm To: linux-xfs Cc: Simon Matter , Seth Mos Subject: Re: Updated RedHat errata kernel with XFS 1.2 Message-ID: <20030320221720.GD25879@puariko.nirvana> References: <3E77289F.960BF744@ch.sauter-bc.com> <20030318231811.P52057-100000@xs1.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20030318231811.P52057-100000@xs1.xs4all.nl> User-Agent: Mutt/1.4.1i X-Sender: 520039812576-0001@t-dialin.net X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1452 Lines: 47 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2003 at 11:20:52PM +0100, Seth Mos wrote: > On Tue, 18 Mar 2003, Simon Matter wrote: > > I have created XFS enabled versions of todays RedHat errata kernel. [..= .] > Ah, I just created a similar source rpm as well, [...] "me too" for Red Hat 8.0. I also have (re)built the userland xfs rpms, with= some fixes in the dependencies and further minor changes. You can keep your XFS = system now uptodate with apt-get ;) http://atrpms.physik.fu-berlin.de/topic/xfs/ Note: The kernel includes more than the XFS patches: * base kernel sources: Taken from current redhat errata (2.4.18-27.8.0) * XFS: merged patches found in 1.2 * i2c-2.7.0 and lm_sensors-2.7.0. You should also get the updated userl= and tools. * 3ware 1.02.00.027 kernel driver for Escalade 7xxx series. Try to keep= in sync with your firmware and userland tools. * v4l2-api (backported from http://bytesex.org/patches/2.4/11-v4l2-api-2.4.20-pre11.diff.gz) --=20 Axel.Thimm@physik.fu-berlin.de --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ej3wQBVS1GOamfERAiYqAJ41ayLzUdyZsUYkqQ6V0y3FrCy2PgCfdOXP XRtOM/glacr0TrdJb0oQcEI= =z6Qp -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-linux-xfs@oss.sgi.com Thu Mar 20 15:15:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 15:15:45 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KNFaq9025170 for ; Thu, 20 Mar 2003 15:15:36 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id A815F183EEE4; Thu, 20 Mar 2003 15:15:35 -0800 (PST) Date: Thu, 20 Mar 2003 15:15:35 -0800 From: Chris Wedgwood To: Michal Adamczak Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030320231535.GA16975@f00f.org> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> <20030320191734.GA18090@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320191734.GA18090@localhost> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 423 Lines: 15 On Thu, Mar 20, 2003 at 08:17:34PM +0100, Michal Adamczak wrote: > i'm not very familiar with oprofile please check http://oprofile.sourceforge.net/docs/ for a quick quide; how to poke it depends on your CPU and a few other things > i know it is and can install it but could You please be more > specific and tell what kinds of results You'd expect? i'd like to see *where* all the CPU time is being consumed --cw From owner-linux-xfs@oss.sgi.com Thu Mar 20 16:09:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 16:09:25 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L08Vq9001671 for ; Thu, 20 Mar 2003 16:09:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2L0Jokq020071 for ; Thu, 20 Mar 2003 18:19:51 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2L0777L2586813 for ; Fri, 21 Mar 2003 11:07:07 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2L076tU2577579 for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 11:07:06 +1100 (EST) Date: Fri, 21 Mar 2003 11:07:06 +1100 (EST) From: Nathan Scott Message-Id: <200303210007.h2L076tU2577579@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs man page X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 293 Lines: 13 Document the -f option to mkfs.xfs. Date: Thu Mar 20 16:06:49 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:142274a cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.15 From owner-linux-xfs@oss.sgi.com Thu Mar 20 16:26:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 16:27:01 -0800 (PST) Received: from hotmail.com (bay1-f58.bay1.hotmail.com [65.54.245.58]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L0Qwq9002548 for ; Thu, 20 Mar 2003 16:26:59 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Mar 2003 16:26:52 -0800 Received: from 66.167.1.42 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 21 Mar 2003 00:26:51 GMT X-Originating-IP: [66.167.1.42] X-Originating-Email: [mwhang77@hotmail.com] From: "Michael Whang" To: linux-xfs@oss.sgi.com Subject: ultra 320 and XFS Date: Thu, 20 Mar 2003 16:26:51 -0800 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Mar 2003 00:26:52.0385 (UTC) FILETIME=[91DBED10:01C2EF40] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mwhang77@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 770 Lines: 5
Hi,

Im trying to install Redhat 8.0 wih XFS on a workstation but my SCSI drive fails to show up on the list of hard drives to install onto.  I have a super micro motherboard with the E7505 chipset (dual xeon 2.4 GHZ).  It has an onboard AIC7902 Ultra 320 SCSI card.  When I boot off the XFS disk, i type in "linux dd" to install the SCSI drivers for Redhat 8.0 and it seems to go fine, but when the partitioning section of the install comes up, I dont see the hard drive.  Has anyone experienced this before?
 
Michael Whang

Help STOP SPAM with the new MSN 8 and get 2 months FREE* From owner-linux-xfs@oss.sgi.com Thu Mar 20 18:52:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 18:52:16 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L2pPq9004902 for ; Thu, 20 Mar 2003 18:52:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2L2pKnH022527 for ; Thu, 20 Mar 2003 18:51:20 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA73881 for ; Thu, 20 Mar 2003 20:51:20 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2L2pKwX32258221 for ; Thu, 20 Mar 2003 20:51:20 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2L2pJ100630; Thu, 20 Mar 2003 20:51:19 -0600 Message-Id: <200303210251.h2L2pJ100630@jen.americas.sgi.com> Date: Thu, 20 Mar 2003 20:51:19 -0600 Subject: TAKE - fix mtime updates in the 2.5 kernel To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 637 Lines: 23 optimize timestamp updates, use new hires timestamps more directly, also fix a bug where the mtime field was not correctly updated. Date: Thu Mar 20 18:50:03 PST 2003 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:142296a linux/fs/xfs/xfs_inode.c - 1.366 - cleanup xfs_ichgtime, fix assignment of mtime linux/fs/xfs/linux/xfs_vnode.c - 1.112 - use direct assignment between timeval structures, reduce cost of the getattr call. linux/fs/xfs/support/time.h - 1.12 - use CURRENT_TIME to implement nanotime From owner-linux-xfs@oss.sgi.com Thu Mar 20 19:22:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 19:22:08 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2L3M3q9005799 for ; Thu, 20 Mar 2003 19:22:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2L3M2la005797 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 19:22:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2L3M0qB005784 for ; Thu, 20 Mar 2003 19:22:00 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2L2ssCV005105; Thu, 20 Mar 2003 18:54:54 -0800 Date: Thu, 20 Mar 2003 18:54:54 -0800 Message-Id: <200303210254.h2L2ssCV005105@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 231] XFS does not update directory mtime when changes made in directory X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 724 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=231 lord@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lord@sgi.com 2003-03-20 18:54 ------- Code is in the xfs 2.5 cvs tree, and should make it to Linus in the near future. A typo crept in when the nanosecond resolution timer was added. The mtime seconds field was not being updated in the linux inode. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 20 19:41:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 19:41:40 -0800 (PST) Received: from main.kldp.org ([211.39.143.147]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L3erq9006280 for ; Thu, 20 Mar 2003 19:41:34 -0800 Received: from kss by main.kldp.org with local (Exim 3.12 #1 (Debian)) id 18wDOh-0007Tn-00; Fri, 21 Mar 2003 12:40:47 +0900 Date: Fri, 21 Mar 2003 12:40:47 +0900 From: Soon-Son Kwon To: linux-xfs@oss.sgi.com Subject: low level access path for xfs operation Message-ID: <20030321124047.A26767@mail.kldp.org> Reply-To: kss@kldp.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Debian GNU/Linux Organization: KLDP(Korean Linux Documentation Project) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kss@kldp.org Precedence: bulk X-list: linux-xfs Content-Length: 902 Lines: 29 Hi xfs folks: Could anyone please let me know the following xfs internal operation details? I would like to know if there is any operation that bypasses submit_bio() when accessing the lower level block devices. I want to add some function whenever the filesystem tries to modify any block and concluded that submit_bio() seems to be the lowest entry point for such operations. But I later found that I did not consider the direct i/o or raw i/o operations that seems to have shorter path for lower devices by eliminating the copy operations. I suspect those direct i/o or raw i/o operations do not use submit_bio(). If there is any mistake or missing point, please let me know. Thanks very much. -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (o_ **WTFM** (o_ (o_ //\ (/)_ (/)_ V_/_ http://kldp.org -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-linux-xfs@oss.sgi.com Thu Mar 20 21:05:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 21:06:04 -0800 (PST) Received: from out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L55Wq9015454 for ; Thu, 20 Mar 2003 21:05:54 -0800 Received: from kanhome ([141.154.58.208]) by out004.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030321050526.RNQE7930.out004.verizon.net@kanhome> for ; Thu, 20 Mar 2003 23:05:26 -0600 Date: Fri, 21 Mar 2003 00:05:25 -0500 From: Alexander Kabaev To: linux-xfs@oss.sgi.com Subject: CVSUP server is down on ftp.thebarn.com Message-Id: <20030321000525.2639f00b.kabaev@bellatlantic.net> Reply-To: ak03@gte.com X-Mailer: Sylpheed version 0.8.10claws18 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [141.154.58.208] at Thu, 20 Mar 2003 23:05:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kabaev@bellatlantic.net Precedence: bulk X-list: linux-xfs Content-Length: 52 Lines: 5 Could someone please fix it? -- Alexander Kabaev From owner-linux-xfs@oss.sgi.com Thu Mar 20 22:35:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 22:35:09 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L6Yxq9017139 for ; Thu, 20 Mar 2003 22:35:00 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 0DAB3AC35; Fri, 21 Mar 2003 07:48:04 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id AE1F8190D1; Fri, 21 Mar 2003 07:48:05 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 7ADBF30881D; Fri, 21 Mar 2003 07:34:56 +0100 (CET) Message-ID: <3E7AB28F.B41482DA@ch.sauter-bc.com> Date: Fri, 21 Mar 2003 07:34:55 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Michael Whang Cc: linux-xfs@oss.sgi.com Subject: Re: ultra 320 and XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 896 Lines: 26 Michael Whang schrieb: > > Hi, > > Im trying to install Redhat 8.0 wih XFS on a workstation but my SCSI > drive fails to show up on the list of hard drives to install onto. I > have a super micro motherboard with the E7505 chipset (dual xeon 2.4 > GHZ). It has an onboard AIC7902 Ultra 320 SCSI card. When I boot off > the XFS disk, i type in "linux dd" to install the SCSI drivers for Do you need "linux dd"? AFAIK as long as you only use kernel modules from the RedHat distribution, you don't have to use a driver disk (dd) at all. Did you try without dd? HTH Simon > Redhat 8.0 and it seems to go fine, but when the partitioning section > of the install comes up, I dont see the hard drive. Has anyone > experienced this before? > > Michael Whang > > ---------------------------------------------------------------------- > Help STOP SPAM with the new MSN 8 and get 2 months FREE* From owner-linux-xfs@oss.sgi.com Fri Mar 21 01:15:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 01:15:21 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L9EQq9022433 for ; Fri, 21 Mar 2003 01:15:07 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18wIbX-0007XY-00; Fri, 21 Mar 2003 09:14:23 +0000 Date: Fri, 21 Mar 2003 09:14:23 +0000 From: Christoph Hellwig To: Soon-Son Kwon Cc: linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030321091423.A28976@infradead.org> References: <20030321124047.A26767@mail.kldp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030321124047.A26767@mail.kldp.org>; from kss@kldp.org on Fri, Mar 21, 2003 at 12:40:47PM +0900 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 589 Lines: 18 On Fri, Mar 21, 2003 at 12:40:47PM +0900, Soon-Son Kwon wrote: > Hi xfs folks: > Could anyone please let me know the following > xfs internal operation details? > > I would like to know if there is any operation > that bypasses submit_bio() when accessing the > lower level block devices. No, there is no such operation. > I want to add some function whenever the filesystem > tries to modify any block and concluded that submit_bio() > seems to be the lowest entry point for such operations. You might want to rewrite a block remapper like dm or md instead of modifying core core.. From owner-linux-xfs@oss.sgi.com Fri Mar 21 02:58:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 02:58:18 -0800 (PST) Received: from main.kldp.org ([211.39.143.147]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LAvNq9032193 for ; Fri, 21 Mar 2003 02:58:05 -0800 Received: from kss by main.kldp.org with local (Exim 3.12 #1 (Debian)) id 18wK09-0003Vw-00; Fri, 21 Mar 2003 19:43:53 +0900 Date: Fri, 21 Mar 2003 19:43:53 +0900 From: Soon-Son Kwon To: Christoph Hellwig Cc: Soon-Son Kwon , linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030321194353.A12729@mail.kldp.org> Reply-To: kss@kldp.org References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030321091423.A28976@infradead.org>; from hch@infradead.org on Fri, Mar 21, 2003 at 09:14:23AM +0000 X-Operating-System: Debian GNU/Linux Organization: KLDP(Korean Linux Documentation Project) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kss@kldp.org Precedence: bulk X-list: linux-xfs Content-Length: 1561 Lines: 41 On Fri, Mar 21, 2003 at 09:14:23AM +0000, Christoph Hellwig wrote: > On Fri, Mar 21, 2003 at 12:40:47PM +0900, Soon-Son Kwon wrote: > > Hi xfs folks: > > Could anyone please let me know the following > > xfs internal operation details? > > > > I would like to know if there is any operation > > that bypasses submit_bio() when accessing the > > lower level block devices. > > No, there is no such operation. > > > I want to add some function whenever the filesystem > > tries to modify any block and concluded that submit_bio() > > seems to be the lowest entry point for such operations. > > You might want to rewrite a block remapper like dm or md > instead of modifying core core.. What I would like to implement is the snapshot functionality within the filesystem. I know LVM supports snapshot but it requires a separate volume for each snapshot. I thought snapshot within the filesystem would be more convenient. Snapshot functionality requires copy-on-write implementation when something tries to modify any block, copy the old content to new block and overwrite the new content to that block while the snapshot image keeps track of the original content. Anyway, do you think implementing that operation requires modifying dm/md code instead of modifying submit_bio()? Any comment is welcomed and thank you very much for answering my question..... -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (o_ **WTFM** (o_ (o_ //\ (/)_ (/)_ V_/_ http://kldp.org -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-linux-xfs@oss.sgi.com Fri Mar 21 07:26:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 07:27:05 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LFQGq9020291 for ; Fri, 21 Mar 2003 07:26:57 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Mar 2003 10:26:10 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0921A5@THOR.goeci.com> From: Murthy Kambhampaty To: "'Simon Matter'" , Michael Whang Cc: linux-xfs@oss.sgi.com Subject: RE: ultra 320 and XFS Date: Fri, 21 Mar 2003 10:26:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 1947 Lines: 56 I had this problem with the 3ware card way back when. You can look for Bryan Smith's message re XFS (1.02?) on the 3ware card. Basically, you are going to have to: 1. Install with vanilla RedHat distro (not XFS Installer) 2. On your vanilla RedHat system, recompile the kernel with XFS and aic79xx support 3. Reboot to the new kernel; drop to single user; move partitions around; fix lilo 4. Reboot to you target system. Instead of mastering this ballet, I found it much simpler to put the system on a controller that the XFS distro (stock kernel drivers) supports and only put data on the "exotic" controller (I have an XFS database volume running on an Adaptec 39320, in fact; aic79xx v. 1.1.0 drivers; the system volume on the machine with the 3ware card is still on a single SCSI disk, though that should change "any day now"). Cheers, Murthy -----Original Message----- From: Simon Matter [mailto:simon.matter@ch.sauter-bc.com] Sent: Friday, March 21, 2003 01:35 To: Michael Whang Cc: linux-xfs@oss.sgi.com Subject: Re: ultra 320 and XFS Michael Whang schrieb: > > Hi, > > Im trying to install Redhat 8.0 wih XFS on a workstation but my SCSI > drive fails to show up on the list of hard drives to install onto. I > have a super micro motherboard with the E7505 chipset (dual xeon 2.4 > GHZ). It has an onboard AIC7902 Ultra 320 SCSI card. When I boot off > the XFS disk, i type in "linux dd" to install the SCSI drivers for Do you need "linux dd"? AFAIK as long as you only use kernel modules from the RedHat distribution, you don't have to use a driver disk (dd) at all. Did you try without dd? HTH Simon > Redhat 8.0 and it seems to go fine, but when the partitioning section > of the install comes up, I dont see the hard drive. Has anyone > experienced this before? > > Michael Whang > > ---------------------------------------------------------------------- > Help STOP SPAM with the new MSN 8 and get 2 months FREE* From owner-linux-xfs@oss.sgi.com Fri Mar 21 08:28:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 08:28:24 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LGSFq9023475 for ; Fri, 21 Mar 2003 08:28:16 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HC300A1BXR242@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 10:28:14 -0600 (CST) Date: Fri, 21 Mar 2003 10:28:14 -0600 From: Dan Yocum Subject: KDB-ized RH 2.4.18-X kernel? To: xfs-list Message-id: <3E7B3D9E.3090805@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 17 Hi all, I've got a couple machines that like to freeze up for no apparent reason. Does anyone have a kdb-ized RH 2.4.18-X kernel they'd be willing to share? I spent all day yesterday trying to apply different kdb patches to 2.4.18-18 and 2.4.18-26 with no success, and I'm not keen on going to a custom kernel. Thanks, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Fri Mar 21 08:38:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 08:38:16 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LGbRq9023964 for ; Fri, 21 Mar 2003 08:38:07 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h2LGbQR04272; Fri, 21 Mar 2003 11:37:26 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 21 Mar 2003 11:37:26 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Dan Yocum cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-Reply-To: <3E7B3D9E.3090805@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 629 Lines: 17 On Fri, 21 Mar 2003 at 10:28am, Dan Yocum wrote > I've got a couple machines that like to freeze up for no apparent reason. > Does anyone have a kdb-ized RH 2.4.18-X kernel they'd be willing to share? > > I spent all day yesterday trying to apply different kdb patches to 2.4.18-18 > and 2.4.18-26 with no success, and I'm not keen on going to a custom kernel. It looks to me like the RH based kernel from the 1.2 release has kdb in the source but not compiled. Grab the SRPM, install it, tweak the appropriate config files, and rpmbuild it. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Mar 21 09:16:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 09:16:14 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LHG5q9028403 for ; Fri, 21 Mar 2003 09:16:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2LHRSkq003010 for ; Fri, 21 Mar 2003 11:27:28 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA32413 for ; Fri, 21 Mar 2003 11:15:59 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2LHFxwX32422401 for ; Fri, 21 Mar 2003 11:15:59 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2LHFOb32727; Fri, 21 Mar 2003 11:15:24 -0600 Message-Id: <200303211715.h2LHFOb32727@stout.americas.sgi.com> Date: Fri, 21 Mar 2003 11:15:24 -0600 Subject: TAKE - Document -l logdev and -r rtdev mkfs.xfs options X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 307 Lines: 12 Document -l logdev and -r rtdev mkfs.xfs options Date: Fri Mar 21 09:15:37 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:142333a xfsprogs/man/man8/mkfs.xfs.8 - 1.16 From owner-linux-xfs@oss.sgi.com Fri Mar 21 12:41:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 12:41:35 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LKerq9032155 for ; Fri, 21 Mar 2003 12:41:33 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AFE3A18469D2; Fri, 21 Mar 2003 12:40:52 -0800 (PST) Date: Fri, 21 Mar 2003 12:40:52 -0800 From: Chris Wedgwood To: Soon-Son Kwon Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030321204052.GB27409@f00f.org> References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> <20030321194353.A12729@mail.kldp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030321194353.A12729@mail.kldp.org> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1141 Lines: 30 On Fri, Mar 21, 2003 at 07:43:53PM +0900, Soon-Son Kwon wrote: > What I would like to implement is the snapshot functionality within > the filesystem. I know LVM supports snapshot but it requires a > separate volume for each snapshot. I thought snapshot within the > filesystem would be more convenient. How should this work from a user perspective? > Snapshot functionality requires copy-on-write implementation when > something tries to modify any block, copy the old content to new > block and overwrite the new content to that block while the snapshot > image keeps track of the original content. You need to be sure whatever mechanism you use to keep track of block placements is efficient and the granularity are sane or else the metadata to keep track of this can be enormous. > Anyway, do you think implementing that operation requires modifying > dm/md code instead of modifying submit_bio()? No... I don't see why it should --- ideally you want a pseudo-block device or similar to place the fs on; this will then be able to track changes and such like. Check the device-mapper and LVM as they effectively do this. --cw From owner-linux-xfs@oss.sgi.com Fri Mar 21 12:38:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 12:38:28 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LKbbq9031937 for ; Fri, 21 Mar 2003 12:38:17 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id CEC3318469D2; Fri, 21 Mar 2003 12:37:36 -0800 (PST) Date: Fri, 21 Mar 2003 12:37:36 -0800 From: Chris Wedgwood To: Murthy Kambhampaty Cc: "'Simon Matter'" , Michael Whang , linux-xfs@oss.sgi.com Subject: Re: ultra 320 and XFS Message-ID: <20030321203736.GA27409@f00f.org> References: <2D92FEBFD3BE1346A6C397223A8DD3FC0921A5@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC0921A5@THOR.goeci.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1290 Lines: 36 On Fri, Mar 21, 2003 at 10:26:10AM -0500, Murthy Kambhampaty wrote: Warning: Non Super-Difficult-Red-Hat-Solution-Ahead :) > 1. Install with vanilla RedHat distro (not XFS Installer) > 2. On your vanilla RedHat system, recompile the kernel with XFS and > aic79xx support > 3. Reboot to the new kernel; drop to single user; move partitions > around; fix lilo > 4. Reboot to you target system. or build a non-modular kernel with all the right magic bits in it (super easy) and put this on a floppy (cp), use rdev to make the floppy strap suitably using a ramdisk, usually "rdev -r /dev/fd0 49152 ; rdev /dev/fd0 /dev/fd0" suffices boot this disk --- it will prompt for a second disk, at this point give it a Debian rootfs image on a floppy and follow the prompts... sorry i can't tell you how to do this with Red Hat, I tried to find out last night how this was done and everyone tells me it can't be, so, if someone does know of a Red Hat solution then perhaps post it here and maybe I'll compile a list of 'more difficult' XFS installation methods or something the other suggestion i have is since most network cards can PXE boot, then PXE boot a kernel which mounts / via nfs --- again, I know how to do this with Debian but not Red Hat[1] --cw [1] bug me if interested From owner-linux-xfs@oss.sgi.com Fri Mar 21 14:00:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 14:00:54 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LM0iq9001892 for ; Fri, 21 Mar 2003 14:00:45 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HC400FDZD58LP@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 16:00:44 -0600 (CST) Date: Fri, 21 Mar 2003 16:00:44 -0600 From: Dan Yocum Subject: Re: KDB-ized RH 2.4.18-X kernel? To: Joshua Baker-LePain Cc: xfs-list Message-id: <3E7B8B8C.9020808@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 References: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 884 Lines: 29 Sorry, I jumped ahead in my error reporting - I tried re-compiling the RH kernel source with kdb enabled. No go. Horrible death. Die, die, die. :-( Joshua Baker-LePain wrote: > On Fri, 21 Mar 2003 at 10:28am, Dan Yocum wrote > > >>I've got a couple machines that like to freeze up for no apparent reason. >>Does anyone have a kdb-ized RH 2.4.18-X kernel they'd be willing to share? >> >>I spent all day yesterday trying to apply different kdb patches to 2.4.18-18 >>and 2.4.18-26 with no success, and I'm not keen on going to a custom kernel. > > > It looks to me like the RH based kernel from the 1.2 release has kdb in > the source but not compiled. Grab the SRPM, install it, tweak the > appropriate config files, and rpmbuild it. > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Fri Mar 21 14:12:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 14:12:08 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LMBLq9002395 for ; Fri, 21 Mar 2003 14:12:02 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h2LMBK105163; Fri, 21 Mar 2003 17:11:20 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 21 Mar 2003 17:11:20 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Dan Yocum cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-Reply-To: <3E7B8B8C.9020808@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 502 Lines: 15 On Fri, 21 Mar 2003 at 4:00pm, Dan Yocum wrote > Sorry, I jumped ahead in my error reporting - I tried re-compiling the RH > kernel source with kdb enabled. No go. Horrible death. Die, die, die. Did you compile the source in /usr/src/linux-2.4 as installed by the kernel-source*rpm, or did you compile from the SRPM? ISTR that the first method can be broken sometimes, but I've had had good luck with the second. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Mar 21 15:23:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 15:23:56 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LNNDq9005034 for ; Fri, 21 Mar 2003 15:23:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2LNN8nH027776 for ; Fri, 21 Mar 2003 15:23:08 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA62358 for ; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2LNN72r925946 for ; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h2LNN7oG7896022 for ; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2LNN7ZV7888357 for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Date: Fri, 21 Mar 2003 17:23:07 -0600 (CST) From: Dean Roehrich Message-Id: <200303212323.h2LNN7ZV7888357@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix initialization of dmapi code X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 13 Date: Fri Mar 21 15:22:47 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142389a linux/fs/xfs/linux/xfs_super.h - 1.41 - Call dmapi_init/dmapi_uninit instead of xfs_dm_init/xfs_dm_exit From owner-linux-xfs@oss.sgi.com Fri Mar 21 15:29:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 15:29:38 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LNTZq9005524 for ; Fri, 21 Mar 2003 15:29:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2LNTUnH028218 for ; Fri, 21 Mar 2003 15:29:30 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA67561 for ; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2LNTT2r924043 for ; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h2LNTToG7910748 for ; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2LNTT2d7883723 for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Date: Fri, 21 Mar 2003 17:29:29 -0600 (CST) From: Dean Roehrich Message-Id: <200303212329.h2LNTT2d7883723@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add "dmi" mount option for dmapi--for people and code migrating from Irix. X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 292 Lines: 13 Date: Fri Mar 21 15:29:14 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142391a linux/fs/xfs/dmapi/dmapi_xfs.c - 1.3 - Add "dmi" mount option. From owner-linux-xfs@oss.sgi.com Fri Mar 21 17:14:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 17:14:44 -0800 (PST) Received: from main.kldp.org ([211.39.143.147]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2M1EUq9009916 for ; Fri, 21 Mar 2003 17:14:32 -0800 Received: from kss by main.kldp.org with local (Exim 3.12 #1 (Debian)) id 18wXad-0000CZ-00; Sat, 22 Mar 2003 10:14:27 +0900 Date: Sat, 22 Mar 2003 10:14:27 +0900 From: Soon-Son Kwon To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030322101427.A32751@mail.kldp.org> Reply-To: kss@kldp.org References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> <20030321194353.A12729@mail.kldp.org> <20030321204052.GB27409@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030321204052.GB27409@f00f.org>; from cw@f00f.org on Fri, Mar 21, 2003 at 12:40:52PM -0800 X-Operating-System: Debian GNU/Linux Organization: KLDP(Korean Linux Documentation Project) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kss@kldp.org Precedence: bulk X-list: linux-xfs Content-Length: 2936 Lines: 69 On Fri, Mar 21, 2003 at 12:40:52PM -0800, Chris Wedgwood wrote: > On Fri, Mar 21, 2003 at 07:43:53PM +0900, Soon-Son Kwon wrote: > > > What I would like to implement is the snapshot functionality within > > the filesystem. I know LVM supports snapshot but it requires a > > separate volume for each snapshot. I thought snapshot within the > > filesystem would be more convenient. > > How should this work from a user perspective? If a snapshot can be generated/maintained within the filesystem, the user do not have to care for the overall disk layout as long as there are some free spaces in the filesystem while LVM requires additional volume which means even if there are a lot of of free blocks on the source filesystem, the user should allocate another volume for the snapshot. This can be a problem if the system administrator had allocated all the blocks to some volumes already because he/she cannot generate volume for snapshot any more. And the snapshot does not affect anything to normal users. What snapshot can provide to the users are he/she can revert the filesystem to the state when the snapshot was taken which means the user can get an older version of file or deleted files. > > Snapshot functionality requires copy-on-write implementation when > > something tries to modify any block, copy the old content to new > > block and overwrite the new content to that block while the snapshot > > image keeps track of the original content. > > You need to be sure whatever mechanism you use to keep track of block > placements is efficient and the granularity are sane or else the > metadata to keep track of this can be enormous. > > > Anyway, do you think implementing that operation requires modifying > > dm/md code instead of modifying submit_bio()? > > No... I don't see why it should --- ideally you want a pseudo-block > device or similar to place the fs on; this will then be able to track > changes and such like. > > Check the device-mapper and LVM as they effectively do this. So, you mean the following design as follows? (VFS)-(XFS)-(pseudo-block device)-(md)-(dm) I just thought if I can be notified any write/modify operation for a block, then I can copy and allocate the old block to a new location and record that information to the snapshot file, then the original block contents can be (over)written. (of course when generating a snapshot information, it should store every information on which block was in use/free at that time the snapshot was taken as a form of something like block map.) But anyway I am not an expert on this field. Could you please give a little more detailed explanation of the "pseudo block device" or any comment on my descriptions above? Thank you very much... -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (o_ **WTFM** (o_ (o_ //\ (/)_ (/)_ V_/_ http://kldp.org -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-linux-xfs@oss.sgi.com Fri Mar 21 20:55:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 20:56:03 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2M4tDq9013271 for ; Fri, 21 Mar 2003 20:55:53 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.8/8.12.6) with ESMTP id h2M4tBxk017049; Fri, 21 Mar 2003 22:55:11 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: CVSUP server is down on ftp.thebarn.com From: Russell Cattelan To: ak03@gte.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030321000525.2639f00b.kabaev@bellatlantic.net> References: <20030321000525.2639f00b.kabaev@bellatlantic.net> Content-Type: text/plain Organization: Message-Id: <1048308910.49263.7.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Mar 2003 22:55:11 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 288 Lines: 12 On Thu, 2003-03-20 at 23:05, Alexander Kabaev wrote: > Could someone please fix it? Machine couldn't handle the flood of backlogged email after the power outage. Seems SpamAssassin can be a bit of memory hog. Everything should be up again. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Sat Mar 22 05:59:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Mar 2003 06:00:02 -0800 (PST) Received: from azrael.blades.cxm (ua57d13hel.dial.kolumbus.fi [62.248.140.57]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2MDx9q9024218 for ; Sat, 22 Mar 2003 05:59:51 -0800 Received: (from blades@localhost) by azrael.blades.cxm (SGI-8.9.3/8.9.3) id PAA15439 for linux-xfs@oss.sgi.com; Sat, 22 Mar 2003 15:59:08 +0200 (EET) X-Authentication-Warning: azrael.blades.cxm: blades set sender to harri.haataja@kolumbus.fi using -f Date: Sat, 22 Mar 2003 15:59:07 +0200 From: Harri Haataja Cc: linux-xfs@oss.sgi.com Subject: Re: CVSUP server is down on ftp.thebarn.com Message-ID: <20030322155907.A15416@azrael.blades.cxm> References: <20030321000525.2639f00b.kabaev@bellatlantic.net> <1048308910.49263.7.camel@lupo.thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1048308910.49263.7.camel@lupo.thebarn.com>; from cattelan@thebarn.com on Fri, Mar 21, 2003 at 10:55:11PM -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: harri.haataja@kolumbus.fi Precedence: bulk X-list: linux-xfs Content-Length: 596 Lines: 18 On Fri, Mar 21, 2003 at 10:55:11PM -0600, Russell Cattelan wrote: > On Thu, 2003-03-20 at 23:05, Alexander Kabaev wrote: > > Could someone please fix it? > Machine couldn't handle the flood of backlogged email after the power > outage. > Seems SpamAssassin can be a bit of memory hog. > > Everything should be up again. Is it using the client/server setup? (Wasn't that in SA or am I thinking of something else?) Not sure if that cuts down on memory use, but it might if it prevents too many copies being run at once. -- The only person getting his work done by Friday was Robinson Crusoe. From owner-linux-xfs@oss.sgi.com Sun Mar 23 09:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Mar 2003 09:58:27 -0800 (PST) Received: from duckman.blub.net (postfix@cust.90.10.adsl.cistron.nl [195.64.90.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2NHvZq9021350 for ; Sun, 23 Mar 2003 09:58:16 -0800 Received: from sahara.openoffice.nl (node1ec29.a2000.nl [24.132.236.41]) by duckman.blub.net (Postfix) with ESMTP id 1A69E3FAE0 for ; Sun, 23 Mar 2003 18:57:34 +0100 (CET) Received: by sahara.openoffice.nl (Postfix, from userid 1001) id A32163E24; Sun, 23 Mar 2003 18:57:33 +0100 (CET) Date: Sun, 23 Mar 2003 18:57:33 +0100 From: Valentijn Sessink To: linux-xfs@oss.sgi.com Subject: error 990 out of the blue? Message-ID: <20030323175733.GA32375@openoffice.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Message-Flag: Open Office - Linux for the desktop X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: valentyn+xfs@nospam.openoffice.nl Precedence: bulk X-list: linux-xfs Content-Length: 1348 Lines: 37 Hello List, Just a short notice, as I don't have any extra info on this. One of my machines showed an "error 990" just out of the blue, 3 days ago. I couldn't find anything - there was a loose inode and that was it. What puzzles me is that this machine has a load of almost 0; the file with problems was /usr/share/mysql/portuguese/errmsg.sys - which is not in use in any way. xfs_check said: disconnected inode 410362, nlink 1 link count mismatch for inode 7536890 (name ?), nlink 0, counted 1 ... xfs_repair put the thing in /lost+found and moving this to /usr/share/mysql/portuguese/errmsg.sys resolved the issue, but it leaves me wondering how this came about? No error messages in the kernel log, no disk errors (used "dd" to read the whole disk to /dev/null). Linux 2.4.19 on a Pentium 133, 48Mb SGI XFS 1.2pre4 with ACLs, quota, no debug enabled (And a VIA vt82c586 (rev 02) IDE controller) Any ideas? Or is this just a single bit that fell of the drive accidentally? Oh, BTW, this was the first time I actually needed xfs_repair and it felt a bit uneasy to see that you can't repair mounted fs's. Well, it's in the faq, I should have read that fine manual before use, I know ;-) Best regards, Valentijn -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink valentyn+sessink@nospam.openoffice.nl From owner-linux-xfs@oss.sgi.com Sun Mar 23 21:02:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Mar 2003 21:02:23 -0800 (PST) Received: from relay02.roc.frontiernet.net (relay02.roc.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2O52Dq9032439 for ; Sun, 23 Mar 2003 21:02:15 -0800 Received: (qmail 11016 invoked from network); 24 Mar 2003 05:02:12 -0000 Received: from unknown (HELO xp1600) ([209.130.163.196]) (envelope-sender ) by relay02.roc.frontiernet.net (FrontierMTA 2.3.2) with SMTP for ; 24 Mar 2003 05:02:12 -0000 From: "Matt & Dawn Pohlman" To: Subject: Installing RedHat on Indy Date: Sun, 23 Mar 2003 23:04:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dpohlman@frontiernet.net Precedence: bulk X-list: linux-xfs Content-Length: 495 Lines: 8 I just got my first SGI machine (R5000/180mhz) and got IRIX 6.2 loaded and running fine. Now my next project is to try and get RedHat Linux installed on it. I downloaded the RH w/xfs for SGI iso file and burned it onto a CD. Whenever I boot the indy and try to set up the drive for RH/xfs, I get error messages referring to an invalid cd. Any suggestions on how to properly burn the .iso image so the indy can recognize it and what steps are needed to get this loaded on the SGI machine. From owner-linux-xfs@oss.sgi.com Sun Mar 23 23:25:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Mar 2003 23:25:59 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2O7P5q9002942 for ; Sun, 23 Mar 2003 23:25:46 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2O7P2KU015712; Mon, 24 Mar 2003 08:25:02 +0100 (CET) Message-Id: <4.3.2.7.2.20030324082033.03629008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Mar 2003 08:24:59 +0100 To: "Matt & Dawn Pohlman" , From: Seth Mos Subject: Re: Installing RedHat on Indy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1175 Lines: 28 At 23:04 23-3-2003 -0800, Matt & Dawn Pohlman wrote: >I just got my first SGI machine (R5000/180mhz) and got IRIX 6.2 loaded and >running fine. Now my next project is to try and get RedHat Linux installed >on it. I downloaded the RH w/xfs for SGI iso file and burned it onto a >CD. Whenever I boot the indy and try to set up the drive for RH/xfs, I get >error messages referring to an invalid cd. Any suggestions on how to >properly burn the .iso image so the indy can recognize it and what steps are >needed to get this loaded on the SGI machine. The Indy is a Mips machine. You will need the mips port of debian (which is fairly complete) or the development version of some redhat packages that are floating around. AFAIK there still is no easy installer software for the Mips machines although it has been some time. The cd that you are trying to install is a Intel CD with XFS filesystem support. Yes, Irix uses XFS but that is the only common between the 2. Mips machines are a entirely different nature from the Intel world. It's the same effect as trying to install windows on a Mac. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Mar 24 00:12:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 00:12:35 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2O8BWq9003988 for ; Mon, 24 Mar 2003 00:12:13 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 51DAEAC42; Mon, 24 Mar 2003 09:24:58 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id CB8BB19097; Mon, 24 Mar 2003 09:24:59 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id C297730881D; Mon, 24 Mar 2003 09:11:28 +0100 (CET) Message-ID: <3E7EBDB0.65DAFBD9@ch.sauter-bc.com> Date: Mon, 24 Mar 2003 09:11:28 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.24-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Valentijn Sessink Cc: linux-xfs@oss.sgi.com Subject: Re: error 990 out of the blue? References: <20030323175733.GA32375@openoffice.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1545 Lines: 44 You may check this bugreport https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81925 Simon Valentijn Sessink schrieb: > > Hello List, > > Just a short notice, as I don't have any extra info on this. One of my > machines showed an "error 990" just out of the blue, 3 days ago. > > I couldn't find anything - there was a loose inode and that was it. > > What puzzles me is that this machine has a load of almost 0; the file with > problems was /usr/share/mysql/portuguese/errmsg.sys - which is not in use in > any way. > > xfs_check said: > disconnected inode 410362, nlink 1 > link count mismatch for inode 7536890 (name ?), nlink 0, counted 1 > > ... xfs_repair put the thing in /lost+found and moving this to > /usr/share/mysql/portuguese/errmsg.sys resolved the issue, but it leaves me > wondering how this came about? No error messages in the kernel log, no disk > errors (used "dd" to read the whole disk to /dev/null). > > Linux 2.4.19 on a Pentium 133, 48Mb > SGI XFS 1.2pre4 with ACLs, quota, no debug enabled > (And a VIA vt82c586 (rev 02) IDE controller) > > Any ideas? Or is this just a single bit that fell of the drive accidentally? > > Oh, BTW, this was the first time I actually needed xfs_repair and it felt a > bit uneasy to see that you can't repair mounted fs's. Well, it's in the faq, > I should have read that fine manual before use, I know ;-) > > Best regards, > > Valentijn > -- > http://www.openoffice.nl/ Open Office - Linux Office Solutions > Valentijn Sessink valentyn+sessink@nospam.openoffice.nl From owner-linux-xfs@oss.sgi.com Mon Mar 24 05:24:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 05:24:10 -0800 (PST) Received: from duckman.blub.net (postfix@cust.90.10.adsl.cistron.nl [195.64.90.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ODNNq9027982 for ; Mon, 24 Mar 2003 05:24:04 -0800 Received: from sahara.openoffice.nl (node1ec29.a2000.nl [24.132.236.41]) by duckman.blub.net (Postfix) with ESMTP id 3230F952; Mon, 24 Mar 2003 14:23:19 +0100 (CET) Received: by sahara.openoffice.nl (Postfix, from userid 1001) id 5B2423E59; Mon, 24 Mar 2003 14:23:15 +0100 (CET) Date: Mon, 24 Mar 2003 14:23:15 +0100 From: Valentijn Sessink To: Simon Matter Cc: linux-xfs@oss.sgi.com Subject: Re: error 990 out of the blue? Message-ID: <20030324132315.GD7287@openoffice.nl> References: <20030323175733.GA32375@openoffice.nl> <3E7EBDB0.65DAFBD9@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E7EBDB0.65DAFBD9@ch.sauter-bc.com> User-Agent: Mutt/1.3.28i X-Message-Flag: Open Office - Linux for the desktop X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: valentyn+xfs@nospam.openoffice.nl Precedence: bulk X-list: linux-xfs Content-Length: 587 Lines: 18 At Mon, Mar 24, 2003 at 09:11:28AM +0100, Simon Matter wrote: > You may check this bugreport > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81925 Hmm, that's about a controller failure. It seems a bit weird to have a controller failure help kill a file index that's neither written nor read :-( Oh well, I'll just see what happens during the next month. It /could/ still actually /be/ a controller bug. Thanks for the link. Best regards, Valentijn -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink valentyn+sessink@nospam.openoffice.nl From owner-linux-xfs@oss.sgi.com Mon Mar 24 05:36:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 05:37:01 -0800 (PST) Received: from ncstu.ru (ns.stv.runnet.ru [195.209.244.8]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ODaDq9029209 for ; Mon, 24 Mar 2003 05:36:56 -0800 Received: from [195.209.245.67] (HELO admin-g) by ncstu.ru (CommuniGate Pro SMTP 4.0.6) with ESMTP id 142694 for linux-xfs@oss.sgi.com; Mon, 24 Mar 2003 16:36:07 +0300 Date: Mon, 24 Mar 2003 16:40:30 +0300 From: Oleg Novikov X-Mailer: The Bat! (v1.60f) Reply-To: Oleg Novikov Organization: NCSTU X-Priority: 3 (Normal) Message-ID: <399222921.20030324164030@stv.runnet.ru> To: linux-xfs@oss.sgi.com Subject: ACL and XFS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olnow@stv.runnet.ru Precedence: bulk X-list: linux-xfs Content-Length: 644 Lines: 27 Hello, linux-xfs. I setup the xfs 1.2 on kernel version 2.4.19 with support FS_POSIX_ACL. And then i change acl on the directory: chacl u::r-x,g::r-x,o::r-x,m::r-x There ara result of getfacl : # file: profile # owner: student # group: Domain Users user::r-x group::r-x mask::r-x other::r-x default:user::rwx default:group::rwx default:mask::rwx default:other::--- When I try to create in this directory file or another directory the result of this operation is ok. I.e. the mask is r-x, but I can create file. Why acl don't work? -- With redgards, Oleg mailto:olnow@stv.runnet.ru From owner-linux-xfs@oss.sgi.com Mon Mar 24 05:57:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 05:57:18 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ODuSq9029711 for ; Mon, 24 Mar 2003 05:57:12 -0800 Received: (qmail 17278 invoked from network); 24 Mar 2003 14:09:22 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 24 Mar 2003 14:09:22 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18xSR3-00013W-00; Mon, 24 Mar 2003 14:56:21 +0100 Date: Mon, 24 Mar 2003 14:56:21 +0100 To: Chris Wedgwood Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030324135621.GA4038@localhost> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> <20030320191734.GA18090@localhost> <20030320231535.GA16975@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320231535.GA16975@f00f.org> User-Agent: Mutt/1.5.4i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 903 Lines: 30 > > i know it is and can install it but could You please be more > > specific and tell what kinds of results You'd expect? > > i'd like to see *where* all the CPU time is being consumed didn't have time during weekend but made a few tests now the result of op_time 1 0.0061 0.0000 /lib/libnsl-2.3.1.so 1 0.0061 0.0000 /lib/libproc.so.3.1.6 1 0.0061 0.0000 /oprofile 1 0.0061 0.0000 /usr/bin/mawk 4 0.0242 0.0000 /usr/bin/oprofiled 37 0.2239 0.0000 /bin/bash 38 0.2299 0.0000 /lib/ld-2.3.1.so 81 0.4901 0.0000 /bin/cp 222 1.3433 0.0000 /lib/libc-2.3.1.so 317 1.9182 0.0000 /lib/libncurses.so.5.3 15797 95.5888 0.0000 /boot/v where v is the uncompressed kernel image -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Mon Mar 24 08:51:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 08:52:02 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2OGpNq9031903 for ; Mon, 24 Mar 2003 08:51:25 -0800 Received: from rope.americas (rope.americas.sgi.com [128.162.232.44]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2OH2vkq018189 for ; Mon, 24 Mar 2003 11:02:57 -0600 Received: (from roehrich@localhost) by rope.americas (8.11.6/8.11.6) id h2OGpIl01053 for linux-xfs@oss.sgi.com; Mon, 24 Mar 2003 10:51:18 -0600 Date: Mon, 24 Mar 2003 10:51:18 -0600 From: Dean Roehrich Message-Id: <200303241651.h2OGpIl01053@rope.americas> Subject: TAKE - fix initialization of dmapi code X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@rope.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 449 Lines: 16 Date: Mon Mar 24 08:50:43 PST 2003 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.5.x-xfs-a Author: roehrich Merged by: roehrich Merged mods: 2.4.x-xfs:slinx:142389a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142389a linux/fs/xfs/linux/xfs_super.h - 1.41 - Merge of 2.4.x-xfs:slinx:142389a by roehrich. Call dmapi_init/dmapi_uninit instead of xfs_dm_init/xfs_dm_exit From owner-linux-xfs@oss.sgi.com Mon Mar 24 11:47:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 11:47:22 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2OJlCq9002520 for ; Mon, 24 Mar 2003 11:47:14 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HC900H2BQYO80@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 24 Mar 2003 13:47:12 -0600 (CST) Date: Mon, 24 Mar 2003 13:47:12 -0600 From: Dan Yocum Subject: Re: KDB-ized RH 2.4.18-X kernel? To: xfs-list Message-id: <3E7F60C0.6000708@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 References: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 757 Lines: 32 I compiled the kernel-source...i386.rpm. Maybe Keith might have some insight into this? It looks like it's a linker problem... Keith? Thanks, Dan Joshua Baker-LePain wrote: > On Fri, 21 Mar 2003 at 4:00pm, Dan Yocum wrote > > >>Sorry, I jumped ahead in my error reporting - I tried re-compiling the RH >>kernel source with kdb enabled. No go. Horrible death. Die, die, die. > > > Did you compile the source in /usr/src/linux-2.4 as installed by the > kernel-source*rpm, or did you compile from the SRPM? ISTR that the first > method can be broken sometimes, but I've had had good luck with the > second. > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Mon Mar 24 15:09:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 15:09:57 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ON95q9009506 for ; Mon, 24 Mar 2003 15:09:47 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AF91B1847114; Mon, 24 Mar 2003 15:09:04 -0800 (PST) Date: Mon, 24 Mar 2003 15:09:04 -0800 From: Chris Wedgwood To: Michal Adamczak Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030324230904.GB27380@f00f.org> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> <20030320191734.GA18090@localhost> <20030320231535.GA16975@f00f.org> <20030324135621.GA4038@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030324135621.GA4038@localhost> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 314 Lines: 14 On Mon, Mar 24, 2003 at 02:56:21PM +0100, Michal Adamczak wrote: > the result of op_time > 15797 95.5888 0.0000 /boot/v we actually need the results of where inside the kernel time is being spent... not which userspace objects are consuming time are you able to retest and provide that please? --cw From owner-linux-xfs@oss.sgi.com Mon Mar 24 16:50:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 16:50:49 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P0ocq9011320 for ; Mon, 24 Mar 2003 16:50:39 -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 h2P0oWuY029667 for ; Mon, 24 Mar 2003 16:50:32 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17322; Tue, 25 Mar 2003 11:49:14 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id C39FF3000B8; Tue, 25 Mar 2003 11:49:13 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id A9FFF8F; Tue, 25 Mar 2003 11:49:13 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dan Yocum Cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "Mon, 24 Mar 2003 13:47:12 MDT." <3E7F60C0.6000708@fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 2003 11:49:08 +1100 Message-ID: <13516.1048553348@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 13 On Mon, 24 Mar 2003 13:47:12 -0600, Dan Yocum wrote: >I compiled the kernel-source...i386.rpm. > >Maybe Keith might have some insight into this? It looks like it's a linker >problem... > >Keith? Sorry, my telepathy is not working today. Perhaps if I had some details of the patches used, the compile steps and the errors then I might be able to comment. From owner-linux-xfs@oss.sgi.com Mon Mar 24 20:02:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 20:02:54 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P42jq9014666 for ; Mon, 24 Mar 2003 20:02:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2P42cnH003445 for ; Mon, 24 Mar 2003 20:02:39 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2P41L7L3130530 for ; Tue, 25 Mar 2003 15:01:21 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2P41L5s3043128 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 15:01:21 +1100 (EST) Date: Tue, 25 Mar 2003 15:01:21 +1100 (EST) From: Nathan Scott Message-Id: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1814 Lines: 54 Add xfs_io into xfsprogs, an xfs_db-alike program for the XFS IO path which knows about direct IO, space preallocation, realtime files, etc, which the usual tools like dd don't unfortunately. This is a fixed-up version of a hacked tool that I found useful for coding, debugging and testing unwritten extents; hopefully it'll be useful for realtime too. readline support also optionally exists in xfs_db and xfs_io now, but not by default (need to configure with --enable-readline=yes). Handy for command history, editing, etc. cheers. Date: Mon Mar 24 19:48:48 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:142552a cmd/xfsprogs/man/man8/xfs_io.8 - 1.1 cmd/xfsprogs/io/command.c - 1.1 cmd/xfsprogs/io/command.h - 1.1 cmd/xfsprogs/io/xfs_bmap.sh - 1.1 cmd/xfsprogs/io/pread.c - 1.1 cmd/xfsprogs/io/input.h - 1.1 cmd/xfsprogs/io/Makefile - 1.1 cmd/xfsprogs/io/truncate.c - 1.1 cmd/xfsprogs/io/resblks.c - 1.1 cmd/xfsprogs/io/quit.c - 1.1 cmd/xfsprogs/io/pwrite.c - 1.1 cmd/xfsprogs/io/prealloc.c - 1.1 cmd/xfsprogs/io/help.c - 1.1 cmd/xfsprogs/io/input.c - 1.1 cmd/xfsprogs/io/init.h - 1.1 cmd/xfsprogs/io/open.c - 1.1 cmd/xfsprogs/io/init.c - 1.1 cmd/xfsprogs/db/input.c - 1.7 cmd/xfsprogs/db/Makefile - 1.10 cmd/xfsprogs/configure.in - 1.19 cmd/xfsprogs/Makefile - 1.17 cmd/xfsprogs/VERSION - 1.69 cmd/xfsprogs/doc/CHANGES - 1.94 cmd/xfsprogs/bmap/Makefile - 1.9 xfsprogs/bmap/xfs_bmap.c 1.14 renamed to xfsprogs/io/bmap.c 1.1 - xfsprogs/bmap/xfs_bmap.c 1.13 Renamed to xfsprogs/io/bmap.c cmd/xfsprogs/include/xfs_fs.h - 1.24 cmd/xfsprogs/include/builddefs.in - 1.27 cmd/xfsprogs/debian/control - 1.13 cmd/xfsprogs/debian/changelog - 1.62 cmd/xfsprogs/debian/rules - 1.16 From owner-linux-xfs@oss.sgi.com Mon Mar 24 22:09:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 22:09:36 -0800 (PST) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P68jq9015817 for ; Mon, 24 Mar 2003 22:09:26 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id B2239EDDB17 for ; Tue, 25 Mar 2003 14:08:38 +0800 (PHT) Received: from lawin.leathercollection.ph (lawin.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 064CBEB4A3C for ; Tue, 25 Mar 2003 14:08:35 +0800 (PHT) Received: by lawin.leathercollection.ph (Postfix, from userid 1000) id AA2D31A4004; Tue, 25 Mar 2003 14:08:34 +0800 (PHT) Date: Tue, 25 Mar 2003 14:08:34 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: mkfs.xfs and zeroing of unwritten extents (was: TAKE - xfsprogs) Message-ID: <20030325060834.GF22572@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 2018 Lines: 39 On Tue, Mar 25, 2003 at 03:01:21PM +1100, Nathan Scott wrote: > This is a fixed-up version of a hacked tool that I found useful for > coding, debugging and testing unwritten extents; hopefully it'll be > useful for realtime too. I read in the announcement about the new Debian package for xfsprogs that zeroing out of unwritten extents is now enabled by default in mkfs.xfs. A search about unwritten extents pointed me to . I haven't been in touch with XFS development lately[1], so please pardon me if this was discussed previously. Is there anything that has to be done for systems that were created with slightly older versions of xfsprogs (eg: 2.3.11)? What problems to XFS filesystems created on top of previously existing filesystems (eg: ext3) pose? --> Jijo [1] I used to be an avid XFS user, then I ran into problems[2] that I couldn't explain, and couldn't get anyone else to figure out. I was forced to shift to ext3, and things ran smoothly as soon as I "jumped ship". Then after around four months, the system again ran into a very similar kernel panic. I had an opportunity to make the server breathe awhile after that, so I decided to run a full memory scan using memtest86, which I can't recall having done before. It found ploblems in a small section of one of the modules, that I have now replaced. With this new information, I am confident the problems I ran into before were largely caused by the problematic RAM and the way XFS stresses systems more than ext3 does. Because of the very significant performance hit of using ext3 instead of XFS, I took time to transfer everything back, and have for a week now been happily running XFS again. :) [2] http://marc.theaimsgroup.com/?l=linux-xfs&m=103369234209733&w=2 -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Mon Mar 24 22:45:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 22:45:19 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P6jCq9016479 for ; Mon, 24 Mar 2003 22:45: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 h2P6j5nH011708 for ; Mon, 24 Mar 2003 22:45:06 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20178 for ; Tue, 25 Mar 2003 17:43:50 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA24440 for ; Tue, 25 Mar 2003 17:43:49 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2P6ekuQ032165 for ; Tue, 25 Mar 2003 17:40:46 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2P6ekVX032163 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 17:40:46 +1100 Date: Tue, 25 Mar 2003 17:40:46 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs and zeroing of unwritten extents (was: TAKE - xfsprogs) Message-ID: <20030325064046.GD6306@frodo> References: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> <20030325060834.GF22572@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030325060834.GF22572@leathercollection.ph> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 891 Lines: 27 On Tue, Mar 25, 2003 at 02:08:34PM +0800, Federico Sevilla III wrote: > ... > I read in the announcement about the new Debian package for xfsprogs > that zeroing out of unwritten extents is now enabled by default in > mkfs.xfs. A search about unwritten extents pointed me to > . There has been more extensive discussion on the XFS list recently; see the archives, I don't have a pointer handy. > I haven't been in touch with XFS development lately[1], so please pardon > me if this was discussed previously. Is there anything that has to be > done for systems that were created with slightly older versions of > xfsprogs (eg: 2.3.11)? You can enable unwritten extents using the xfs_admin(8) -e option. > What problems to XFS filesystems created on top > of previously existing filesystems (eg: ext3) pose? None at all. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 25 00:14:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 00:14:25 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P8ECq9017564 for ; Tue, 25 Mar 2003 00:14:14 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2P8E8sN054349; Tue, 25 Mar 2003 09:14:08 +0100 (CET) Message-Id: <4.3.2.7.2.20030325085227.02421458@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Mar 2003 09:14:03 +0100 To: Keith Owens , Dan Yocum From: Seth Mos Subject: Re: KDB-ized RH 2.4.18-X kernel? Cc: xfs-list In-Reply-To: <13516.1048553348@kao2.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 3177 Lines: 81 At 11:49 25-3-2003 +1100, Keith Owens wrote: >On Mon, 24 Mar 2003 13:47:12 -0600, >Dan Yocum wrote: > >I compiled the kernel-source...i386.rpm. > > > >Maybe Keith might have some insight into this? It looks like it's a linker > >problem... > > > >Keith? > >Sorry, my telepathy is not working today. Perhaps if I had some >details of the patches used, the compile steps and the errors then I >might be able to comment. I reported this problem earlier as well when I was working on the 2.4.18-24 kernel IIRC and it had to do with the linking. You commented on this that the symbols were not exported right. Here is the first email I sent. 1.2pre5 was hip then. Cheers ---------------snip---------------------- At 08:13 21-1-2003 +1100, Keith Owens wrote: >On Mon, 20 Jan 2003 17:11:46 +0100, >Seth Mos wrote: > >At 10:24 20-1-2003 -0500, Jeremy Jackson wrote: > >> > > >>Any time I've had "internal compiler error", it's been a hardware > >>problem. ie bad heatsing or memory. I suggest running memtest86.com's > >>test utility. > > > >That's not the case here. In fact the error is that the kdb symbols are not > >ending up in the right place when it is linking as far I can tell. > >Details please, my telepathy is not working this morning ... kallsyms pass 1 init/main.o: In function `parse_options': init/main.o(.text.init+0x5e6): undefined reference to `kdb_on' init/main.o(.text.init+0x5eb): undefined reference to `kdb_flags' init/main.o(.text.init+0x622): undefined reference to `kdb_on' init/main.o(.text.init+0x64f): undefined reference to `kdb_on' init/main.o(.text.init+0x674): undefined reference to `kdb_flags' init/main.o(.text.init+0x67f): undefined reference to `kdb_on' init/main.o(.text.init+0x687): undefined reference to `kdb_flags' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2aba): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ac4): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ad1): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ae9): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2af3): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2afd): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b07): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b14): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o: In function `fetch_data': /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b79): undefined reference to `kdb_printf' make[1]: *** [kallsyms] Fout 1 make: *** [vmlinux] Fout 2 error: Bad exit status from /var/tmp/rpm-tmp.14321 (%build) ------------------snip------------------- -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Mar 25 00:52:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 00:52:44 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P8psq9018917 for ; Tue, 25 Mar 2003 00:52:34 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2P8plnH018896 for ; Tue, 25 Mar 2003 00:51:48 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA20839; Tue, 25 Mar 2003 19:50:27 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0E8723000B8; Tue, 25 Mar 2003 19:50:26 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id C6B528F; Tue, 25 Mar 2003 19:50:26 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Seth Mos Cc: Dan Yocum , xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "Tue, 25 Mar 2003 09:14:03 BST." <4.3.2.7.2.20030325085227.02421458@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 2003 19:50:21 +1100 Message-ID: <18343.1048582221@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1148 Lines: 30 On Tue, 25 Mar 2003 09:14:03 +0100, Seth Mos wrote: >I reported this problem earlier as well when I was working on the 2.4.18-24 >kernel IIRC and it had to do with the linking. >kallsyms pass 1 >init/main.o: In function `parse_options': >init/main.o(.text.init+0x5e6): undefined reference to `kdb_on' >init/main.o(.text.init+0x5eb): undefined reference to `kdb_flags' >init/main.o(.text.init+0x622): undefined reference to `kdb_on' >init/main.o(.text.init+0x64f): undefined reference to `kdb_on' >init/main.o(.text.init+0x674): undefined reference to `kdb_flags' >init/main.o(.text.init+0x67f): undefined reference to `kdb_on' >init/main.o(.text.init+0x687): undefined reference to `kdb_flags' You only applied the kdb-i386 patch and did not apply the kdb-common patch. If the kdb-common patch was applied the the build did not descend into the kdb directory, probably a missing patch to the top level Makefile, it should look like this. LIBS =$(TOPDIR)/lib/lib.a SUBDIRS =kernel drivers mm fs net ipc lib ifeq ($(CONFIG_KDB),y) CORE_FILES += kdb/kdb.o SUBDIRS += kdb endif DRIVERS-n := From owner-linux-xfs@oss.sgi.com Tue Mar 25 02:22:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 02:22:35 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PAMNq9021468 for ; Tue, 25 Mar 2003 02:22:23 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PAMNrt021466 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 02:22:23 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PAMLqB021453 for ; Tue, 25 Mar 2003 02:22:22 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PA9bCm020065; Tue, 25 Mar 2003 02:09:37 -0800 Date: Tue, 25 Mar 2003 02:09:37 -0800 Message-Id: <200303251009.h2PA9bCm020065@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 565 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-25 02:09 ------- Kernel recompiled with xfs-2003-03-23, and without any additional patches. With the same conditions, whan I enter kdb and use 'ps', some untrivial output occures: all processes, exept init have string: Error: does not matsh running process tables:( 0xc03e0000). As the result, bta shows no useful information. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 03:22:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 03:22:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PBMMq9024160 for ; Tue, 25 Mar 2003 03:22:22 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PBMMsQ024158 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 03:22:22 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PBMKqB024144 for ; Tue, 25 Mar 2003 03:22:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PAdxOm022158; Tue, 25 Mar 2003 02:39:59 -0800 Date: Tue, 25 Mar 2003 02:39:59 -0800 Message-Id: <200303251039.h2PAdxOm022158@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 326 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From kaos@sgi.com 2003-03-25 02:39 ------- How are you entering kdb? I need the output from these kdb commands cpu ps ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 06:30:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 06:30:58 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.114.72.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PEUjq9029041 for ; Tue, 25 Mar 2003 06:30:47 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.12.8/8.12.5) with ESMTP id h2PEUcAW002664; Tue, 25 Mar 2003 09:30:40 -0500 Subject: Re: low level access path for xfs operation From: Jeremy Jackson To: kss@kldp.org Cc: Chris Wedgwood , linux-xfs@oss.sgi.com In-Reply-To: <20030322101427.A32751@mail.kldp.org> References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> <20030321194353.A12729@mail.kldp.org> <20030321204052.GB27409@f00f.org> <20030322101427.A32751@mail.kldp.org> Content-Type: text/plain Organization: Message-Id: <1048602638.1261.9.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 25 Mar 2003 09:30:38 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 3274 Lines: 74 If using EVMS with dm/LVM, it is easy to make another volume. The administrator needs to learn the hard way not to fill up the disk with a filesystem that cannot shrink. (I know I have) It will create other problems besides not having room to snapshot. Sure would be nice if XFS *could* shrink. The other features outweigh this disadvantage for me. Jeremy On Fri, 2003-03-21 at 20:14, Soon-Son Kwon wrote: > On Fri, Mar 21, 2003 at 12:40:52PM -0800, Chris Wedgwood wrote: > > On Fri, Mar 21, 2003 at 07:43:53PM +0900, Soon-Son Kwon wrote: > > > > > What I would like to implement is the snapshot functionality within > > > the filesystem. I know LVM supports snapshot but it requires a > > > separate volume for each snapshot. I thought snapshot within the > > > filesystem would be more convenient. > > > > How should this work from a user perspective? > > If a snapshot can be generated/maintained within the filesystem, > the user do not have to care for the overall disk layout as long > as there are some free spaces in the filesystem while LVM > requires additional volume which means even if there are a lot of > of free blocks on the source filesystem, the user should allocate > another volume for the snapshot. This can be a problem if the > system administrator had allocated all the blocks to some > volumes already because he/she cannot generate volume for snapshot > any more. > > And the snapshot does not affect anything to normal users. > What snapshot can provide to the users are he/she can revert > the filesystem to the state when the snapshot was taken > which means the user can get an older version of file or deleted > files. > > > > Snapshot functionality requires copy-on-write implementation when > > > something tries to modify any block, copy the old content to new > > > block and overwrite the new content to that block while the snapshot > > > image keeps track of the original content. > > > > You need to be sure whatever mechanism you use to keep track of block > > placements is efficient and the granularity are sane or else the > > metadata to keep track of this can be enormous. > > > > > Anyway, do you think implementing that operation requires modifying > > > dm/md code instead of modifying submit_bio()? > > > > No... I don't see why it should --- ideally you want a pseudo-block > > device or similar to place the fs on; this will then be able to track > > changes and such like. > > > > Check the device-mapper and LVM as they effectively do this. > > So, you mean the following design as follows? > > (VFS)-(XFS)-(pseudo-block device)-(md)-(dm) > > I just thought if I can be notified any write/modify operation for > a block, then I can copy and allocate the old block to a new location > and record that information to the snapshot file, then the original > block contents can be (over)written. > > (of course when generating a snapshot information, it should > store every information on which block was in use/free at that time > the snapshot was taken as a form of something like block map.) > > But anyway I am not an expert on this field. > Could you please give a little more detailed explanation of > the "pseudo block device" or any comment on my descriptions above? > > Thank you very much... From owner-linux-xfs@oss.sgi.com Tue Mar 25 07:08:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 07:08:26 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PF7Zq9029850 for ; Tue, 25 Mar 2003 07:08:15 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2PF7VMq005351; Tue, 25 Mar 2003 16:07:31 +0100 (CET) Message-Id: <4.3.2.7.2.20030325160606.03aff8c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Mar 2003 16:07:08 +0100 To: Keith Owens From: Seth Mos Subject: Re: KDB-ized RH 2.4.18-X kernel? Cc: Dan Yocum , xfs-list In-Reply-To: <18343.1048582221@kao2.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 467 Lines: 18 > >You only applied the kdb-i386 patch and did not apply the kdb-common >patch. If the kdb-common patch was applied the the build did not >descend into the kdb directory, probably a missing patch to the top >level Makefile, it should look like this. You are right. I'll look into it. The kdb-common wasn't in the pre5 rpm anyways which might explain it. And I normally don't rebuild with KDB. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Mar 25 08:30:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 08:31:17 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PGUpq9032143 for ; Tue, 25 Mar 2003 08:30:56 -0800 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel11.hp.com (Postfix) with ESMTP id 4D2611C00D2F for ; Tue, 25 Mar 2003 08:30:51 -0800 (PST) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 43AD21C00AC8 for ; Tue, 25 Mar 2003 08:30:51 -0800 (PST) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Mar 2003 08:30:51 -0800 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: crash in xfs_inactive Date: Tue, 25 Mar 2003 08:30:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 3047 Lines: 82 I've gotten the following crash in xfs_inactive a few times after pushing a server very hard running the SPEC SFS NFS test. This crash doesn't happen every time unfortunately. Unable to handle kernel NULL pointer dereference at virtual address 00000008 801c932e *pde = 72db8001 Oops: 0000 CPU: 2 EIP: 0010:[<801c932e>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 801c929c ebx: bc0139a0 ecx: 00000001 edx: 000081b6 esi: f7746000 edi: 00000000 ebp: bc0139b8 esp: f7bd9ee8 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 7, stackpage=f7bd9000) Stack: b335bc40 f7bd9f58 b9f1e328 f7bd9f60 00000000 00000296 c4bc8c80 801da3e9 bc0139b8 00000000 b335bc40 801d9348 b335bc40 b335bc60 8014ca1e b335bc60 b335bc60 8014caa4 b335bc60 d5bf0dc0 d5bf0dc8 8014cdd4 f7bd9f58 00000013 Call Trace: [<801da3e9>] [<801d9348>] [<8014ca1e>] [<8014caa4>] [<8014cdd4>] [<8014ce0f>] [<8012fce7>] [<8012fd3c>] [<8012fe41>] [<8012fea6>] [<8012ff Code: 8b 47 08 f6 00 01 0f 85 80 03 00 00 83 bb 34 01 00 00 00 0f >>EIP; 801c932e <===== >>eax; 801c929c >>ebx; bc0139a0 >>edx; 000081b6 Before first symbol >>esi; f7746000 >>ebp; bc0139b8 >>esp; f7bd9ee8 Trace; 801da3e9 Trace; 801d9348 Trace; 8014ca1e Trace; 8014caa4 Trace; 8014cdd4 Trace; 8014ce0f Trace; 8012fce7 Trace; 8012fd3c Trace; 8012fe41 Trace; 8012fea6 Code; 801c932e 00000000 <_EIP>: Code; 801c932e <===== 0: 8b 47 08 mov 0x8(%edi),%eax <===== Code; 801c9331 3: f6 00 01 testb $0x1,(%eax) Code; 801c9334 6: 0f 85 80 03 00 00 jne 38c <_EIP+0x38c> Code; 801c933a c: 83 bb 34 01 00 00 00 cmpl $0x0,0x134(%ebx) Code; 801c9341 13: 0f 00 00 sldtl (%eax) The code in question is derefencing the vp->v_vfsp pointer and failing because the vp pointer is NULL for some scary unknown reason: Dissassembly of xfs_inactive: /src/kernel/linux/fs/xfs/xfs_vnodeops.c:1666 error = 0; /* If this is a read-only mount, don't do this (would generate I/O) */ if (vp->v_vfsp->vfs_flag & VFS_RDONLY) 801c932e: 8b 47 08 mov 0x8(%edi),%eax 801c9331: f6 00 01 testb $0x1,(%eax) 801c9334: 0f 85 80 03 00 00 jne 801c96ba We're running 2.4.20 with XFS CVS from March 17th. I did see this crash on earlier CVS downloads, but wanted to see the crash a few more times before mentioning it. Erik Habbinga From owner-linux-xfs@oss.sgi.com Tue Mar 25 09:40:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 09:40:34 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PHeJq9001281 for ; Tue, 25 Mar 2003 09:40:20 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2PHeE0L009618 for ; Tue, 25 Mar 2003 09:40:14 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id JAA25247 for ; Tue, 25 Mar 2003 09:40:13 -0800 (PST) Date: Tue, 25 Mar 2003 09:40:13 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Re: crash in xfs_inactive In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 3976 Lines: 107 Erik, Are you using NFS patches from nfs.sourceforge.net? If so take a look a Bug 195 in bugzilla and you will notice there is an issue with the patch to do Direct IO on NFS. I had the same output when I had the patch installed. -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Tue, 25 Mar 2003, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Date: Tue, 25 Mar 2003 08:30:45 -0800 > From: "HABBINGA,ERIK (HP-Loveland,ex1)" > To: "'linux-xfs@oss.sgi.com'" > Subject: crash in xfs_inactive > > I've gotten the following crash in xfs_inactive a few times after pushing a > server very hard running the SPEC SFS NFS test. This crash doesn't happen > every time unfortunately. > > Unable to handle kernel NULL pointer dereference at virtual address 00000008 > 801c932e > *pde = 72db8001 > Oops: 0000 > CPU: 2 > EIP: 0010:[<801c932e>] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: 801c929c ebx: bc0139a0 ecx: 00000001 edx: 000081b6 > esi: f7746000 edi: 00000000 ebp: bc0139b8 esp: f7bd9ee8 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 7, stackpage=f7bd9000) > Stack: b335bc40 f7bd9f58 b9f1e328 f7bd9f60 00000000 00000296 c4bc8c80 > 801da3e9 > bc0139b8 00000000 b335bc40 801d9348 b335bc40 b335bc60 8014ca1e > b335bc60 > b335bc60 8014caa4 b335bc60 d5bf0dc0 d5bf0dc8 8014cdd4 f7bd9f58 > 00000013 > Call Trace: [<801da3e9>] [<801d9348>] [<8014ca1e>] [<8014caa4>] > [<8014cdd4>] > [<8014ce0f>] [<8012fce7>] [<8012fd3c>] [<8012fe41>] [<8012fea6>] > [<8012ff > Code: 8b 47 08 f6 00 01 0f 85 80 03 00 00 83 bb 34 01 00 00 00 0f > > > >>EIP; 801c932e <===== > > >>eax; 801c929c > >>ebx; bc0139a0 > >>edx; 000081b6 Before first symbol > >>esi; f7746000 > >>ebp; bc0139b8 > >>esp; f7bd9ee8 > > Trace; 801da3e9 > Trace; 801d9348 > Trace; 8014ca1e > Trace; 8014caa4 > Trace; 8014cdd4 > Trace; 8014ce0f > Trace; 8012fce7 > Trace; 8012fd3c > Trace; 8012fe41 > Trace; 8012fea6 > > Code; 801c932e > 00000000 <_EIP>: > Code; 801c932e <===== > 0: 8b 47 08 mov 0x8(%edi),%eax <===== > Code; 801c9331 > 3: f6 00 01 testb $0x1,(%eax) > Code; 801c9334 > 6: 0f 85 80 03 00 00 jne 38c <_EIP+0x38c> > Code; 801c933a > c: 83 bb 34 01 00 00 00 cmpl $0x0,0x134(%ebx) > Code; 801c9341 > 13: 0f 00 00 sldtl (%eax) > > The code in question is derefencing the vp->v_vfsp pointer and failing > because the vp pointer is NULL for some scary unknown reason: > > Dissassembly of xfs_inactive: > /src/kernel/linux/fs/xfs/xfs_vnodeops.c:1666 > error = 0; > > /* If this is a read-only mount, don't do this (would generate I/O) > */ > if (vp->v_vfsp->vfs_flag & VFS_RDONLY) > 801c932e: 8b 47 08 mov 0x8(%edi),%eax > 801c9331: f6 00 01 testb $0x1,(%eax) > 801c9334: 0f 85 80 03 00 00 jne 801c96ba > > We're running 2.4.20 with XFS CVS from March 17th. I did see this crash on > earlier CVS downloads, but wanted to see the crash a few more times before > mentioning it. > > Erik Habbinga > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 09:51:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 09:51:08 -0800 (PST) Received: from gateway.max-t.com (h216-18-124-229.gtconnect.net [216.18.124.229]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PHp4q9003656 for ; Tue, 25 Mar 2003 09:51:05 -0800 Received: from dog.max-t.internal ([192.168.1.124]) by gateway.max-t.com with esmtp (Exim 3.32 #3) id 18xsbd-0002wq-00; Tue, 25 Mar 2003 12:53:01 -0500 Received: from localhost (sdoyon@localhost) by dog.max-t.internal (8.11.6/8.11.6) with ESMTP id h2PHoYK15657; Tue, 25 Mar 2003 12:50:35 -0500 X-Authentication-Warning: dog.max-t.internal: sdoyon owned process doing -bs Date: Tue, 25 Mar 2003 12:50:34 -0500 (EST) From: =?ISO-8859-1?Q?St=E9phane_Doyon?= X-X-Sender: sdoyon@dog.max-t.internal To: nathans@sgi.com, Subject: Maximum log stripe size Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sdoyon@max-t.com Precedence: bulk X-list: linux-xfs Content-Length: 546 Lines: 20 Hi, mkfs.xfs insists that the log stripe unit (-l sunit) must be smaller than 256K. See xfs_mkfs.c around line 1730: if ((lsunit * blocksize) > 256 * 1024) { fprintf(stderr, _("log stripe unit (%d bytes) is too large for kernel to handle (max 256k)\n"), (lsunit * blocksize)); exit(1); } Can anyone please tell me whether this is really necessary? Our SCSI RAID controllers would much prefer stripes in the order of 1MB. And the kernel doesn't seem to mind. Thank you From owner-linux-xfs@oss.sgi.com Tue Mar 25 10:34:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 10:34:49 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PIY2q9009733 for ; Tue, 25 Mar 2003 10:34:43 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id LAA08217 for ; Tue, 25 Mar 2003 11:46:07 -0700 Message-ID: <3E809EB1.6000904@mvista.com> Date: Tue, 25 Mar 2003 11:23:45 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Need some help with cause of Oops in XFS 1.2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 5141 Lines: 113 XFS Developers, Ok here is what I have done: I have a tree that already had XFS 1.1 (with a bunch of other stuff) included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and everything seems to work fine, except when I run bonnie++ and under load (Writing intelligently operation), I receive the following Oops: Mar 24 15:20:13 192 kernel: invalid operand: 0000 Mar 24 15:20:13 192 kernel: CPU: 0 Mar 24 15:20:13 192 kernel: EIP: 0010:[] Not tainted Mar 24 15:20:13 192 kernel: EFLAGS: 00010286 Mar 24 15:20:13 192 kernel: eax: 00000037 ebx: 000000f8 ecx: 00000008 edx: 00000000 Mar 24 15:20:13 192 kernel: esi: c30000bc edi: 00000000 ebp: c2a517c0 esp: f7465e80 Mar 24 15:20:13 192 kernel: ds: 0018 es: 0018 ss: 0018 Mar 24 15:20:13 192 kernel: Process bonnie++ (pid: 114, stackpage=f7465000) Mar 24 15:20:13 192 kernel: Stack: c0327060 000000f8 00018541 00000000 f748ee80 c012abf6 f7465ec0 00001000 Mar 24 15:20:13 192 kernel: 00000000 00001000 00001000 00001000 1650f000 00000000 f740e320 f740e3d4 Mar 24 15:20:13 192 kernel: 00000000 3e7f849d 000e6b32 3e7f849d 3852bb50 0640d230 f7465f64 1650e000 Mar 24 15:20:13 192 kernel: Call Trace: [] [] [] [] [] Mar 24 15:20:13 192 kernel: [] Mar 24 15:20:13 192 kernel: Mar 24 15:20:13 192 kernel: Code: 0f 0b 83 c4 0c 8d 46 04 39 46 04 74 12 5b 89 f0 31 c9 ba 03 Mar 24 15:20:13 192 kernel: invalid operand: 0000 Mar 24 15:20:13 192 kernel: CPU: 0 Mar 24 15:20:13 192 kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Mar 24 15:20:13 192 kernel: EFLAGS: 00010286 Mar 24 15:20:13 192 kernel: eax: 00000037 ebx: 000000f8 ecx: 00000008 edx: 00000000 Mar 24 15:20:13 192 kernel: esi: c30000bc edi: 00000000 ebp: c2a517c0 esp: f7465e80 Mar 24 15:20:13 192 kernel: ds: 0018 es: 0018 ss: 0018 Mar 24 15:20:13 192 kernel: Process bonnie++ (pid: 114, stackpage=f7465000) Mar 24 15:20:13 192 kernel: Stack: c0327060 000000f8 00018541 00000000 f748ee80 c012abf6 f7465ec0 00001000 Mar 24 15:20:13 192 kernel: 00000000 00001000 00001000 00001000 1650f000 00000000 f740e320 f740e3d4 Mar 24 15:20:13 192 kernel: 00000000 3e7f849d 000e6b32 3e7f849d 3852bb50 0640d230 f7465f64 1650e000 Mar 24 15:20:13 192 kernel: Call Trace: [] [] [] [] [] Mar 24 15:20:13 192 kernel: [] Mar 24 15:20:13 192 kernel: Code: 0f 0b 83 c4 0c 8d 46 04 39 46 04 74 12 5b 89 f0 31 c9 ba 03 >>EIP; c0128331 <===== Trace; c012abf6 Trace; c024ad64 Trace; c02467a6 Trace; c0135836 Trace; c0116f9b Trace; c0106d03 Code; c0128331 00000000 <_EIP>: Code; c0128331 <===== 0: 0f 0b ud2a <===== Code; c0128333 2: 83 c4 0c add $0xc,%esp Code; c0128336 5: 8d 46 04 lea 0x4(%esi),%eax Code; c0128339 8: 39 46 04 cmp %eax,0x4(%esi) Code; c012833c b: 74 12 je 1f <_EIP+0x1f> c0128350 Code; c012833e d: 5b pop %ebx Code; c012833f e: 89 f0 mov %esi,%eax Code; c0128341 10: 31 c9 xor %ecx,%ecx Code; c0128343 12: ba 03 00 00 00 mov $0x3,%edx I tracked down the oops to a BUG() call in unlock_page which is triggered when a page that is already unlocked is attempted to be unlocked again (this just wouldn't work which is why there is a bug...). I read through the code in generic_file_write_nolock and it looks to me as if the page is being locked, and then unlocked consistently. If I put syslog() calls in the bonnie++ output to write the chunk count, (slowing down the I/Os) there is no oops. Bonnie++ consistently Oops on the 45703 write. I checked every function in the Oops call path and all the functions are identical to taking linux 2.4.19 and applying XFS 1.2 except for 2.4.19 isms. I though perhaps some changes to the mm layer in 2.4.19 would be the cause, so I modified my 2.4.18 to match the 2.4.19 implementation + xfs core patch with same results. I am running on Linux 2.4.18 with significant modifications (although most of the memory manager and filesystem layer are the same as 2.4.18). I am running UP on a custom Pentium4 board/processor (well tested before this to be operational). I have run the same bonnie++ benchmark on other filesystems without incident. I was thinking I could take the xfs_write routine from 1.1 and meld it into the 1.2 source codes, but this looks to be very painful, and hey, I want 1.2 anyway ;) Anyone know why I am receiving this Oops? Thanks -steve From owner-linux-xfs@oss.sgi.com Tue Mar 25 10:42:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 10:42:15 -0800 (PST) Received: from ubergeek (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PIfWq9010355 for ; Tue, 25 Mar 2003 10:42:13 -0800 Received: (qmail 4888 invoked by uid 500); 25 Mar 2003 18:38:24 -0000 Subject: Rebuilding the src rpm for xfs 1.2 redhat kernel. From: Austin Gonyou To: xfs-list Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1048617504.30660.58.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 25 Mar 2003 12:38:24 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 188 Lines: 8 I want it to build for Pentium IVs and SMP but I'm building it on a PIII box. What is the best way to accomplish this? Tia. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Mar 25 10:51:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 10:52:04 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PIpJq9010926 for ; Tue, 25 Mar 2003 10:51:59 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HCB003VHJ1IP3@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 12:51:19 -0600 (CST) Date: Tue, 25 Mar 2003 12:51:18 -0600 From: Dan Yocum Subject: Re: KDB-ized RH 2.4.18-X kernel? To: Keith Owens Cc: xfs-list Message-id: <3E80A526.2050301@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 References: <13516.1048553348@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 1019 Lines: 40 Keith, I simply used the kernel-source-2.4.18-18.i386.rpm, copied the configs/kernel-2.4.18-i686-smp.config to .config, 'make menuconfig,' enable kdb, save, exit, 'make dep && make clean && make bzImage'. Looking at the patch list in the kernel-2.4.18-18.src.rpm I see that there's only one kdb patch, called linux-2.4.19-kdb.patch, I assumed that this was a complete patch containing the common as well as the arch dependent kdb patches. Thanks, Dan Keith Owens wrote: > On Mon, 24 Mar 2003 13:47:12 -0600, > Dan Yocum wrote: > >>I compiled the kernel-source...i386.rpm. >> >>Maybe Keith might have some insight into this? It looks like it's a linker >>problem... >> >>Keith? > > > Sorry, my telepathy is not working today. Perhaps if I had some > details of the patches used, the compile steps and the errors then I > might be able to comment. > > > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Tue Mar 25 11:02:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 11:02:34 -0800 (PST) Received: from esds.vss.fsi.com (adsl-66-136-174-212.dsl.stlsmo.swbell.net [66.136.174.212]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PJ2Rq9011620 for ; Tue, 25 Mar 2003 11:02:29 -0800 Received: from mosix.vss.fsi.com (mosix [198.51.27.89]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id NAA07545 for ; Tue, 25 Mar 2003 13:02:21 -0600 (CST) Subject: XFS 1.1 vs. 1.2 From: Matt Schillinger To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 25 Mar 2003 13:02:33 -0600 Message-Id: <1048618954.22460.5.camel@mosix> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschilli@vss.fsi.com Precedence: bulk X-list: linux-xfs Content-Length: 378 Lines: 16 Could someone tell me if it is worthwhile to use 1.2 over 1.1? I have dev systems that are about to become production file servers.. I am wondering if there are major benefits to 1.2 over 1.1.. particularly data integrity benefits, better prevention of log corruption.. performance of course is great also.. Thanks for the help, -- Matt Schillinger mschilli@vss.fsi.com From owner-linux-xfs@oss.sgi.com Tue Mar 25 11:11:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 11:11:39 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PJBZq9012330 for ; Tue, 25 Mar 2003 11:11:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2PJNCkq026296 for ; Tue, 25 Mar 2003 13:23:12 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA82181; Tue, 25 Mar 2003 13:11:29 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2PJBTwX34132525; Tue, 25 Mar 2003 13:11:29 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2PJBTa21835; Tue, 25 Mar 2003 13:11:29 -0600 Subject: Re: Maximum log stripe size From: Steve Lord To: =?ISO-8859-1?Q?St=E9phane?= Doyon Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Organization: Message-Id: <1048619489.4739.416.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 25 Mar 2003 13:11:29 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2PJBZq9012331 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1316 Lines: 37 On Tue, 2003-03-25 at 11:50, Stéphane Doyon wrote: > Hi, > > mkfs.xfs insists that the log stripe unit (-l sunit) must be > smaller than 256K. > > See xfs_mkfs.c around line 1730: > if ((lsunit * blocksize) > 256 * 1024) { > fprintf(stderr, > _("log stripe unit (%d bytes) is too large for kernel to handle (max > 256k)\n"), > (lsunit * blocksize)); > exit(1); > } > > Can anyone please tell me whether this is really necessary? > Our SCSI RAID controllers would much prefer stripes in the order of 1MB. > And the kernel doesn't seem to mind. You really really do not want to make them this big. The reason for the maximum size is the maximum size of iclog buffers - which they are written from. These are capped at 256K it is very hard to guarantee allocations of large chunks of kernel memory. Secondly, the larger the stripe, the more log space is burned in padding. The more log space we use, the faster metadata has to be flushed to disk to allow old log space to be reused. So a large stripe size is probably going to mean more I/O for the same number of filesystem operations. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 25 11:39:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 11:39:26 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PJceq9013166 for ; Tue, 25 Mar 2003 11:39:21 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18xuFq-0001bG-00; Tue, 25 Mar 2003 19:38:38 +0000 Date: Tue, 25 Mar 2003 19:38:38 +0000 From: Christoph Hellwig To: Steven Dake Cc: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 Message-ID: <20030325193838.A6142@infradead.org> References: <3E809EB1.6000904@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E809EB1.6000904@mvista.com>; from sdake@mvista.com on Tue, Mar 25, 2003 at 11:23:45AM -0700 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 472 Lines: 12 On Tue, Mar 25, 2003 at 11:23:45AM -0700, Steven Dake wrote: > XFS Developers, > > Ok here is what I have done: > > I have a tree that already had XFS 1.1 (with a bunch of other stuff) > included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and > everything seems to work fine, except when I run bonnie++ and under load > (Writing intelligently operation), I receive the following Oops: Are you using the preempt patch or other obscure core kernel changes? From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:29:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:29:54 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKTgq9014758 for ; Tue, 25 Mar 2003 12:29:43 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id NAA09881; Tue, 25 Mar 2003 13:41:43 -0700 Message-ID: <3E80B9C9.5090107@mvista.com> Date: Tue, 25 Mar 2003 13:19:21 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> In-Reply-To: <20030325193838.A6142@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 840 Lines: 31 the preempt patch is applied (heavily modified, as I said :) however, I have preemption turned off. The other significant difference is the use of the real time scheduler (which is also turned off). The realtime scheduler was a MontaVista authored scheduler patch prior to O1. Thanks for any help -steve Christoph Hellwig wrote: >On Tue, Mar 25, 2003 at 11:23:45AM -0700, Steven Dake wrote: > > >>XFS Developers, >> >>Ok here is what I have done: >> >>I have a tree that already had XFS 1.1 (with a bunch of other stuff) >>included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and >>everything seems to work fine, except when I run bonnie++ and under load >>(Writing intelligently operation), I receive the following Oops: >> >> > >Are you using the preempt patch or other obscure core kernel changes? > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:30:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:30:50 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKUgq9014872 for ; Tue, 25 Mar 2003 12:30:43 -0800 Received: from mnsu.edu (j3gum-3.MNSU.EDU [134.29.1.30]) by mail.mnsu.edu (8.12.8/8.12.8) with ESMTP id h2PKUZ29017545 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Mar 2003 14:30:36 -0600 Message-ID: <3E80BC6B.3090402@mnsu.edu> Date: Tue, 25 Mar 2003 14:30:35 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS: unknown mount option [usrquota] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Content-Length: 649 Lines: 20 Hello, I've compiled today's current CVS tree for linux-2.4.20-xfs. When I boot this kernel I get: XFS: unknown mount option [usrquota] If I try to mount the file system manually "mount -o remount,usrquota /" I get the same error. It's like usrquota is no longer an option to mount-xfs. It looks like 8 days ago there was a split off of the quota pieces of xfs. Could there perhaps be problems with it? I used the same kernel .config that I used on the 2003-02-24 CVS tree. That kernel booted fine, with usrquota support. I've double check my config and these are both set: CONFIG_QUOTA=y CONFIG_XFS_QUOTA=y Full .config at request. From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:32:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:32:34 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKWUq9015316 for ; Tue, 25 Mar 2003 12:32:31 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18xv5x-0001n7-00; Tue, 25 Mar 2003 20:32:29 +0000 Date: Tue, 25 Mar 2003 20:32:29 +0000 From: Christoph Hellwig To: Steven Dake Cc: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 Message-ID: <20030325203229.A6850@infradead.org> References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E80B9C9.5090107@mvista.com>; from sdake@mvista.com on Tue, Mar 25, 2003 at 01:19:21PM -0700 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 491 Lines: 9 On Tue, Mar 25, 2003 at 01:19:21PM -0700, Steven Dake wrote: > the preempt patch is applied (heavily modified, as I said :) however, I > have preemption turned off. The other significant difference is the use > of the real time scheduler (which is also turned off). The realtime > scheduler was a MontaVista authored scheduler patch prior to O1. Can you please try to reproduce it with a plain 1.2 XFS tree? It's hard to debug some widly different tree we don't even have source to. From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:43:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:43:55 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKhBq9016162 for ; Tue, 25 Mar 2003 12:43:52 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id NAA10078; Tue, 25 Mar 2003 13:55:12 -0700 Message-ID: <3E80BCF2.5090005@mvista.com> Date: Tue, 25 Mar 2003 13:32:50 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> <20030325203229.A6850@infradead.org> In-Reply-To: <20030325203229.A6850@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 1035 Lines: 34 I suspect the issue wouldn't present itself with a vanilla 2.4.18 + xfs1.2 tree as it would have already been caught... And unfortunately I can't apply to a plain vanilla tree, it must go into this particular tree for my company to release it... If you have any suggestions on how I could debug, I'd be willing to try them out. I was really hoping someone had run into this type of problem in the past and could provide some quick pointers on how I could debug. Thanks -steve Christoph Hellwig wrote: >On Tue, Mar 25, 2003 at 01:19:21PM -0700, Steven Dake wrote: > > >>the preempt patch is applied (heavily modified, as I said :) however, I >>have preemption turned off. The other significant difference is the use >>of the real time scheduler (which is also turned off). The realtime >>scheduler was a MontaVista authored scheduler patch prior to O1. >> >> > >Can you please try to reproduce it with a plain 1.2 XFS tree? It's hard >to debug some widly different tree we don't even have source to. > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:55:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:55:16 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKsWq9016679 for ; Tue, 25 Mar 2003 12:55:13 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18xvRF-0001qY-00; Tue, 25 Mar 2003 20:54:29 +0000 Date: Tue, 25 Mar 2003 20:54:29 +0000 From: Christoph Hellwig To: Steven Dake Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 Message-ID: <20030325205429.A7098@infradead.org> References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> <20030325203229.A6850@infradead.org> <3E80BCF2.5090005@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E80BCF2.5090005@mvista.com>; from sdake@mvista.com on Tue, Mar 25, 2003 at 01:32:50PM -0700 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 732 Lines: 16 On Tue, Mar 25, 2003 at 01:32:50PM -0700, Steven Dake wrote: > I suspect the issue wouldn't present itself with a vanilla 2.4.18 + > xfs1.2 tree as it would have already been caught... And unfortunately I > can't apply to a plain vanilla tree, it must go into this particular > tree for my company to release it... > > If you have any suggestions on how I could debug, I'd be willing to try > them out. > > I was really hoping someone had run into this type of problem in the > past and could provide some quick pointers on how I could debug. Maybe get some consultant that knows Linux filesystem code to fix it for your company? I wouldn't expect too much help on a heavily patched tree that's not publically available. From owner-linux-xfs@oss.sgi.com Tue Mar 25 13:13:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 13:13:41 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PLCoq9017234 for ; Tue, 25 Mar 2003 13:13:31 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id OAA10524; Tue, 25 Mar 2003 14:24:50 -0700 Message-ID: <3E80C3E4.20203@mvista.com> Date: Tue, 25 Mar 2003 14:02:28 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> <20030325203229.A6850@infradead.org> <3E80BCF2.5090005@mvista.com> <20030325205429.A7098@infradead.org> In-Reply-To: <20030325205429.A7098@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 968 Lines: 33 I understand filesystem code quite well, and the particular problem (if you would have read the oops) is in the memory management layer. But thanks for your advice. -steve Christoph Hellwig wrote: >On Tue, Mar 25, 2003 at 01:32:50PM -0700, Steven Dake wrote: > > >>I suspect the issue wouldn't present itself with a vanilla 2.4.18 + >>xfs1.2 tree as it would have already been caught... And unfortunately I >>can't apply to a plain vanilla tree, it must go into this particular >>tree for my company to release it... >> >>If you have any suggestions on how I could debug, I'd be willing to try >>them out. >> >>I was really hoping someone had run into this type of problem in the >>past and could provide some quick pointers on how I could debug. >> >> > >Maybe get some consultant that knows Linux filesystem code to fix it for >your company? I wouldn't expect too much help on a heavily patched >tree that's not publically available. > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 14:22:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 14:22:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PMMOq9018668 for ; Tue, 25 Mar 2003 14:22:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PMMOUA018665 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 14:22:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PMMMqB018651 for ; Tue, 25 Mar 2003 14:22:23 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PLx2WP018430; Tue, 25 Mar 2003 13:59:02 -0800 Date: Tue, 25 Mar 2003 13:59:02 -0800 Message-Id: <200303252159.h2PLx2WP018430@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 634 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-25 13:59 ------- Created an attachment (id=71) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=71&action=view) result of cpu, ps and some of bta Created by this sequence: normal boot on initlevel3, log as root, than: updatedb ; reboot After updatedb (approx 4 min) system begins to reboot, try to umout disks, (approx 2-3min) , than hangs. Than I press 'pause' and enter kdb. Results in attach. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 15:24:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 15:25:05 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PNODq9003839 for ; Tue, 25 Mar 2003 15:24:54 -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 h2PNO7nH001882 for ; Tue, 25 Mar 2003 15:24:08 -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 KAA28685; Wed, 26 Mar 2003 10:22:51 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA44918; Wed, 26 Mar 2003 10:22:50 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2PNJjV4001092; Wed, 26 Mar 2003 10:19:45 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2PNJiHb001090; Wed, 26 Mar 2003 10:19:44 +1100 Date: Wed, 26 Mar 2003 10:19:44 +1100 From: Nathan Scott To: "Jeffrey E. Hundstad" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS: unknown mount option [usrquota] Message-ID: <20030325231944.GC789@frodo> References: <3E80BC6B.3090402@mnsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E80BC6B.3090402@mnsu.edu> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1388 Lines: 37 On Tue, Mar 25, 2003 at 02:30:35PM -0600, Jeffrey E. Hundstad wrote: > Hello, > > I've compiled today's current CVS tree for linux-2.4.20-xfs. When I > boot this kernel I get: > XFS: unknown mount option [usrquota] > If I try to mount the file system manually "mount -o remount,usrquota /" > I get the same error. It's like usrquota is no longer an option to > mount-xfs. It looks like 8 days ago there was a split off of the quota > pieces of xfs. Could there perhaps be problems with it? Firstly, there is an off chance you never had quota working... previously even if XFS was built without quota support, it would still parse the quota options and silently drop them on the ground. Probably not the case, but could be. > I used the same kernel .config that I used on the 2003-02-24 CVS tree. > That kernel booted fine, with usrquota support. > > I've double check my config and these are both set: > CONFIG_QUOTA=y > CONFIG_XFS_QUOTA=y > > Full .config at request. Do you have a log of your build?, that would be more interesting. In particular, has the build descended into fs/xfs/quota (and are there a bunch of .o files there?). And if so is xfs_quota.o being linked into your xfs.o? I'm suspecting a build problem at your end at the moment, cos this works for me and my nightly QA runs do some quota tests (and all those are working fine). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:00:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:01:06 -0800 (PST) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q00rq9004635 for ; Tue, 25 Mar 2003 16:00:55 -0800 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id TAA32084 for ; Tue, 25 Mar 2003 19:00:46 -0500 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.12.7/8.12.7/Debian 8.9.3-21) with ESMTP id h2Q00kYq016736 for ; Tue, 25 Mar 2003 19:00:46 -0500 Subject: XFS, extended attrs and UML? From: Derek Glidden To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Mar 2003 19:00:46 -0500 Message-Id: <1048636846.13786.113.camel@two.nks.net> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs Content-Length: 1696 Lines: 44 Does anyone know of a specific problem with XFS, extended attributes and UML (user-mode linux)? We've got a 2.4.19 kernel with XFS 1.2 and UML 2.4.19-51 patches applied that, when we try to run "attr" to add/set extended attributes to a file under the UML, returns: attr_set: Function not implemented if we 'strace' the 'attr' action, we see: SYS_227(0xbffffea1, 0xbffffbb4, 0xbffffe98, 0x8, 0) = -1 ENOSYS (Function not implemented) The exact same kernel source, compiled and running "native" works as-expected. Any ideas? Is this a known problem? Is there anyone else out there crazy enough to be using XFS under User-mode Linux? :) (And yes, we know that running a journaling filesystem under UML isn't entirely the best idea, but we have an application that wants XFS extended attributes that we want to run under UML if at all possible.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/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 Tue Mar 25 16:27:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:27:24 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0Qcq9008380 for ; Tue, 25 Mar 2003 16:27:18 -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 h2Q0QVuY013332 for ; Tue, 25 Mar 2003 16:26:32 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29472; Wed, 26 Mar 2003 11:25:13 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id F0078300087; Wed, 26 Mar 2003 11:25:12 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 778088F; Wed, 26 Mar 2003 11:25:12 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dan Yocum Cc: xfs-list , sandeen@sgi.com Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "Tue, 25 Mar 2003 12:51:18 MDT." <3E80A526.2050301@fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 2003 11:25:06 +1100 Message-ID: <28714.1048638306@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 878 Lines: 18 On Tue, 25 Mar 2003 12:51:18 -0600, Dan Yocum wrote: >I simply used the kernel-source-2.4.18-18.i386.rpm, copied the >configs/kernel-2.4.18-i686-smp.config to .config, 'make menuconfig,' enable >kdb, save, exit, 'make dep && make clean && make bzImage'. > >Looking at the patch list in the kernel-2.4.18-18.src.rpm I see that there's >only one kdb patch, called linux-2.4.19-kdb.patch, I assumed that this was a >complete patch containing the common as well as the arch dependent kdb patches. linux-2.4.19-kdb.patch in kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm is incomplete. At the very least, it is missing the patch to the top level Makefile. So the kdb directory is never built and all the global variables and functions are missing. Eric, do you want to rebuild kernel-source-2.4.18 src.rpm with a working kdb patch or wait for the next XFS release? From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:44:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:44:20 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0iGq9008960 for ; Tue, 25 Mar 2003 16:44:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q0i8uY014565 for ; Tue, 25 Mar 2003 16:44:11 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA40089; Tue, 25 Mar 2003 18:44:07 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q0i7wX32108681; Tue, 25 Mar 2003 18:44:07 -0600 (CST) Subject: Re: XFS, extended attrs and UML? From: Rusell Cattelan To: Derek Glidden Cc: linux-xfs@oss.sgi.com In-Reply-To: <1048636846.13786.113.camel@two.nks.net> References: <1048636846.13786.113.camel@two.nks.net> Content-Type: text/plain Organization: Message-Id: <1048639529.11118.40.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 25 Mar 2003 18:45:29 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1644 Lines: 43 This is because uml doesn't have the attr syscalls mapped kernel/sys_call_table.c [ __NR_setxattr ] = sys_ni_syscall, [ __NR_lsetxattr ] = sys_ni_syscall, [ __NR_fsetxattr ] = sys_ni_syscall, [ __NR_getxattr ] = sys_ni_syscall, [ __NR_lgetxattr ] = sys_ni_syscall, [ __NR_fgetxattr ] = sys_ni_syscall, [ __NR_listxattr ] = sys_ni_syscall, [ __NR_llistxattr ] = sys_ni_syscall, [ __NR_flistxattr ] = sys_ni_syscall, [ __NR_removexattr ] = sys_ni_syscall, [ __NR_lremovexattr ] = sys_ni_syscall, [ __NR_fremovexattr ] = sys_ni_syscall, You'll need to correct this table before it will work. On Tue, 2003-03-25 at 18:00, Derek Glidden wrote: > Does anyone know of a specific problem with XFS, extended attributes and > UML (user-mode linux)? > > We've got a 2.4.19 kernel with XFS 1.2 and UML 2.4.19-51 patches applied > that, when we try to run "attr" to add/set extended attributes to a file > under the UML, returns: > > attr_set: Function not implemented > > if we 'strace' the 'attr' action, we see: > > SYS_227(0xbffffea1, 0xbffffbb4, 0xbffffe98, 0x8, 0) = -1 ENOSYS > (Function not implemented) > > The exact same kernel source, compiled and running "native" works > as-expected. > > Any ideas? Is this a known problem? Is there anyone else out there > crazy enough to be using XFS under User-mode Linux? :) > > (And yes, we know that running a journaling filesystem under UML isn't > entirely the best idea, but we have an application that wants XFS > extended attributes that we want to run under UML if at all possible.) From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:49:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:49:39 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0naq9009407 for ; Tue, 25 Mar 2003 16:49:36 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q0nUuY014914 for ; Tue, 25 Mar 2003 16:49:30 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA55224; Tue, 25 Mar 2003 18:49:29 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q0nTwX35259244; Tue, 25 Mar 2003 18:49:29 -0600 (CST) Subject: Re: Need some help with cause of Oops in XFS 1.2 From: Rusell Cattelan To: Steven Dake Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E809EB1.6000904@mvista.com> References: <3E809EB1.6000904@mvista.com> Content-Type: text/plain Organization: Message-Id: <1048639851.11129.44.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 25 Mar 2003 18:50:51 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 688 Lines: 21 On Tue, 2003-03-25 at 12:23, Steven Dake wrote: > XFS Developers, > > Ok here is what I have done: > > I have a tree that already had XFS 1.1 (with a bunch of other stuff) > included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and > everything seems to work fine, except when I run bonnie++ and under load > (Writing intelligently operation), I receive the following Oops: > If possible get kbd into your tree. Then open a bug and attach what ever backtraces you can get. bta is a good place to start. That might shed some light on the situation, but without wading through the lock changes you might have in your tree this problem may be hard to track down. -Russell From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:51:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:51:54 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0ppq9009843 for ; Tue, 25 Mar 2003 16:51:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q0pjuY015108 for ; Tue, 25 Mar 2003 16:51:45 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA13688; Tue, 25 Mar 2003 18:51:45 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q0piwX35372556; Tue, 25 Mar 2003 18:51:44 -0600 (CST) Subject: Re: KDB-ized RH 2.4.18-X kernel? From: Rusell Cattelan To: Keith Owens Cc: Dan Yocum , xfs-list , sandeen@sgi.com In-Reply-To: <28714.1048638306@kao2.melbourne.sgi.com> References: <28714.1048638306@kao2.melbourne.sgi.com> Content-Type: text/plain Organization: Message-Id: <1048639986.11129.47.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 25 Mar 2003 18:53:06 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1148 Lines: 26 On Tue, 2003-03-25 at 18:25, Keith Owens wrote: > On Tue, 25 Mar 2003 12:51:18 -0600, > Dan Yocum wrote: > >I simply used the kernel-source-2.4.18-18.i386.rpm, copied the > >configs/kernel-2.4.18-i686-smp.config to .config, 'make menuconfig,' enable > >kdb, save, exit, 'make dep && make clean && make bzImage'. > > > >Looking at the patch list in the kernel-2.4.18-18.src.rpm I see that there's > >only one kdb patch, called linux-2.4.19-kdb.patch, I assumed that this was a > >complete patch containing the common as well as the arch dependent kdb patches. > > linux-2.4.19-kdb.patch in kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm is > incomplete. At the very least, it is missing the patch to the top > level Makefile. So the kdb directory is never built and all the global > variables and functions are missing. > > Eric, do you want to rebuild kernel-source-2.4.18 src.rpm with a > working kdb patch or wait for the next XFS release? If a working kdb patch is available for the current release I'll rebuild the rpms and toss them on oss. After all I can build the whole lot 4 or 5 hours now (down from 12) :-) -Russell From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:01:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:01:12 -0800 (PST) Received: from hotmail.com (bay1-f70.bay1.hotmail.com [65.54.245.70]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q11Aq9010345 for ; Tue, 25 Mar 2003 17:01:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Mar 2003 17:01:04 -0800 Received: from 66.167.1.42 by by1fd.bay1.hotmail.msn.com with HTTP; Wed, 26 Mar 2003 01:01:04 GMT X-Originating-IP: [66.167.1.42] X-Originating-Email: [mwhang77@hotmail.com] From: "Michael Whang" To: linux-xfs@oss.sgi.com Subject: xfs installer Date: Tue, 25 Mar 2003 17:01:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2003 01:01:04.0843 (UTC) FILETIME=[2D48E9B0:01C2F333] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mwhang77@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 10 Is there anyone that has created an XFS installer with a later kernel? Mike _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:22:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:22:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2Q1MQq9011077 for ; Tue, 25 Mar 2003 17:22:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2Q1MQfl011075 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 17:22:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2Q1MNqB011062 for ; Tue, 25 Mar 2003 17:22:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2Q0gfuN008951; Tue, 25 Mar 2003 16:42:41 -0800 Date: Tue, 25 Mar 2003 16:42:41 -0800 Message-Id: <200303260042.h2Q0gfuN008951@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 641 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From kaos@sgi.com 2003-03-25 16:42 ------- Kernel bug. UP systems call task_set_cpu() but never call task_release_cpu() so all tasks appear to own the cpu, which confuses debuggers. This problem has been bounced to linux-kernel. I doubt that the missing task_release_cpu() has anything to do with your umount hang. Unfortunately it does stop kdb backtrace working on UP systems. I expect to get a fix from l-k in the next day or so. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:24:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:24:59 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q1OFq9011489 for ; Tue, 25 Mar 2003 17:24:56 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id SAA14226; Tue, 25 Mar 2003 18:35:47 -0700 Message-ID: <3E80FEB5.90801@mvista.com> Date: Tue, 25 Mar 2003 18:13:25 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rusell Cattelan CC: linux-xfs@oss.sgi.com Subject: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> In-Reply-To: <1048639851.11129.44.camel@rose.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 4631 Lines: 156 Russell, Thanks for the hints but I believe I found a bug in XFS 1.2, and perhaps you could verify it since I'm not very familiar with the XFS code. both linvfs_write_full_page and write_full_page will attempt to unlock_page in some circumstances. The page is previously locked in the function generic_file_write_nolock. This generic_file_write_nolock function will unlock the page after it is done using it. Unlocking a page twice will result in an Oops, so either the mm layer (generic_file_write_nolock) shouldn't be unlocking the page, or the xfs code in linvfs_write_full_page and write_full_page shouldn't unlock the page a second time. The unlock in the xfs code is suspect, since it only unlocks on certain conditions (which will result in an Oops) The function linvfs_write_full_page unlocks a page in the case of an error conditon. I have not been able to hit this error condition, but if it occurs, an Oops will most certainly occur. STATIC int linvfs_write_full_page( struct page *page) { int flagset = 0; int error; int need_trans; int nr_delalloc, nr_unmapped; if (count_page_state(page, &nr_delalloc, &nr_unmapped)) { need_trans = nr_delalloc + nr_unmapped; } else { need_trans = 1; } if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) goto out_fail; if (need_trans) { current->flags |= PF_NOIO; flagset = 1; } error = write_full_page(page, nr_delalloc); if (flagset) current->flags &= ~PF_NOIO; return error; out_fail: SetPageDirty(page); unlock_page(page); return 0; } The function write_full_page will unlock the page if delalloc_convert returns a negative value. I don't understand why delalloc_convert returns a negative value, and if the page should be unlocked, but it seems that it shouldn't. Could you give me some background on why the page is unlocked at this point? If I comment out this unlock, bonnie++ does not crash and the filesystem seems still stable, but I'd like to understand _why_ this condition is occuring and if the unlock_page is really needed, or if letting the mm handle it is appropriate. STATIC int write_full_page( struct page *page, int delalloc) { struct inode *inode = (struct inode*)page->mapping->host; unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; int ret; /* Are we off the end of the file ? */ if (page->index >= end_index) { unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); if ((page->index >= end_index+1) || !offset) { ret = -EIO; goto out; } } if (!page_has_buffers(page)) { create_empty_buffers(page, inode->i_dev, 1 << inode->i_blkbits); } ret = delalloc_convert(inode, page, 1, delalloc == 0); out: if (ret < 0) { /* * If it's delalloc and we have nowhere to put it, * throw it away. */ if (delalloc) block_flushpage(page, 0); ClearPageUptodate(page); // unlock_page(page); } return ret; } It looks like the real problem is that no error return is processed to not unlock the buffer if an error is returned by linvfs_write_full_page by the function generic_file_write_nolock in the call chain but the return values are used to indicate state in some of the calls and cannot be used as error returns... The call stack that gets to the point where the page is unlocked is: generic_file_write_nolock() generic_commit_write() __block_commit_write() balance_dirty() write_some_buffers() write_buffer_delay() linvfs_write_full_page() write_full_page() After that the finish of the call generic_file_write_nolock will also unlock that same page causing an oops. Thanks! -steve Rusell Cattelan wrote: >On Tue, 2003-03-25 at 12:23, Steven Dake wrote: > > >>XFS Developers, >> >>Ok here is what I have done: >> >>I have a tree that already had XFS 1.1 (with a bunch of other stuff) >>included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and >>everything seems to work fine, except when I run bonnie++ and under load >>(Writing intelligently operation), I receive the following Oops: >> >> >> >If possible get kbd into your tree. >Then open a bug and attach what ever backtraces you can get. >bta is a good place to start. > >That might shed some light on the situation, but without wading through >the lock changes you might have in your tree this problem may be hard >to track down. > >-Russell > > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:55:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:55:49 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q1srq9012074 for ; Tue, 25 Mar 2003 17:55:38 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q26Vkq004361 for ; Tue, 25 Mar 2003 20:06:31 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA60031; Tue, 25 Mar 2003 19:54:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q1slCJ6200481; Tue, 25 Mar 2003 19:54:47 -0600 (CST) Date: Tue, 25 Mar 2003 19:53:31 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Steven Dake cc: Rusell Cattelan , Subject: Re: XFS 1.2 bug? In-Reply-To: <3E80FEB5.90801@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 895 Lines: 21 On Tue, 25 Mar 2003, Steven Dake wrote: > The function write_full_page will unlock the page if delalloc_convert > returns a negative value. I don't understand why delalloc_convert > returns a negative value, and if the page should be unlocked, but it > seems that it shouldn't. Could you give me some background on why the > page is unlocked at this point? If I comment out this unlock, bonnie++ delalloc_convert can fail on some error, and we have to do something with the buffer at that point. This case was put in because if we ignored the error, we'd write out a buffer with block 0 (delalloc) and clobber the superblock. Perhaps locking has changed such that the unlock_page is no longer correct, I'd have to look more closely. Are you hitting this case? It would be very helpful if you could run this on a "stock" xfs 1.2 kernel to see if you still hit this problem. -Eric From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:58:21 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q1wFq9012508 for ; Tue, 25 Mar 2003 17:58:16 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id TAA14731; Tue, 25 Mar 2003 19:10:19 -0700 Message-ID: <3E8106CD.2050101@mvista.com> Date: Tue, 25 Mar 2003 18:47:57 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Dake CC: Rusell Cattelan , linux-xfs@oss.sgi.com Subject: update: Re: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> <3E80FEB5.90801@mvista.com> In-Reply-To: <3E80FEB5.90801@mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 6056 Lines: 204 Russell, I had a deeper look at why write_full_page was failing... In the code: STATIC int write_full_page( struct page *page, int delalloc) { struct inode *inode = (struct inode*)page->mapping->host; unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; int ret; /* Are we off the end of the file ? */ if (page->index >= end_index) { unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); if ((page->index >= end_index+1) || !offset) { ret = -EIO; printk ("Off the end of the file %d %d %d %d\n", page->index, end_index, offset, inode- >i_size); goto out; } } I added the above printk and got the output Mar 24 22:49:47 192 kernel: Off the end of the file 91406 91406 0 374398976 offset is zero, because 374398976 & ((1 << 12) -1) is zero. This operation looks like it should proceed since the size is ok and the page index and end index are within ranges. Why should we error if the size & PAGE_CACHE_SIZE-1 is zero? Any help appreciated on the two issues (the offset issue and the extra unlock_pages) Thanks! -steve Steven Dake wrote: > Russell, > > Thanks for the hints but I believe I found a bug in XFS 1.2, and > perhaps you could verify it since I'm not very familiar with the XFS > code. > > both linvfs_write_full_page and write_full_page will attempt to > unlock_page in some circumstances. The page is previously locked in > the function generic_file_write_nolock. This > generic_file_write_nolock function will unlock the page after it is > done using it. Unlocking a page twice will result in an Oops, so > either the mm layer (generic_file_write_nolock) shouldn't be unlocking > the page, or the xfs code in linvfs_write_full_page and > write_full_page shouldn't unlock the page a second time. The unlock > in the xfs code is suspect, since it only unlocks on certain > conditions (which will result in an Oops) > > The function linvfs_write_full_page unlocks a page in the case of an > error conditon. I have not been able to hit this error condition, but > if it occurs, an Oops will most certainly occur. > > STATIC int > linvfs_write_full_page( > struct page *page) > { > int flagset = 0; > int error; > int need_trans; > int nr_delalloc, nr_unmapped; > > if (count_page_state(page, &nr_delalloc, &nr_unmapped)) { > need_trans = nr_delalloc + nr_unmapped; > } else { > need_trans = 1; > } > > if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) > goto out_fail; > > if (need_trans) { > current->flags |= PF_NOIO; > flagset = 1; > } > > error = write_full_page(page, nr_delalloc); > > if (flagset) > current->flags &= ~PF_NOIO; > return error; > > out_fail: > SetPageDirty(page); > unlock_page(page); > return 0; > } > > The function write_full_page will unlock the page if delalloc_convert > returns a negative value. I don't understand why delalloc_convert > returns a negative value, and if the page should be unlocked, but it > seems that it shouldn't. Could you give me some background on why the > page is unlocked at this point? If I comment out this unlock, > bonnie++ does not crash and the filesystem seems still stable, but I'd > like to understand _why_ this condition is occuring and if the > unlock_page is really needed, or if letting the mm handle it is > appropriate. > > STATIC int > write_full_page( > struct page *page, > int delalloc) > { > struct inode *inode = (struct inode*)page->mapping->host; > unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; > int ret; > > /* Are we off the end of the file ? */ > if (page->index >= end_index) { > unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); > if ((page->index >= end_index+1) || !offset) { > ret = -EIO; > goto out; > } > } > > if (!page_has_buffers(page)) { > create_empty_buffers(page, inode->i_dev, 1 << inode->i_blkbits); > } > > ret = delalloc_convert(inode, page, 1, delalloc == 0); > > out: > if (ret < 0) { > /* > * If it's delalloc and we have nowhere to put it, > * throw it away. > */ > if (delalloc) > block_flushpage(page, 0); > ClearPageUptodate(page); > // unlock_page(page); > } > > return ret; > } > > It looks like the real problem is that no error return is processed to > not unlock the buffer if an error is returned by > linvfs_write_full_page by the function generic_file_write_nolock in > the call chain but the return values are used to indicate state in > some of the calls and cannot be used as error returns... > > The call stack that gets to the point where the page is unlocked is: > generic_file_write_nolock() > generic_commit_write() > __block_commit_write() > balance_dirty() > write_some_buffers() > write_buffer_delay() > linvfs_write_full_page() > write_full_page() > > After that the finish of the call generic_file_write_nolock will also > unlock that same page causing an oops. > > Thanks! > -steve > > Rusell Cattelan wrote: > >> On Tue, 2003-03-25 at 12:23, Steven Dake wrote: >> >> >>> XFS Developers, >>> >>> Ok here is what I have done: >>> >>> I have a tree that already had XFS 1.1 (with a bunch of other stuff) >>> included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and >>> everything seems to work fine, except when I run bonnie++ and under >>> load (Writing intelligently operation), I receive the following Oops: >>> >>> >> >> If possible get kbd into your tree. >> Then open a bug and attach what ever backtraces you can get. >> bta is a good place to start. >> >> That might shed some light on the situation, but without wading through >> the lock changes you might have in your tree this problem may be hard >> to track down. >> >> -Russell >> >> >> >> >> >> > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 20:58:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 20:58:18 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q4w2q9014134 for ; Tue, 25 Mar 2003 20:58:04 -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 h2Q1jguY019452 for ; Tue, 25 Mar 2003 17:45:44 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00313; Wed, 26 Mar 2003 12:44:26 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 1C8EA300087; Wed, 26 Mar 2003 12:44:24 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 98D118F; Wed, 26 Mar 2003 12:44:24 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Rusell Cattelan Cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "25 Mar 2003 18:53:06 MDT." <1048639986.11129.47.camel@rose.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 2003 12:44:18 +1100 Message-ID: <29637.1048643058@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1658 Lines: 45 On 25 Mar 2003 18:53:06 -0600, Rusell Cattelan wrote: >On Tue, 2003-03-25 at 18:25, Keith Owens wrote: >> linux-2.4.19-kdb.patch in kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm is >> incomplete. At the very least, it is missing the patch to the top >> level Makefile. So the kdb directory is never built and all the global >> variables and functions are missing. > >If a working kdb patch is available for the current release I'll rebuild >the rpms and toss them on oss. >After all I can build the whole lot 4 or 5 hours now (down from 12) :-) The missing patch to Makefile is below, apply after linux-2.4.19-kdb.patch. However after applying that and compiling with CONFIG_KALLSYMS=y, CONFIG_KDB=y, CONFIG_KDB_MODULES=y there are build errors in kdb/modules/kdbm_pg.c and kdb/kdbmain.c. The kdb code in the XFS tree needs more work to make it fit all the changes that RH have made to the kernel. Unfortunately I do not have time to work on this at the moment, kdb for 2.4.{19,20}-ia64 is taking all my time. Back to the XFS team. --- linux1/Makefile Wed Mar 26 11:25:48 2003 +++ linux2/Makefile Wed Mar 26 12:24:11 2003 @@ -139,6 +139,11 @@ LIBS =$(TOPDIR)/lib/lib.a SUBDIRS =kernel drivers mm fs net ipc lib abi crypto +ifeq ($(CONFIG_KDB),y) +CORE_FILES += kdb/kdb.o +SUBDIRS += kdb +endif + DRIVERS-n := DRIVERS-y := DRIVERS-m := @@ -254,6 +259,7 @@ scripts/lxdialog/*.o scripts/lxdialog/lxdialog \ .menuconfig.log \ include/asm \ + kdb/gen-kdb_cmds.c \ .hdepend scripts/mkdep scripts/split-include scripts/docproc \ $(TOPDIR)/include/linux/modversions.h \ scripts/mkconfigs kernel/configs.c kernel/configs.o \ From owner-linux-xfs@oss.sgi.com Tue Mar 25 21:26:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 21:26:30 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q5Pcq9014741 for ; Tue, 25 Mar 2003 21:26:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q5PVuY001999 for ; Tue, 25 Mar 2003 21:25:32 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2Q5OE7L3608010 for ; Wed, 26 Mar 2003 16:24:14 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2Q5OEr73609823 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 16:24:14 +1100 (EST) Date: Wed, 26 Mar 2003 16:24:14 +1100 (EST) From: Nathan Scott Message-Id: <200303260524.h2Q5OEr73609823@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs configure script X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 389 Lines: 14 Fix readline use in xfsprogs configure script such that distributions which do not contain a correctly-linked libreadline will still work. Date: Tue Mar 25 21:23:33 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:142672a cmd/xfsprogs/configure.in - 1.20 From owner-linux-xfs@oss.sgi.com Tue Mar 25 23:03:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 23:03:22 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q73Aq9016042 for ; Tue, 25 Mar 2003 23:03:11 -0800 Received: from thebarn.com (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.8/8.12.6) with ESMTP id h2Q738xk090660; Wed, 26 Mar 2003 01:03:08 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3E8151E4.809@thebarn.com> Date: Wed, 26 Mar 2003 01:08:20 -0600 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Dake CC: linux-xfs@oss.sgi.com Subject: Re: update: Re: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> <3E80FEB5.90801@mvista.com> <3E8106CD.2050101@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 6854 Lines: 225 Ok I've looked over the code. write_full_page is modeled after block_write_full_page. The past the end of file is the same check used in that function. Basically the offset var used to see if size of the file is part way into a page so if the size of the file lands on a page boundry offset will be 0. As far as the unlock_page in the error case ... again based on block_write_full_page it seems correct to unlock the page in case of an error. do you have the backtrace of crash again? I'm wondering who called write_full_page in this case. Steven Dake wrote: > Russell, > > I had a deeper look at why write_full_page was failing... In the code: > STATIC int > write_full_page( > struct page *page, > int delalloc) > { > struct inode *inode = (struct inode*)page->mapping->host; > unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; > int ret; > > /* Are we off the end of the file ? */ > if (page->index >= end_index) { > unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); > if ((page->index >= end_index+1) || !offset) { > ret = -EIO; > printk ("Off the end of the file %d %d %d %d\n", > page->index, end_index, offset, inode- > >i_size); > goto out; > } > } > > I added the above printk and got the output > Mar 24 22:49:47 192 kernel: Off the end of the file 91406 91406 0 > 374398976 > > offset is zero, because 374398976 & ((1 << 12) -1) is zero. > This operation looks like it should proceed since the size is ok and > the page index and end index are within ranges. Why should we error > if the size & PAGE_CACHE_SIZE-1 is zero? > > Any help appreciated on the two issues > (the offset issue and the extra unlock_pages) > > Thanks! > -steve > > Steven Dake wrote: > >> Russell, >> >> Thanks for the hints but I believe I found a bug in XFS 1.2, and >> perhaps you could verify it since I'm not very familiar with the XFS >> code. >> >> both linvfs_write_full_page and write_full_page will attempt to >> unlock_page in some circumstances. The page is previously locked in >> the function generic_file_write_nolock. This >> generic_file_write_nolock function will unlock the page after it is >> done using it. Unlocking a page twice will result in an Oops, so >> either the mm layer (generic_file_write_nolock) shouldn't be >> unlocking the page, or the xfs code in linvfs_write_full_page and >> write_full_page shouldn't unlock the page a second time. The unlock >> in the xfs code is suspect, since it only unlocks on certain >> conditions (which will result in an Oops) >> >> The function linvfs_write_full_page unlocks a page in the case of an >> error conditon. I have not been able to hit this error condition, >> but if it occurs, an Oops will most certainly occur. >> >> STATIC int >> linvfs_write_full_page( >> struct page *page) >> { >> int flagset = 0; >> int error; >> int need_trans; >> int nr_delalloc, nr_unmapped; >> >> if (count_page_state(page, &nr_delalloc, &nr_unmapped)) { >> need_trans = nr_delalloc + nr_unmapped; >> } else { >> need_trans = 1; >> } >> >> if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) >> goto out_fail; >> >> if (need_trans) { >> current->flags |= PF_NOIO; >> flagset = 1; >> } >> >> error = write_full_page(page, nr_delalloc); >> >> if (flagset) >> current->flags &= ~PF_NOIO; >> return error; >> >> out_fail: >> SetPageDirty(page); >> unlock_page(page); >> return 0; >> } >> >> The function write_full_page will unlock the page if delalloc_convert >> returns a negative value. I don't understand why delalloc_convert >> returns a negative value, and if the page should be unlocked, but it >> seems that it shouldn't. Could you give me some background on why >> the page is unlocked at this point? If I comment out this unlock, >> bonnie++ does not crash and the filesystem seems still stable, but >> I'd like to understand _why_ this condition is occuring and if the >> unlock_page is really needed, or if letting the mm handle it is >> appropriate. >> >> STATIC int >> write_full_page( >> struct page *page, >> int delalloc) >> { >> struct inode *inode = (struct inode*)page->mapping->host; >> unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; >> int ret; >> >> /* Are we off the end of the file ? */ >> if (page->index >= end_index) { >> unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); >> if ((page->index >= end_index+1) || !offset) { >> ret = -EIO; >> goto out; >> } >> } >> >> if (!page_has_buffers(page)) { >> create_empty_buffers(page, inode->i_dev, 1 << inode->i_blkbits); >> } >> >> ret = delalloc_convert(inode, page, 1, delalloc == 0); >> >> out: >> if (ret < 0) { >> /* >> * If it's delalloc and we have nowhere to put it, >> * throw it away. >> */ >> if (delalloc) >> block_flushpage(page, 0); >> ClearPageUptodate(page); >> // unlock_page(page); >> } >> >> return ret; >> } >> >> It looks like the real problem is that no error return is processed >> to not unlock the buffer if an error is returned by >> linvfs_write_full_page by the function generic_file_write_nolock in >> the call chain but the return values are used to indicate state in >> some of the calls and cannot be used as error returns... >> >> The call stack that gets to the point where the page is unlocked is: >> generic_file_write_nolock() >> generic_commit_write() >> __block_commit_write() >> balance_dirty() >> write_some_buffers() >> write_buffer_delay() >> linvfs_write_full_page() >> write_full_page() >> >> After that the finish of the call generic_file_write_nolock will also >> unlock that same page causing an oops. >> >> Thanks! >> -steve >> >> Rusell Cattelan wrote: >> >>> On Tue, 2003-03-25 at 12:23, Steven Dake wrote: >>> >>> >>>> XFS Developers, >>>> >>>> Ok here is what I have done: >>>> >>>> I have a tree that already had XFS 1.1 (with a bunch of other >>>> stuff) included. I hand applied the XFS 1.2 on top of XFS 1.1 >>>> patch and everything seems to work fine, except when I run bonnie++ >>>> and under load (Writing intelligently operation), I receive the >>>> following Oops: >>>> >>>> >>> >>> >>> If possible get kbd into your tree. >>> Then open a bug and attach what ever backtraces you can get. >>> bta is a good place to start. >>> >>> That might shed some light on the situation, but without wading through >>> the lock changes you might have in your tree this problem may be >>> hard to track down. >>> >>> -Russell >>> >>> >>> >>> >>> >>> >> >> >> >> From owner-linux-xfs@oss.sgi.com Tue Mar 25 23:12:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 23:12:16 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q7BAq9016539 for ; Tue, 25 Mar 2003 23:11:50 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 86DDCAC4A; Wed, 26 Mar 2003 07:34:25 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id D1D46190C3; Wed, 26 Mar 2003 07:34:24 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 64F31308828; Wed, 26 Mar 2003 07:34:12 +0100 (CET) Message-ID: <3E8149E4.8A511858@ch.sauter-bc.com> Date: Wed, 26 Mar 2003 07:34:12 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.24-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Matt Schillinger Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 vs. 1.2 References: <1048618954.22460.5.camel@mosix> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 21 Matt Schillinger schrieb: > > Could someone tell me if it is worthwhile to use 1.2 over 1.1? Short answer: yes! Simon > > I have dev systems that are about to become production file servers.. I > am wondering if there are major benefits to 1.2 over 1.1.. > > particularly data integrity benefits, better prevention of log > corruption.. performance of course is great also.. > > Thanks for the help, > -- > Matt Schillinger > > mschilli@vss.fsi.com From owner-linux-xfs@oss.sgi.com Wed Mar 26 04:38:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 04:38:11 -0800 (PST) Received: from redix.it (host49-169.pool8172.interbusiness.it [81.72.169.49]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QCbHq9027965 for ; Wed, 26 Mar 2003 04:37:59 -0800 Received: (qmail 4167 invoked by uid 507); 26 Mar 2003 12:37:13 -0000 Received: from roberto@redix.it by mail.redix.it by uid 504 with qmail-scanner-1.14 (clamscan: 0.24. Clear:. Processed in 1.458866 secs); 26 Mar 2003 12:37:13 -0000 Received: from localhost (HELO redix.it) (127.0.0.1) by 0 with SMTP; 26 Mar 2003 12:37:11 -0000 Received: from 212.239.118.101 (proxying for unknown) (SquirrelMail authenticated user roberto) by mail.redix.it with HTTP; Wed, 26 Mar 2003 13:37:11 +0100 (CET) Message-ID: <2545.212.239.118.101.1048682231.squirrel@mail.redix.it> Date: Wed, 26 Mar 2003 13:37:11 +0100 (CET) Subject: Question about upgrade to XFS 1.2 From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roberto@redix.it Precedence: bulk X-list: linux-xfs Content-Length: 448 Lines: 16 Date: 26 mar 2003 I'm running kernel 2.4.18 + XFS1.1+ LVM 1.3 on my PC. I'd like to know: 1) can I upgrade to kernel 2.4.19 + XFS 1.2 without reformatting and recreate new File System with XFS 1.2? any drawbacks using the current filesystem created with XFS1.1? It is best reformatting? 2) what is the suggested (well tested) version of LVM with XFS 1.2? LVM 1.7 or LVM2? anyone is already using these combination? thanks in advance, Roberto From owner-linux-xfs@oss.sgi.com Wed Mar 26 04:52:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 04:52:52 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QCq4q9028825 for ; Wed, 26 Mar 2003 04:52:44 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QD3ikq013692 for ; Wed, 26 Mar 2003 07:03:44 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA25779; Wed, 26 Mar 2003 06:51:58 -0600 (CST) Received: from laptop.americas.sgi.com (cf-vpn-sw-corp-64-53.corp.sgi.com [134.15.64.53]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QCpvwX35441412; Wed, 26 Mar 2003 06:51:58 -0600 (CST) Received: from laptop.americas.sgi.com by laptop.americas.sgi.com (8.12.8/SGI-client-1.7) via ESMTP id h2QCpUHb001414; Wed, 26 Mar 2003 06:51:30 -0600 Received: (from lord@localhost) by laptop.americas.sgi.com (8.12.8/8.12.8/Submit) id h2QCpSm8001412; Wed, 26 Mar 2003 06:51:28 -0600 X-Authentication-Warning: laptop.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: Question about upgrade to XFS 1.2 From: Steve Lord To: roberto@redix.it Cc: linux-xfs@oss.sgi.com In-Reply-To: <2545.212.239.118.101.1048682231.squirrel@mail.redix.it> References: <2545.212.239.118.101.1048682231.squirrel@mail.redix.it> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 26 Mar 2003 06:51:28 -0600 Message-Id: <1048683088.1247.2.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 627 Lines: 24 On Wed, 2003-03-26 at 06:37, roberto@redix.it wrote: > Date: 26 mar 2003 > > I'm running kernel 2.4.18 + XFS1.1+ LVM 1.3 on my PC. > > I'd like to know: > 1) can I upgrade to kernel 2.4.19 + XFS 1.2 without reformatting and > recreate new File System with XFS 1.2? any drawbacks using the current > filesystem created with XFS1.1? It is best reformatting? On disk XFS is identical across all versions - we are not changing on disk format. Steve > > 2) what is the suggested (well tested) version of LVM with XFS 1.2? LVM > 1.7 or LVM2? anyone is already using these combination? > > thanks in advance, > Roberto > > From owner-linux-xfs@oss.sgi.com Wed Mar 26 05:22:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 05:22:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QDMRq9005605 for ; Wed, 26 Mar 2003 05:22:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QDMRc2005601 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 05:22:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QDMQqB005587 for ; Wed, 26 Mar 2003 05:22:26 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QCNsro024571; Wed, 26 Mar 2003 04:23:54 -0800 Date: Wed, 26 Mar 2003 04:23:54 -0800 Message-Id: <200303261223.h2QCNsro024571@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 608 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-26 04:23 ------- Created an attachment (id=72) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=72&action=view) some kdb outputs I'm also seeing that bug on a machine here. I can also reproduce it with 'updatedb; reboot'. System is Debian Woody, Kernel-2.4.20 + xfs-030316+ ptrace patch. I've created some kdb backtraces, maybe they help. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 06:01:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 06:01:31 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.114.72.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QE1Rq9006901 for ; Wed, 26 Mar 2003 06:01:28 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.12.8/8.12.5) with ESMTP id h2QE1OAW004380; Wed, 26 Mar 2003 09:01:24 -0500 Subject: Re: xfs installer From: Jeremy Jackson To: Michael Whang Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1048687283.1248.8.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 26 Mar 2003 09:01:24 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 16 I'm working on one for Debian... Jeremy On Tue, 2003-03-25 at