From owner-linux-xfs Sun Aug 1 12:02:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Aug 2004 12:02:57 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i71J2pC1030566 for ; Sun, 1 Aug 2004 12:02:53 -0700 Received: (qmail 17391 invoked from network); 1 Aug 2004 18:55:39 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 1 Aug 2004 18:55:39 -0000 Date: Sun, 1 Aug 2004 21:02:41 +0200 From: Adrian Bunk To: Nathan Scott Cc: Arjan van de Ven , "Jeffrey E. Hundstad" , Linus Torvalds , Andrew Morton , Steve Lord , linux-xfs@oss.sgi.com, Cahya Wirawan , linux-kernel@vger.kernel.org Subject: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL Message-ID: <20040801190241.GC2746@fs.tum.de> References: <20040720114418.GH21918@email.archlab.tuwien.ac.at> <40FD0A61.1040503@xfs.org> <40FD2E99.20707@mnsu.edu> <20040720195012.GN14733@fs.tum.de> <20040729060900.GA1946@frodo> <20040729114219.GN2349@fs.tum.de> <20040730083040.A2703153@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730083040.A2703153@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.6i X-archive-position: 3804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: linux-xfs On Fri, Jul 30, 2004 at 08:30:40AM +1000, Nathan Scott wrote: >... > Adrian wrote: > > 2.6 is a stable kernel series used in production environments. > > > > Regarding Linus' tree, it's IMHO the best solution to work around it > > this way until all issues are sorted out. > > I'm not really convinced - the EXPERIMENTAL marking should > be plenty of a deterent to folks in production environments. > There are reports of stack overruns on other filesystems as > well with 4KSTACKS, so doesn't seem worthwhile to me to do > this just for XFS. OK, below is a patch that only adds a dependency of 4KSTACKS on EXPERIMENTAL. Considering that not all issues with 4kb stacks are currently corrected, this patch should IMHO go in 2.6.8 . Signed-off-by: Adrian Bunk --- linux-2.6.8-rc2-mm1-full/arch/i386/Kconfig.old 2004-08-01 20:59:02.000000000 +0200 +++ linux-2.6.8-rc2-mm1-full/arch/i386/Kconfig 2004-08-01 20:59:46.000000000 +0200 @@ -1474,7 +1474,8 @@ to solve problems without frame pointers. config 4KSTACKS - bool "Use 4Kb for kernel stacks instead of 8Kb" + bool "Use 4Kb for kernel stacks instead of 8Kb (EXPERIMENTAL)" + depends on EXPERIMENTAL help If you say Y here the kernel will use a 4Kb stacksize for the kernel stack attached to each process/thread. This facilitates From owner-linux-xfs Sun Aug 1 21:03:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Aug 2004 21:03:50 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7243YR8020069 for ; Sun, 1 Aug 2004 21:03:35 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i725588v007661 for ; Sun, 1 Aug 2004 22:05:08 -0700 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 OAA05017; Mon, 2 Aug 2004 14:02:12 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i72429ln2834704; Mon, 2 Aug 2004 14:02:10 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i724wUgh021660; Mon, 2 Aug 2004 14:58:30 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i724wRdD021658; Mon, 2 Aug 2004 14:58:27 +1000 Date: Mon, 2 Aug 2004 14:58:27 +1000 From: Nathan Scott To: Cahya Wirawan Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS: Oops in 2.4.26 and 2.4.27-rc4 Message-ID: <20040802045827.GA21646@frodo> References: <20040801165946.GA1045@email.archlab.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040801165946.GA1045@email.archlab.tuwien.ac.at> User-Agent: Mutt/1.5.3i X-archive-position: 3805 X-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 On Sun, Aug 01, 2004 at 06:59:46PM +0200, Cahya Wirawan wrote: > Hi, Hi there, > ... > 2.4.26 and 2.4.27-rc4 get an Oops again. The server will not always > crash, but it gets always an Oops at the same test (diotest4), and it is Thanks for reporting it, here is the fix. cheers. -- Nathan --- fs/xfs/linux-2.4/xfs_lrw.c.orig 2004-08-02 12:57:02.000000000 +1000 +++ fs/xfs/linux-2.4/xfs_lrw.c 2004-08-02 13:00:03.000000000 +1000 @@ -283,6 +283,8 @@ XFS_STATS_INC(xs_read_calls); if (unlikely(ioflags & IO_ISDIRECT)) { + if ((ssize_t)size < 0) + return -XFS_ERROR(EINVAL); if (((__psint_t)buf & BBMASK) || (*offset & mp->m_blockmask) || (size & mp->m_blockmask)) { @@ -325,7 +327,8 @@ if (unlikely(ioflags & IO_ISDIRECT)) { xfs_rw_enter_trace(XFS_DIORD_ENTER, &ip->i_iocore, buf, size, *offset, ioflags); - ret = do_generic_direct_read(file, buf, size, offset); + ret = (*offset < ip->i_d.di_size) ? + do_generic_direct_read(file, buf, size, offset) : 0; UPDATE_ATIME(file->f_dentry->d_inode); } else { xfs_rw_enter_trace(XFS_READ_ENTER, &ip->i_iocore, From owner-linux-xfs Sun Aug 1 21:17:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Aug 2004 21:17:30 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i724HR09020592 for ; Sun, 1 Aug 2004 21:17:28 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i725J02n012619 for ; Sun, 1 Aug 2004 22:19:02 -0700 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 OAA05289; Mon, 2 Aug 2004 14:17:20 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i724HHln2831548; Mon, 2 Aug 2004 14:17:18 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i725Dcgh021750; Mon, 2 Aug 2004 15:13:39 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i725DaDq021748; Mon, 2 Aug 2004 15:13:36 +1000 Date: Mon, 2 Aug 2004 15:13:36 +1000 From: Nathan Scott To: Stormy Waters Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.26 XFS file space reporting bug Message-ID: <20040802051336.GC21646@frodo> References: <20040730224245.56872.qmail@web61207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730224245.56872.qmail@web61207.mail.yahoo.com> User-Agent: Mutt/1.5.3i X-archive-position: 3806 X-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 On Fri, Jul 30, 2004 at 03:42:45PM -0700, Stormy Waters wrote: > Hi people, > > I think I found a bug in the 2.4.26 kernel, I have a I suspect this may be pilot error... > logical partition (see below) that is partitioned for > 20 gig's. when i use df it reports it as 278MB. > Which is not even close to 20gb. This Machine is Did you run mkfs.xfs on this device right after it was partitioned? mkfs.xfs is only going to use as much as the block layer says it can, so if the kernels in-core partition table was out of whack, mkfs will be told an out-of-date device size. If this may be the case, try rebooting and then see if mkfs.xfs sees the updated device size. Also xfs_info / "mkfs.xfs -fN" output would be useful here, along with the contents of /proc/partitions. cheers. -- Nathan From owner-linux-xfs Sun Aug 1 21:52:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Aug 2004 21:53:00 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i724qvUa021310 for ; Sun, 1 Aug 2004 21:52:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i725sUms024718 for ; Sun, 1 Aug 2004 22:54:31 -0700 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 OAA05790; Mon, 2 Aug 2004 14:52:50 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i724qfln2836284; Mon, 2 Aug 2004 14:52:41 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i725mwgh021854; Mon, 2 Aug 2004 15:48:59 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i725ms9X021852; Mon, 2 Aug 2004 15:48:54 +1000 Date: Mon, 2 Aug 2004 15:48:54 +1000 From: Nathan Scott To: Callan Tham Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Possible XFS Corruption Message-ID: <20040802054854.GD21646@frodo> References: <1091418545.6750.12.camel@taz.lan.securecirt.com> <20040802050232.GB21646@frodo> <1091420414.7363.17.camel@taz.lan.securecirt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1091420414.7363.17.camel@taz.lan.securecirt.com> User-Agent: Mutt/1.5.3i X-archive-position: 3807 X-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 On Mon, Aug 02, 2004 at 12:20:14PM +0800, Callan Tham wrote: > On Mon, 2004-08-02 at 13:02, Nathan Scott wrote: > > > I'm running a Gentoo-patched 2.6.7 kernel, and am experiencing possible > > > XFS corruption on one of my partitions. I've included a sample of the > > > > Is it reproducible with an unpatched kernel.org kernel? > > > > thanks. > > Hi Nathan, > > Unfortunately, I am unable to test this with a vanilla kernel. However, Oh? > looking through the Gentoo patches, they did not touch any of the XFS > code in a vanilla 2.6.7 kernel. I would be surprised if they had. A more likely source of problems would be changes in the VM subsystem (XFS metadata buffers are cached in the page cache). > Is there any other way to diagnose this? The failure you see is XFS reporting corruption in a directory btree buffer which didn't have an appropriate magic number at its start when read in from disk. There's thousands of potential reasons why that may have happened; more often than not these days its an error thats occured outside of XFS though, and XFS is passing on the bad news. If you can find a reproducible test case, you're half way there. If you can find a reproducible test case on a kernel.org kernel, you're 95% of the way there, cos then we can more easily help. ;) cheers. -- Nathan From owner-linux-xfs Sun Aug 1 22:06:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Aug 2004 22:06:39 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7256R3l021795 for ; Sun, 1 Aug 2004 22:06:28 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i72681tP029279 for ; Sun, 1 Aug 2004 23:08:02 -0700 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 PAA06060; Mon, 2 Aug 2004 15:05:00 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7254vln2809444; Mon, 2 Aug 2004 15:04:57 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7261Dgh021936; Mon, 2 Aug 2004 16:01:15 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i726193K021934; Mon, 2 Aug 2004 16:01:09 +1000 Date: Mon, 2 Aug 2004 16:01:09 +1000 From: Nathan Scott To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared Message-ID: <20040802060109.GF21646@frodo> References: <40FB2417.7030406@berdmann.de> <4774.1090202489@kao2.melbourne.sgi.com> <20040720015826.A2406645@wobbly.melbourne.sgi.com> <40FDFBF2.7020500@berdmann.de> <20040729054638.GK800@frodo> <410B3E47.2030806@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410B3E47.2030806@berdmann.de> User-Agent: Mutt/1.5.3i X-archive-position: 3808 X-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 On Sat, Jul 31, 2004 at 08:37:59AM +0200, Bernhard Erdmann wrote: > Nathan Scott wrote: > > >Does your /usr/include/{bits,sys}/mman.h have those missing macros? > >If so, what cpp macro is guarding them? (mail me the file please) > >If not, can you grep below /usr/include for them and let me know > >which header defines them? thanks. > > Hi Nathan, > > /usr/include/{bits,sys}/mman.h does not have a definition for > MADV_NORMAL. Instead, it is defined in /usr/include/asm/mman.h: Does adding #include (in xfsprogs/io/mmap.c) get a working build for you or do you see subsequent errors too? thanks. -- Nathan From owner-linux-xfs Sun Aug 1 22:55:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Aug 2004 22:55:40 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i725tdBW022995 for ; Sun, 1 Aug 2004 22:55:39 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i725td37022994 for linux-xfs@oss.sgi.com; Sun, 1 Aug 2004 22:55:39 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i725tcdA022979 for ; Sun, 1 Aug 2004 22:55:38 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7250gLM021716; Sun, 1 Aug 2004 22:00:42 -0700 Date: Sun, 1 Aug 2004 22:00:42 -0700 Message-Id: <200408020500.i7250gLM021716@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3809 X-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 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From nathans@sgi.com 2004-01-08 22:00 PDT ------- > Tried with -d size=512g (additionally to the parameters used before) and the > forced shutdown still happens. Unfortunately, I don't have a 500g device to test with either ;) - but here's a few more things worth testing: - try mkfs without a version 2 log, does problem persist? - try without any data stripe alignment options - try with -dagsize=4g - try with default inode size (256 bytes).. and one-at-a-time, not all-at-once of course - if the problem goes away with any one of these, then we have a big hint. Also, does it only happen on top of MD, or does the failure occur with those options on a regular disk too? thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Aug 2 04:20:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 04:20:59 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72BKobn009019 for ; Mon, 2 Aug 2004 04:20:53 -0700 Received: by mproxy.gmail.com with SMTP id 76so123281rnl for ; Mon, 02 Aug 2004 04:20:47 -0700 (PDT) Received: by 10.38.82.68 with SMTP id f68mr405096rnb; Mon, 02 Aug 2004 04:20:46 -0700 (PDT) Message-ID: <2bd6037a04080204201903e8fe@mail.gmail.com> Date: Mon, 2 Aug 2004 04:20:46 -0700 From: Tupshin Harper To: linux-xfs@oss.sgi.com Subject: xfs_repair fatal error in phase 6 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@gmail.com Precedence: bulk X-list: linux-xfs I have an xfs partition that xfs_repair refuses to fix. It always dies with the following: Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 empty data block 9 in directory inode 54540222: junking block fatal error -- can't read block 8388608 for directory inode 54540222 I have tried dd'ing it to a file on another filesystem, and I get the same results. I've tried running it a few times, and no change. Mount doesn't recognize it. For what it's woth, xfs_repair is running on a debian sid box on an athlon xp cpu, and xfsprogs is from debian's xfsprogs_2.6.20-1 package. Any suggestions? -Tupshin From owner-linux-xfs Mon Aug 2 06:43:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 06:44:11 -0700 (PDT) Received: from mx-gate.digithi.de (m18s05.vlinux.de [80.190.204.167]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72DhuqM018643 for ; Mon, 2 Aug 2004 06:43:57 -0700 Received: from mailout.digithi.de (localhost [127.0.0.1]) by mx-gate.digithi.de (8.12.3/8.12.3/0.5) with ESMTP id i72Dcuv1015425 for ; Mon, 2 Aug 2004 15:38:56 +0200 Received: from ganymede.digithi.de (ganymede.thimo.net [192.168.88.3]) by mailout.digithi.de (8.12.10/8.12.10/2.8) with ESMTP id i72Di5k2020778 for ; Mon, 2 Aug 2004 15:44:05 +0200 Message-Id: <6.1.2.0.0.20040802153333.01bfc548@janus.thimo.net> X-Sender: digithi@janus.thimo.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 02 Aug 2004 15:44:02 +0200 To: linux-xfs@oss.sgi.com From: Thimo E Subject: XFS on Loop Device on Raid Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: 1/1 part ok X-Scanned-By: MIMEDefang at digithi.de X-archive-position: 3811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: abc@digithi.de Precedence: bulk X-list: linux-xfs Hello, I am using XFS on an encrypted loop devices (loop-aes.sourceforge.net) and that runs on a software RAID 5 system. Raid 5 doesn't support variable length transfers, normally xfs recognize it and disables them, but here xfs only sees a LOOP device, so variable length transfers are enabled and the filesystem gets corrupted in this case. I found a solution on another list: http://mail.nl.linux.org/linux-crypto/2003-12/msg00024.html This disables variable length transfers on all loop devices... --- linux-2.4.22aa1r3/fs/xfs/linux/xfs_super.c.old Fri Dec 12 08:19:49 2003 +++ linux-2.4.22aa1r3/fs/xfs/linux/xfs_super.c Fri Dec 12 08:20:58 2003 @@ -303,6 +303,7 @@ switch (MAJOR(btp->pbr_dev)) { case MD_MAJOR: + case LOOP_MAJOR: case EVMS_MAJOR: btp->pbr_flags = PBR_ALIGNED_ONLY; break; Is there another solution ? I have nothing found about this interoperability on sgi's website. bye Thimo From owner-linux-xfs Mon Aug 2 07:49:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 07:49:38 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72EnQTO021753 for ; Mon, 2 Aug 2004 07:49:26 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i72Fp47d011743 for ; Mon, 2 Aug 2004 08:51:05 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i72EmLOV44225167; Mon, 2 Aug 2004 09:48:21 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i72EmK3b11221800; Mon, 2 Aug 2004 09:48:21 -0500 (CDT) Date: Mon, 2 Aug 2004 09:46:30 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: Tupshin Harper cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair fatal error in phase 6 In-Reply-To: <2bd6037a04080204201903e8fe@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3812 X-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 On Mon, 2 Aug 2004, Tupshin Harper wrote: > I have an xfs partition that xfs_repair refuses to fix. It always dies > with the following: > > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 128 > empty data block 9 in directory inode 54540222: junking block > > fatal error -- can't read block 8388608 for directory inode 54540222 maybe stracing xfs_repair would tell us what the real error was, although the output will be quite large - the option "-etrace=read" might catch only the read calls, and see if one fails. Or, maybe some creative printf debugging in phase6.c to find the underlying error. > I have tried dd'ing it to a file on another filesystem, and I get the > same results. I've tried running it a few times, and no change. Mount > doesn't recognize it. What does mount say? -Eric From owner-linux-xfs Mon Aug 2 09:55:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 09:55:44 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72GteTF029141 for ; Mon, 2 Aug 2004 09:55:41 -0700 Received: by mproxy.gmail.com with SMTP id 77so56042rnl for ; Mon, 02 Aug 2004 09:55:36 -0700 (PDT) Received: by 10.38.12.79 with SMTP id 79mr94149rnl; Mon, 02 Aug 2004 09:55:36 -0700 (PDT) Message-ID: <2bd6037a040802095517728a99@mail.gmail.com> Date: Mon, 2 Aug 2004 09:55:36 -0700 From: Tupshin Harper To: Eric Sandeen Subject: Re: xfs_repair fatal error in phase 6 Cc: linux-xfs@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-archive-position: 3814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 3397 Lines: 84 Hi, Eric....thanks for your suggestions. First, of all, it turns out that I can mount the loopback copy of this filesystem, though I'm not sure if the difference between that version and the original disk version is due to additional runs of xfs_repair or something else. Trying to mount the original still gives the generic "wrong fs type, bad superblock" message. When I mount the loopback version there are lots of directories with leading slashes and if I try to copy almost anything off of it (even things without leading slashes), I get "Unknown error 990" and repair gives thousands and thousands of errors like: entry at block 1078 offset 1792 in directory inode 58812988 has illegal name "/27523.": entry "/27524." at block 1078 offset 1816 in directory inode 58812988 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1816... running strace with the etrace option doesn't seem to show much...there are 18 lines of " read(3, "XFSB\0\0\20\0\0\0\0\0\0$\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 in phase 1, but no other strace output. If at all useful, here's the very end of a full strace output: pread(4, "XD2D\2\340\r \0\0\0\0\0\0\0\0\0\0\0\0\2\212\221\16\007"..., 4096, 7869706240) = 4096 pread(4, "XD2D\0\20\vX\v\200\1\340\rx\1h\377\377\vX\2\212\375\\\007"..., 4096, 7869726720) = 4096 pread(4, "XD2D\5\370\n\10\0\20\5\320\0\0\0\0\377\377\5\320\2\213"..., 4096, 7869730816) = 4096 pread(4, "XD2D\0\20\6\30\v8\4\310\10\200\1\260\377\377\6\30\2\213"..., 4096, 7869734912) = 4096 pread(4, "XD2D\4\30\n\370\0\20\2\350\3\20\0\360\377\377\2\350\2\213"..., 4096, 7869739008) = 4096 pread(4, "XD2D\t\240\6H\0p\5\240\6(\3`\377\377\0H\2\213v\341\007"..., 4096, 7869747200) = 4096 brk(0) = 0x8270000 brk(0x8291000) = 0x8291000 pread(4, "XD2D\0\20\r\310\16P\1h\r\360\0H\377\377\r\310\2\213\221"..., 4096, 7869751296) = 4096 pread(4, "XD2D\0\20\6\30\6@\0048\n\220\3`\377\377\6\30\2\213\247"..., 4096, 7869755392) = 4096 write(2, "\nfatal error -- ", 16 fatal error -- ) = 16 write(2, "can\'t read block 8388608 for dir"..., 54can't read block 8388608 for directory inode 54540222 ) = 54 exit_group(1) = ? -Tupshin On Mon, 2 Aug 2004 09:46:30 -0500 (CDT), Eric Sandeen wrote: > On Mon, 2 Aug 2004, Tupshin Harper wrote: > > > I have an xfs partition that xfs_repair refuses to fix. It always dies > > with the following: > > > > Phase 6 - check inode connectivity... > > - resetting contents of realtime bitmap and summary inodes > > - ensuring existence of lost+found directory > > - traversing filesystem starting at / ... > > rebuilding directory inode 128 > > empty data block 9 in directory inode 54540222: junking block > > > > fatal error -- can't read block 8388608 for directory inode 54540222 > > maybe stracing xfs_repair would tell us what the real error was, although > the output will be quite large - the option "-etrace=read" might catch > only the read calls, and see if one fails. Or, maybe some creative > printf debugging in phase6.c to find the underlying error. > > > I have tried dd'ing it to a file on another filesystem, and I get the > > same results. I've tried running it a few times, and no change. Mount > > doesn't recognize it. > > What does mount say? > > -Eric > > From owner-linux-xfs Mon Aug 2 10:24:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 10:24:36 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72HOYxQ029960 for ; Mon, 2 Aug 2004 10:24:34 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i72IQEQR027980 for ; Mon, 2 Aug 2004 11:26:14 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i72HOUOV44200530 for ; Mon, 2 Aug 2004 12:24:30 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i72HOT5N12469863 for ; Mon, 2 Aug 2004 12:24:29 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i72HMbRr018724; Mon, 2 Aug 2004 12:22:37 -0500 Received: (from arunr@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i72HMbZe018722; Mon, 2 Aug 2004 12:22:37 -0500 Date: Mon, 2 Aug 2004 12:22:37 -0500 From: Arun Ramakrishnan Message-Id: <200408021722.i72HMbZe018722@penguin.americas.sgi.com> Subject: PARTIAL TAKE 915187 - Code checks to trap access to fsb zero. X-archive-position: 3815 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: arunr@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 957 Lines: 32 Code checks to trap access to fsb zero. Date: Mon Aug 2 10:20:16 PDT 2004 Workarea: penguin.americas.sgi.com:/data/lwork/attica1/arunr/xfs Inspected by: gwehrman,nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:176159a fs/xfs/xfs_bmap_btree.h - 1.63 - Added invalid extent state(XFS_EXT_INVALID) to xfs_exntst_t. fs/xfs/xfs_bmap.c - 1.319 - Initialized extent entry structure in bmap_do_search_extents. Added checks to trap access to block zero in xfs_bmap_search_extents. fs/xfs/xfs_iomap.h - 1.3 - Added IOMAP_REALTIME flag. fs/xfs/xfs_iomap.c - 1.29 - Added checks to trap access to block zero in xfs_iomap_write_direct,xfs_iomap_write_delay,xfs_iomap_write_allocate and xfs_iomap_write_unwritten. fs/xfs/linux-2.6/xfs_aops.c - 1.77 - Added checks to trap access to block zero. fs/xfs/linux-2.4/xfs_aops.c - 1.83 - Added checks to trap access to block zero. From owner-linux-xfs Mon Aug 2 13:29:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 13:29:33 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72KTUYv015113 for ; Mon, 2 Aug 2004 13:29:30 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i72LVBeE020632 for ; Mon, 2 Aug 2004 14:31:11 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i72KSPOV44183177; Mon, 2 Aug 2004 15:28:25 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i72KSA3b11286404; Mon, 2 Aug 2004 15:28:15 -0500 (CDT) Date: Mon, 2 Aug 2004 15:26:16 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: Tupshin Harper cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair fatal error in phase 6 In-Reply-To: <2bd6037a040802095517728a99@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3816 X-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: 1274 Lines: 34 On Mon, 2 Aug 2004, Tupshin Harper wrote: > First, of all, it turns out that I can mount the loopback copy of this > filesystem, though I'm not sure if the difference between that version > and the original disk version is due to additional runs of xfs_repair > or something else. Trying to mount the original still gives the > generic "wrong fs type, bad superblock" message. dmesg will tell you the real error. > When I mount the loopback version there are lots of directories with > leading slashes and if I try to copy almost anything off of it (even > things without leading slashes), I get "Unknown error 990" This is xfs shutting down; again, dmesg will tell you more. > and repair gives thousands and thousands of errors like: > entry at block 1078 offset 1792 in directory inode 58812988 has > illegal name "/27523.": entry "/27524." at block 1078 offset 1816 in > directory inode 58812988 references invalid inode 18374686479671623679 > clearing inode number in entry at offset 1816... How did the filesystem go bad in the first place? What prompted the repair? > If at all useful, here's the very end of a full strace output: Hm, lots of seemingly successful directory reads, followed by a failure message... Not sure on this one yet... -Eric From owner-linux-xfs Mon Aug 2 13:55:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 13:55:20 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72KtGQT015753 for ; Mon, 2 Aug 2004 13:55:18 -0700 Received: by mproxy.gmail.com with SMTP id 77so65109rnl for ; Mon, 02 Aug 2004 13:55:07 -0700 (PDT) Received: by 10.38.78.25 with SMTP id a25mr84564rnb; Mon, 02 Aug 2004 13:55:07 -0700 (PDT) Message-ID: <2bd6037a04080213555be87741@mail.gmail.com> Date: Mon, 2 Aug 2004 13:55:07 -0700 From: Tupshin Harper To: Eric Sandeen Subject: Re: xfs_repair fatal error in phase 6 Cc: linux-xfs@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-archive-position: 3817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1844 Lines: 52 > dmesg will tell you the real error. I feel silly...dmesg does indeed say quite a bit...sample output at the bottom of this message...I got quite a number of these, presumably one each time xfs gave me an error. > How did the filesystem go bad in the first place? What prompted > the repair? The repair was prompted by not being able to mount it. The corruption was due to a heinous system crash when trying to do a pvmove on a lvm volume group that this partitition was not on. Thanks for your help -Tupshin dmesg output (let me know if I can give you any more info about this): xfs_da_do_buf: bno 8388608 dir: inode 54540222 Filesystem "loop0": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xc024a4 97 [] xfs_da_do_buf+0x749/0x900 [] xfs_da_read_buf+0x57/0x60 [] ip_rcv_finish+0x0/0x280 [] netif_receive_skb+0x1b8/0x260 [] schedule+0x28e/0x490 [] xfs_da_read_buf+0x57/0x60 [] xfs_da_node_lookup_int+0x80/0x370 [] xfs_da_node_lookup_int+0x80/0x370 [] xfs_dir2_node_lookup+0x3f/0xc0 [] xfs_dir2_lookup+0x12a/0x140 [] xfs_dir_lookup_int+0x4c/0x130 [] xfs_lookup+0x50/0x90 [] linvfs_lookup+0x67/0xa0 [] real_lookup+0xcf/0x100 [] do_lookup+0x96/0xb0 [] link_path_walk+0x6d3/0xda0 [] tty_default_put_char+0x33/0x40 [] opost+0x99/0x1b0 [] recalc_task_prio+0x8f/0x190 [] path_lookup+0x83/0x180 [] __user_walk+0x49/0x80 [] vfs_lstat+0x1c/0x60 [] kfree_skbmem+0x24/0x30 [] __kfree_skb+0xb1/0x140 [] sys_lstat64+0x1b/0x40 [] __do_softirq+0x7d/0x80 [] do_IRQ+0xfd/0x130 [] syscall_call+0x7/0xb From owner-linux-xfs Mon Aug 2 14:51:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 14:51:04 -0700 (PDT) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72Lp0Ek017259 for ; Mon, 2 Aug 2004 14:51:01 -0700 Received: from port-212-202-185-131.dynamic.qsc.de ([212.202.185.131] helo=ente.berdmann.de) by coredumps.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.33) id 1Brkhr-00083i-W7 for linux-xfs@oss.sgi.com; Mon, 02 Aug 2004 23:50:56 +0200 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1Brkhr-0006c7-00 for linux-xfs@oss.sgi.com; Mon, 02 Aug 2004 23:50:55 +0200 Message-ID: <410EB73E.9080603@berdmann.de> Date: Mon, 02 Aug 2004 23:50:54 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.6) Gecko/20040505 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared References: <40FB2417.7030406@berdmann.de> <4774.1090202489@kao2.melbourne.sgi.com> <20040720015826.A2406645@wobbly.melbourne.sgi.com> <40FDFBF2.7020500@berdmann.de> <20040729054638.GK800@frodo> <410B3E47.2030806@berdmann.de> <20040802060109.GF21646@frodo> In-Reply-To: <20040802060109.GF21646@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3818 X-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: 1283 Lines: 26 Nathan Scott wrote: > Does adding #include (in xfsprogs/io/mmap.c) get > a working build for you or do you see subsequent errors too? gcc -O1 -g -DDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.6.19\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_FADVISE -DHAVE_SENDFILE -DHAVE_INJECT -DHAVE_RESBLKS -DHAVE_SHUTDOWN -I/usr/local/src/xfs-cmds/xfsprogs/include -I/usr/local/src/xfs-cmds/dmapi/include -I/usr/local/src/xfs-cmds/attr/include -c -o fadvise.o fadvise.c fadvise.c: In function `fadvise_f': fadvise.c:91: `POSIX_FADV_NORMAL' undeclared (first use in this function) fadvise.c:91: (Each undeclared identifier is reported only once fadvise.c:91: for each function it appears in.) fadvise.c:96: `POSIX_FADV_DONTNEED' undeclared (first use in this function) fadvise.c:100: `POSIX_FADV_NOREUSE' undeclared (first use in this function) fadvise.c:104: `POSIX_FADV_RANDOM' undeclared (first use in this function) fadvise.c:108: `POSIX_FADV_SEQUENTIAL' undeclared (first use in this function) fadvise.c:112: `POSIX_FADV_WILLNEED' undeclared (first use in this function) gmake[2]: *** [fadvise.o] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/local/src/xfs-cmds/xfsprogs' From owner-linux-xfs Mon Aug 2 16:55:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 16:55:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72NtgXQ024602 for ; Mon, 2 Aug 2004 16:55:42 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i72Ntg4c024601 for linux-xfs@oss.sgi.com; Mon, 2 Aug 2004 16:55:42 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72NtfUW024587 for ; Mon, 2 Aug 2004 16:55:41 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i72NAKrP020243; Mon, 2 Aug 2004 16:10:20 -0700 Date: Mon, 2 Aug 2004 16:10:20 -0700 Message-Id: <200408022310.i72NAKrP020243@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3819 X-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: 673 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-02-08 16:10 PDT ------- Nathan, In all cases, the filesystem was shut down. Additional cases: - XFS on md with mkfs.xfs defaults: CRASH - XFS on single JBOD: OK - XFS on 3ware array (no md): CRASH - XFS on md (whatever underlying devices): CRASH - ext2/3 on 3ware array: OK - ext2/3 on md: OK I'm afraid I have to do the full matrix if we want to investigate this further. Might be completely unrelated to XFS/md/3w-9xxx... Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Aug 2 20:14:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 20:14:10 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i733E6lC002259 for ; Mon, 2 Aug 2004 20:14:07 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i733E10f029752 for ; Mon, 2 Aug 2004 22:14:02 -0500 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 i733Dp7X7379178; Tue, 3 Aug 2004 13:13:52 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i733DoXH7613567; Tue, 3 Aug 2004 13:13:50 +1000 (EST) Date: Tue, 3 Aug 2004 13:13:50 +1000 (EST) From: Nathan Scott Message-Id: <200408030313.i733DoXH7613567@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 918967 - diotest4 X-archive-position: 3820 X-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: 339 Lines: 13 Fix diotest4 test case issues with direct reads in XFS. Date: Mon Aug 2 20:13:02 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:176192a linux-2.4/xfs_lrw.c - 1.218 From owner-linux-xfs Mon Aug 2 21:06:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Aug 2004 21:07:08 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7346ubU006511 for ; Mon, 2 Aug 2004 21:06:56 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7358dCF031400 for ; Mon, 2 Aug 2004 22:08:39 -0700 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 i7346g7X7604969; Tue, 3 Aug 2004 14:06:43 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7346fhD7644737; Tue, 3 Aug 2004 14:06:41 +1000 (EST) Date: Tue, 3 Aug 2004 14:06:41 +1000 (EST) From: Nathan Scott Message-Id: <200408030406.i7346fhD7644737@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 914153 - sync preallocations X-archive-position: 3821 X-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: 5318 Lines: 125 Fix accidental reverting of sync write preallocations. Date: Mon Aug 2 21:06:25 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: felixb@sgi.com,cw@f00f.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:176195a xfs_iomap.h - 1.4 xfs_iomap.c - 1.30 linux-2.6/xfs_aops.c - 1.78 linux-2.4/xfs_aops.c - 1.84 rom owner-linux-xfs Tue Aug 3 11:32:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Aug 2004 11:32:10 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i73IW3QE010475 for ; Tue, 3 Aug 2004 11:32:04 -0700 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i73IVsBi022122; Tue, 3 Aug 2004 11:31:54 -0700 Message-ID: <410FDA19.9020805@tlinx.org> Date: Tue, 03 Aug 2004 11:31:53 -0700 From: L A Walsh User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS: how to NOT null files on fsck? References: <200407050247.53743.norberto+linux-kernel@bensa.ath.cx> <40EEC9DC.8080501@tlinx.org> <20040729013049.GE800@frodo> In-Reply-To: <20040729013049.GE800@frodo> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@tlinx.org Precedence: bulk X-list: linux-xfs On 07-28-04 Nathan Scott blissfully wrote: >On Fri, Jul 09, 2004 at 09:37:48AM -0700, L A Walsh wrote: > >>It's a feature! :-) >>It's been in the code for years to randomly write nulls to some files >> >Pfft, nonsense. > The above was meant somewhat tongue-in-cheek, ya know... > The problem relates to an updated inode size >being flushed ahead of the data behind it (hence a size update >can make it out before delayed allocate extents do, and we end >up with a hole beyond the end of file, which reads as zeroes). > I believe I understand the scenario you are talking about, but I don't think it fits the examples I have referred to. In particular, "/etc/fstab". I update 'fstab' on Tuesday, say, it works fine...gets backed up just fine...and I forget about it and move on. Then, 2-3 days later, my system crashes and doesn't want to some up. That's odd, usually after a crash, it just burps a bit and comes back up. I grumble and go for single user. Turns out my 1.2k fstab file is all "nulls". Coinidentally, I find, _maybe_, a couple of other files written around the same time, also nulled, including times when the nulls appeared in the system log for that time period! Now I know it takes a while before data may end up on disk and that it may not go out to disk in an ordered fashion, but 2-3 days? This isn't a case of a multi-extent file. My current fstab is only 1335 bytes long. I doubt it has ever been more than 2. My filesystems all use the Allocation unit (AU) size allowed. I wish for something larger than a 4k AU size but I'm told it is limited by the linux page size and to find a PC that uses the IA64 page size to use larger file AU size (but I haven't seen to many of these IA64 machines available from Dell or Gateway...:-) Maybe the code in FAT32 that handles larger AU's could be ported to XFS? If FAT32 can do it...nevermind... I'm sure there are more important issues on the plate. >>Apparently not easily reproduced, no one has a clue why it does it. >>Just does. >> >No, its actually well known why it behaves this way. >We are looking into ways to address this, and have some >ideas - the trick is fixing it without hurting write >performance - which we will do, its just not trivial. > You could increase the max AU size :-) But more seriously, is my example of writing a 1 AU sized file that becomes zeroed days later an example of the problem you are speaking of? >There are several techiques to reduce the impact of this >behaviour, as others have described (or see the linux-xfs >archives). > Like setting the disk for synchronous writes? Why not something in between, like guaranteeing the info on a mostly quiescent machine will be written to disk within an hour or so? Or is that not "it"? I haven't seen an incidence of this behavior in several months on my machines so my particular problem may have been fixed and the problem you speak of is unrelated to my own, but the number of unplanned shutdowns on my system has only increased recently, since I upgraded to the stable 2.6 series, whereas before, with 2.4, it could be months between "blue screens". Sad was the day that it was decided that the linux-kernel "corp" decided on feature development vs. stability in the "stable" kernel series. Isn't that criticism lodged most often against MS. It seems most "companies", incorporated or not, seem to follow similar growth patterns. Wasn't there an Eastern saying about choosing your enemies wisely for you will eventually become like them? -l From owner-linux-xfs Tue Aug 3 11:55:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Aug 2004 11:55:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i73ItkCV011234 for ; Tue, 3 Aug 2004 11:55:46 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i73ItkfB011233 for linux-xfs@oss.sgi.com; Tue, 3 Aug 2004 11:55:46 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i73Itje7011219 for ; Tue, 3 Aug 2004 11:55:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i73ICl9R010221; Tue, 3 Aug 2004 11:12:47 -0700 Date: Tue, 3 Aug 2004 11:12:47 -0700 Message-Id: <200408031812.i73ICl9R010221@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3823 X-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: 5583 Lines: 148 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From sandeen@sgi.com 2004-03-08 11:12 PDT ------- FWIW, I tried this with a small raid0 of 4 devices, and did not hit the problem. [root@penguin3 root]# xfs_info /mnt/foo meta-data=/mnt/foo isize=256 agcount=16, agsize=555696 blks = sectsz=512 data = bsize=4096 blocks=8891136, imaxpct=25 = sunit=16 swidth=64 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=4352, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=262144 blocks=0, rtextents=0 [root@penguin3 root]# mdadm -Q --detail /dev/md0 /dev/md0: Version : 00.90.00 Creation Time : Sat Jul 24 21:16:12 2004 Raid Level : raid0 Array Size : 35565056 (33.92 GiB 36.46 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sat Jul 24 21:16:12 2004 State : dirty, no-errors Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Chunk Size : 64K Number Major Minor RaidDevice State 0 8 81 0 active sync /dev/sdf1 1 8 97 1 active sync /dev/sdg1 2 8 113 2 active sync /dev/sdh1 3 8 129 3 active sync /dev/sdi1 UUID : 2e3f1b40:01d6b0a0:f08ed8ec:9936997f ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. rom owner-linux-xfs Tue Aug 3 13:11:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Aug 2004 13:12:06 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i73KBsjR017872 for ; Tue, 3 Aug 2004 13:11:55 -0700 Received: (qmail 28117 invoked from network); 3 Aug 2004 20:04:34 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 3 Aug 2004 20:04:34 -0000 Date: Tue, 3 Aug 2004 22:11:44 +0200 From: Adrian Bunk To: Alan Cox Cc: Andrew Morton , Linux Kernel Mailing List , xfs-masters@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: [2.6 patch] let 4KSTACKS depend on EXPERIMENTAL (fwd) Message-ID: <20040803201143.GE2746@fs.tum.de> References: <20040802225951.GR2746@fs.tum.de> <20040802162846.3929e463.akpm@osdl.org> <20040803004509.GW2746@fs.tum.de> <1091490958.1647.25.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1091490958.1647.25.camel@localhost.localdomain> User-Agent: Mutt/1.5.6i X-archive-position: 3824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: linux-xfs On Tue, Aug 03, 2004 at 12:56:01AM +0100, Alan Cox wrote: > On Maw, 2004-08-03 at 01:45, Adrian Bunk wrote: > > OTOH, at least XFS is known to have problems with 4kb stacks - and you > > don't want such problems to occur in production environments. > > So put && !4KSTACKS in the XFS configuration ? The patch below does exactly this. The 4KSTACKS option has to be moved for that it's asked before XFS in "make config". diffstat output: arch/i386/Kconfig | 18 +++++++++--------- fs/Kconfig | 1 + 2 files changed, 10 insertions(+), 9 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.8-rc2-full/arch/i386/Kconfig.old 2004-07-20 21:00:32.000000000 +0200 +++ linux-2.6.8-rc2-full/arch/i386/Kconfig 2004-07-20 21:03:30.000000000 +0200 @@ -865,6 +865,15 @@ generate incorrect output with certain kernel constructs when -mregparm=3 is used. +config 4KSTACKS + bool "Use 4Kb for kernel stacks instead of 8Kb" + help + If you say Y here the kernel will use a 4Kb stacksize for the + kernel stack attached to each process/thread. This facilitates + running more threads on a system and also reduces the pressure + on the VM subsystem for higher order allocations. This option + will also use IRQ stacks to compensate for the reduced stackspace. + endmenu @@ -1289,15 +1299,6 @@ If you don't debug the kernel, you can say N, but we may not be able to solve problems without frame pointers. -config 4KSTACKS - bool "Use 4Kb for kernel stacks instead of 8Kb" - help - If you say Y here the kernel will use a 4Kb stacksize for the - kernel stack attached to each process/thread. This facilitates - running more threads on a system and also reduces the pressure - on the VM subsystem for higher order allocations. This option - will also use IRQ stacks to compensate for the reduced stackspace. - config X86_FIND_SMP_CONFIG bool depends on X86_LOCAL_APIC || X86_VOYAGER --- linux-2.6.8-rc2-full/fs/Kconfig.old 2004-07-20 21:04:02.000000000 +0200 +++ linux-2.6.8-rc2-full/fs/Kconfig 2004-07-20 21:04:25.000000000 +0200 @@ -294,6 +294,7 @@ config XFS_FS tristate "XFS filesystem support" + depends on (4KSTACKS=n || BROKEN) help XFS is a high performance journaling filesystem which originated on the SGI IRIX platform. It is completely multi-threaded, can From owner-linux-xfs Tue Aug 3 17:49:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Aug 2004 17:49:43 -0700 (PDT) Received: from zero.aec.at (Junker_Barlow@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i740ncwA032135 for ; Tue, 3 Aug 2004 17:49:39 -0700 Received: from averell.firstfloor.org.muc.de (Theodore_Roosevelt@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i740m9X01390; Wed, 4 Aug 2004 02:48:11 +0200 To: L A Walsh cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, nathans@sgi.com Subject: Re: XFS: how to NOT null files on fsck? References: <200407050247.53743.norberto+linux-kernel@bensa.ath.cx> <40EEC9DC.8080501@tlinx.org> <20040729013049.GE800@frodo> <410FDA19.9020805@tlinx.org> From: Andi Kleen Date: Wed, 04 Aug 2004 02:48:09 +0200 In-Reply-To: <410FDA19.9020805@tlinx.org> (L. A. Walsh's message of "Tue, 03 Aug 2004 11:31:53 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3825 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 660 Lines: 19 L A Walsh writes: > Now I know it takes a while before data may end up on disk and that it > may not go out to disk in an ordered fashion, but 2-3 days? This isn't > a case of a multi-extent file. My current fstab is only 1335 bytes long. > I doubt it has ever been more than 2. Is this perhaps on a laptop? Some scripts for laptop use configure insanely long data flush times to conserve HD spin time. Sometimes it is even completely turned off (laptop mode). The extent flush is dependent on the configured bdflush or pdflushd data timeouts. The truncate is independent from this because it is flushed with a different path. -Andi From owner-linux-xfs Tue Aug 3 21:05:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Aug 2004 21:05:23 -0700 (PDT) Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7445Jig007494 for ; Tue, 3 Aug 2004 21:05:20 -0700 Received: from elaine24.Stanford.EDU (elaine24.Stanford.EDU [171.64.15.99]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i7445Abk013048 for ; Tue, 3 Aug 2004 21:05:10 -0700 Received: (from yjf@localhost) by elaine24.Stanford.EDU (8.12.10/8.12.9) id i744590V002912; Tue, 3 Aug 2004 21:05:09 -0700 (PDT) Date: Tue, 3 Aug 2004 21:05:09 -0700 (PDT) From: Junfeng Yang To: linux-xfs@oss.sgi.com Subject: xfs 1.3.1 patch for kernel 2.4.19? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yjf@stanford.edu Precedence: bulk X-list: linux-xfs Content-Length: 6863 Lines: 207 Hi, I'm a Ph.D. student in Prof. Dawson Engler's checking group. Currently our group is working on a file system checking tool. We've checked ext3, IBM JFS and reiserfs and found serious bugs in all of them. We would like to check XFS since it is even more widely used. Unfortunately the kernel that we based our checker on is 2.4.19, and I couldn't find a 1.3.1 core patch for 2.4.19. I tried to apply linux-2.4.21-core-xfs-1.3.1.patch but 12 hunks failed. I'm wondering if you guys have a 2.4.19 xfs-1.3.1 core patch that I can download. Thanks a lot, -Junfeng rom owner-linux-xfs Tue Aug 3 23:04:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Aug 2004 23:04:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74640eK010610 for ; Tue, 3 Aug 2004 23:04:00 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i7463l118806; Tue, 3 Aug 2004 23:03:47 -0700 Date: Tue, 3 Aug 2004 23:02:17 -0700 From: Andrew Morton To: linux-xfs@oss.sgi.com Cc: karoly.vegh@uta.at Subject: Fw: [Bug 3152] New: XFS Oops + page allocation failure Message-Id: <20040803230217.247199c6.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs The 2.6.8-rc2 oops trace is here: http://web.utanet.at/charlie/dmesg Begin forwarded message: Date: Tue, 3 Aug 2004 16:33:27 -0700 From: bugme-daemon@osdl.org To: akpm@digeo.com Subject: [Bug 3152] New: XFS Oops + page allocation failure http://bugme.osdl.org/show_bug.cgi?id=3152 Summary: XFS Oops + page allocation failure Kernel Version: 2.6.8-rc2 Status: NEW Severity: normal Owner: akpm@digeo.com Submitter: karoly.vegh@uta.at Distribution: Debian Sarge Hardware Environment: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50) 00:09.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 54) 00:0c.0 RAID bus controller: 3ware Inc 3ware ATA-RAID (rev 12) 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) ~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 896.693 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1789.13 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 896.693 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1789.13 ~$ free total used free shared buffers cached Mem: 903416 192712 710704 0 17468 79792 -/+ buffers/cache: 95452 807964 Swap: 1999928 0 1999928 Software Environment: charlie@unet:~$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.4/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.4 (Debian) charlie@unet:~$ make -version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i386-pc-linux-gnu Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . charlie@unet:~$ ii binutils 2.14.90.0.7-6 The GNU assembler, linker and binary utilities ii memtester 2.93.1-2 A utility for testing the memory subsystem xfsprogs version: our XFS storage was set up with 2.0.3, now we upgraded to 2.6.18. Problem Description: Problems began with an XFS problem, see: http://web.utanet.at/charlie/dmesg well, at this point our thought was: RAM problem. We took out one half of our RAM-blocks, and booted. After the boot we used memtester ( http://www.qcc.ca/~charlesc/software/memtester/ ) to check coupole of things on the box. with 'memtest all' we tried to test. The answer was at once a page allocation failure, see: http://web.utanet.at/charlie/dmesg.2 This we were able to reproduce. After changeing RAM blocks to the other half of our sum of RAMs, we got the same page allocation failure. swap was plenty to get. We excluded the hw as a source for the troubles. But we're not sure, if the XFS and the page allocation problem hang together or not. Steps to reproduce: boot. memtester. The XFS problem thx god we couldn't reproduce. it's 1:30 a.m. here now, so if I was a bit confuse, pls forgive me. feel free to contact me for more info about the box. Since the machine is in productive status, we switched back to 2.4.27-rc4, since there memtester couldn't have crashed the box. kernelconfig: http://web.utanet.at/charlie/config-2.6.8-rc2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 3 23:38:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Aug 2004 23:38:26 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i746cNUw011614 for ; Tue, 3 Aug 2004 23:38:23 -0700 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i746bfBi030913; Tue, 3 Aug 2004 23:37:41 -0700 Message-ID: <41108433.9040002@tlinx.org> Date: Tue, 03 Aug 2004 23:37:39 -0700 From: L A Walsh User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, nathans@sgi.com Subject: Re: XFS: how to NOT null files on fsck? References: <200407050247.53743.norberto+linux-kernel@bensa.ath.cx> <40EEC9DC.8080501@tlinx.org> <20040729013049.GE800@frodo> <410FDA19.9020805@tlinx.org> In-Reply-To: X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 777 Lines: 32 Not laptop, 2-CPU workstation used as home "server". :-) Andi Kleen wrote: >L A Walsh writes: > > > >>Now I know it takes a while before data may end up on disk and that it >>may not go out to disk in an ordered fashion, but 2-3 days? This isn't >>a case of a multi-extent file. My current fstab is only 1335 bytes long. >>I doubt it has ever been more than 2. >> >> > >Is this perhaps on a laptop? Some scripts for laptop use configure >insanely long data flush times to conserve HD spin time. Sometimes >it is even completely turned off (laptop mode). The extent >flush is dependent on the configured bdflush or pdflushd data >timeouts. > >The truncate is independent from this because it is flushed with a >different path. > >-Andi > > > > From owner-linux-xfs Wed Aug 4 06:23:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 06:23:31 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74DNSDd007695 for ; Wed, 4 Aug 2004 06:23:28 -0700 Received: from mail.eljako.org (juvenal-1-82-224-138-111.fbx.proxad.net [82.224.138.111]) by postfix4-1.free.fr (Postfix) with ESMTP id 0CB0316EB01 for ; Wed, 4 Aug 2004 15:23:23 +0200 (CEST) Received: from mail.sequensys.dnsalias.com (mail.sequensys.dnsalias.com [127.1.1.1]) by mail.eljako.org (Postfix) with SMTP id 317978582 for ; Wed, 4 Aug 2004 15:23:19 +0200 (CEST) Received: from sequensys.com (perenoel.sequensys.dnsalias.com [192.168.0.103]) by mail.sequensys.dnsalias.com (Postfix) with ESMTP id 117BC4A5FC for ; Wed, 4 Aug 2004 15:23:07 +0200 (CEST) Message-ID: <4110E341.9000205@sequensys.com> Date: Wed, 04 Aug 2004 15:23:13 +0200 From: Claude-Jacques Tronquet Organization: http://www.sequensys.com User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: ACL-over-XFS patch for 2.4.26 kernels? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cjt@sequensys.com Precedence: bulk X-list: linux-xfs Content-Length: 112 Lines: 7 Hi, Is there any plan to provide the acl/xfs patch for 2.4.26 kernels? Best regards, Claude-Jacques Tronquet From owner-linux-xfs Wed Aug 4 06:34:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 06:34:27 -0700 (PDT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74DYGr4008610 for ; Wed, 4 Aug 2004 06:34:17 -0700 Received: from mail.ter.nu ([213.114.210.36] [213.114.210.36]) by mxfep02.bredband.com with ESMTP id <20040804133407.LTHG23867.mxfep02.bredband.com@mail.ter.nu>; Wed, 4 Aug 2004 15:34:07 +0200 Received: from grabbarna.nu (w.tenet [192.168.0.5]) by mail.ter.nu (Postfix) with ESMTP id E93109981AF; Wed, 4 Aug 2004 15:34:04 +0200 (CEST) Message-ID: <4110E5FF.3070203@grabbarna.nu> Date: Wed, 04 Aug 2004 15:34:55 +0200 From: Jan Banan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Chris Wedgwood Subject: Re: Recover a XFS on raid -1 (linear) when one disk is broken References: <40F6DBC1.6050909@grabbarna.nu> <20040715205910.GA9948@taniwha.stupidest.org> <40F9321C.7060403@grabbarna.nu> <20040717203943.GL20260@plato.local.lan> <410ADC0A.6060100@grabbarna.nu> <20040731054924.GA4748@taniwha.stupidest.org> <410B4BC3.8000404@grabbarna.nu> <20040731091220.GA6158@taniwha.stupidest.org> <410BE0A9.3030904@grabbarna.nu> <20040731183312.GD11283@taniwha.stupidest.org> In-Reply-To: <20040731183312.GD11283@taniwha.stupidest.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b@grabbarna.nu Precedence: bulk X-list: linux-xfs Content-Length: 2772 Lines: 75 >>According to the man-page of "dd" then "seek" and "skip" skips >>"ibs/obs-sized BLOCKS" and not "SECTORS". So am I typing the correct >>value (28117692)? > > > for bs=512 the 'dd BLOCKS' are sectors. There is one thing that seem strange to me. "fdisk -l /dev/hdh" (the damaged harddisk) says /dev/hdh1 1 30515 245111706 83 Linux But now "dd" is working with sectors above 245111706, how is that possible? Right now it seem to be at 244536664 according to /var/log/messages: Aug 4 15:32:56 d kernel: hdh: dma_intr: status=0x51 { DriveReady SeekComplete Error } Aug 4 15:32:56 d kernel: hdh: dma_intr: error=0x40 { UncorrectableError }, LBAsect=244536735, high=14, low=9655711, sector=244536672 Aug 4 15:32:56 d kernel: end_request: I/O error, dev 22:41 (hdh), sector 244536672 Best regards, Jan rom owner-linux-xfs Wed Aug 4 06:55:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 06:55:49 -0700 (PDT) Received: from mail.dfi-intl.com (w0user.dfi-intl.com [63.174.101.50] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74Dtew4009295 for ; Wed, 4 Aug 2004 06:55:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: XFS vs. EXT3 - Performance Questions. Date: Wed, 4 Aug 2004 09:55:31 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS vs. EXT3 - Performance Questions. Thread-Index: AcR6KrSyVE/qDPwQTzyG+Ds1QyVGBQ== From: "Errol Neal" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i74Dtfw4009296 X-archive-position: 3831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: eneal@dfi-intl.com Precedence: bulk X-list: linux-xfs Hello folks. I am trying to determine if XFS offers any performance advantages over EXT3 for our environment. I've been doing some testing between the two using a Power Edge 1650 with 1GB Ram, 2 X 1.4 PIII CPUs and a single 36 GB disk. In my silly little "which file system can untar a kernel tar file the fastest", ext3 has always been faster, I mean significantly. Can anyone help me understand when one would want to use XFS over the default linux FS. Thanks in advance. Errol __________________________________________ Errol Uriel Neal Jr. Network Administrator DFI International, Inc. 1717 Pennsylvania Ave NW, Suite 1300 Washington, DC 20006 Tel (202)452-6955 Fax (202)452-6910 eneal@dfi-intl.com www.dfi-intl.com From owner-linux-xfs Wed Aug 4 06:55:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 06:55:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74DtosR009337 for ; Wed, 4 Aug 2004 06:55:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i74DtoHt009336 for linux-xfs@oss.sgi.com; Wed, 4 Aug 2004 06:55:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74Dtmxx009311 for ; Wed, 4 Aug 2004 06:55:49 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i74DE8Aw007351; Wed, 4 Aug 2004 06:14:08 -0700 Date: Wed, 4 Aug 2004 06:14:08 -0700 Message-Id: <200408041314.i74DE8Aw007351@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3832 X-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: 2130 Lines: 56 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From dbatchovski@technologica.com 2004-04-08 06:14 PDT ------- Can confirm the same bug.Celeron 850, Kernel 2.6.7, Debian Sarge. System crash when try intensive disk IO. Boot log follow: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: raid1 personality registered as nr 3 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:07.1 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci0000:00:07.1 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio hda: ST38410A, ATA DISK drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: ST38410A, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 16841664 sectors (8622 MB) w/512KiB Cache, CHS=16708/16/63, UDMA(66) /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 hdc: max request size: 128KiB hdc: 16841664 sectors (8622 MB) w/512KiB Cache, CHS=16708/16/63, UDMA(66) /dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4 md: md0 stopped. md: bind md: bind raid1: raid set md0 active with 2 out of 2 mirrors mdadm: /devfs/md/0 has been started with 2 drives. SGI XFS with ACLs, security attributes, realtime, large block numbers, no debugd SGI XFS Quota Management subsystem XFS mounting filesystem md0 Starting XFS recovery on filesystem: md0 (dev: md0) Ending XFS recovery on filesystem: md0 (dev: md0) INIT: version 2.85 booting Activating swap. Unable to find swap-space signature xfs_force_shutdown(md0,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. b Filesystem "md0": Corruption of in-memory data detected. Shutting down filesys0 Please umount the filesystem, and rectify the problem(s) can't create loc ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Aug 4 07:55:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 07:55:57 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74EtoUV012098 for ; Wed, 4 Aug 2004 07:55:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i74EtoEb012097 for linux-xfs@oss.sgi.com; Wed, 4 Aug 2004 07:55:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74Etmxt012083 for ; Wed, 4 Aug 2004 07:55:48 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i74EOPs2010756; Wed, 4 Aug 2004 07:24:25 -0700 Date: Wed, 4 Aug 2004 07:24:25 -0700 Message-Id: <200408041424.i74EOPs2010756@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3833 X-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: 18339 Lines: 449 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From sandeen@sgi.com 2004-04-08 07:24 PDT ------- Talked with peter, confirmed no other messages prior to shutdown: Aug 4 10:37:01 oplapro97 kernel: XFS mounting filesystem md0 Aug 4 10:39:50 oplapro97 kernel: xfs_force_shutdown(md0,0x8) called from line 1088 of file fs/xfs_trans.c. Return address = 0xa0000002002b4dd0 If anyone who's hitting this reliably can get kdb compiled in, please set the xfs_panic_mask to BUG on a shutdown (see xfs.txt in the kernel tree), load xfsidbg, and then when the fs shuts down & bugs, try dumping the transaction with the "xtp" command in kdb - find the transaction pointer in one of the arguments on the stack. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. rom owner-linux-xfs Wed Aug 4 08:34:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 08:34:21 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74FYBKk016583 for ; Wed, 4 Aug 2004 08:34:12 -0700 Received: from localhost (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id BB29E886E25 for ; Wed, 4 Aug 2004 23:34:06 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gusi.leathercollection.ph (Postfix) with ESMTP id 35F0C886E22 for ; Wed, 4 Aug 2004 23:33:58 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 9017EA563B19; Wed, 4 Aug 2004 23:33:56 +0800 (PHT) Date: Wed, 4 Aug 2004 23:33:56 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Irreparable 'corrupt dinode ... error 990' Revisited Message-ID: <20040804153356.GD26826@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline 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.6+20040523i X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at leathercollection.ph X-archive-position: 3834 X-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 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi everyone, This isn't the first time I bumped into this problem, although this is the first time I'm reporting it. I'm using Debian Sid and Linux kernel 2.4.26 with the following patches installed from : - 010-lckbase.diff.bz2 - 011-readlatency2.diff.bz2 - 012-rl2dt.diff.bz2 - 013-j64.diff.bz2 - 014-vhz.diff.bz2 - 032-nfsacl-0.8.71.diff.bz2 The problem was triggered by, I believe, the hard system lockup caused by some problem with my external USB hard drive enclosure (accessed via usb-storage, it's essentially a USB to IDE controller/converter with a case). I don't know how to reproduce the lockup itself, however during both instances that this lockup happened I got filesystem corruption after that xfs_repair could not repair. I would have understood filesystem corruption in the filesystem stored on the external storage. Unfortunately, I had filesystem corruption in my root filesystem, which is /dev/hda1. Right after the lockup I did a hard reset (the system would not respond to anything: no network, no keyboard, no mouse) and the system booted up fine. I had a hunch there was corruption, though, so I rebooted using Knoppix 3.4 2004-05-17 (which has Linux kernel 2.4.26 and xfsprogs 2.6.11) and used xfs_repair to try and fix /dev/hda1. The first pass put a number of files in lost+found, which on inspection were files from tmp that were probably in the middle of being saved or modified during the lockup. It reported a lot of other errors, but I wasn't able to take note of these. It ended with a report about an unrepairable error 990 on a corrupted dinode. I was able to capture the output of the second pass of xfs_repair. The same dinode corruption prevented it from finishing cleanly. The output of the second pass of xfs_repair is attached as xfs_repair_verbose.log. Having had "experience" with this, I used the du utility to find out which particular file had a problem. I isolated it to the file , which I had not touched since I upgraded the gimp-data package at least a few weeks ago. I can't understand why this inode was corrupt. I didn't need the file, though, so I just got some more information on the corrupt dinode based on instructions to someone else on the list, then removed it by zeroing out core.size and core.extents before running a third pass of xfs_repair which completed successfully. The output of xfs_info for the filesystem is attached as xfs_info.log. The output of xfs_check querying the corrupt inode is attached as xfs_db_244162409.log. The output of the third pass of xfs_repair is attached as xfs_repair_verbose_afterxfsdbpurge244162409.log. No other inodes seem to have been corrupted. xfs_check gave the filesystem a clean bill of health. I haven't tried a fourth pass with xfs_repair, though. Should I do it again, just to be sure? Some other files were corrupted as far as the applications that use them is concerned, though, so I had to work things out to correct these on the application level (eg: do a full reimport of Lurker's archives due to a database corruption there, remove Cyrus user.seen files due to corruption there). Why these files were corrupted is beyond me. I figure it's the data vs. metadata journalling story, once again. Oh well. :( I hope the information I've provided here can help in any way. The last time it happened I also "fixed" things by removing the files using the xfs_db hack. They couldn't be removed any other way (eg: any normal filesystem access to the corrupt inode barfs with an error 990). --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_repair_verbose.log" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 799 tail block 799 - 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 data fork in ino 50343204 claims free block 3157855 data fork in ino 50343204 claims free block 3157856 data fork in ino 50343204 claims free block 3157857 data fork in ino 50343204 claims free block 3157858 data fork in ino 50343204 claims free block 3157859 data fork in ino 50343204 claims free block 3157860 data fork in ino 50343204 claims free block 3157861 data fork in ino 50343204 claims free block 3158364 data fork in ino 50343204 claims free block 3158365 data fork in ino 50343204 claims free block 3158366 data fork in ino 50343204 claims free block 3158367 data fork in ino 50343204 claims free block 3158368 data fork in ino 50343204 claims free block 3158369 data fork in ino 50343204 claims free block 3158370 data fork in ino 50343204 claims free block 3158371 data fork in ino 50343204 claims free block 3158372 data fork in ino 50343204 claims free block 3158373 data fork in ino 50343204 claims free block 3158374 data fork in ino 50343204 claims free block 3158375 data fork in ino 50343204 claims free block 3158363 data fork in ino 50343204 claims free block 3158362 data fork in ino 50343204 claims free block 3158360 data fork in ino 50343204 claims free block 3158361 data fork in ino 50343204 claims free block 3158359 data fork in ino 50343204 claims free block 3158358 data fork in ino 50343204 claims free block 3158357 data fork in ino 50343204 claims free block 3158356 data fork in ino 50343204 claims free block 3158355 data fork in ino 50343204 claims free block 3158353 data fork in ino 50343204 claims free block 3158354 data fork in ino 50343204 claims free block 3158352 data fork in ino 50343204 claims free block 3158351 data fork in ino 50343204 claims free block 3158350 data fork in ino 50343204 claims free block 3158349 data fork in ino 50343204 claims free block 3158348 data fork in ino 50343204 claims free block 3158347 data fork in ino 50343204 claims free block 3158346 data fork in ino 50343204 claims free block 3158344 data fork in ino 50343204 claims free block 3158345 data fork in ino 50343204 claims free block 3158343 data fork in ino 50343204 claims free block 3158342 data fork in ino 50343204 claims free block 3158341 data fork in ino 50343204 claims free block 3158340 data fork in ino 50343204 claims free block 3158338 data fork in ino 50343204 claims free block 3158339 data fork in ino 50343204 claims free block 3158337 data fork in ino 50343204 claims free block 3158336 data fork in ino 50343204 claims free block 3158335 data fork in ino 50343204 claims free block 3158334 data fork in ino 50343204 claims free block 3158333 data fork in ino 50343204 claims free block 3158332 data fork in ino 50343204 claims free block 3158331 data fork in ino 50343204 claims free block 3158330 correcting nblocks for inode 50343204, was 80620 - counted 81072 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 correcting nblocks for inode 244162409, was 0 - counted 1 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 data fork in regular inode 50343204 claims used block 7920128 correcting nblocks for inode 50343204, was 81072 - counted 80620 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 data fork in regular inode 244162409 claims used block 15260160 correcting nblocks for inode 244162409, was 1 - counted 0 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... corrupt dinode 244162409, extent total = 1, nblocks = 0. Unmount and run xfs_repair. fatal error -- couldn't map inode 244162409, err = 990 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_info.log" meta-data=/mnt/hda1 isize=256 agcount=16, agsize=580097 blks = sectsz=512 data = bsize=4096 blocks=9281552, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_db_244162409.log" core.magic = 0x494e core.mode = 0100644 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 0 core.gid = 0 core.flushiter = 9 core.atime.sec = Sun Jun 27 23:59:12 2004 core.atime.nsec = 000000000 core.mtime.sec = Thu Jun 24 21:13:39 2004 core.mtime.nsec = 000000000 core.ctime.sec = Sun Jun 27 23:59:33 2004 core.ctime.nsec = 566118000 core.size = 503 core.nblocks = 0 core.extsize = 0 core.nextents = 1 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.gen = 3 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,15260160,1,0] --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_repair_verbose_afterxfsdbpurge244162409.log" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - 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 data fork in ino 50343204 claims free block 3157855 data fork in ino 50343204 claims free block 3157856 data fork in ino 50343204 claims free block 3157857 data fork in ino 50343204 claims free block 3157858 data fork in ino 50343204 claims free block 3157859 data fork in ino 50343204 claims free block 3157860 data fork in ino 50343204 claims free block 3157861 data fork in ino 50343204 claims free block 3158364 data fork in ino 50343204 claims free block 3158365 data fork in ino 50343204 claims free block 3158366 data fork in ino 50343204 claims free block 3158367 data fork in ino 50343204 claims free block 3158368 data fork in ino 50343204 claims free block 3158369 data fork in ino 50343204 claims free block 3158370 data fork in ino 50343204 claims free block 3158371 data fork in ino 50343204 claims free block 3158372 data fork in ino 50343204 claims free block 3158373 data fork in ino 50343204 claims free block 3158374 data fork in ino 50343204 claims free block 3158375 data fork in ino 50343204 claims free block 3158363 data fork in ino 50343204 claims free block 3158362 data fork in ino 50343204 claims free block 3158360 data fork in ino 50343204 claims free block 3158361 data fork in ino 50343204 claims free block 3158359 data fork in ino 50343204 claims free block 3158358 data fork in ino 50343204 claims free block 3158357 data fork in ino 50343204 claims free block 3158356 data fork in ino 50343204 claims free block 3158355 data fork in ino 50343204 claims free block 3158353 data fork in ino 50343204 claims free block 3158354 data fork in ino 50343204 claims free block 3158352 data fork in ino 50343204 claims free block 3158351 data fork in ino 50343204 claims free block 3158350 data fork in ino 50343204 claims free block 3158349 data fork in ino 50343204 claims free block 3158348 data fork in ino 50343204 claims free block 3158347 data fork in ino 50343204 claims free block 3158346 data fork in ino 50343204 claims free block 3158344 data fork in ino 50343204 claims free block 3158345 data fork in ino 50343204 claims free block 3158343 data fork in ino 50343204 claims free block 3158342 data fork in ino 50343204 claims free block 3158341 data fork in ino 50343204 claims free block 3158340 data fork in ino 50343204 claims free block 3158338 data fork in ino 50343204 claims free block 3158339 data fork in ino 50343204 claims free block 3158337 data fork in ino 50343204 claims free block 3158336 data fork in ino 50343204 claims free block 3158335 data fork in ino 50343204 claims free block 3158334 data fork in ino 50343204 claims free block 3158333 data fork in ino 50343204 claims free block 3158332 data fork in ino 50343204 claims free block 3158331 data fork in ino 50343204 claims free block 3158330 correcting nblocks for inode 50343204, was 80620 - counted 81072 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 data fork in regular inode 50343204 claims used block 7920128 correcting nblocks for inode 50343204, was 81072 - counted 80620 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done --9zSXsLTf0vkW971A-- From owner-linux-xfs Wed Aug 4 09:10:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 09:11:05 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74GApwP018139 for ; Wed, 4 Aug 2004 09:10:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i74HCmUB012614 for ; Wed, 4 Aug 2004 10:12:48 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i74G9kOV44340602; Wed, 4 Aug 2004 11:09:47 -0500 (CDT) Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i74G9kQM035183; Wed, 4 Aug 2004 11:09:46 -0500 (CDT) Subject: Re: xfs 1.3.1 patch for kernel 2.4.19? From: Eric Sandeen To: Junfeng Yang Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1091635785.5415.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 04 Aug 2004 11:09:46 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3835 X-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: 3250 Lines: 82 Hi Junfeng - Hm, pity you're using such an old kernel. :) We'd be happy to have you check xfs though, thanks - let me see what I can do about getting recent xfs code into 2.4.19.... -Eric On Tue, 2004-08-03 at 23:05, Junfeng Yang wrote: > Hi, > > I'm a Ph.D. student in Prof. Dawson Engler's checking group. Currently > our group is working on a file system checking tool. We've checked ext3, > IBM JFS and reiserfs and found serious bugs in all of them. We would like > to check XFS since it is even more widely used. Unfortunately the kernel > that we based our checker on is 2.4.19, and I couldn't find a 1.3.1 core > patch for 2.4.19. I tried to apply linux-2.4.21-core-xfs-1.3.1.patch but > 12 hunks failed. I'm wondering if you guys have a 2.4.19 xfs-1.3.1 core > patch that I can download. > > Thanks a lot, > -Junfeng -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 rom owner-linux-xfs Wed Aug 4 09:34:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 09:34:51 -0700 (PDT) Received: from mail-h12-02.cc.ksu.edu (mail-h12-02.cc.ksu.edu [129.130.12.151]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74GYhs7030171 for ; Wed, 4 Aug 2004 09:34:44 -0700 Received: from unix2.cc.ksu.edu (unix2.cc.ksu.edu [129.130.12.4]) by mail-h12-02.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id i74GYVfY018755; Wed, 4 Aug 2004 11:34:35 -0500 (CDT) Received: from localhost (matts@localhost) by unix2.cc.ksu.edu (8.11.6+Sun/8.11.6) with ESMTP id i74GYV310756; Wed, 4 Aug 2004 11:34:31 -0500 (CDT) X-Authentication-Warning: unix2.cc.ksu.edu: matts owned process doing -bs Date: Wed, 4 Aug 2004 11:34:30 -0500 (CDT) From: Matt Stegman X-X-Sender: matts@unix2.cc.ksu.edu To: Jan Banan cc: linux-xfs@oss.sgi.com, Chris Wedgwood Subject: Re: Recover a XFS on raid -1 (linear) when one disk is broken In-Reply-To: <4110E5FF.3070203@grabbarna.nu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean X-archive-position: 3836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matts@ksu.edu Precedence: bulk X-list: linux-xfs Because fdisk is reporting kilobytes (blocks of 1024 bytes) while the kernel is reporting 512 byte sectors. -- Matt Stegman On Wed, 4 Aug 2004, Jan Banan wrote: > There is one thing that seem strange to me. "fdisk -l /dev/hdh" (the > damaged harddisk) says > > /dev/hdh1 1 30515 245111706 83 Linux > > But now "dd" is working with sectors above 245111706, how is that > possible? Right now it seem to be at 244536664 according to > /var/log/messages: > > Aug 4 15:32:56 d kernel: hdh: dma_intr: status=0x51 { DriveReady > SeekComplete Error } > Aug 4 15:32:56 d kernel: hdh: dma_intr: error=0x40 { UncorrectableError > }, LBAsect=244536735, high=14, low=9655711, sector=244536672 > Aug 4 15:32:56 d kernel: end_request: I/O error, dev 22:41 (hdh), > sector 244536672 From owner-linux-xfs Wed Aug 4 09:40:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 09:40:55 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74GepC2031174 for ; Wed, 4 Aug 2004 09:40:51 -0700 Received: from localhost (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 7692F886E5E for ; Thu, 5 Aug 2004 00:40:46 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gusi.leathercollection.ph (Postfix) with ESMTP id 3474D886DA1 for ; Thu, 5 Aug 2004 00:40:38 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id AE4EDA54F1B6; Thu, 5 Aug 2004 00:40:37 +0800 (PHT) Date: Thu, 5 Aug 2004 00:40:37 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Re: Irreparable 'corrupt dinode ... error 990' Revisited Message-ID: <20040804164037.GC18867@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List References: <20040804153356.GD26826@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804153356.GD26826@leathercollection.ph> 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.6+20040523i X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at leathercollection.ph X-archive-position: 3837 X-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: 2970 Lines: 66 On Wed, Aug 04, 2004 at 11:33:56PM +0800, Federico Sevilla III wrote: > The problem was triggered by, I believe, the hard system lockup caused > by some problem with my external USB hard drive enclosure (accessed > via usb-storage, it's essentially a USB to IDE controller/converter > with a case). I don't know how to reproduce the lockup itself, however > during both instances that this lockup happened I got filesystem > corruption after that xfs_repair could not repair. > > I would have understood filesystem corruption in the filesystem stored > on the external storage. Unfortunately, I had filesystem corruption in > my root filesystem, which is /dev/hda1. I just mounted, unmounted, then did an xfs_repair of my filesystem in the external storage, and it did NOT have any corruption despite the fact that I was doing file operations on it when the lockup occured. Strange! The root filesystem goes bork (on an otherwise idle inode), but the active filesystem on the device that causes the crash (I think it causes it anyway) is a-okay. --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. rom owner-linux-xfs Wed Aug 4 10:36:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 10:37:05 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74HawaS002446 for ; Wed, 4 Aug 2004 10:36:58 -0700 Received: from taniwha.stupidest.org (adsl-63-202-172-176.dsl.snfc21.pacbell.net [63.202.172.176]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i74Har5C132454 for ; Wed, 4 Aug 2004 13:36:53 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id DDA74115C868; Wed, 4 Aug 2004 10:36:51 -0700 (PDT) Date: Wed, 4 Aug 2004 10:36:51 -0700 From: Chris Wedgwood To: Linux-XFS Mailing List Subject: Re: Irreparable 'corrupt dinode ... error 990' Revisited Message-ID: <20040804173651.GA1107@taniwha.stupidest.org> References: <20040804153356.GD26826@leathercollection.ph> <20040804164037.GC18867@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804164037.GC18867@leathercollection.ph> X-archive-position: 3838 X-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 On Thu, Aug 05, 2004 at 12:40:37AM +0800, Federico Sevilla III wrote: > I just mounted, unmounted, then did an xfs_repair of my filesystem > in the external storage, and it did NOT have any corruption despite > the fact that I was doing file operations on it when the lockup > occured. Could be an in-memory corruption. Do you have ECC memory? --cw From owner-linux-xfs Wed Aug 4 14:13:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 14:13:14 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74LDBZd024030 for ; Wed, 4 Aug 2004 14:13:11 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i74MF9qE007340 for ; Wed, 4 Aug 2004 15:15:10 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i74LC6OV44288096; Wed, 4 Aug 2004 16:12:06 -0500 (CDT) Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i74LC5QM069301; Wed, 4 Aug 2004 16:12:05 -0500 (CDT) Subject: Re: xfs 1.3.1 patch for kernel 2.4.19? From: Eric Sandeen To: Junfeng Yang Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1091653925.5415.50.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 04 Aug 2004 16:12:05 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3839 X-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: 1303 Lines: 34 http://oss.sgi.com/~sandeen/linux-2.4.19-xfs contains patches for top of tree xfs to work with 2.4.19, for the stanford checker folks. linux-2.4.19-xfs-TOT-core.patch - patch for core linux 2.4.19 tree xfs-TOT-for-2.4.19.patch - patch against latest fs/xfs from CVS This builds & functions basically for me, although I do manage to hit some bugs in core kernel changes that existed in 2.4.19, because I took the existing core 2.4.19 patch to start with. If these bugs get in the way of testing, please let me know. -Eric On Tue, 2004-08-03 at 23:05, Junfeng Yang wrote: > Hi, > > I'm a Ph.D. student in Prof. Dawson Engler's checking group. Currently > our group is working on a file system checking tool. We've checked ext3, > IBM JFS and reiserfs and found serious bugs in all of them. We would like > to check XFS since it is even more widely used. Unfortunately the kernel > that we based our checker on is 2.4.19, and I couldn't find a 1.3.1 core > patch for 2.4.19. I tried to apply linux-2.4.21-core-xfs-1.3.1.patch but > 12 hunks failed. I'm wondering if you guys have a 2.4.19 xfs-1.3.1 core > patch that I can download. > > Thanks a lot, > -Junfeng -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs Wed Aug 4 14:28:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 14:28:48 -0700 (PDT) Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i74LSiF2031396 for ; Wed, 4 Aug 2004 14:28:45 -0700 Received: from elaine24.Stanford.EDU (elaine24.Stanford.EDU [171.64.15.99]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i74LSZpg018979; Wed, 4 Aug 2004 14:28:35 -0700 Received: (from yjf@localhost) by elaine24.Stanford.EDU (8.12.10/8.12.9) id i74LSYQe019228; Wed, 4 Aug 2004 14:28:34 -0700 (PDT) Date: Wed, 4 Aug 2004 14:28:34 -0700 (PDT) From: Junfeng Yang To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: xfs 1.3.1 patch for kernel 2.4.19? In-Reply-To: <1091653925.5415.50.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yjf@stanford.edu Precedence: bulk X-list: linux-xfs Content-Length: 1425 Lines: 41 cool! Thanks a lot! On Wed, 4 Aug 2004, Eric Sandeen wrote: > http://oss.sgi.com/~sandeen/linux-2.4.19-xfs contains > patches for top of tree xfs to work with 2.4.19, for the stanford > checker folks. > > linux-2.4.19-xfs-TOT-core.patch - patch for core linux 2.4.19 tree > xfs-TOT-for-2.4.19.patch - patch against latest fs/xfs from CVS > > This builds & functions basically for me, although I do manage to hit > some bugs in core kernel changes that existed in 2.4.19, because I took > the existing core 2.4.19 patch to start with. > > If these bugs get in the way of testing, please let me know. > > -Eric > > > On Tue, 2004-08-03 at 23:05, Junfeng Yang wrote: > > Hi, > > > > I'm a Ph.D. student in Prof. Dawson Engler's checking group. Currently > > our group is working on a file system checking tool. We've checked ext3, > > IBM JFS and reiserfs and found serious bugs in all of them. We would like > > to check XFS since it is even more widely used. Unfortunately the kernel > > that we based our checker on is 2.4.19, and I couldn't find a 1.3.1 core > > patch for 2.4.19. I tried to apply linux-2.4.21-core-xfs-1.3.1.patch but > > 12 hunks failed. I'm wondering if you guys have a 2.4.19 xfs-1.3.1 core > > patch that I can download. > > > > Thanks a lot, > > -Junfeng > -- > Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > From owner-linux-xfs Wed Aug 4 19:43:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 19:43:59 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i752htCR009782 for ; Wed, 4 Aug 2004 19:43:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i753jrVb025258 for ; Wed, 4 Aug 2004 20:45:54 -0700 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 MAA15701; Thu, 5 Aug 2004 12:43:45 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i752hgln2918617; Thu, 5 Aug 2004 12:43:43 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i753dmgh003632; Thu, 5 Aug 2004 13:39:50 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i753dk8l003630; Thu, 5 Aug 2004 13:39:46 +1000 Date: Thu, 5 Aug 2004 13:39:45 +1000 From: Nathan Scott To: Claude-Jacques Tronquet Cc: linux-xfs@oss.sgi.com Subject: Re: ACL-over-XFS patch for 2.4.26 kernels? Message-ID: <20040805033945.GA3619@frodo> References: <4110E341.9000205@sequensys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4110E341.9000205@sequensys.com> User-Agent: Mutt/1.5.3i X-archive-position: 3841 X-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: 306 Lines: 14 On Wed, Aug 04, 2004 at 03:23:13PM +0200, Claude-Jacques Tronquet wrote: > Hi, > > Is there any plan to provide the acl/xfs patch for 2.4.26 kernels? This has been provided for awhile - see the split-patches directory at the top of the CVS tree, it contains a patch "acl-backport". cheers. -- Nathan From owner-linux-xfs Wed Aug 4 19:48:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 19:48:25 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i752mKh2010082 for ; Wed, 4 Aug 2004 19:48:23 -0700 Received: from localhost (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 32FD7886DAC for ; Thu, 5 Aug 2004 10:48:16 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gusi.leathercollection.ph (Postfix) with ESMTP id 34A31886E3D for ; Thu, 5 Aug 2004 10:48:09 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 55217A54F1B5; Thu, 5 Aug 2004 10:48:08 +0800 (PHT) Date: Thu, 5 Aug 2004 10:48:08 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Re: Irreparable 'corrupt dinode ... error 990' Revisited Message-ID: <20040805024808.GF10358@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List References: <20040804153356.GD26826@leathercollection.ph> <20040804164037.GC18867@leathercollection.ph> <20040804173651.GA1107@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804173651.GA1107@taniwha.stupidest.org> 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.6+20040523i X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at leathercollection.ph X-archive-position: 3842 X-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: 1001 Lines: 24 On Wed, Aug 04, 2004 at 10:36:51AM -0700, Chris Wedgwood wrote: > Could be an in-memory corruption. Do you have ECC memory? Ack. No, I don't have ECC memory on this system, as it is a clone workstation. I already ran MemTest86 on this before, and remember it passing the basic tests consistently. I will schedule to run MemTest86 on this to see if it still passes the basic tests, and the extended tests on multiple passes as well. How sensitive is XFS to RAM quality? Would anyone know how sensitive other Linux filesystems (ext3, ReiserFS and JFS) are to RAM quality? Does the kernel necessarily have to panic when RAM has very slight problems (eg: not the type you can detect with basic MemTest86 tests and block out using the BadRAM patch), or can slow long-term corruption like this happen? Thank you very much for your time. :) --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs Wed Aug 4 20:30:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 20:30:55 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i753UrbG014151 for ; Wed, 4 Aug 2004 20:30:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i754WrSw002449 for ; Wed, 4 Aug 2004 21:32:54 -0700 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 i753UV7X8093335; Thu, 5 Aug 2004 13:30:32 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i753UT7X8748889; Thu, 5 Aug 2004 13:30:29 +1000 (EST) Date: Thu, 5 Aug 2004 13:30:29 +1000 (EST) From: Nathan Scott Message-Id: <200408050330.i753UT7X8748889@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 917732 - fix a deadlock X-archive-position: 3843 X-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: 395 Lines: 15 Fix a blocksize-smaller-than-pagesize hang when writing buffers with a shared page. Date: Wed Aug 4 20:29:16 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:176412a linux-2.6/xfs_buf.c - 1.176 linux-2.4/xfs_buf.c - 1.194 From owner-linux-xfs Wed Aug 4 20:51:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Aug 2004 20:51:50 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i753plFL014641 for ; Wed, 4 Aug 2004 20:51:47 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i754rlh8006378 for ; Wed, 4 Aug 2004 21:53:48 -0700 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 NAA16919; Thu, 5 Aug 2004 13:50:23 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i753oJln2922716; Thu, 5 Aug 2004 13:50:21 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i754kOgh003894; Thu, 5 Aug 2004 14:46:25 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i754kLxL003892; Thu, 5 Aug 2004 14:46:21 +1000 Date: Thu, 5 Aug 2004 14:46:21 +1000 From: Nathan Scott To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared Message-ID: <20040805044621.GE3619@frodo> References: <40FB2417.7030406@berdmann.de> <4774.1090202489@kao2.melbourne.sgi.com> <20040720015826.A2406645@wobbly.melbourne.sgi.com> <40FDFBF2.7020500@berdmann.de> <20040729054638.GK800@frodo> <410B3E47.2030806@berdmann.de> <20040802060109.GF21646@frodo> <410EB73E.9080603@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410EB73E.9080603@berdmann.de> User-Agent: Mutt/1.5.3i X-archive-position: 3844 X-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: 1472 Lines: 33 On Mon, Aug 02, 2004 at 11:50:54PM +0200, Bernhard Erdmann wrote: > Nathan Scott wrote: > > >Does adding #include (in xfsprogs/io/mmap.c) get > >a working build for you or do you see subsequent errors too? > > gcc -O1 -g -DDEBUG -funsigned-char -Wall -I../include > -DVERSION=\"2.6.19\" -DLOCALEDIR=\"/usr/share/locale\" > -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -DHAVE_FADVISE -DHAVE_SENDFILE -DHAVE_INJECT -DHAVE_RESBLKS > -DHAVE_SHUTDOWN -I/usr/local/src/xfs-cmds/xfsprogs/include > -I/usr/local/src/xfs-cmds/dmapi/include > -I/usr/local/src/xfs-cmds/attr/include -c -o fadvise.o fadvise.c > fadvise.c: In function `fadvise_f': > fadvise.c:91: `POSIX_FADV_NORMAL' undeclared (first use in this function) > fadvise.c:91: (Each undeclared identifier is reported only once > fadvise.c:91: for each function it appears in.) > fadvise.c:96: `POSIX_FADV_DONTNEED' undeclared (first use in this function) > fadvise.c:100: `POSIX_FADV_NOREUSE' undeclared (first use in this function) > fadvise.c:104: `POSIX_FADV_RANDOM' undeclared (first use in this function) > fadvise.c:108: `POSIX_FADV_SEQUENTIAL' undeclared (first use in this > function) > fadvise.c:112: `POSIX_FADV_WILLNEED' undeclared (first use in this function) Ugh, this is going to take some autoconf/configure work to avoid compiling these files entirely I think. Or you could upgrade to a more recent distribution (did you say Redhat 6.2?)... cheers. -- Nathan From owner-linux-xfs Thu Aug 5 03:15:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 03:15:27 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75AFP65031521 for ; Thu, 5 Aug 2004 03:15:25 -0700 Received: from taniwha.stupidest.org (adsl-63-202-172-176.dsl.snfc21.pacbell.net [63.202.172.176]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i75AFJ5C163926 for ; Thu, 5 Aug 2004 06:15:20 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id D488D1114F86; Thu, 5 Aug 2004 03:15:18 -0700 (PDT) Date: Thu, 5 Aug 2004 03:15:18 -0700 From: Chris Wedgwood To: Linux-XFS Mailing List Subject: Re: Irreparable 'corrupt dinode ... error 990' Revisited Message-ID: <20040805101518.GA24999@taniwha.stupidest.org> References: <20040804153356.GD26826@leathercollection.ph> <20040804164037.GC18867@leathercollection.ph> <20040804173651.GA1107@taniwha.stupidest.org> <20040805024808.GF10358@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040805024808.GF10358@leathercollection.ph> X-archive-position: 3845 X-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: 1257 Lines: 34 On Thu, Aug 05, 2004 at 10:48:08AM +0800, Federico Sevilla III wrote: > Ack. No, I don't have ECC memory on this system, as it is a clone > workstation. I already ran MemTest86 on this before, and remember > it passing the basic tests consistently. that just means it probably doesn't have bad ram, but it doesn't mean you didn't get an ecc error (memory errors are statistically possible even with the best ram, cheap ram is just more likely than expensive ram usually) > How sensitive is XFS to RAM quality? tree structures don't tollerate memory corruption well > Would anyone know how sensitive other Linux filesystems (ext3, > ReiserFS and JFS) are to RAM quality? reiserfs is also sensitive to marginal ram --- this is relative to ext2 which is much less sensitive it seems don't know about ext3 or jfs > Does the kernel necessarily have to panic when RAM has very slight > problems no, usually it doesn't even notice, things just silently go bad if the kernel can detect it it usually panics as it doesn't presently have the infrustructure to deal with things. fwiw there are no ECC drivers in mainline anyhow for the most part if we are talking ia32, for other platforms (ie. ia64) you get events and the kernel will usually just panic From owner-linux-xfs Thu Aug 5 07:55:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 07:55:57 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75Ett1M013432 for ; Thu, 5 Aug 2004 07:55:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i75Ett4d013431 for linux-xfs@oss.sgi.com; Thu, 5 Aug 2004 07:55:55 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75Etrie013417 for ; Thu, 5 Aug 2004 07:55:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i75EISaW012898; Thu, 5 Aug 2004 07:18:28 -0700 Date: Thu, 5 Aug 2004 07:18:28 -0700 Message-Id: <200408051418.i75EISaW012898@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 352] New: Compilation failure in sendfile.c X-Bugzilla-Reason: AssignedTo X-archive-position: 3846 X-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: 1271 Lines: 37 http://oss.sgi.com/bugzilla/show_bug.cgi?id=352 Summary: Compilation failure in sendfile.c Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: Nicolas.Kowalski@imag.fr I updated my copy of xfs-cmds today from cvsup. The computer runs Debian GNU/Linux 3.0. When trying to compile xfsprogs, it fails with the following error messages: gcc -O1 -g -DNDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.6.20\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_FADVISE -DHAVE_SENDFILE -DHAVE_INJECT -DHAVE_RESBLKS -DHAVE_SHUTDOWN -DENABLE_READLINE -c -o sendfile.o sendfile.c In file included from sendfile.c:34: /usr/include/sys/sendfile.h:26: #error " cannot be used with _FILE_OFFSET_BITS=64" make[2]: *** [sendfile.o] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/xfs-cmds/xfsprogs' make: *** [built] Error 2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Aug 5 08:55:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 08:55:58 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75Ftson017970 for ; Thu, 5 Aug 2004 08:55:54 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i75FtsNT017969 for linux-xfs@oss.sgi.com; Thu, 5 Aug 2004 08:55:54 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75FtrGL017955 for ; Thu, 5 Aug 2004 08:55:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i75FFNkh014011; Thu, 5 Aug 2004 08:15:23 -0700 Date: Thu, 5 Aug 2004 08:15:23 -0700 Message-Id: <200408051515.i75FFNkh014011@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3847 X-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: 4930 Lines: 88 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From sandeen@sgi.com 2004-05-08 08:15 PDT ------- Update from peter - set a panic mask and got this backtrace. This is from 2.6.8-rc3, vanilla kernel from kernel.org. XFS mounting filesystem md0 xfs_force_shutdown(md0,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xa0 XFS: Transforming an alert into a BUG. Filesystem "md0": Corruption of in-memory data detected. Shutting down filesystem: md0 kernel BUG at fs/xfs/support/debug.c:126! cp[1679]: bugcheck! 0 [1] Modules linked in: raid0 md 3w_9xxx button ixgb tg3 ipt_REJECT ipt_state ip_conntrack iptable_filtes Pid: 1679, CPU 2, comm: cp psr : 0000101008026038 ifs : 800000000000038a ip : [] Not tainted ip is at icmn_err+0x280/0x2a0 [xfs] unat: 0000000000000000 pfs : 000000000000038a rsc : 0000000000000003 rnat: a0000001008a6910 bsps: a0000001008a6908 pr : 0000006455996955 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000002002b7620 b6 : a000000100002d70 b7 : a000000100019400 f6 : 1003e0fc0fc0fc0fc0fc1 f7 : 0ffd9a200000000000000 f8 : 1003e0000000000000240 f9 : 1003e0000000000002490 f10 : 1003e000000000ea00000 f11 : 1003e00000000367b7ad0 r1 : a000000100a8e870 r2 : 0000000000000000 r3 : e000004091d30ec0 r8 : 000000000000002a r9 : 0000000000000000 r10 : 0000000000000001 r11 : 0000000000004000 r12 : e000004091d3fb80 r13 : e000004091d30000 r14 : 0000000000004000 r15 : 0000000000004000 r16 : 0000000000000300 r17 : e0000040fd8cfdf0 r18 : 0000000000000001 r19 : 0000000000000003 r20 : a0000001008be784 r21 : a0000001007f1c40 r22 : a0000001008be784 r23 : a00000010088e9d8 r24 : 0000000000000002 r25 : 0000000000000000 r26 : e000004091d30ec0 r27 : e000004091d30ed0 r28 : 0000001008022038 r29 : 0000000000000002 r30 : e000004091d3fb40 r31 : 0000000000000000 Call Trace: [] show_stack+0x80/0xa0 sp=e000004091d3f750 bsp=e000004091d31470 [] die+0x200/0x300 sp=e000004091d3f920 bsp=e000004091d31448 [] ia64_bad_break+0x230/0x340 sp=e000004091d3f920 bsp=e000004091d31428 [] ia64_leave_kernel+0x0/0x270 sp=e000004091d3f9b0 bsp=e000004091d31428 [] icmn_err+0x280/0x2a0 [xfs] sp=e000004091d3fb80 bsp=e000004091d313d0 [] xfs_fs_vcmn_err+0xf0/0x160 [xfs] sp=e000004091d3fb80 bsp=e000004091d31388 [] xfs_cmn_err+0xd0/0x120 [xfs] sp=e000004091d3fb80 bsp=e000004091d31330 [] xfs_do_force_shutdown+0x1f0/0x2a0 [xfs] sp=e000004091d3fba0 bsp=e000004091d312d8 [] vfs_force_shutdown+0xd0/0x100 [xfs] sp=e000004091d3fba0 bsp=e000004091d312a0 [] xfs_trans_cancel+0x2a0/0x2c0 [xfs] sp=e000004091d3fba0 bsp=e000004091d31270 [] xfs_create+0x6b0/0xf40 [xfs] sp=e000004091d3fba0 bsp=e000004091d31150 [] linvfs_mknod+0x550/0x5e0 [xfs] sp=e000004091d3fc00 bsp=e000004091d310f0 [] vfs_create+0x140/0x1a0 sp=e000004091d3fdb0 bsp=e000004091d310b8 [] open_namei+0x1110/0x1260 sp=e000004091d3fdb0 bsp=e000004091d31038 [] filp_open+0x60/0xe0 sp=e000004091d3fdc0 bsp=e000004091d31010 [] sys_open+0xb0/0x140 sp=e000004091d3fe30 bsp=e000004091d30f90 [] ia64_ret_from_syscall+0x0/0x20 sp=e000004091d3fe30 bsp=e000004091d30f90 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Aug 5 13:30:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 13:30:35 -0700 (PDT) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75KUWO8027713 for ; Thu, 5 Aug 2004 13:30:33 -0700 Received: from port-212-202-185-131.dynamic.qsc.de ([212.202.185.131] helo=ente.berdmann.de) by coredumps.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.33) id 1Bsosd-00029c-S5 for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 22:30:27 +0200 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1Bsosd-0003Wr-00 for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 22:30:27 +0200 Message-ID: <411298E2.60404@berdmann.de> Date: Thu, 05 Aug 2004 22:30:26 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.6) Gecko/20040505 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared References: <40FB2417.7030406@berdmann.de> <4774.1090202489@kao2.melbourne.sgi.com> <20040720015826.A2406645@wobbly.melbourne.sgi.com> <40FDFBF2.7020500@berdmann.de> <20040729054638.GK800@frodo> <410B3E47.2030806@berdmann.de> <20040802060109.GF21646@frodo> <410EB73E.9080603@berdmann.de> <20040805044621.GE3619@frodo> In-Reply-To: <20040805044621.GE3619@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3848 X-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: 295 Lines: 8 Nathan Scott wrote: [...] > Ugh, this is going to take some autoconf/configure work to avoid > compiling these files entirely I think. Or you could upgrade to > a more recent distribution (did you say Redhat 6.2?)... uuuuuhhhh... yeah... some day I'll upgrade this ancient linux installation From owner-linux-xfs Thu Aug 5 14:35:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 14:35:12 -0700 (PDT) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75LZ5kh029888 for ; Thu, 5 Aug 2004 14:35:09 -0700 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0I1Z00D01SXYDS@mailgw1.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 16:35:01 -0500 (CDT) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1Z00MJTTACRJ@mailgw1.fnal.gov> for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 16:35:01 -0500 (CDT) Date: Thu, 05 Aug 2004 16:35:00 -0500 From: Dan Yocum Subject: Scientific Linux with XFS support To: xfs-list Message-id: <4112A804.3000802@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 X-archive-position: 3849 X-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: 1326 Lines: 35 Hi all, I thought you might be interested that I've incorporated Eric's RHEL kernel into the Scientific Linux distrobution. This is the same kernel found in ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre2/kernels/RHEL/RPMS. I took the liberty of merging the xfs bits back into the kernel so there's no more xfs-modules rpm package. Other than that, it's the same kernel as Eric's (with devfs compiled in, but disabled at boot time). Of course, you're asking yourself, "What the heck is Scientific Linux?" It's a long story, but suffice it to say it's being supported and developed by a bunch of the big high energy physics labs including Fermi and CERN. The distro is binary compatible with Red Hat Enterprise Linux version 3 plus all updates and some extra packages (mozilla v1.6, etc.). The isos are here: http://sdsswww.fnal.gov/~yocum/SL302/iso/ To enable xfs support during the install, type 'linux xfs' at the boot prompt. To upgrade with it, type 'linux xfs upgradeany'. If you have any questions or comments or run into problems, feel free to drop me a line. I'm not on the linux-xfs list any more, so you'll need to send it directly to me. Cheers, 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 Thu Aug 5 14:47:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 14:47:16 -0700 (PDT) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75LlDLn030673 for ; Thu, 5 Aug 2004 14:47:13 -0700 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0I1Z00M01TDHZG@mailgw1.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 16:47:09 -0500 (CDT) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1Z00MHDTUKRC@mailgw1.fnal.gov> for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 16:47:09 -0500 (CDT) Date: Thu, 05 Aug 2004 16:47:08 -0500 From: Dan Yocum Subject: Re: Scientific Linux with XFS support In-reply-to: To: xfs-list Message-id: <4112AADC.2040702@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 References: <4112A804.3000802@fnal.gov> X-archive-position: 3850 X-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: 596 Lines: 24 D'oh! Hmmmmm. I forgot about that. Give me a second.... Joshua Baker-LePain wrote: > On Thu, 5 Aug 2004 at 4:35pm, Dan Yocum wrote > > >>The isos are here: >> >>http://sdsswww.fnal.gov/~yocum/SL302/iso/ >> >>To enable xfs support during the install, type 'linux xfs' at the boot >>prompt. To upgrade with it, type 'linux xfs upgradeany'. > > > I don't know if anyone has let you know, but that's asking for a username > and password for "SDSS COLLAB". > -- 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 Thu Aug 5 14:50:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 14:50:55 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [207.218.156.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75LopML031293 for ; Thu, 5 Aug 2004 14:50:52 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i75LKNNp012185; Thu, 5 Aug 2004 16:20:29 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i75LKLsH012182; Thu, 5 Aug 2004 16:20:22 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Thu, 5 Aug 2004 16:20:21 -0500 (EST) From: Net Llama! To: Dan Yocum cc: xfs-list Subject: Re: Scientific Linux with XFS support In-Reply-To: <4112A804.3000802@fnal.gov> Message-ID: References: <4112A804.3000802@fnal.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1251 Lines: 28 On Thu, 5 Aug 2004, Dan Yocum wrote: > Hi all, > > I thought you might be interested that I've incorporated Eric's RHEL kernel > into the Scientific Linux distrobution. This is the same kernel found in > ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre2/kernels/RHEL/RPMS. > I took the liberty of merging the xfs bits back into the kernel so there's > no more xfs-modules rpm package. Other than that, it's the same kernel as > Eric's (with devfs compiled in, but disabled at boot time). > > Of course, you're asking yourself, "What the heck is Scientific Linux?" > It's a long story, but suffice it to say it's being supported and developed > by a bunch of the big high energy physics labs including Fermi and CERN. > The distro is binary compatible with Red Hat Enterprise Linux version 3 plus > all updates and some extra packages (mozilla v1.6, etc.). > > The isos are here: > > http://sdsswww.fnal.gov/~yocum/SL302/iso/ Looks intersting, but unfortunately, i'm getting a password prompt trying to access that URL. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Thu Aug 5 14:57:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 14:57:05 -0700 (PDT) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i75Lv2nO031641 for ; Thu, 5 Aug 2004 14:57:03 -0700 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0I1Z00B01TWP5H@mailgw1.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 16:56:58 -0500 (CDT) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1Z00MVFUAYRJ@mailgw1.fnal.gov> for linux-xfs@oss.sgi.com; Thu, 05 Aug 2004 16:56:58 -0500 (CDT) Date: Thu, 05 Aug 2004 16:56:58 -0500 From: Dan Yocum Subject: Re: Scientific Linux with XFS support In-reply-to: <4112AADC.2040702@fnal.gov> To: xfs-list Message-id: <4112AD2A.3080602@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 References: <4112A804.3000802@fnal.gov> <4112AADC.2040702@fnal.gov> X-archive-position: 3852 X-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: 691 Lines: 34 Ok, it's fixed. Sorry about that. Cheers, Dan Dan Yocum wrote: > D'oh! Hmmmmm. I forgot about that. Give me a second.... > > Joshua Baker-LePain wrote: > >> On Thu, 5 Aug 2004 at 4:35pm, Dan Yocum wrote >> >> >>> The isos are here: >>> >>> http://sdsswww.fnal.gov/~yocum/SL302/iso/ >>> >>> To enable xfs support during the install, type 'linux xfs' at the >>> boot prompt. To upgrade with it, type 'linux xfs upgradeany'. >> >> >> >> I don't know if anyone has let you know, but that's asking for a >> username and password for "SDSS COLLAB". >> > -- 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 Thu Aug 5 17:16:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 17:16:57 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i760Gowp004973 for ; Thu, 5 Aug 2004 17:16:54 -0700 Received: by mproxy.gmail.com with SMTP id 73so29317rnk for ; Thu, 05 Aug 2004 17:16:45 -0700 (PDT) Received: by 10.38.76.26 with SMTP id y26mr109128rna; Thu, 05 Aug 2004 17:16:45 -0700 (PDT) Message-ID: <3b94088e04080517166fd22dd3@mail.gmail.com> Date: Thu, 5 Aug 2004 17:16:45 -0700 From: Bo Yang To: linux-xfs@oss.sgi.com Subject: Patch to make XFS to work on ramdisk Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kealia@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 4441 Lines: 99 Hi, Appended is a patch to make XFS to work on ramdisk. I tried to use ramdisk as the external logging device to measure the logging overhead. It didn't work. Creating an XFS file system on a ramdisk didn't work, either. In both cases, mkfs.xfs would work. But while mounting the ramdisk, I got error complaining about wrong wrong fs type. The following is the complete output: [root@stor01 xfsprogs-2.5.6.orig]# mkfs/mkfs.xfs -f /dev/ram0 mkfs.xfs: warning - cannot set blocksize on block device /dev/ram0: Invalid argument meta-data=/dev/ram0 isize=256 agcount=4, agsize=4096 blks = sectsz=512 data = bsize=4096 blocks=16384, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@stor01 xfsprogs-2.5.6.orig]# mount /dev/ram0 /mnt/ramdisk mount: you must specify the filesystem type [root@stor01 xfsprogs-2.5.6.orig]# mount -t xfs /dev/ram0 /mnt/ramdisk mount: wrong fs type, bad option, bad superblock on /dev/ram0, or too many mounted file systems [root@stor01 xfsprogs-2.5.6.orig]# During debugging, I found pages containing superblock and meta data created by mkfs.xfs on ramdisk was corrupted somehow before mounting. It turns out this is caused by the semantics of BLKFLSBUF of ramdisk (rd_ioctl() in kernel 2.4.25). I assume the expected semantics of BLKFLSBUG on a normal block device is to: 1) flush buffers to device; 2) release buffers from main memory. Apparently a ramdisk cannot do both at the same time. It just invalidates all its pages in page cache and returns. So the XFS meta data is lost. XFS tools' mkfs.xfs makes an ioctl() call to do BLKFLSBUF after creating the file system. This caused the problem. I noticed ext3 somehow does not call this after mkfs.ext3. I haven't checked whether it's the ramdisk implementation that should get fixed. I changed XFS tools a little bit so it does not call BLKFLSBUF on a ramdisk. The following patch is for xfsprogs-2.5.6. It works on kernel 2.4.25. With it I've successfully used ramdisk as an external logging device and used XFS directly on a ramdisk. I booted the kernel with option "ramdisk=65536 ramdisk_blocksize=512". - Bo Yang diff -Naur --exclude=CVS --exclude=builddefs --exclude=platform_defs.h xfsprogs-2.5.6.orig/include/ramdisk.h xfsprogs-2.5.6/include/ramdisk.h --- xfsprogs-2.5.6.orig/include/ramdisk.h Wed Dec 31 16:00:00 1969 +++ xfsprogs-2.5.6/include/ramdisk.h Thu Aug 5 15:40:31 2004 @@ -0,0 +1,5 @@ +/* RAMDISK major number */ + +#ifndef __RAMDISK_H__ +#define RAMDISK_MAJOR 1 /* ramdisk major number */ +#endif /* #ifndef __RAMDISK_H__ */ diff -Naur --exclude=CVS --exclude=builddefs --exclude=platform_defs.h xfsprogs-2.5.6.orig/libxfs/init.c xfsprogs-2.5.6/libxfs/init.c --- xfsprogs-2.5.6.orig/libxfs/init.c Mon Mar 8 11:29:21 2004 +++ xfsprogs-2.5.6/libxfs/init.c Thu Aug 5 15:42:35 2004 @@ -31,6 +31,7 @@ */ #include +#include #include #include "init.h" @@ -159,7 +160,9 @@ dev_map[d].dev = dev_map[d].fd = 0; fsync(fd); - platform_flush_device(fd); + if (major(dev) != RAMDISK_MAJOR) { + platform_flush_device(fd); + } close(fd); return; diff -Naur --exclude=CVS --exclude=builddefs --exclude=platform_defs.h xfsprogs-2.5.6.orig/libxfs/linux.c xfsprogs-2.5.6/libxfs/linux.c --- xfsprogs-2.5.6.orig/libxfs/linux.c Mon Mar 8 11:29:21 2004 +++ xfsprogs-2.5.6/libxfs/linux.c Thu Aug 5 15:44:21 2004 @@ -114,9 +114,9 @@ platform_set_blocksize(int fd, char *path, int blocksize) { if (ioctl(fd, BLKBSZSET, &blocksize) < 0) { - fprintf(stderr, _("%s: warning - cannot set blocksize " + fprintf(stderr, _("%s: warning - cannot set blocksize to %d " "on block device %s: %s\n"), - progname, path, strerror(errno)); + progname, blocksize, path, strerror(errno)); } } From owner-linux-xfs Thu Aug 5 19:55:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 19:55:59 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i762tumX007239 for ; Thu, 5 Aug 2004 19:55:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i762tulp007238 for linux-xfs@oss.sgi.com; Thu, 5 Aug 2004 19:55:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i762ttsj007224 for ; Thu, 5 Aug 2004 19:55:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i762QRpG006878; Thu, 5 Aug 2004 19:26:27 -0700 Date: Thu, 5 Aug 2004 19:26:27 -0700 Message-Id: <200408060226.i762QRpG006878@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3854 X-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: 4416 Lines: 96 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-05-08 19:26 PDT ------- Further digging with Eric's guidance. Modifications to the source: fs/xfs/Makefile: EXTRA_CFLAGS += -Ifs/xfs -Ifs/xfs/linux-2.6 -funsigned-char -DDEBUG fs/xfs/xfs_error.c: #ifdef DEBUG int xfs_etrap[XFS_ERROR_NTRAP] = { EFSCORRUPTED, 0, }; We've got a trace: XFS: device md0- bad inode magic/vsn daddr 2064 #0 (magic=0) xfs_error_trap: error 990 kernel BUG at fs/xfs/xfs_error.c:75! cp[1663]: bugcheck! 0 [1] Modules linked in: raid0 md 3w_9xxx button ixgb tg3 ipt_REJECT ipt_state ip_conntrack iptable_filtes Pid: 1663, CPU 0, comm: cp psr : 0000101008026038 ifs : 8000000000000288 ip : [] Not tainted ip is at xfs_error_trap+0xd0/0xe0 [xfs] unat: 0000000000000000 pfs : 0000000000000288 rsc : 0000000000000003 rnat: 0009804c8a70033f bsps: 0000000000000060 pr : 000119501a556965 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a00000020033bf90 b6 : a000000100002d70 b7 : a000000100094fc0 f6 : 1003e0fc0fc0fc0fc0fc1 f7 : 0ffdc8dc0000000000000 f8 : 1003e0000000000000240 f9 : 1003e0000000000002490 f10 : 1003e000000000ea00000 f11 : 1003e00000000367b7ad0 r1 : a000000100a0a810 r2 : 0000000000000000 r3 : e00000034a1b0eb0 r8 : 0000000000000025 r9 : 0000000000000000 r10 : 0000000000000001 r11 : 0000000000004000 r12 : e00000034a1bfad0 r13 : e00000034a1b0000 r14 : 0000000000004000 r15 : 0000000000004000 r16 : 0000000000000100 r17 : e00000003e26fdf0 r18 : 0000000000000001 r19 : 0000000000000001 r20 : a000000100838a8c r21 : a000000100771c40 r22 : a000000100838a8c r23 : a00000010080a958 r24 : 0000000000000002 r25 : 0000000000000000 r26 : e00000034a1b0eb0 r27 : e00000034a1b0ec0 r28 : 0000001008022038 r29 : 0000000000000002 r30 : e00000034a1bfa90 r31 : 0000000000000000 Call Trace: [] show_stack+0x80/0xa0 sp=e00000034a1bf6a0 bsp=e00000034a1b1650 [] die+0x200/0x300 sp=e00000034a1bf870 bsp=e00000034a1b1628 [] ia64_bad_break+0x230/0x340 sp=e00000034a1bf870 bsp=e00000034a1b1608 [] ia64_leave_kernel+0x0/0x270 sp=e00000034a1bf900 bsp=e00000034a1b1608 [] xfs_error_trap+0xd0/0xe0 [xfs] sp=e00000034a1bfad0 bsp=e00000034a1b15c0 [] xfs_itobp+0x4a0/0x6a0 [xfs] sp=e00000034a1bfad0 bsp=e00000034a1b1518 [] xfs_iread+0xd0/0x540 [xfs] sp=e00000034a1bfb20 bsp=e00000034a1b14c0 [] xfs_iget_core+0x220/0x1900 [xfs] sp=e00000034a1bfb30 bsp=e00000034a1b1438 [] xfs_iget+0x2c0/0x360 [xfs] sp=e00000034a1bfb40 bsp=e00000034a1b13c0 [] xfs_trans_iget+0x5f0/0x920 [xfs] sp=e00000034a1bfb40 bsp=e00000034a1b1378 [] xfs_ialloc+0x150/0xd40 [xfs] sp=e00000034a1bfb50 bsp=e00000034a1b1300 [] xfs_dir_ialloc+0x110/0x740 [xfs] sp=e00000034a1bfb60 bsp=e00000034a1b1238 [] xfs_create+0x840/0x1340 [xfs] sp=e00000034a1bfba0 bsp=e00000034a1b1140 [] linvfs_mknod+0x5d0/0x660 [xfs] sp=e00000034a1bfc00 bsp=e00000034a1b10e0 [] vfs_create+0x140/0x1a0 sp=e00000034a1bfdb0 bsp=e00000034a1b10a8 [] open_namei+0x1110/0x1260 sp=e00000034a1bfdb0 bsp=e00000034a1b1028 [] filp_open+0x60/0xe0 sp=e00000034a1bfdc0 bsp=e00000034a1b1000 [] sys_open+0xb0/0x140 sp=e00000034a1bfe30 bsp=e00000034a1b0f80 [] ia64_ret_from_syscall+0x0/0x20 sp=e00000034a1bfe30 bsp=e00000034a1b0f80 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Aug 5 20:55:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Aug 2004 20:55:59 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i763tuSc011339 for ; Thu, 5 Aug 2004 20:55:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i763tuV6011338 for linux-xfs@oss.sgi.com; Thu, 5 Aug 2004 20:55:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i763ttfC011324 for ; Thu, 5 Aug 2004 20:55:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i763U39s011150; Thu, 5 Aug 2004 20:30:03 -0700 Date: Thu, 5 Aug 2004 20:30:03 -0700 Message-Id: <200408060330.i763U39s011150@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3855 X-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: 1366 Lines: 52 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From sandeen@sgi.com 2004-05-08 20:30 PDT ------- here's the inode: xfs_db> dblock 2064, type inode, print: core.magic = 0x494e core.mode = 0 core.version = 1 core.format = 0 (dev) core.nlinkv1 = 0 core.uid = 0 core.gid = 0 core.flushiter = 0 core.atime.sec = Thu Jan 1 01:00:00 1970 core.atime.nsec = 000000000 core.mtime.sec = Thu Jan 1 01:00:00 1970 core.mtime.nsec = 000000000 core.ctime.sec = Thu Jan 1 01:00:00 1970 core.ctime.nsec = 000000000 core.size = 0 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 0 (dev) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.gen = 0 so this is a little odd; we returned EFSCORRUPTED from xfs_itobp because either the magic or the version was wrong, but on disk it looks fine. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Aug 6 00:54:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Aug 2004 00:54:38 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i767sXhQ018635 for ; Fri, 6 Aug 2004 00:54:33 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i767sO0f004238 for ; Fri, 6 Aug 2004 02:54:26 -0500 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 RAA15244; Fri, 6 Aug 2004 17:54:21 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i767sIln2950720; Fri, 6 Aug 2004 17:54:19 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i768oKfv004162; Fri, 6 Aug 2004 18:50:21 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i768o8FP004160; Fri, 6 Aug 2004 18:50:08 +1000 Date: Fri, 6 Aug 2004 18:50:07 +1000 From: Nathan Scott To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared Message-ID: <20040806085007.GA4142@frodo> References: <40FB2417.7030406@berdmann.de> <4774.1090202489@kao2.melbourne.sgi.com> <20040720015826.A2406645@wobbly.melbourne.sgi.com> <40FDFBF2.7020500@berdmann.de> <20040729054638.GK800@frodo> <410B3E47.2030806@berdmann.de> <20040802060109.GF21646@frodo> <410EB73E.9080603@berdmann.de> <20040805044621.GE3619@frodo> <411298E2.60404@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411298E2.60404@berdmann.de> User-Agent: Mutt/1.5.3i X-archive-position: 3856 X-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: 451 Lines: 16 On Thu, Aug 05, 2004 at 10:30:26PM +0200, Bernhard Erdmann wrote: > Nathan Scott wrote: > [...] > >Ugh, this is going to take some autoconf/configure work to avoid > >compiling these files entirely I think. Or you could upgrade to > >a more recent distribution (did you say Redhat 6.2?)... > > uuuuuhhhh... yeah... some day I'll upgrade this ancient linux installation s'okay, i have a fix - should be available by next week. cheers. -- Nathan From owner-linux-xfs Fri Aug 6 01:00:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Aug 2004 01:00:41 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7680bSr019094 for ; Fri, 6 Aug 2004 01:00:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i7692kSH017721 for ; Fri, 6 Aug 2004 02:02:48 -0700 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 RAA15282; Fri, 6 Aug 2004 17:59:14 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i767xBln2954926; Fri, 6 Aug 2004 17:59:12 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i768t9fv004181; Fri, 6 Aug 2004 18:55:10 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i768t7Xb004179; Fri, 6 Aug 2004 18:55:07 +1000 Date: Fri, 6 Aug 2004 18:55:07 +1000 From: Nathan Scott To: Bo Yang Cc: linux-xfs@oss.sgi.com Subject: Re: Patch to make XFS to work on ramdisk Message-ID: <20040806085507.GB4142@frodo> References: <3b94088e04080517166fd22dd3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b94088e04080517166fd22dd3@mail.gmail.com> User-Agent: Mutt/1.5.3i X-archive-position: 3857 X-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: 999 Lines: 33 On Thu, Aug 05, 2004 at 05:16:45PM -0700, Bo Yang wrote: > Hi, > > Appended is a patch to make XFS to work on ramdisk. Thanks. > (rd_ioctl() in kernel 2.4.25). I assume the expected semantics of > BLKFLSBUG on a normal block device is to: 1) flush buffers to device; Heh, "BLKFLSBUG" - Freudian slip? > 2) release buffers from main memory. Apparently a ramdisk cannot do > both at the same time. It just invalidates all its pages in page cache > and returns. So the XFS meta data is lost. Yep. Actually saw discussion of this on linux-kernel not too long ago, just didn't register that it'd affect us in mkfs. > it's the ramdisk implementation that should get fixed. I changed XFS > tools a little bit so it does not call BLKFLSBUF on a ramdisk. Its mkfs.xfs that should be fixed, yes - I see the kernel code does a very similar thing when initialising the initrd. I'll push a slight variant on your fix into the oss tree on Monday (after a bit more testing here). thanks! -- Nathan From owner-linux-xfs Fri Aug 6 01:55:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Aug 2004 01:56:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i768twC6020606 for ; Fri, 6 Aug 2004 01:55:58 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i768twoZ020605 for linux-xfs@oss.sgi.com; Fri, 6 Aug 2004 01:55:58 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i768tu2T020591 for ; Fri, 6 Aug 2004 01:55:56 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i767xR2i019037; Fri, 6 Aug 2004 00:59:27 -0700 Date: Fri, 6 Aug 2004 00:59:27 -0700 Message-Id: <200408060759.i767xR2i019037@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 352] Compilation failure in sendfile.c X-Bugzilla-Reason: AssignedTo X-archive-position: 3858 X-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: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=352 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From nathans@sgi.com 2004-06-08 00:59 PDT ------- Thanks, I have a fix - will test some more, but should be in the oss tree on Monday. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Aug 7 09:56:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Aug 2004 09:56:06 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i77Gu4oX023177 for ; Sat, 7 Aug 2004 09:56:04 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i77Gu4YN023176 for linux-xfs@oss.sgi.com; Sat, 7 Aug 2004 09:56:04 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i77Gu3eP023162 for ; Sat, 7 Aug 2004 09:56:03 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i77GExlM022602; Sat, 7 Aug 2004 09:14:59 -0700 Date: Sat, 7 Aug 2004 09:14:59 -0700 Message-Id: <200408071614.i77GExlM022602@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3859 X-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: 493 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-07-08 09:14 PDT ------- Okay, so following the lead given by panic_mask, the testcase is reduced to: # mount fresh filesystem for i in `seq 1 13`; do touch $i; done # now blow up touch 14 Further info when I get kdb and xfsidbg running on ia64. Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Aug 8 21:21:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 21:21:29 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i794LPKE009445 for ; Sun, 8 Aug 2004 21:21:25 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i794LI0f022295 for ; Sun, 8 Aug 2004 23:21:19 -0500 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i794LHJ12766 for linux-xfs@oss.sgi.com; Mon, 9 Aug 2004 14:21:17 +1000 Date: Mon, 9 Aug 2004 14:21:17 +1000 From: Nathan Scott Message-Id: <200408090421.i794LHJ12766@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - update split patches X-archive-position: 3860 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 582 Lines: 21 Update 2.4 split patches for 2.4.27 merge. Date: Sun Aug 8 21:20:28 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:176622a split-patches/series - 1.8 split-patches/rwsem-backport - 1.2 split-patches/kdb-i386 - 1.2 split-patches/kdb-common - 1.2 split-patches/docs-update - 1.2 split-patches/dmapi-enable - 1.3 split-patches/acl-backport - 1.2 split-patches/bhdelay-typo - 1.2 split-patches/downgrade_write-backport - 1.2 From owner-linux-xfs Sun Aug 8 22:28:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 22:28:23 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i795S61G012617 for ; Sun, 8 Aug 2004 22:28:06 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i796UcUH025437 for ; Sun, 8 Aug 2004 23:30:40 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i795Qub24419 for linux-xfs@oss.sgi.com; Mon, 9 Aug 2004 15:26:56 +1000 Date: Mon, 9 Aug 2004 15:26:56 +1000 From: Nathan Scott Message-Id: <200408090526.i795Qub24419@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - merge up to 2.4.27 X-archive-position: 3861 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 20383 Lines: 663 Date: Sun Aug 8 21:52:50 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: marcelo@cyclades.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:176624a drivers/scsi/sata_promise.h - 1.1 drivers/scsi/sata_promise.c - 1.1 drivers/scsi/sata_sil.c - 1.1 drivers/scsi/sata_sis.c - 1.1 Documentation/DocBook/libata.tmpl - 1.1 drivers/scsi/sata_svw.c - 1.1 drivers/scsi/sata_sx4.c - 1.1 drivers/scsi/libata.h - 1.1 drivers/scsi/libata-scsi.c - 1.1 drivers/scsi/libata-core.c - 1.1 drivers/scsi/sata_via.c - 1.1 drivers/scsi/sata_vsc.c - 1.1 drivers/usb/gadget/epautoconf.c - 1.1 net/sched/sch_netem.c - 1.1 drivers/usb/gadget/ndis.h - 1.1 drivers/usb/gadget/rndis.c - 1.1 drivers/net/ibmveth.h - 1.1 drivers/net/ibmveth.c - 1.1 drivers/usb/gadget/rndis.h - 1.1 drivers/message/fusion/lsi/mpi_sas.h - 1.1 drivers/message/fusion/lsi/mpi_inb.h - 1.1 drivers/hotplug/shpchprm_nonacpi.h - 1.1 drivers/hotplug/shpchprm_nonacpi.c - 1.1 drivers/hotplug/shpchprm_legacy.h - 1.1 drivers/hotplug/shpchprm_legacy.c - 1.1 drivers/hotplug/shpchprm_acpi.c - 1.1 drivers/hotplug/shpchprm.h - 1.1 drivers/hotplug/shpchp_pci.c - 1.1 drivers/hotplug/shpchp_hpc.c - 1.1 drivers/hotplug/shpchp_ctrl.c - 1.1 drivers/hotplug/shpchp_core.c - 1.1 drivers/hotplug/shpchp.h - 1.1 drivers/hotplug/pciehprm_nonacpi.h - 1.1 drivers/hotplug/pciehprm_nonacpi.c - 1.1 drivers/hotplug/pciehprm_acpi.c - 1.1 drivers/hotplug/pciehprm.h - 1.1 drivers/hotplug/pciehp_pci.c - 1.1 drivers/hotplug/pciehp_hpc.c - 1.1 drivers/hotplug/pciehp_ctrl.c - 1.1 arch/ia64/ia32/elfcore32.h - 1.1 drivers/hotplug/pciehp_core.c - 1.1 drivers/hotplug/pciehp.h - 1.1 drivers/char/parport_serial.c - 1.1 drivers/block/sx8.c - 1.1 crypto/tea.c - 1.1 include/asm-x86_64/bluesmoke.h - 1.1 crypto/michael_mic.c - 1.1 include/scsi/scsi_host.h - 1.1 include/linux/ata.h - 1.1 include/linux/libata.h - 1.1 CREDITS - 1.6 Documentation/CodingStyle - 1.2 Documentation/Configure.help - 1.14 Documentation/DocBook/Makefile - 1.2 Documentation/cciss.txt - 1.2 Documentation/crypto/api-intro.txt - 1.4 Documentation/filesystems/hpfs.txt - 1.2 Documentation/filesystems/xfs.txt - 1.6 Documentation/ioctl-number.txt - 1.2 Documentation/kernel-parameters.txt - 1.3 Documentation/networking/bridge.txt - 1.2 Documentation/networking/ip-sysctl.txt - 1.3 Documentation/usb/silverlink.txt - 1.2 MAINTAINERS - 1.9 Makefile - 1.13 arch/alpha/kernel/sys_eiger.c - 1.2 arch/alpha/kernel/sys_takara.c - 1.2 arch/cris/drivers/eeprom.c - 1.2 arch/i386/defconfig - 1.4 arch/i386/kernel/acpi.c - 1.3 arch/i386/kernel/edd.c - 1.2 arch/i386/kernel/i8259.c - 1.3 arch/i386/kernel/io_apic.c - 1.4 arch/i386/kernel/mpparse.c - 1.3 arch/i386/kernel/mtrr.c - 1.2 arch/i386/kernel/pci-irq.c - 1.3 arch/i386/kernel/pci-pc.c - 1.2 arch/i386/kernel/setup.c - 1.4 arch/i386/mm/fault.c - 1.2 arch/i386/mm/pageattr.c - 1.2 arch/ia64/configs/dig - 1.3 arch/ia64/configs/generic - 1.3 arch/ia64/configs/numa - 1.3 arch/ia64/configs/ski - 1.2 arch/ia64/configs/zx1 - 1.3 arch/ia64/defconfig - 1.3 arch/ia64/ia32/binfmt_elf32.c - 1.2 arch/ia64/ia32/sys_ia32.c - 1.3 arch/ia64/kernel/efi.c - 1.3 arch/ia64/kernel/efivars.c - 1.2 arch/ia64/kernel/palinfo.c - 1.2 arch/ia64/kernel/perfmon.c - 1.3 arch/ia64/kernel/salinfo.c - 1.4 arch/ia64/kernel/unwind.c - 1.3 arch/m68k/ifpsp060/iskeleton.S - 1.2 arch/m68k/kernel/setup.c - 1.2 arch/m68k/mac/iop.c - 1.2 arch/mips/sibyte/sb1250/bcm1250_tbprof.c - 1.2 arch/ppc/boot/simple/m8260_tty.c - 1.3 arch/ppc/config.in - 1.7 arch/ppc/kernel/head_44x.S - 1.3 arch/ppc/kernel/m8260_setup.c - 1.3 arch/ppc/kernel/ppc_htab.c - 1.2 arch/ppc/platforms/Makefile - 1.6 arch/ppc/platforms/error_log.c - 1.2 arch/ppc/platforms/error_log.h - 1.2 arch/ppc/platforms/proc_rtas.c - 1.2 arch/ppc64/kernel/nvram.c - 1.3 arch/ppc64/kernel/proc_pmc.c - 1.2 arch/ppc64/kernel/rtas-proc.c - 1.3 arch/s390/kernel/debug.c - 1.2 arch/s390x/kernel/debug.c - 1.2 arch/sh64/config.in - 1.4 arch/sh64/defconfig - 1.3 arch/sh64/kernel/entry.S - 1.2 arch/sh64/kernel/head.S - 1.2 arch/sh64/kernel/pci_sh5.c - 1.2 arch/sh64/kernel/time.c - 1.3 arch/sh64/lib/io.c - 1.2 arch/sh64/mach-cayman/irq.c - 1.2 arch/sh64/mach-cayman/setup.c - 1.2 arch/sh64/mm/cache.c - 1.2 arch/sh64/vmlinux.lds.S - 1.2 arch/sparc/Makefile - 1.2 arch/sparc/kernel/process.c - 1.2 arch/sparc/kernel/unaligned.c - 1.2 arch/sparc/mm/fault.c - 1.2 arch/sparc/prom/memory.c - 1.2 arch/sparc64/Makefile - 1.2 arch/sparc64/config.in - 1.3 arch/sparc64/defconfig - 1.6 arch/sparc64/kernel/ioctl32.c - 1.3 arch/sparc64/kernel/power.c - 1.2 arch/sparc64/kernel/process.c - 1.2 arch/sparc64/kernel/signal32.c - 1.2 arch/sparc64/kernel/sparc64_ksyms.c - 1.2 arch/sparc64/kernel/sys_sparc32.c - 1.4 arch/sparc64/kernel/sys_sunos32.c - 1.3 arch/sparc64/kernel/unaligned.c - 1.2 arch/sparc64/mm/fault.c - 1.2 arch/sparc64/mm/init.c - 1.4 arch/sparc64/prom/memory.c - 1.2 arch/x86_64/boot/bootsect.S - 1.2 arch/x86_64/ia32/ia32entry.S - 1.3 arch/x86_64/kernel/Makefile - 1.3 arch/x86_64/kernel/acpi.c - 1.3 arch/x86_64/kernel/bluesmoke.c - 1.3 arch/x86_64/kernel/e820.c - 1.4 arch/x86_64/kernel/i8259.c - 1.2 arch/x86_64/kernel/io_apic.c - 1.3 arch/x86_64/kernel/mpparse.c - 1.3 arch/x86_64/kernel/mtrr.c - 1.4 arch/x86_64/kernel/pci-gart.c - 1.4 arch/x86_64/kernel/pci-pc.c - 1.3 arch/x86_64/kernel/setup.c - 1.3 crypto/Config.in - 1.4 crypto/Makefile - 1.4 crypto/cipher.c - 1.4 crypto/digest.c - 1.2 crypto/tcrypt.c - 1.4 crypto/tcrypt.h - 1.4 crypto/twofish.c - 1.3 drivers/acpi/Config.in - 1.3 drivers/acpi/ac.c - 1.3 drivers/acpi/asus_acpi.c - 1.4 drivers/acpi/battery.c - 1.3 drivers/acpi/bus.c - 1.3 drivers/acpi/button.c - 1.3 drivers/acpi/ec.c - 1.4 drivers/acpi/fan.c - 1.3 drivers/acpi/pci_irq.c - 1.4 drivers/acpi/pci_link.c - 1.3 drivers/acpi/pci_root.c - 1.2 drivers/acpi/power.c - 1.3 drivers/acpi/processor.c - 1.4 drivers/acpi/tables.c - 1.3 drivers/acpi/thermal.c - 1.3 drivers/acpi/toshiba_acpi.c - 1.5 drivers/atm/Config.in - 1.2 drivers/atm/fore200e.c - 1.2 drivers/atm/fore200e.h - 1.2 drivers/atm/nicstar.c - 1.4 drivers/block/Config.in - 1.2 drivers/block/Makefile - 1.2 drivers/block/acsi_slm.c - 1.2 drivers/block/cciss.c - 1.5 drivers/block/cciss_scsi.c - 1.3 drivers/block/rd.c - 1.2 drivers/bluetooth/Makefile.lib - 1.2 drivers/bluetooth/bfusb.c - 1.2 drivers/bluetooth/bluecard_cs.c - 1.2 drivers/bluetooth/bt3c_cs.c - 1.2 drivers/bluetooth/btuart_cs.c - 1.2 drivers/bluetooth/dtl1_cs.c - 1.2 drivers/bluetooth/hci_bcsp.c - 1.2 drivers/bluetooth/hci_ldisc.c - 1.2 drivers/bluetooth/hci_uart.h - 1.2 drivers/bluetooth/hci_usb.c - 1.3 drivers/bluetooth/hci_usb.h - 1.3 drivers/char/ChangeLog - 1.2 drivers/char/Config.in - 1.5 drivers/char/Makefile - 1.5 drivers/char/agp/agp.h - 1.3 drivers/char/agp/agpgart_be.c - 1.5 drivers/char/amd7xx_tco.c - 1.2 drivers/char/drm/drmP.h - 1.2 drivers/char/drm/sis_mm.c - 1.2 drivers/char/i8k.c - 1.2 drivers/char/istallion.c - 1.2 drivers/char/mem.c - 1.2 drivers/char/nvram.c - 1.2 drivers/char/nwflash.c - 1.2 drivers/char/raw.c - 1.2 drivers/char/sysrq.c - 1.2 drivers/char/tipar.c - 1.3 drivers/char/tpqic02.c - 1.2 drivers/char/vc_screen.c - 1.2 drivers/gsc/eisa_eeprom.c - 1.2 drivers/hotplug/Config.in - 1.2 drivers/hotplug/Makefile - 1.2 drivers/hotplug/acpiphp.h - 1.2 drivers/hotplug/acpiphp_core.c - 1.2 drivers/hotplug/acpiphp_glue.c - 1.2 drivers/hotplug/acpiphp_pci.c - 1.2 drivers/hotplug/acpiphp_res.c - 1.2 drivers/hotplug/pci_hotplug.h - 1.2 drivers/hotplug/pci_hotplug_core.c - 1.2 drivers/ide/Config.in - 1.5 drivers/ide/ide-disk.c - 1.2 drivers/ide/ide.c - 1.3 drivers/ide/pci/aec62xx.c - 1.2 drivers/ide/pci/amd74xx.c - 1.3 drivers/ide/pci/amd74xx.h - 1.3 drivers/ide/pci/cmd64x.c - 1.2 drivers/ide/pci/generic.c - 1.2 drivers/ide/pci/generic.h - 1.3 drivers/ide/pci/hpt34x.c - 1.2 drivers/ide/pci/hpt366.c - 1.3 drivers/ide/pci/it8172.c - 1.2 drivers/ide/pci/pdc202xx_new.c - 1.2 drivers/ide/pci/pdc202xx_old.c - 1.2 drivers/ide/pci/piix.c - 1.3 drivers/ide/pci/serverworks.c - 1.2 drivers/ide/pci/siimage.c - 1.3 drivers/ide/pci/sis5513.c - 1.2 drivers/ide/pci/slc90e66.c - 1.2 drivers/ieee1394/pcilynx.c - 1.2 drivers/ieee1394/sbp2.c - 1.2 drivers/ieee1394/video1394.c - 1.3 drivers/isdn/divert/divert_procfs.c - 1.2 drivers/isdn/hisax/nj_s.c - 1.2 drivers/isdn/hysdn/hysdn_procconf.c - 1.2 drivers/isdn/hysdn/hysdn_proclog.c - 1.2 drivers/isdn/isdn_common.c - 1.2 drivers/isdn/sc/command.c - 1.2 drivers/macintosh/ans-lcd.c - 1.2 drivers/macintosh/nvram.c - 1.2 drivers/md/raid5.c - 1.4 drivers/media/video/cpia.c - 1.2 drivers/media/video/videodev.c - 1.2 drivers/message/fusion/isense.c - 1.3 drivers/message/fusion/lsi/mpi.h - 1.3 drivers/message/fusion/lsi/mpi_cnfg.h - 1.3 drivers/message/fusion/lsi/mpi_fc.h - 1.2 drivers/message/fusion/lsi/mpi_init.h - 1.3 drivers/message/fusion/lsi/mpi_ioc.h - 1.3 drivers/message/fusion/lsi/mpi_lan.h - 1.2 drivers/message/fusion/lsi/mpi_raid.h - 1.3 drivers/message/fusion/lsi/mpi_targ.h - 1.3 drivers/message/fusion/lsi/mpi_type.h - 1.2 drivers/message/fusion/mptbase.c - 1.3 drivers/message/fusion/mptbase.h - 1.4 drivers/message/fusion/mptctl.c - 1.4 drivers/message/fusion/mptctl.h - 1.3 drivers/message/fusion/mptlan.c - 1.2 drivers/message/fusion/mptscsih.c - 1.4 drivers/message/fusion/mptscsih.h - 1.3 drivers/message/fusion/scsi3.h - 1.3 drivers/mtd/mtdchar.c - 1.2 drivers/net/8139cp.c - 1.3 drivers/net/8139too.c - 1.3 drivers/net/8390.c - 1.2 drivers/net/Config.in - 1.3 drivers/net/Makefile - 1.3 drivers/net/a2065.c - 1.2 drivers/net/aironet4500_core.c - 1.2 drivers/net/amd8111e.c - 1.2 drivers/net/amd8111e.h - 1.2 drivers/net/b44.c - 1.2 drivers/net/defxx.c - 1.2 drivers/net/e100/e100.h - 1.3 drivers/net/e100/e100_main.c - 1.3 drivers/net/e100/e100_ucode.h - 1.3 drivers/net/e1000/e1000.h - 1.3 drivers/net/e1000/e1000_ethtool.c - 1.3 drivers/net/e1000/e1000_hw.c - 1.3 drivers/net/e1000/e1000_hw.h - 1.3 drivers/net/e1000/e1000_main.c - 1.3 drivers/net/e1000/e1000_osdep.h - 1.3 drivers/net/e1000/e1000_param.c - 1.3 drivers/net/eql.c - 1.2 drivers/net/fealnx.c - 1.2 drivers/net/hamradio/6pack.c - 1.2 drivers/net/macsonic.c - 1.2 drivers/net/natsemi.c - 1.3 drivers/net/pcnet32.c - 1.3 drivers/net/r8169.c - 1.3 drivers/net/sis900.c - 1.3 drivers/net/sis900.h - 1.2 drivers/net/tg3.c - 1.5 drivers/net/tg3.h - 1.3 drivers/net/tulip/ChangeLog - 1.2 drivers/net/tulip/timer.c - 1.2 drivers/net/tulip/tulip_core.c - 1.3 drivers/net/tun.c - 1.2 drivers/net/via-rhine.c - 1.2 drivers/net/wan/farsync.c - 1.2 drivers/net/wan/farsync.h - 1.2 drivers/net/wireless/airo.c - 1.3 drivers/net/wireless/orinoco_pci.c - 1.2 drivers/parport/ChangeLog - 1.2 drivers/parport/Makefile - 1.2 drivers/parport/parport_pc.c - 1.2 drivers/parport/parport_serial.c - 1.2 drivers/pci/pci.c - 1.2 drivers/pci/pci.ids - 1.3 drivers/pci/proc.c - 1.2 drivers/pci/quirks.c - 1.2 drivers/pcmcia/yenta.c - 1.4 drivers/pnp/isapnp_proc.c - 1.2 drivers/s390/block/dasd.c - 1.3 drivers/s390/char/tapechar.c - 1.2 drivers/s390/net/ctcmain.c - 1.3 drivers/s390/net/netiucv.c - 1.2 drivers/s390/net/qeth.c - 1.2 drivers/s390/s390io.c - 1.3 drivers/sbus/char/flash.c - 1.3 drivers/scsi/ChangeLog.ips - 1.2 drivers/scsi/Config.in - 1.2 drivers/scsi/Makefile - 1.2 drivers/scsi/NCR53C9x.c - 1.2 drivers/scsi/ips.c - 1.3 drivers/scsi/ips.h - 1.3 drivers/scsi/megaraid2.c - 1.3 drivers/scsi/megaraid2.h - 1.3 drivers/scsi/oktagon_esp.c - 1.2 drivers/scsi/osst.c - 1.3 drivers/scsi/scsi_scan.c - 1.3 drivers/scsi/st.c - 1.3 drivers/sound/724hwmcode.h - 1.2 drivers/sound/Hwmcode.h - 1.2 drivers/sound/ad1848.c - 1.2 drivers/sound/cmpci.c - 1.2 drivers/sound/i810_audio.c - 1.3 drivers/sound/kahlua.c - 1.2 drivers/sound/mpu401.c - 1.2 drivers/sound/msnd.c - 1.2 drivers/sound/msnd.h - 1.2 drivers/sound/msnd_pinnacle.c - 1.2 drivers/sound/pss.c - 1.2 drivers/usb/audio.c - 1.3 drivers/usb/auermain.c - 1.3 drivers/usb/brlvger.c - 1.2 drivers/usb/devio.c - 1.2 drivers/usb/drivers.c - 1.2 drivers/usb/gadget/Config.in - 1.4 drivers/usb/gadget/Makefile - 1.4 drivers/usb/gadget/ether.c - 1.4 drivers/usb/gadget/usbstring.c - 1.3 drivers/usb/gadget/zero.c - 1.4 drivers/usb/hiddev.c - 1.3 drivers/usb/host/ehci-hcd.c - 1.3 drivers/usb/host/ehci-sched.c - 1.4 drivers/usb/host/uhci-debug.h - 1.2 drivers/usb/printer.c - 1.3 drivers/usb/serial/ftdi_sio.c - 1.3 drivers/usb/serial/ftdi_sio.h - 1.3 drivers/usb/serial/io_edgeport.c - 1.3 drivers/usb/serial/ipaq.c - 1.2 drivers/usb/serial/mct_u232.c - 1.2 drivers/usb/serial/pl2303.c - 1.3 drivers/usb/serial/usb-serial.h - 1.2 drivers/usb/serial/usbserial.c - 1.2 drivers/usb/serial/visor.c - 1.4 drivers/usb/speedtch.c - 1.2 drivers/usb/storage/jumpshot.c - 1.2 drivers/usb/storage/scsiglue.c - 1.3 drivers/usb/storage/unusual_devs.h - 1.4 drivers/usb/storage/usb.c - 1.4 drivers/usb/storage/usb.h - 1.2 drivers/usb/tiglusb.c - 1.2 drivers/usb/vicam.c - 1.3 drivers/video/fbmem.c - 1.3 drivers/video/riva/accel.c - 1.2 drivers/video/riva/fbdev.c - 1.2 drivers/video/sis/300vtbl.h - 1.4 drivers/video/sis/310vtbl.h - 1.4 drivers/video/sis/init.c - 1.4 drivers/video/sis/init.h - 1.4 drivers/video/sis/init301.c - 1.4 drivers/video/sis/init301.h - 1.4 drivers/video/sis/initdef.h - 1.4 drivers/video/sis/oem300.h - 1.4 drivers/video/sis/oem310.h - 1.4 drivers/video/sis/osdef.h - 1.4 drivers/video/sis/sis.h - 1.2 drivers/video/sis/sis_accel.c - 1.4 drivers/video/sis/sis_accel.h - 1.4 drivers/video/sis/sis_main.c - 1.4 drivers/video/sis/sis_main.h - 1.4 drivers/video/sis/vgatypes.h - 1.4 drivers/video/sis/vstruct.h - 1.4 drivers/zorro/proc.c - 1.2 fs/affs/amigaffs.c - 1.2 fs/affs/bitmap.c - 1.2 fs/affs/super.c - 1.2 fs/attr.c - 1.2 fs/buffer.c - 1.6 fs/cramfs/inode.c - 1.2 fs/devfs/base.c - 1.3 fs/devpts/inode.c - 1.2 fs/dquot.c - 1.3 fs/ext2/inode.c - 1.3 fs/ext2/super.c - 1.3 fs/ext3/inode.c - 1.3 fs/ext3/super.c - 1.4 fs/hfs/file.c - 1.2 fs/hfs/file_cap.c - 1.2 fs/hfs/file_hdr.c - 1.2 fs/hpfs/alloc.c - 1.2 fs/hpfs/anode.c - 1.2 fs/hpfs/buffer.c - 1.2 fs/hpfs/ea.c - 1.2 fs/hpfs/hpfs.h - 1.2 fs/hpfs/hpfs_fn.h - 1.2 fs/hpfs/inode.c - 1.2 fs/hpfs/map.c - 1.2 fs/hpfs/super.c - 1.2 fs/jbd/transaction.c - 1.3 fs/jfs/file.c - 1.2 fs/jfs/inode.c - 1.2 fs/jfs/jfs_btree.h - 1.2 fs/jfs/jfs_debug.c - 1.2 fs/jfs/jfs_dmap.c - 1.3 fs/jfs/jfs_dtree.c - 1.3 fs/jfs/jfs_extent.c - 1.3 fs/jfs/jfs_imap.c - 1.3 fs/jfs/jfs_incore.h - 1.2 fs/jfs/jfs_logmgr.c - 1.5 fs/jfs/jfs_metapage.c - 1.3 fs/jfs/jfs_metapage.h - 1.2 fs/jfs/jfs_txnmgr.c - 1.4 fs/jfs/jfs_txnmgr.h - 1.2 fs/jfs/jfs_types.h - 1.2 fs/jfs/jfs_xtree.c - 1.3 fs/jfs/namei.c - 1.4 fs/jfs/super.c - 1.3 fs/jfs/xattr.c - 1.3 fs/namei.c - 1.3 fs/nfs/dir.c - 1.3 fs/nfs/unlink.c - 1.2 fs/openpromfs/inode.c - 1.2 fs/proc/base.c - 1.2 fs/proc/generic.c - 1.2 fs/proc/kcore.c - 1.2 fs/proc/proc_misc.c - 1.2 fs/reiserfs/journal.c - 1.2 fs/stat.c - 1.2 fs/udf/file.c - 1.2 include/asm-i386/acpi.h - 1.3 include/asm-i386/bitops.h - 1.2 include/asm-i386/i387.h - 1.2 include/asm-i386/smpboot.h - 1.2 include/asm-ia64/acpi.h - 1.3 include/asm-ia64/ia32.h - 1.2 include/asm-ia64/system.h - 1.2 include/asm-m68k/motorola_pgalloc.h - 1.2 include/asm-ppc64/ptrace.h - 1.3 include/asm-sh64/cayman.h - 1.2 include/asm-sh64/io.h - 1.2 include/asm-sh64/keyboard.h - 1.2 include/asm-sh64/processor.h - 1.2 include/asm-sh64/registers.h - 1.2 include/asm-sh64/unistd.h - 1.2 include/asm-sparc64/mmu_context.h - 1.2 include/asm-sparc64/page.h - 1.2 include/asm-sparc64/pgalloc.h - 1.2 include/asm-sparc64/pgtable.h - 1.2 include/asm-sparc64/svr4.h - 1.2 include/asm-sparc64/unistd.h - 1.2 include/asm-x86_64/acpi.h - 1.3 include/asm-x86_64/desc.h - 1.3 include/asm-x86_64/i387.h - 1.2 include/linux/acpi.h - 1.2 include/linux/affs_fs.h - 1.2 include/linux/affs_fs_sb.h - 1.2 include/linux/atmdev.h - 1.3 include/linux/atmlec.h - 1.2 include/linux/cciss_ioctl.h - 1.2 include/linux/compiler.h - 1.3 include/linux/crypto.h - 1.3 include/linux/ethtool.h - 1.2 include/linux/fs.h - 1.6 include/linux/hpfs_fs_sb.h - 1.2 include/linux/icmpv6.h - 1.2 include/linux/if.h - 1.2 include/linux/if_arp.h - 1.2 include/linux/kernel.h - 1.2 include/linux/module.h - 1.4 include/linux/netdevice.h - 1.2 include/linux/netfilter.h - 1.2 include/linux/netfilter_arp.h - 1.2 include/linux/netfilter_ipv4/ip_conntrack.h - 1.4 include/linux/netfilter_ipv4/ip_conntrack_tftp.h - 1.2 include/linux/netfilter_ipv4/ip_tables.h - 1.2 include/linux/netfilter_ipv6/ip6_tables.h - 1.2 include/linux/netlink.h - 1.2 include/linux/pci.h - 1.3 include/linux/pci_ids.h - 1.4 include/linux/pkt_cls.h - 1.2 include/linux/pkt_sched.h - 1.4 include/linux/rtnetlink.h - 1.2 include/linux/sched.h - 1.2 include/linux/sctp.h - 1.3 include/linux/sisfb.h - 1.4 include/linux/skbuff.h - 1.3 include/linux/sysctl.h - 1.6 include/linux/usb_ch9.h - 1.2 include/linux/usb_gadget.h - 1.4 include/net/bluetooth/bluetooth.h - 1.2 include/net/bluetooth/hci.h - 1.3 include/net/bluetooth/l2cap.h - 1.2 include/net/sctp/command.h - 1.3 include/net/sctp/constants.h - 1.3 include/net/sctp/sctp.h - 1.3 include/net/sctp/sm.h - 1.3 include/net/sctp/structs.h - 1.3 include/net/sctp/tsnmap.h - 1.3 include/net/sctp/ulpevent.h - 1.3 include/net/sctp/ulpqueue.h - 1.2 include/net/sctp/user.h - 1.3 include/net/sock.h - 1.3 include/net/tcp.h - 1.3 kernel/sysctl.c - 1.3 lib/rwsem-spinlock.c - 1.2 lib/rwsem.c - 1.4 mm/page_alloc.c - 1.3 mm/shmem.c - 1.2 net/802/Makefile - 1.2 net/802/p8022.c - 1.2 net/802/psnap.c - 1.2 net/8021q/vlan.h - 1.2 net/8021q/vlan_dev.c - 1.3 net/8021q/vlanproc.c - 1.2 net/Config.in - 1.2 net/Makefile - 1.3 net/atm/br2684.c - 1.3 net/atm/lec.c - 1.3 net/atm/lec.h - 1.2 net/atm/lec_arpc.h - 1.2 net/atm/mpoa_proc.c - 1.3 net/bluetooth/af_bluetooth.c - 1.3 net/bluetooth/bnep/core.c - 1.2 net/bluetooth/hci_event.c - 1.2 net/bluetooth/l2cap.c - 1.3 net/bluetooth/rfcomm/tty.c - 1.3 net/bridge/br.c - 1.2 net/bridge/br_if.c - 1.2 net/bridge/br_ioctl.c - 1.2 net/bridge/br_private.h - 1.2 net/bridge/br_stp.c - 1.2 net/core/Makefile - 1.2 net/core/ethtool.c - 1.3 net/core/sock.c - 1.3 net/decnet/dn_dev.c - 1.2 net/ipv4/af_inet.c - 1.2 net/ipv4/devinet.c - 1.5 net/ipv4/igmp.c - 1.6 net/ipv4/ip_gre.c - 1.2 net/ipv4/ip_input.c - 1.2 net/ipv4/ip_sockglue.c - 1.3 net/ipv4/ipip.c - 1.2 net/ipv4/ipmr.c - 1.2 net/ipv4/netfilter/arp_tables.c - 1.2 net/ipv4/netfilter/ip_conntrack_core.c - 1.2 net/ipv4/netfilter/ip_conntrack_standalone.c - 1.3 net/ipv4/netfilter/ip_conntrack_tftp.c - 1.2 net/ipv4/netfilter/ip_fw_compat_masq.c - 1.2 net/ipv4/netfilter/ip_nat_core.c - 1.2 net/ipv4/netfilter/ip_nat_rule.c - 1.2 net/ipv4/netfilter/ip_tables.c - 1.4 net/ipv4/netfilter/ipt_MASQUERADE.c - 1.3 net/ipv4/netfilter/ipt_REJECT.c - 1.2 net/ipv4/netfilter/ipt_ULOG.c - 1.2 net/ipv4/netfilter/ipt_helper.c - 1.3 net/ipv4/netfilter/ipt_owner.c - 1.2 net/ipv4/netfilter/ipt_unclean.c - 1.2 net/ipv4/netfilter/iptable_mangle.c - 1.2 net/ipv4/raw.c - 1.2 net/ipv4/sysctl_net_ipv4.c - 1.3 net/ipv4/tcp.c - 1.2 net/ipv4/tcp_input.c - 1.3 net/ipv4/tcp_minisocks.c - 1.2 net/ipv4/tcp_output.c - 1.2 net/ipv4/udp.c - 1.3 net/ipv6/af_inet6.c - 1.2 net/ipv6/icmp.c - 1.3 net/ipv6/mcast.c - 1.5 net/ipv6/netfilter/ip6_tables.c - 1.4 net/ipv6/netfilter/ip6t_owner.c - 1.2 net/ipv6/raw.c - 1.2 net/ipv6/sit.c - 1.2 net/ipv6/tcp_ipv6.c - 1.3 net/ipv6/udp.c - 1.3 net/netsyms.c - 1.3 net/sched/Config.in - 1.4 net/sched/Makefile - 1.3 net/sched/sch_cbq.c - 1.4 net/sched/sch_dsmark.c - 1.4 net/sched/sch_htb.c - 1.5 net/sched/sch_tbf.c - 1.5 net/sctp/associola.c - 1.3 net/sctp/crc32c.c - 1.2 net/sctp/debug.c - 1.3 net/sctp/ipv6.c - 1.3 net/sctp/objcnt.c - 1.3 net/sctp/output.c - 1.3 net/sctp/outqueue.c - 1.3 net/sctp/protocol.c - 1.3 net/sctp/sm_make_chunk.c - 1.3 net/sctp/sm_sideeffect.c - 1.3 net/sctp/sm_statefuns.c - 1.3 net/sctp/sm_statetable.c - 1.3 net/sctp/socket.c - 1.3 net/sctp/sysctl.c - 1.3 net/sctp/transport.c - 1.3 net/sctp/tsnmap.c - 1.3 net/sctp/ulpevent.c - 1.3 net/sctp/ulpqueue.c - 1.3 net/wanrouter/wanproc.c - 1.2 arch/ppc64/kernel/lparcfg.c - 1.3 drivers/net/irda/via-ircc.c - 1.4 arch/ia64/mm/hugetlbpage.c - 1.2 drivers/message/fusion/lsi/mpi_tool.h - 1.2 drivers/usb/gadget/file_storage.c - 1.3 net/sched/sch_hfsc.c - 1.3 drivers/usb/gadget/config.c - 1.3 drivers/usb/gadget/gadget_chips.h - 1.3 net/sched/sch_delay.c - 1.3 Documentation/networking/packet_mmap.txt - 1.3 crypto/scatterwalk.h - 1.3 net/sctp/chunk.c - 1.3 arch/ppc/cpm2_io/fcc_enet.c - 1.3 From owner-linux-xfs Sun Aug 8 22:33:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 22:33:08 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i795X4XJ012945 for ; Sun, 8 Aug 2004 22:33:04 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i796ZeC7026333 for ; Sun, 8 Aug 2004 23:35:40 -0700 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 i795VP7X10666966; Mon, 9 Aug 2004 15:31:26 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i795VMN17616652; Mon, 9 Aug 2004 15:31:22 +1000 (EST) Date: Mon, 9 Aug 2004 15:31:22 +1000 (EST) From: Nathan Scott Message-Id: <200408090531.i795VMN17616652@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 919278 - fix userspace wrt ramdisk devices X-archive-position: 3862 X-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: 470 Lines: 18 Do not issue BLKFLSBUF to ramdisk devices. Date: Sun Aug 8 22:30:39 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: kealia@gmail.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:176625a xfsprogs/libxfs/init.c - 1.37 xfsprogs/libxfs/init.h - 1.5 xfsprogs/libxfs/linux.c - 1.8 xfsprogs/libxfs/darwin.c - 1.5 xfsprogs/libxfs/irix.c - 1.5 xfsprogs/libxfs/freebsd.c - 1.8 From owner-linux-xfs Sun Aug 8 22:42:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 22:42:33 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i795gVDA013364 for ; Sun, 8 Aug 2004 22:42:31 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i795gN0f022799 for ; Mon, 9 Aug 2004 00:42:25 -0500 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 i795gB7X10820944; Mon, 9 Aug 2004 15:42:12 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i795g9Sa10876910; Mon, 9 Aug 2004 15:42:09 +1000 (EST) Date: Mon, 9 Aug 2004 15:42:09 +1000 (EST) From: Nathan Scott Message-Id: <200408090542.i795g9Sa10876910@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 919278 - xfsprogs builds X-archive-position: 3863 X-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: 748 Lines: 27 Fix up auto-detection of available libc features being used by xfs_io; including sendfile, fadvise, madvise, etc. Date: Sun Aug 8 22:41:55 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:176628a xfsprogs/m4/package_libcdev.m4 - 1.1 xfsprogs/io/madvise.c - 1.1 xfsprogs/io/mincore.c - 1.1 xfsprogs/configure.in - 1.32 xfsprogs/include/builddefs.in - 1.38 xfsprogs/io/command.c - 1.7 xfsprogs/io/command.h - 1.8 xfsprogs/io/Makefile - 1.8 xfsprogs/io/init.c - 1.8 xfsprogs/aclocal.m4 - 1.11 xfsprogs/m4/Makefile - 1.3 xfsprogs/io/fadvise.c - 1.2 xfsprogs/io/io.h - 1.2 xfsprogs/io/mmap.c - 1.4 From owner-linux-xfs Sun Aug 8 22:49:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 22:49:31 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i795nUf2013705 for ; Sun, 8 Aug 2004 22:49:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i796q5K0029743 for ; Sun, 8 Aug 2004 23:52:06 -0700 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 PAA12585; Mon, 9 Aug 2004 15:48:02 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i795ltln3016313; Mon, 9 Aug 2004 15:47:56 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i796hvU4002064; Mon, 9 Aug 2004 16:43:59 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i796hsVu002062; Mon, 9 Aug 2004 16:43:54 +1000 Date: Mon, 9 Aug 2004 16:43:54 +1000 From: Nathan Scott To: Bo Yang Cc: linux-xfs@oss.sgi.com Subject: Re: Patch to make XFS to work on ramdisk Message-ID: <20040809064354.GA1991@frodo> References: <3b94088e04080517166fd22dd3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b94088e04080517166fd22dd3@mail.gmail.com> User-Agent: Mutt/1.5.3i X-archive-position: 3864 X-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: 256 Lines: 15 On Thu, Aug 05, 2004 at 05:16:45PM -0700, Bo Yang wrote: > Hi, > > Appended is a patch to make XFS to work on ramdisk. Hi Bo, Could you try current CVS xfsprogs (2.6.21) when you get a chance and verify this issue is resolved now? thanks! -- Nathan From owner-linux-xfs Sun Aug 8 22:51:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 22:51:22 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i795pJPG014016 for ; Sun, 8 Aug 2004 22:51:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i796rrAB030132 for ; Sun, 8 Aug 2004 23:53:54 -0700 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 PAA12633; Mon, 9 Aug 2004 15:51:07 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i795p4ln3043676; Mon, 9 Aug 2004 15:51:05 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i796l6U4002086; Mon, 9 Aug 2004 16:47:07 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i796kr1p002084; Mon, 9 Aug 2004 16:46:53 +1000 Date: Mon, 9 Aug 2004 16:46:53 +1000 From: Nathan Scott To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared Message-ID: <20040809064653.GB1991@frodo> References: <4774.1090202489@kao2.melbourne.sgi.com> <20040720015826.A2406645@wobbly.melbourne.sgi.com> <40FDFBF2.7020500@berdmann.de> <20040729054638.GK800@frodo> <410B3E47.2030806@berdmann.de> <20040802060109.GF21646@frodo> <410EB73E.9080603@berdmann.de> <20040805044621.GE3619@frodo> <411298E2.60404@berdmann.de> <20040806085007.GA4142@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040806085007.GA4142@frodo> User-Agent: Mutt/1.5.3i X-archive-position: 3865 X-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: 601 Lines: 19 On Fri, Aug 06, 2004 at 06:50:07PM +1000, Nathan Scott wrote: > On Thu, Aug 05, 2004 at 10:30:26PM +0200, Bernhard Erdmann wrote: > > Nathan Scott wrote: > > [...] > > >Ugh, this is going to take some autoconf/configure work to avoid > > >compiling these files entirely I think. Or you could upgrade to > > >a more recent distribution (did you say Redhat 6.2?)... > > > > uuuuuhhhh... yeah... some day I'll upgrade this ancient linux installation > > s'okay, i have a fix - should be available by next week. Should be fixed in CVS xfsprogs (2.6.21) now - let me know if not. cheers. -- Nathan From owner-linux-xfs Sun Aug 8 22:56:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 22:56:13 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i795uBBE014400 for ; Sun, 8 Aug 2004 22:56:11 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i795uBbT014399 for linux-xfs@oss.sgi.com; Sun, 8 Aug 2004 22:56:11 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i795u9ZZ014385 for ; Sun, 8 Aug 2004 22:56:09 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i795o3GB013812; Sun, 8 Aug 2004 22:50:03 -0700 Date: Sun, 8 Aug 2004 22:50:03 -0700 Message-Id: <200408090550.i795o3GB013812@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 352] Compilation failure in sendfile.c X-Bugzilla-Reason: AssignedTo X-archive-position: 3866 X-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: 666 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=352 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From nathans@sgi.com 2004-08-08 22:50 PDT ------- Could you try building with xfsprogs from XFS CVS (version 2.6.21)? This issue should be resolved there now after a fresh checkout. thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Aug 8 23:25:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 23:25:22 -0700 (PDT) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i796PH4d015260 for ; Sun, 8 Aug 2004 23:25:18 -0700 Received: from erbenson.alaska.net (66-230-90-228-dial-as4.nwc.acsalaska.net [66.230.90.228]) by hob.acsalaska.net (8.12.11/8.12.11) with ESMTP id i796PBQM028444 for ; Sun, 8 Aug 2004 22:25:12 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 83A59393C for ; Sun, 8 Aug 2004 22:25:10 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 9D50C40FF35; Sun, 8 Aug 2004 22:25:10 -0800 (AKDT) Date: Sun, 8 Aug 2004 22:25:10 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - update split patches Message-ID: <20040809062510.GA23859@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200408090421.i794LHJ12766@chook.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <200408090421.i794LHJ12766@chook.melbourne.sgi.com> 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-ACS-Scanned-By: MD 2.42; SA 2.63; spamdefang 1.102 X-archive-position: 3867 X-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: 1086 Lines: 42 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2004 at 02:21:17PM +1000, Nathan Scott wrote: > Update 2.4 split patches for 2.4.27 merge. >=20 > Date: Sun Aug 8 21:20:28 PDT 2004 > Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs > Inspected by: nathans >=20 > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs >=20 >=20 > Modid: 2.4.x-xfs:linux:176622a > split-patches/series - 1.8 > split-patches/rwsem-backport - 1.2 > split-patches/downgrade_write-backport - 1.2 how important are these particular patches? is there any serious issue with using 2.4.27 mainline? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkEXGMYACgkQJKx7GixEevzjpgCeKvdFPQzs8V6xijnJQQ8yCuk4 bVUAnRHpzq2r9R2hGS69hl0aI9GAkQcj =owwY -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-linux-xfs Sun Aug 8 23:33:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Aug 2004 23:33:09 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i796X725015659 for ; Sun, 8 Aug 2004 23:33:07 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i797Zfk4005930 for ; Mon, 9 Aug 2004 00:35:43 -0700 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 QAA13484 for ; Mon, 9 Aug 2004 16:31:42 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i796Veln3046276 for ; Mon, 9 Aug 2004 16:31:40 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i797RgU4002214 for ; Mon, 9 Aug 2004 17:27:43 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i797RfGG002212 for linux-xfs@oss.sgi.com; Mon, 9 Aug 2004 17:27:41 +1000 Date: Mon, 9 Aug 2004 17:27:41 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - update split patches Message-ID: <20040809072741.GC1991@frodo> References: <200408090421.i794LHJ12766@chook.melbourne.sgi.com> <20040809062510.GA23859@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040809062510.GA23859@plato.local.lan> User-Agent: Mutt/1.5.3i X-archive-position: 3868 X-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: 638 Lines: 24 Hi Ethan, On Sun, Aug 08, 2004 at 10:25:10PM -0800, Ethan Benson wrote: > On Mon, Aug 09, 2004 at 02:21:17PM +1000, Nathan Scott wrote: > > ... > > Modid: 2.4.x-xfs:linux:176622a > > split-patches/series - 1.8 > > split-patches/rwsem-backport - 1.2 > > split-patches/downgrade_write-backport - 1.2 > > how important are these particular patches? is there any serious > issue with using 2.4.27 mainline? They improve mrlock scalability at large CPU counts. Starts to get noticable at >16 CPUs and only for certain workloads where specific locks become highly contended. So, not important at all for most folks. cheers. -- Nathan From owner-linux-xfs Mon Aug 9 02:52:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Aug 2004 02:52:11 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i799q4n5026460 for ; Mon, 9 Aug 2004 02:52:05 -0700 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i799ptkT003662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2004 11:51:56 +0200 Received: (from thimm@localhost) by neu.physik.fu-berlin.de (8.12.11/8.12.11/Submit) id i799pu2H031723; Mon, 9 Aug 2004 11:51:56 +0200 Date: Mon, 9 Aug 2004 11:51:51 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: oopses with xfs 1.3.1 on 2.4.22 (FC1 kernel patched by ATrpms) Message-ID: <20040809095151.GA30787@neu.physik.fu-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-archive-position: 3869 X-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@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 4339 Lines: 106 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I am using the 2.4.22-1.2197.nptl_51.rhfc1.at kernels, which are RH's latest errata kernels for FC1 with xfs 1.3.1 patched in (and some other less relevant patches). Another oops was one stack level deeper in _pagebuf_find. Is this a known bug of XFS 1.3.1? If yes, when does it trigger, and how can I avoid it in the future? And finally: the oops caused some httpd processes to get stuck in D state. Is there any other way to get rid of them other than rebooting - rebooting when xfs oopses that way is not possible, only hard power-cycles :(? Thanks! Aug 9 10:40:36 heretic kernel: Unable to handle kernel paging request at v= irtual address 852e08c0 Aug 9 10:40:36 heretic kernel: printing eip: Aug 9 10:40:36 heretic kernel: f8a4c2fe Aug 9 10:40:36 heretic kernel: *pde =3D 00000000 Aug 9 10:40:36 heretic kernel: Oops: 0002 Aug 9 10:40:36 heretic kernel: nfs ipt_LOG ipt_limit ipt_conntrack binfmt_= misc nfsd lockd sunrpc autofs4 via686a eeprom i2c-proc i2c-isa i2c-viapro i= 2c-core iptable_filter ip_nat_ftp ip_con Aug 9 10:40:36 heretic kernel: CPU: 0 Aug 9 10:40:36 heretic kernel: EIP: 0060:[] Not tainted Aug 9 10:40:36 heretic kernel: EFLAGS: 00010286 Aug 9 10:40:36 heretic kernel:=20 Aug 9 10:40:36 heretic kernel: EIP is at _pagebuf_initialize [xfs] 0xae (2= .4.22-1.2197.nptl_51.rhfc1.at) Aug 9 10:40:36 heretic kernel: eax: c5b53480 ebx: 4366f000 ecx: c5b534= 80 edx: 00010221 Aug 9 10:40:36 heretic kernel: esi: 00000006 edi: c5b53534 ebp: 000010= 00 esp: c3487c14 Aug 9 10:40:42 heretic kernel: ds: 0068 es: 0068 ss: 0068 Aug 9 10:40:42 heretic kernel: Process rsync (pid: 25265, stackpage=3Dc348= 7000) Aug 9 10:40:53 heretic kernel: Stack: 0000000c 00000014 00800000 00000000 = d788fc2c d788fc00 4366f000 00000006=20 Aug 9 10:40:58 heretic kernel: f8a4ca80 c5b53480 f7d58340 4366f000 = 00000006 00001000 0001a205 f8a82d40=20 Aug 9 10:40:59 heretic kernel: 000000e8 c5b53480 000129f1 0000a205 = 00000000 f8a4cc4f f7d58340 0321b378=20 Aug 9 10:41:00 heretic kernel: Call Trace: [] _pagebuf_find [x= fs] 0xe0 (0xc3487c34) Aug 9 10:41:00 heretic kernel: [] pbhash [xfs] 0xae0 (0xc3487c50) Aug 9 10:41:04 heretic kernel: [] pagebuf_get [xfs] 0x7f (0xc348= 7c68) Aug 9 10:41:05 heretic kernel: [] xfs_trans_read_buf [xfs] 0x32e= (0xc3487c98) Aug 9 10:41:07 heretic kernel: [] xfs_da_do_buf [xfs] 0x6b7 (0xc= 3487cc0) Aug 9 10:41:09 heretic kernel: [] xfs_da_read_buf [xfs] 0x57 (0x= c3487d60) Aug 9 10:41:11 heretic kernel: [] xfs_da_node_lookup_int [xfs] 0= xa4 (0xc3487d80) Aug 9 10:41:13 heretic kernel: [] xfs_da_node_lookup_int [xfs] 0= xa4 (0xc3487d8c) Aug 9 10:41:16 heretic kernel: [] xfs_dir2_node_lookup [xfs] 0x3= f (0xc3487dd4) Aug 9 10:41:22 heretic kernel: [] xfs_dir2_lookup [xfs] 0x128 (0= xc3487df4) Aug 9 10:41:28 heretic kernel: [] xfs_dir_lookup_int [xfs] 0x4c = (0xc3487e78) Aug 9 10:41:32 heretic kernel: [] xfs_lookup [xfs] 0x65 (0xc3487= eac) Aug 9 10:41:33 heretic kernel: [] linvfs_lookup [xfs] 0x67 (0xc3= 487edc) Aug 9 10:41:37 heretic kernel: [] real_lookup [kernel] 0xc7 (0xc= 3487f04) Aug 9 10:41:40 heretic kernel: [] link_path_walk [kernel] 0x558 = (0xc3487f20) Aug 9 10:41:41 heretic kernel: [] path_lookup [kernel] 0x37 (0xc= 3487f60) Aug 9 10:41:46 heretic kernel: [] __user_walk [kernel] 0x49 (0xc= 3487f70) Aug 9 10:41:49 heretic kernel: [] sys_lstat64 [kernel] 0x1f (0xc= 3487f8c) Aug 9 10:41:50 heretic kernel: [] system_call [kernel] 0x33 (0xc= 3487fc0) Aug 9 10:41:51 heretic kernel:=20 Aug 9 10:41:56 heretic kernel:=20 Aug 9 10:41:57 heretic kernel: Code: ff 83 c0 18 c7 41 14 00 00 00 00 89 4= 1 18 89 40 04 ff 05 04=20 --=20 Axel.Thimm at ATrpms.net --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBF0hGQBVS1GOamfERAr90AJ442m8bvJiZoSUn1kihp16oNk4SpACfZasL npxhQ4MHY6m5fRXRWb6fiag= =a6ix -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-linux-xfs Mon Aug 9 03:11:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Aug 2004 03:11:50 -0700 (PDT) Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i79ABifB027423 for ; Mon, 9 Aug 2004 03:11:45 -0700 Received: from xiii.bis.pasteur.fr (xiii.bis.pasteur.fr [157.99.90.14]) by electre.pasteur.fr (8.12.11/8.12.11) with ESMTP id i79ABbOG288475; Mon, 9 Aug 2004 12:11:37 +0200 (CEST) Received: (from tru@localhost) by xiii.bis.pasteur.fr (8.11.6/8.11.6) id i79ABbu17089; Mon, 9 Aug 2004 12:11:37 +0200 Date: Mon, 9 Aug 2004 12:11:37 +0200 From: Tru Huynh To: Dan Yocum Cc: xfs-list Subject: oops release-1.3.3-pre2/x86_64 from Scientific Linux Message-ID: <20040809121137.A16748@xiii.bis.pasteur.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 3870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tru@pasteur.fr Precedence: bulk X-list: linux-xfs Content-Length: 4533 Lines: 68 On Thu, Aug 05, 2004 at 04:35:00PM -0500, Dan Yocum wrote: > Hi all, > > I thought you might be interested that I've incorporated Eric's RHEL kernel > into the Scientific Linux distrobution. This is the same kernel found in > ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre2/kernels/RHEL/RPMS. > I took the liberty of merging the xfs bits back into the kernel so there's > no more xfs-modules rpm package. Other than that, it's the same kernel as > Eric's (with devfs compiled in, but disabled at boot time). Thanks for the work, I have rebuild the kernel-smp from the src.rpm on a x86_64 machine. I have a IDE-SCSI external attachement with 2 LUNs (1.2/1.6TB) XFS formatted partitions from a IA32 machine through an Adaptec 29160 card. The LUNs are properly discovered, xfs is properly loaded but the machine hard locks upon 'mount /dev/sdc1 /mnt': nothing on remote syslog/console. Aug 9 12:01:46 cybot kernel: scsi : 2 hosts left. Aug 9 12:01:48 cybot kernel: PCI: Enabling device 01:03.0 (0115 -> 0117) Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Reading SEEPROM...done. Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: BIOS eeprom is present Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Secondary High byte termination Enabled Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Secondary Low byte termination Enabled Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Primary Low Byte termination Enabled Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Primary High Byte termination Enabled Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Downloading Sequencer Program... 422 instructions downloaded Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Features 0x1def6, Bugs 0x40, Flags 0x20405540 Aug 9 12:01:48 cybot kernel: scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Aug 9 12:01:48 cybot kernel: Aug 9 12:01:48 cybot kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs Aug 9 12:01:48 cybot kernel: Aug 9 12:02:03 cybot kernel: scsi2:A:0:0: DV failed to configure device. Please file a bug report against this driver. Aug 9 12:02:06 cybot kernel: (scsi2:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 Aug 9 12:02:06 cybot kernel: (scsi2:A:0:0): Received PPR width 1, period 9, offset 1f,options 2 Aug 9 12:02:06 cybot kernel: ^IFiltered to width 1, period 9, offset 1f, options 2 Aug 9 12:02:06 cybot kernel: (scsi2:A:0): 6.600MB/s transfers (16bit) Aug 9 12:02:06 cybot kernel: scsi2: target 0 using 16bit transfers Aug 9 12:02:06 cybot kernel: (scsi2:A:0): 160.000MB/s transfers (80.000MHz DT, offset 31, 16bit) Aug 9 12:02:06 cybot kernel: scsi2: target 0 synchronous at 80.0MHz DT, offset = 0x1f Aug 9 12:02:06 cybot kernel: Vendor: FX-1600U Model: 3-R Rev: 0001 Aug 9 12:02:06 cybot kernel: Type: Direct-Access ANSI SCSI revision: 03 Aug 9 12:02:06 cybot kernel: Vendor: FX-1600U Model: 3-R Rev: 0001 Aug 9 12:02:07 cybot kernel: Type: Direct-Access ANSI SCSI revision: 03 Aug 9 12:02:10 cybot kernel: (scsi2:A:0): 160.000MB/s transfers (80.000MHz DT, offset 31, 16bit) Aug 9 12:02:10 cybot kernel: scsi2:A:0:0: Tagged Queuing enabled. Depth 32 Aug 9 12:02:10 cybot kernel: (scsi2:A:0): 160.000MB/s transfers (80.000MHz DT, offset 31, 16bit) Aug 9 12:02:10 cybot kernel: scsi2:A:0:1: Tagged Queuing enabled. Depth 32 Aug 9 12:02:10 cybot kernel: Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0 Aug 9 12:02:10 cybot kernel: Attached scsi disk sdd at scsi2, channel 0, id 0, lun 1 Aug 9 12:02:10 cybot kernel: SCSI device sdc: 3418718208 512-byte hdwr sectors (1750384 MB) Aug 9 12:02:10 cybot kernel: /dev/scsi/host2/bus0/target0/lun0: p1 Aug 9 12:02:10 cybot kernel: (scsi2:A:0:1): Sending PPR bus_width 1, period 9, offset 1f, ppr_options 2 Aug 9 12:02:10 cybot kernel: (scsi2:A:0:1): Received PPR width 1, period 9, offset 1f,options 2 Aug 9 12:02:10 cybot kernel: ^IFiltered to width 1, period 9, offset 1f, options 2 Aug 9 12:02:10 cybot kernel: SCSI device sdd: 2441936896 512-byte hdwr sectors (1250272 MB) Aug 9 12:02:10 cybot kernel: /dev/scsi/host2/bus0/target0/lun1: p1 Aug 9 12:03:18 cybot kernel: SGI XFS 1.3.3 with ACLs, large block/inode numbers, no debug enabled Tru -- Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France From owner-linux-xfs Mon Aug 9 06:52:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Aug 2004 06:52:53 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i79DqmJu008023 for ; Mon, 9 Aug 2004 06:52:48 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i79Dqh0f011264 for ; Mon, 9 Aug 2004 08:52:43 -0500 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i79DqeYX36274926; Mon, 9 Aug 2004 06:52:41 -0700 (PDT) Message-ID: <411781A8.80104@sgi.com> Date: Mon, 09 Aug 2004 08:52:40 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tru Huynh CC: Dan Yocum , xfs-list Subject: Re: oops release-1.3.3-pre2/x86_64 from Scientific Linux References: <20040809121137.A16748@xiii.bis.pasteur.fr> In-Reply-To: <20040809121137.A16748@xiii.bis.pasteur.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3871 X-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: 5037 Lines: 84 what does your ffs() look like? I added this patch to our kernels, but it may not be in Dan's kernels (hm, I need to update the 1.3.3 packages we have on oss...) --- linux/include/asm-x86_64/bitops.h.orig 2004-07-26 12:33:54.000000000 -0500 +++ linux/include/asm-x86_64/bitops.h 2004-07-26 12:35:23.000000000 -0500 @@ -473,7 +473,7 @@ static __inline__ int ffs(int x) __asm__("bsfl %1,%0\n\t" "cmovzl %2,%0" - : "=r" (r) : "g" (x), "r" (32)); + : "=r" (r) : "rm" (x), "r" (-1)); return r+1; } Tru Huynh wrote: > On Thu, Aug 05, 2004 at 04:35:00PM -0500, Dan Yocum wrote: > >>Hi all, >> >>I thought you might be interested that I've incorporated Eric's RHEL kernel >>into the Scientific Linux distrobution. This is the same kernel found in >>ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre2/kernels/RHEL/RPMS. >> I took the liberty of merging the xfs bits back into the kernel so there's >>no more xfs-modules rpm package. Other than that, it's the same kernel as >>Eric's (with devfs compiled in, but disabled at boot time). > > > Thanks for the work, > > I have rebuild the kernel-smp from the src.rpm on a x86_64 machine. > I have a IDE-SCSI external attachement with 2 LUNs (1.2/1.6TB) XFS > formatted partitions from a IA32 machine through an Adaptec 29160 card. > > The LUNs are properly discovered, xfs is properly loaded but > the machine hard locks upon 'mount /dev/sdc1 /mnt': nothing > on remote syslog/console. > > Aug 9 12:01:46 cybot kernel: scsi : 2 hosts left. > Aug 9 12:01:48 cybot kernel: PCI: Enabling device 01:03.0 (0115 -> 0117) > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Reading SEEPROM...done. > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: BIOS eeprom is present > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Secondary High byte termination Enabled > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Secondary Low byte termination Enabled > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Primary Low Byte termination Enabled > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Primary High Byte termination Enabled > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Downloading Sequencer Program... 422 instructions downloaded > Aug 9 12:01:48 cybot kernel: ahc_pci:1:3:0: Features 0x1def6, Bugs 0x40, Flags 0x20405540 > Aug 9 12:01:48 cybot kernel: scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 > Aug 9 12:01:48 cybot kernel: > Aug 9 12:01:48 cybot kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs > Aug 9 12:01:48 cybot kernel: > Aug 9 12:02:03 cybot kernel: scsi2:A:0:0: DV failed to configure device. Please file a bug report against this driver. > Aug 9 12:02:06 cybot kernel: (scsi2:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 > Aug 9 12:02:06 cybot kernel: (scsi2:A:0:0): Received PPR width 1, period 9, offset 1f,options 2 > Aug 9 12:02:06 cybot kernel: ^IFiltered to width 1, period 9, offset 1f, options 2 > Aug 9 12:02:06 cybot kernel: (scsi2:A:0): 6.600MB/s transfers (16bit) > Aug 9 12:02:06 cybot kernel: scsi2: target 0 using 16bit transfers > Aug 9 12:02:06 cybot kernel: (scsi2:A:0): 160.000MB/s transfers (80.000MHz DT, offset 31, 16bit) > Aug 9 12:02:06 cybot kernel: scsi2: target 0 synchronous at 80.0MHz DT, offset = 0x1f > Aug 9 12:02:06 cybot kernel: Vendor: FX-1600U Model: 3-R Rev: 0001 > Aug 9 12:02:06 cybot kernel: Type: Direct-Access ANSI SCSI revision: 03 > Aug 9 12:02:06 cybot kernel: Vendor: FX-1600U Model: 3-R Rev: 0001 > Aug 9 12:02:07 cybot kernel: Type: Direct-Access ANSI SCSI revision: 03 > Aug 9 12:02:10 cybot kernel: (scsi2:A:0): 160.000MB/s transfers (80.000MHz DT, offset 31, 16bit) > Aug 9 12:02:10 cybot kernel: scsi2:A:0:0: Tagged Queuing enabled. Depth 32 > Aug 9 12:02:10 cybot kernel: (scsi2:A:0): 160.000MB/s transfers (80.000MHz DT, offset 31, 16bit) > Aug 9 12:02:10 cybot kernel: scsi2:A:0:1: Tagged Queuing enabled. Depth 32 > Aug 9 12:02:10 cybot kernel: Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0 > Aug 9 12:02:10 cybot kernel: Attached scsi disk sdd at scsi2, channel 0, id 0, lun 1 > Aug 9 12:02:10 cybot kernel: SCSI device sdc: 3418718208 512-byte hdwr sectors (1750384 MB) > Aug 9 12:02:10 cybot kernel: /dev/scsi/host2/bus0/target0/lun0: p1 > Aug 9 12:02:10 cybot kernel: (scsi2:A:0:1): Sending PPR bus_width 1, period 9, offset 1f, ppr_options 2 > Aug 9 12:02:10 cybot kernel: (scsi2:A:0:1): Received PPR width 1, period 9, offset 1f,options 2 > Aug 9 12:02:10 cybot kernel: ^IFiltered to width 1, period 9, offset 1f, options 2 > Aug 9 12:02:10 cybot kernel: SCSI device sdd: 2441936896 512-byte hdwr sectors (1250272 MB) > Aug 9 12:02:10 cybot kernel: /dev/scsi/host2/bus0/target0/lun1: p1 > Aug 9 12:03:18 cybot kernel: SGI XFS 1.3.3 with ACLs, large block/inode numbers, no debug enabled > > > Tru From owner-linux-xfs Mon Aug 9 07:11:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Aug 2004 07:11:02 -0700 (PDT) Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i79EAvL6008884 for ; Mon, 9 Aug 2004 07:11:00 -0700 Received: from xiii.bis.pasteur.fr (xiii.bis.pasteur.fr [157.99.90.14]) by electre.pasteur.fr (8.12.11/8.12.11) with ESMTP id i79EApL5387476; Mon, 9 Aug 2004 16:10:51 +0200 (CEST) Received: (from tru@localhost) by xiii.bis.pasteur.fr (8.11.6/8.11.6) id i79EAp822391; Mon, 9 Aug 2004 16:10:51 +0200 Date: Mon, 9 Aug 2004 16:10:51 +0200 From: Tru Huynh To: Eric Sandeen Cc: Dan Yocum , xfs-list Subject: Re: oops release-1.3.3-pre2/x86_64 from Scientific Linux Message-ID: <20040809161051.B22340@xiii.bis.pasteur.fr> References: <20040809121137.A16748@xiii.bis.pasteur.fr> <411781A8.80104@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <411781A8.80104@sgi.com>; from sandeen@sgi.com on Mon, Aug 09, 2004 at 08:52:40AM -0500 X-archive-position: 3872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tru@pasteur.fr Precedence: bulk X-list: linux-xfs Content-Length: 1058 Lines: 35 On Mon, Aug 09, 2004 at 08:52:40AM -0500, Eric Sandeen wrote: > what does your ffs() look like? I added this patch to our kernels, but > it may not be in Dan's kernels (hm, I need to update the 1.3.3 packages > we have on oss...) > > --- linux/include/asm-x86_64/bitops.h.orig 2004-07-26 > 12:33:54.000000000 -0500 > +++ linux/include/asm-x86_64/bitops.h 2004-07-26 12:35:23.000000000 -0500 > @@ -473,7 +473,7 @@ static __inline__ int ffs(int x) > > __asm__("bsfl %1,%0\n\t" > "cmovzl %2,%0" > - : "=r" (r) : "g" (x), "r" (32)); > + : "=r" (r) : "rm" (x), "r" (-1)); > return r+1; > } include/asm-x86_64/bitops.h ... 470 static __inline__ int ffs(int x) 471 { 472 int r; 473 474 __asm__("bsfl %1,%0\n\t" 475 "cmovzl %2,%0" 476 : "=r" (r) : "g" (x), "r" (32)); 477 return r+1; 478 } I am changing line 476 to :"=r" (r) : "rm" (x), "r" (-1)); I will post the results ASAP. thanks, Tru From owner-linux-xfs Mon Aug 9 08:03:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Aug 2004 08:03:46 -0700 (PDT) Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i79F3gaa017537 for ; Mon, 9 Aug 2004 08:03:43 -0700 Received: from xiii.bis.pasteur.fr (xiii.bis.pasteur.fr [157.99.90.14]) by electre.pasteur.fr (8.12.11/8.12.11) with ESMTP id i79F3agg416172; Mon, 9 Aug 2004 17:03:36 +0200 (CEST) Received: (from tru@localhost) by xiii.bis.pasteur.fr (8.11.6/8.11.6) id i79F3a724263; Mon, 9 Aug 2004 17:03:36 +0200 Date: Mon, 9 Aug 2004 17:03:35 +0200 From: Tru Huynh To: Eric Sandeen Cc: Dan Yocum , xfs-list Subject: Re: oops release-1.3.3-pre2/x86_64 from Scientific Linux Message-ID: <20040809170335.A24256@xiii.bis.pasteur.fr> References: <20040809121137.A16748@xiii.bis.pasteur.fr> <411781A8.80104@sgi.com> <20040809161051.B22340@xiii.bis.pasteur.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040809161051.B22340@xiii.bis.pasteur.fr>; from tru@pasteur.fr on Mon, Aug 09, 2004 at 04:10:51PM +0200 X-archive-position: 3873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tru@pasteur.fr Precedence: bulk X-list: linux-xfs Content-Length: 1276 Lines: 39 On Mon, Aug 09, 2004 at 04:10:51PM +0200, Tru Huynh wrote: > On Mon, Aug 09, 2004 at 08:52:40AM -0500, Eric Sandeen wrote: > > what does your ffs() look like? I added this patch to our kernels, but > > it may not be in Dan's kernels (hm, I need to update the 1.3.3 packages > > we have on oss...) > > > > --- linux/include/asm-x86_64/bitops.h.orig 2004-07-26 > > 12:33:54.000000000 -0500 > > +++ linux/include/asm-x86_64/bitops.h 2004-07-26 12:35:23.000000000 -0500 > > @@ -473,7 +473,7 @@ static __inline__ int ffs(int x) > > > > __asm__("bsfl %1,%0\n\t" > > "cmovzl %2,%0" > > - : "=r" (r) : "g" (x), "r" (32)); > > + : "=r" (r) : "rm" (x), "r" (-1)); > > return r+1; > > } > include/asm-x86_64/bitops.h > ... > 470 static __inline__ int ffs(int x) > 471 { > 472 int r; > 473 > 474 __asm__("bsfl %1,%0\n\t" > 475 "cmovzl %2,%0" > 476 : "=r" (r) : "g" (x), "r" (32)); > 477 return r+1; > 478 } > > I am changing line 476 to :"=r" (r) : "rm" (x), "r" (-1)); > I will post the results ASAP. Yes!!!! that works (mount read-only for the moment) but I can access the files there :D **Best regards**, Tru From owner-linux-xfs Mon Aug 9 15:23:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Aug 2004 15:23:22 -0700 (PDT) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i79MNJFG006644 for ; Mon, 9 Aug 2004 15:23:19 -0700 Received: from port-212-202-185-131.dynamic.qsc.de ([212.202.185.131] helo=ente.berdmann.de) by coredumps.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.33) id 1BuIXx-0007Uq-Hy for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 00:23:13 +0200 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1BuIXx-0006k9-00 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 00:23:13 +0200 Message-ID: <4117F94F.2060204@berdmann.de> Date: Tue, 10 Aug 2004 00:23:11 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.6) Gecko/20040505 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared References: <4774.1090202489@kao2.melbourne.sgi.com> <20040720015826.A2406645@wobbly.melbourne.sgi.com> <40FDFBF2.7020500@berdmann.de> <20040729054638.GK800@frodo> <410B3E47.2030806@berdmann.de> <20040802060109.GF21646@frodo> <410EB73E.9080603@berdmann.de> <20040805044621.GE3619@frodo> <411298E2.60404@berdmann.de> <20040806085007.GA4142@frodo> <20040809064653.GB1991@frodo> In-Reply-To: <20040809064653.GB1991@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3874 X-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: 143 Lines: 6 Nathan Scott wrote: [...] > Should be fixed in CVS xfsprogs (2.6.21) now - let me know if not. Great! Thanks, xfsprogs builds perfectly now. From owner-linux-xfs Tue Aug 10 03:56:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 03:56:20 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AAuHpX016985 for ; Tue, 10 Aug 2004 03:56:17 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7AAuHFL016984 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 03:56:17 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AAuFTS016969 for ; Tue, 10 Aug 2004 03:56:15 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7AA20Ao014403; Tue, 10 Aug 2004 03:02:00 -0700 Date: Tue, 10 Aug 2004 03:02:00 -0700 Message-Id: <200408101002.i7AA20Ao014403@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3875 X-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: 1051 Lines: 36 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-10-08 03:02 PDT ------- Additional info. Using 64K pages, I can trigger the bug, however, any other supported page size (4K, 8K, 16K) works OK. This is with default 4K block size (mkfs.xfs). BUT: if block size equals page size (-b size=64k), then 64K pages are OK as well. Overview matrix: +----------+--------+-----+-----+-----+-----+ |page/block| 4k | 8k | 16k | 32k | 64k | +----------+--------+-----+-----+-----+-----+ | 4k | ok | - | - | - | - | +----------+--------+-----+-----+-----+-----+ | 8k | ok | - | - | - | - | +----------+--------+-----+-----+-----+-----+ | 16k | ok | - | - | - | - | +----------+--------+-----+-----+-----+-----+ | 64k |shutdown| - | - |oops | ok | +----------+--------+-----+-----+-----+-----+ HTH, Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 05:33:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 05:33:05 -0700 (PDT) Received: from plato.arts.usyd.edu.au (plato.arts.usyd.edu.au [129.78.16.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7ACX1VX024650 for ; Tue, 10 Aug 2004 05:33:02 -0700 Received: from [129.78.226.234] (holly.aitch.ucc.usyd.edu.au [129.78.226.234]) by plato.arts.usyd.edu.au (8.12.6/8.12.6) with ESMTP id i7ACWt8S009981 for ; Tue, 10 Aug 2004 22:32:55 +1000 (EST) Message-ID: <4118C077.1070209@arts.usyd.edu.au> Date: Tue, 10 Aug 2004 22:32:55 +1000 From: Matthew Geier User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Fedora Core 2 with XFS Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080805000603080703070106" X-archive-position: 3876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matthew@arts.usyd.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 5620 Lines: 104 This is a cryptographically signed message in MIME format. --------------ms080805000603080703070106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thought I'd post just as I see this sort of thing asked a lot. I just upgraded a Redhat 8.0-sgi-xfs system to Fedora Core 2 by simply booting the Fedora 2 CD. It found a Redhat 8.0 system on the XFS formatted system and upgraded it with out issue - or with out any issue i've so far detected, the system is up and running again, with the latest Fedora updates applied and every thing we need the machine to do it seems to be doing. (Except IPMI, I need to recompile the kernel to enable it - but that's minor in the grand scheme of things). Fedora Core 2 and XFS - it just works.... --------------ms080805000603080703070106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIJmzCCAygwggKRoAMCAQICAwxAwjANBgkqhkiG9w0BAQQFADBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDQwNTA1MDUwMTUwWhcNMDUwNTA1MDUwMTUwWjB3MR8wHQYD VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhht YXR0aGV3QGFydHMudXN5ZC5lZHUuYXUxKzApBgkqhkiG9w0BCQEWHG1hdHRo ZXdAc2xlZXBlci5hcGFuYS5vcmcuYXUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDwAd1tx+TWOfa5VADB99s2pAaccqVbTISUBoOdIaPeOR+H gHeRg0VbYc0c1+8x6ed/bBeEk8Ve6V8vQ3lq7PwwBHFXSUn1vqSPtPwm+ti/ mhCu/ZqdMs+pTGRbcPng7pABRkKNyDujDELu4H6FvFSBYkXFVHiMCRUzaETb gGZIGY8qKqRUgSWeRpTEkqsr8HdtIhtMzkT2oXC8nnQGGK0UIF60EqUUKpFM HyKsmZXx2Vjk8qosYIoD0mTvisYLYY8MHKaXgxt4qLNJ6Ts6ZwLmmHv6uPuU y4dU8YWttOhI6mug/lT4BHE3Oz2jy/Geanancg8bFWRrSphuGekv0wGRAgMB AAGjUzBRMEEGA1UdEQQ6MDiBGG1hdHRoZXdAYXJ0cy51c3lkLmVkdS5hdYEc bWF0dGhld0BzbGVlcGVyLmFwYW5hLm9yZy5hdTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAKYUVmleWefqGmH5SeQMX8M89Tt9l6qr6b+rQN6S 8SgSoLziOW1ND+y3Ph78BV9v82QWNBM2G65TFsFd64fgptwYdnj4/hYrlkJF UeghOQE9zS4+LWOwlS1f/tn5SuuP7c2lb1+MNlGsnI6mwpCjqbPGpGMhsS1v CBgTrYinXeb1MIIDKDCCApGgAwIBAgIDDEDCMA0GCSqGSIb3DQEBBAUAMGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNDA1MDUwNTAxNTBaFw0wNTA1MDUwNTAxNTBaMHcxHzAd BgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJzAlBgkqhkiG9w0BCQEW GG1hdHRoZXdAYXJ0cy51c3lkLmVkdS5hdTErMCkGCSqGSIb3DQEJARYcbWF0 dGhld0BzbGVlcGVyLmFwYW5hLm9yZy5hdTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAPAB3W3H5NY59rlUAMH32zakBpxypVtMhJQGg50ho945 H4eAd5GDRVthzRzX7zHp539sF4STxV7pXy9DeWrs/DAEcVdJSfW+pI+0/Cb6 2L+aEK79mp0yz6lMZFtw+eDukAFGQo3IO6MMQu7gfoW8VIFiRcVUeIwJFTNo RNuAZkgZjyoqpFSBJZ5GlMSSqyvwd20iG0zORPahcLyedAYYrRQgXrQSpRQq kUwfIqyZlfHZWOTyqixgigPSZO+KxgthjwwcppeDG3ios0npOzpnAuaYe/q4 +5TLh1Txha206Ejqa6D+VPgEcTc7PaPL8Z5qdqdyDxsVZGtKmG4Z6S/TAZEC AwEAAaNTMFEwQQYDVR0RBDowOIEYbWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1 gRxtYXR0aGV3QHNsZWVwZXIuYXBhbmEub3JnLmF1MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAphRWaV5Z5+oaYflJ5Axfwzz1O32Xqqvpv6tA 3pLxKBKgvOI5bU0P7Lc+HvwFX2/zZBY0EzYbrlMWwV3rh+Cm3Bh2ePj+FiuW QkVR6CE5AT3NLj4tY7CVLV/+2flK64/tzaVvX4w2UaycjqbCkKOps8akYyGx LW8IGBOtiKdd5vUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQD ExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEW HHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8M OmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPP K9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxG cmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM 0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9 reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcC AQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwxAwjAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4MTAxMjMyNTVa MCMGCSqGSIb3DQEJBDEWBBR0+hTDTkuF42c2hiyZqCpZRMnKMjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQx azBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIDDEDCMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECAwxAwjANBgkqhkiG9w0BAQEFAASCAQCyIHLOqFhKDrWzY8Ozw+FJPRtK BP4ek5HF6gh9nFSPOXIR8QAlD3qr0dKRQcNj4HBCbQ7xQ+FDv5RJ38FTMlL0 Pa1rxTOI+sadAxH+7RTUoIKuAyR0+aQONrMVWyTBolAYFGO3D4pKO4zhJBIU Or9Mz8ZaX2Y1+bg8XkBKmS0l2AqgkJDXuzXo4D2CQs0CW2qTaexeGFdNYYsW swI1PvACDVjKvj02gopTnPvWfds0qw1H2hk8AvOPE83DdxtYAB5Kea4tFMFk QgGKQ0697EedlYEL+Et5icmpJpRZdvPMYsIz7ARBt5ySdllDLthY2lCPQhfP gg/RRoYS4b03uJFaAAAAAAAA --------------ms080805000603080703070106-- From owner-linux-xfs Tue Aug 10 06:56:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 06:56:21 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7ADuH5c027481 for ; Tue, 10 Aug 2004 06:56:17 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7ADuHDh027480 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 06:56:17 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7ADuGJO027466 for ; Tue, 10 Aug 2004 06:56:16 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7ADgxPY027287; Tue, 10 Aug 2004 06:42:59 -0700 Date: Tue, 10 Aug 2004 06:42:59 -0700 Message-Id: <200408101342.i7ADgxPY027287@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3877 X-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: 13811 Lines: 247 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-10-08 06:42 PDT ------- Update: +----------+--------+--------+----------+-----+-----+ |page/block| 4k | 8k | 16k | 32k | 64k | +----------+--------+--------+----------+-----+-----+ | 4k | ok | - | - | - | - | +----------+--------+--------+----------+-----+-----+ | 8k | ok | - | - | - | - | +----------+--------+--------+----------+-----+-----+ | 16k | ok | - | - | - | - | +----------+--------+--------+----------+-----+-----+ | 64k |shutdown|shutdown|MCE+reboot|oops | ok | +----------+--------+--------+----------+-----+-----+ The oops is below: Unable to handle kernel NULL pointer dereference (address 0000000000000037) kswapd0[23]: Oops 11012296146944 [1] Modules linked in: raid0 md 3w_9xxx button ixgb tg3 ipt_REJECT ipt_state ip_cons Pid: 23, CPU 3, comm: kswapd0 psr : 0000121008026018 ifs : 8000000000000813 ip : [] Notd ip is at shrink_list+0x1211/0x1280 unat: 0000000000000000 pfs : 0000000000000813 rsc : 0000000000000003 rnat: 0000000000000001 bsps: 0000000000001009 pr : 0000456656aa9965 ldrs: 0000000000000000 ccv : 0000000000008005 fpsr: 0009804c8a74433f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000001001069f0 b6 : a0000001000f6db0 b7 : a0000002002a0200 f6 : 1003e6db6db6db6db6db7 f7 : 0ffdca200000000000000 f8 : 1003e0000000000000000 f9 : 1003e0000000000000000 f10 : 1003e0000000010400000 f11 : 1003e000000003c893320 r1 : a000000100a0b8f0 r2 : 0000000000008005 r3 : 0000000000008001 r8 : 0000000000000001 r9 : a07ffffff224d314 r10 : 0000000000000000 r11 : 0000000000008001 r12 : e0000040fe88fc50 r13 : e0000040fe880000 r14 : 0000000000000005 r15 : ffffffffffffffff r16 : 0000000000000000 r17 : 0000000000000000 r18 : 0000000000008001 r19 : 0000000000000000 r20 : 0000000000008001 r21 : 0000000000000037 r22 : 000000000000004f r23 : 0000000000000004 r24 : 0000000000000005 r25 : 0000000000000004 r26 : 0000000000000005 r27 : 0000000000000005 r28 : 0000000000000000 r29 : 0000000000000009 r30 : 0000000000000005 r31 : 0000000000000008 Call Trace: [] show_stack+0x80/0xa0 sp=e0000040fe88f820 bsp=e0000040fe881260 [] die+0x200/0x300 sp=e0000040fe88f9f0 bsp=e0000040fe881238 [] ia64_do_page_fault+0x200/0x9c0 sp=e0000040fe88f9f0 bsp=e0000040fe8811d0 [] ia64_leave_kernel+0x0/0x270 sp=e0000040fe88fa80 bsp=e0000040fe8811d0 [] shrink_list+0x1210/0x1280 sp=e0000040fe88fc50 bsp=e0000040fe881138 [] shrink_cache+0x5f0/0xde0 sp=e0000040fe88fcf0 bsp=e0000040fe881040 [] shrink_zone+0x1c0/0x220 sp=e0000040fe88fd90 bsp=e0000040fe881000 [] balance_pgdat+0x570/0x680 sp=e0000040fe88fd90 bsp=e0000040fe880f48 [] kswapd+0x200/0x220 sp=e0000040fe88fdc0 bsp=e0000040fe880f18 [] kernel_thread_helper+0xe0/0x100 sp=e0000040fe88fe30 bsp=e0000040fe880ef0 [] start_kernel_thread+0x20/0x40 sp=e0000040fe88fe30 bsp=e0000040fe880ef0 <6>note: kswapd0[23] exited with preempt_count 1 Unable to handle kernel NULL pointer dereference (address 000000000000002f) pdflush[22]: Oops 11012296146944 [2] Modules linked in: raid0 md 3w_9xxx button ixgb tg3 ipt_REJECT ipt_state ip_cons Pid: 22, CPU 1, comm: pdflush psr : 0000121008026018 ifs : 800000000000038a ip : [] Notd ip is at __lock_page+0x211/0x2e0 unat: 0000000000000000 pfs : 000000000000038a rsc : 0000000000000003 rnat: e0000040fe87f3d8 bsps: e0000040fe870000 pr : 59595555a5666a59 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a74433f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000001000e8280 b6 : a0000001002acc60 b7 : a00000020027af40 f6 : 1003e0000000000000000 f7 : 0ffe7b2ec57be5a000000 f8 : 1003e0000000000000001 f9 : 1003e0000000000000001 f10 : 1003e0000000000001000 f11 : 1003e0000000000000000 r1 : a000000100a0b8f0 r2 : e0000040fe87f598 r3 : 000000000000002f r8 : 0000000000000001 r9 : 0000000000000000 r10 : 0000000000000001 r11 : 0000000000000001 r12 : e0000040fe87f560 r13 : e0000040fe870000 r14 : 0000000000008001 r15 : ffffffffffffffff r16 : e0000040fe870ec0 r17 : e0000040fe870eb0 r18 : 0000000000000000 r19 : 0000000000000001 r20 : e000000001e31768 r21 : 0000000000004000 r22 : 0000000000004000 r23 : e0000040fe87f5b8 r24 : e0000040fe87f5b0 r25 : 0000000000000001 r26 : 0000000000008001 r27 : 0000001008026018 r28 : a000000100094cc0 r29 : 0000000000000001 r30 : 0000000000000001 r31 : 0000000000008001 Call Trace: [] show_stack+0x80/0xa0 sp=e0000040fe87f130 bsp=e0000040fe871cf0 [] die+0x200/0x300 sp=e0000040fe87f300 bsp=e0000040fe871cc8 [] ia64_do_page_fault+0x200/0x9c0 sp=e0000040fe87f300 bsp=e0000040fe871c68 [] ia64_leave_kernel+0x0/0x270 sp=e0000040fe87f390 bsp=e0000040fe871c68 [] __lock_page+0x210/0x2e0 sp=e0000040fe87f560 bsp=e0000040fe871c18 [] find_lock_page+0x210/0x380 sp=e0000040fe87f5e0 bsp=e0000040fe871bd8 [] find_or_create_page+0x20/0x160 sp=e0000040fe87f5e0 bsp=e0000040fe871ba0 [] _pagebuf_lookup_pages+0x220/0x6e0 [xfs] sp=e0000040fe87f5e0 bsp=e0000040fe871ac0 [] pagebuf_get+0x400/0x420 [xfs] sp=e0000040fe87f5f0 bsp=e0000040fe871a70 [] xfs_trans_read_buf+0x310/0x780 [xfs] sp=e0000040fe87f5f0 bsp=e0000040fe871a10 [] xfs_alloc_read_agf+0xc0/0x580 [xfs] sp=e0000040fe87f5f0 bsp=e0000040fe8719c8 [] xfs_alloc_fix_freelist+0x950/0x9e0 [xfs] sp=e0000040fe87f600 bsp=e0000040fe871950 [] xfs_alloc_vextent+0x580/0x980 [xfs] sp=e0000040fe87f680 bsp=e0000040fe871868 [] xfs_bmap_alloc+0x1040/0x1e40 [xfs] sp=e0000040fe87f680 bsp=e0000040fe871788 [] xfs_bmapi+0x730/0x1a60 [xfs] sp=e0000040fe87f6e0 bsp=e0000040fe8715d8 [] xfs_iomap_write_allocate+0x3b0/0x760 [xfs] sp=e0000040fe87f7a0 bsp=e0000040fe871508 [] xfs_iomap+0x5b0/0x800 [xfs] sp=e0000040fe87f830 bsp=e0000040fe871498 [] xfs_bmap+0x40/0x60 [xfs] sp=e0000040fe87f870 bsp=e0000040fe871450 [] xfs_map_blocks+0x90/0x200 [xfs] sp=e0000040fe87f870 bsp=e0000040fe871418 [] xfs_page_state_convert+0x850/0xb80 [xfs] sp=e0000040fe87f880 bsp=e0000040fe871320 [] linvfs_writepage+0xe0/0x260 [xfs] sp=e0000040fe87fcc0 bsp=e0000040fe8712e8 [] mpage_writepages+0x400/0x700 sp=e0000040fe87fcd0 bsp=e0000040fe871210 [] do_writepages+0xe0/0x100 sp=e0000040fe87fd80 bsp=e0000040fe8711e0 [] __sync_single_inode+0x100/0x5e0 sp=e0000040fe87fd80 bsp=e0000040fe871190 [] sync_sb_inodes+0x4c0/0x860 sp=e0000040fe87fd80 bsp=e0000040fe8710e0 [] writeback_inodes+0x300/0x520 sp=e0000040fe87fd80 bsp=e0000040fe871090 [] background_writeout+0x120/0x1c0 sp=e0000040fe87fd80 bsp=e0000040fe871040 [] __pdflush+0x400/0x720 sp=e0000040fe87fdf0 bsp=e0000040fe870f58 [] pdflush+0x40/0x60 sp=e0000040fe87fdf0 bsp=e0000040fe870f48 [] kthread+0x170/0x180 sp=e0000040fe87fe20 bsp=e0000040fe870f18 [] kernel_thread_helper+0xe0/0x100 sp=e0000040fe87fe30 bsp=e0000040fe870ef0 [] start_kernel_thread+0x20/0x40 sp=e0000040fe87fe30 bsp=e0000040fe870ef0 <1>Unable to handle kernel NULL pointer dereference (address 0000000000000000) swapper[0]: Oops 11012296146944 [3] Modules linked in: raid0 md 3w_9xxx button ixgb tg3 ipt_REJECT ipt_state ip_cons Pid: 0, CPU 1, comm: swapper psr : 0000121008022018 ifs : 800000000000050e ip : [] Notd ip is at __wake_up_common+0x81/0x120 unat: 0000000000000000 pfs : 000000000000038c rsc : 0000000000000003 rnat: 80000000000011a7 bsps: 0000000000000000 pr : 80000000ff959569 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a000000100090110 b6 : a000000100003320 b7 : a00000010013d680 f6 : 1003e0000000000000080 f7 : 1003e0000000000000000 f8 : 1000d8000000000000000 f9 : 1003e0000000000000080 f10 : 10005fffffffff0000000 f11 : 1003e0000000000004000 r1 : a000000100a0b8f0 r2 : e000000001e31768 r3 : e0000040fe87f598 r8 : 0000000000000000 r9 : e0000040fe87f580 r10 : e0000040fe87f590 r11 : 0000000000000034 r12 : e00000003f00fb90 r13 : e00000003f000000 r14 : ba4036bda6309308 r15 : e0000040fe87f598 r16 : e00000003f000ec0 r17 : 0000000000000102 r18 : 0000000000000101 r19 : 0000000000000000 r20 : a0000001007a9f38 r21 : a0000001007a9f48 r22 : 0000000000000000 r23 : a0000001007a9b80 r24 : 1000000000000000 r25 : a00000010085d258 r26 : 084036bda6309308 r27 : 0000001008026018 r28 : a0000001000900d0 r29 : a00000010085d258 r30 : 0000000000000000 r31 : e000000001e31760 Call Trace: [] show_stack+0x80/0xa0 sp=e00000003f00f760 bsp=e00000003f0014c8 [] die+0x200/0x300 sp=e00000003f00f930 bsp=e00000003f0014a0 [] ia64_do_page_fault+0x200/0x9c0 sp=e00000003f00f930 bsp=e00000003f001440 [] ia64_leave_kernel+0x0/0x270 sp=e00000003f00f9c0 bsp=e00000003f001440 [] __wake_up_common+0x80/0x120 sp=e00000003f00fb90 bsp=e00000003f0013c8 [] __wake_up+0xb0/0x160 sp=e00000003f00fb90 bsp=e00000003f001390 [] wake_up_page+0x60/0x80 sp=e00000003f00fb90 bsp=e00000003f001378 [] end_buffer_async_write+0x280/0x4c0 sp=e00000003f00fb90 bsp=e00000003f001350 [] end_bio_bh_io_sync+0x90/0xc0 sp=e00000003f00fbb0 bsp=e00000003f001330 [] bio_endio+0x100/0x160 sp=e00000003f00fbb0 bsp=e00000003f001300 [] __end_that_request_first+0x390/0x460 sp=e00000003f00fbb0 bsp=e00000003f001290 [] scsi_end_request+0x50/0x280 sp=e00000003f00fbb0 bsp=e00000003f001250 [] scsi_io_completion+0x270/0x940 sp=e00000003f00fbb0 bsp=e00000003f0011d0 [] sd_rw_intr+0x170/0x5a0 sp=e00000003f00fbb0 bsp=e00000003f001188 [] scsi_finish_command+0x320/0x340 sp=e00000003f00fbb0 bsp=e00000003f001160 [] scsi_softirq+0x220/0x280 sp=e00000003f00fbb0 bsp=e00000003f001128 [] __do_softirq+0x1e0/0x200 sp=e00000003f00fbc0 bsp=e00000003f0010b8 [] do_softirq+0x80/0xe0 sp=e00000003f00fbc0 bsp=e00000003f001060 [] ia64_handle_irq+0x190/0x1c0 sp=e00000003f00fbc0 bsp=e00000003f001028 [] ia64_leave_kernel+0x0/0x270 sp=e00000003f00fbc0 bsp=e00000003f001028 [] ia64_pal_call_static+0xa0/0xc0 sp=e00000003f00fd90 bsp=e00000003f000fd0 [] default_idle+0xe0/0x1a0 sp=e00000003f00fd90 bsp=e00000003f000f88 [] cpu_idle+0x190/0x260 sp=e00000003f00fe30 bsp=e00000003f000f00 [] start_secondary+0x80/0xa0 sp=e00000003f00fe30 bsp=e00000003f000ef0 [] _start+0x260/0x290 sp=e00000003f00fe30 bsp=e00000003f000ef0 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 08:05:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 08:05:15 -0700 (PDT) Received: from mail018.syd.optusnet.com.au (mail018.syd.optusnet.com.au [211.29.132.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AF59a2028984 for ; Tue, 10 Aug 2004 08:05:10 -0700 Received: from saturn (c211-28-164-234.eburwd2.vic.optusnet.com.au [211.28.164.234]) by mail018.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i7AF4tF06624; Wed, 11 Aug 2004 01:04:55 +1000 Received: from [192.168.1.54] (helo=kennedy ident=Debian-exim) by saturn with esmtp (Exim 3.35 #1 (Debian)) id 1BuYAn-0004De-00; Wed, 11 Aug 2004 01:04:21 +1000 Received: from localhost ([127.0.0.1] helo=kennedy ident=stewart) by kennedy with esmtp (Exim 4.34) id 1BuYAS-0003tI-Er; Wed, 11 Aug 2004 01:04:00 +1000 Subject: Re: Fedora Core 2 with XFS From: Stewart Smith To: Matthew Geier Cc: linux-xfs@oss.sgi.com In-Reply-To: <4118C077.1070209@arts.usyd.edu.au> References: <4118C077.1070209@arts.usyd.edu.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4azxwDjVJ3SLnVgZa7d+" Message-Id: <1092150239.3859.8.camel@kennedy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 01:04:00 +1000 X-archive-position: 3878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Content-Length: 857 Lines: 33 --=-4azxwDjVJ3SLnVgZa7d+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-08-10 at 22:32, Matthew Geier wrote: > Fedora Core 2 and XFS - it just works.... However, people should be aware of: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D117776 "crashes during bootloader install if / is xfs" Current as of FC2 release..... haven't tried FC3test1 yet, will do soon. --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-4azxwDjVJ3SLnVgZa7d+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBGOPf3tgLgERgy8oRAnL9AKDmInjz/dR6mZtg8NpuAeqkdTeprQCg0yFL ZjsUxfuIjJipGx5at8NbIdE= =A3lB -----END PGP SIGNATURE----- --=-4azxwDjVJ3SLnVgZa7d+-- From owner-linux-xfs Tue Aug 10 08:15:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 08:16:01 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [207.218.156.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AFFu9m029572 for ; Tue, 10 Aug 2004 08:15:57 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i7AFFRVu017577; Tue, 10 Aug 2004 10:15:28 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i7AFFPhs017574; Tue, 10 Aug 2004 10:15:26 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Tue, 10 Aug 2004 10:15:25 -0500 (EST) From: Net Llama! To: Stewart Smith cc: Matthew Geier , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS In-Reply-To: <1092150239.3859.8.camel@kennedy> Message-ID: References: <4118C077.1070209@arts.usyd.edu.au> <1092150239.3859.8.camel@kennedy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 764 Lines: 23 I think the problem is /boot not / I've installed FC2 with / formatted xfs many times, and not had a single issue. I've seen this problem when /boot was xfs though. On Wed, 11 Aug 2004, Stewart Smith wrote: > On Tue, 2004-08-10 at 22:32, Matthew Geier wrote: > > Fedora Core 2 and XFS - it just works.... > > However, people should be aware of: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117776 > > "crashes during bootloader install if / is xfs" > > Current as of FC2 release..... haven't tried FC3test1 yet, will do soon. > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Tue Aug 10 09:05:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 09:05:15 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:yWSMKM8Ft+keDPX/juCgsa9VsJU9jJED@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AG5ChJ003053 for ; Tue, 10 Aug 2004 09:05:13 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 8E3FC1804DE0; Tue, 10 Aug 2004 11:05:07 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08616-10; Tue, 10 Aug 2004 11:05:07 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 016021804DDB; Tue, 10 Aug 2004 11:05:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id F13441C0A2DC; Tue, 10 Aug 2004 11:05:06 -0500 (EST) Date: Tue, 10 Aug 2004 11:05:06 -0500 (EST) From: Mike Burger To: Stewart Smith Cc: Matthew Geier , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS In-Reply-To: <1092150239.3859.8.camel@kennedy> Message-ID: References: <4118C077.1070209@arts.usyd.edu.au> <1092150239.3859.8.camel@kennedy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 3880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 755 Lines: 30 On Wed, 11 Aug 2004, Stewart Smith wrote: > On Tue, 2004-08-10 at 22:32, Matthew Geier wrote: > > Fedora Core 2 and XFS - it just works.... > > However, people should be aware of: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117776 > > "crashes during bootloader install if / is xfs" > > Current as of FC2 release..... haven't tried FC3test1 yet, will do soon. Doesn't that only happen with GRUB? -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Tue Aug 10 09:05:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 09:05:58 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:BrTJA/52XufNBBaET42c/gmSVTa8oq1O@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AG5tij003226 for ; Tue, 10 Aug 2004 09:05:55 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 2675C1804DE0; Tue, 10 Aug 2004 11:05:50 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10581-02; Tue, 10 Aug 2004 11:05:49 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id A0C431804DDB; Tue, 10 Aug 2004 11:05:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 98EB61C0A2DC; Tue, 10 Aug 2004 11:05:49 -0500 (EST) Date: Tue, 10 Aug 2004 11:05:49 -0500 (EST) From: Mike Burger To: Stewart Smith Cc: Matthew Geier , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS In-Reply-To: <1092150239.3859.8.camel@kennedy> Message-ID: References: <4118C077.1070209@arts.usyd.edu.au> <1092150239.3859.8.camel@kennedy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 3881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 865 Lines: 33 On Wed, 11 Aug 2004, Stewart Smith wrote: > On Tue, 2004-08-10 at 22:32, Matthew Geier wrote: > > Fedora Core 2 and XFS - it just works.... > > However, people should be aware of: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117776 > > "crashes during bootloader install if / is xfs" > > Current as of FC2 release..... haven't tried FC3test1 yet, will do soon. Let me rephrase...doesn't that only happen with GRUB, and if /boot is XFS, not /? Did the bug poster have a separate /boot, or is it part of /? -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Tue Aug 10 10:56:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 10:56:20 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AHuHnd006919 for ; Tue, 10 Aug 2004 10:56:17 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7AHuHm6006918 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 10:56:17 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AHuGEU006892 for ; Tue, 10 Aug 2004 10:56:16 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7AHuFWD006886; Tue, 10 Aug 2004 10:56:15 -0700 Date: Tue, 10 Aug 2004 10:56:15 -0700 Message-Id: <200408101756.i7AHuFWD006886@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 352] Compilation failure in sendfile.c X-Bugzilla-Reason: AssignedTo X-archive-position: 3882 X-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: 331 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=352 ------- Additional Comments From Nicolas.Kowalski@imag.fr 2004-10-08 10:56 PDT ------- Many thanks for this quick fix; it compiles well now. :-) Nicolas. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 10:56:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 10:56:21 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AHuIQ8006929 for ; Tue, 10 Aug 2004 10:56:18 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7AHuI9V006923 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 10:56:18 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AHuGEY006892 for ; Tue, 10 Aug 2004 10:56:17 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7AHVqYo005833; Tue, 10 Aug 2004 10:31:52 -0700 Date: Tue, 10 Aug 2004 10:31:52 -0700 Message-Id: <200408101731.i7AHVqYo005833@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3883 X-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: 1145 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-10-08 10:31 PDT ------- Final matrix: +----------+-----+-----+-----+--------+--------+----------+-----+-----+ |page/block|512b | 1k | 2k | 4k | 8k | 16k | 32k | 64k | +----------+-----+-----+-----+--------+--------+----------+-----+-----+ | 4k | ok | ok | ok | ok | n/a | n/a | n/a | n/a | +----------+-----+-----+-----+--------+--------+----------+-----+-----+ | 8k | ok | ok | ok | ok | ok | n/a | n/a | n/a | +----------+-----+-----+-----+--------+--------+----------+-----+-----+ | 16k | ok | ok | ok | ok | ok | ok | n/a | n/a | +----------+-----+-----+-----+--------+--------+----------+-----+-----+ | 64k | n/a | n/a | n/a |shutdown|shutdown|MCE+reboot|oops | ok | +----------+-----+-----+-----+--------+--------+----------+-----+-----+ As Eric summed up: something about block size < page, + 64k pages, is foo ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 13:28:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 13:28:29 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:CvvUaNBAKARpCsK2fu3wDBRFIDNOG9db@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7AKSPHG013588 for ; Tue, 10 Aug 2004 13:28:26 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 2BBAB1804DE5; Tue, 10 Aug 2004 15:28:20 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16713-01; Tue, 10 Aug 2004 15:28:19 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 937481804DE0; Tue, 10 Aug 2004 15:28:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 905AA1C0A2DD; Tue, 10 Aug 2004 15:28:19 -0500 (EST) Date: Tue, 10 Aug 2004 15:28:19 -0500 (EST) From: Mike Burger To: Matthew Geier Cc: linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS In-Reply-To: <4118C077.1070209@arts.usyd.edu.au> Message-ID: References: <4118C077.1070209@arts.usyd.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 3884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1144 Lines: 39 I have to admit that this is really good news. Maybe I'll schedule an upgrade on my server, currently running XFS patched RHL9. On Tue, 10 Aug 2004, Matthew Geier wrote: > > Thought I'd post just as I see this sort of thing asked a lot. > > I just upgraded a Redhat 8.0-sgi-xfs system to Fedora Core 2 by simply > booting the Fedora 2 CD. It found a Redhat 8.0 system on the XFS > formatted system and upgraded it with out issue - or with out any issue > i've so far detected, the system is up and running again, with the > latest Fedora updates applied and every thing we need the machine to do > it seems to be doing. (Except IPMI, I need to recompile the kernel to > enable it - but that's minor in the grand scheme of things). > > Fedora Core 2 and XFS - it just works.... > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Tue Aug 10 17:03:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 17:03:52 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [202.147.117.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B03i4M025057 for ; Tue, 10 Aug 2004 17:03:45 -0700 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 86DC21800AA; Wed, 11 Aug 2004 10:03:24 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 95F21C2183; Wed, 11 Aug 2004 10:03:23 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 9280B140117; Wed, 11 Aug 2004 10:03:23 +1000 (EST) X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.0.4 From: Keith Owens To: Matthew Geier Cc: linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS In-reply-to: Your message of "Tue, 10 Aug 2004 22:32:55 +1000." <4118C077.1070209@arts.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Aug 2004 10:03:22 +1000 Message-ID: <22931.1092182602@ocs3.ocs.com.au> X-archive-position: 3885 X-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: 1698 Lines: 40 On Tue, 10 Aug 2004 22:32:55 +1000, Matthew Geier wrote: > Thought I'd post just as I see this sort of thing asked a lot. > > I just upgraded a Redhat 8.0-sgi-xfs system to Fedora Core 2 by simply >booting the Fedora 2 CD. It found a Redhat 8.0 system on the XFS >formatted system and upgraded it with out issue - or with out any issue >i've so far detected, the system is up and running again, with the >latest Fedora updates applied and every thing we need the machine to do >it seems to be doing. (Except IPMI, I need to recompile the kernel to >enable it - but that's minor in the grand scheme of things). > > Fedora Core 2 and XFS - it just works.... One small data point. Having just done two upgrades from RH9 to FC2 with nothing but XFS partitions, the upgrade worked fine. However there are hints (IOW I could be talking through my hat here) that the 2.6 kernel in FC2 is more rigorous about checking XFS file structures than the 2.4 kernel in RH8/9. It would not hurt to run xfs_repair over your partitions before doing the upgrade. If you have already upgraded to FC2, do it now. To run xfs_repair, you need a separate boot disk. FC2 disk1 does the job. Make a note of your XFS partition names, e.g. /dev/hda2, /dev/hda4 etc. Do a clean shutdown - this is critical. If the shutdown was not clean, then reboot until it is. Boot FC2 disk1 and type 'linux text rescue'. Do not bother starting the network devices. When it asks about mounting existing partitions, say no (skip). Run xfs_repair from CD, against your XFS disk partitions, e.g. xfs_repair /dev/hda2. Add -n for paranoid mode to see what would be fixed, then run without -n. From owner-linux-xfs Tue Aug 10 18:56:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 18:56:22 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B1uJvq029220 for ; Tue, 10 Aug 2004 18:56:19 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B1uJ0J029219 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 18:56:19 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B1uIZp029205 for ; Tue, 10 Aug 2004 18:56:18 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B1RHmY028712; Tue, 10 Aug 2004 18:27:17 -0700 Date: Tue, 10 Aug 2004 18:27:17 -0700 Message-Id: <200408110127.i7B1RHmY028712@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 3886 X-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: 793 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 ------- Additional Comments From nathans@sgi.com 2004-10-08 17:02 PDT ------- Created an attachment (id=134) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=134&action=view) Increase size of the page offset field in an XFS buffer Hi there, Could you try this patch and see if it helps at all with a 64K pagesize? Its a bit of a guess, so odds are this wont be the problem, but ya never know... thanks. ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-10-08 18:27 PDT ------- The modified kernel withstood the testcase, but barfed on the 30th touch(1). 2.6.8-rc4 vanilla, same backtrace. Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 20:56:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 20:56:30 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B3uK7O002484 for ; Tue, 10 Aug 2004 20:56:20 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B3uKQL002482 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 20:56:20 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B3uIpO002451 for ; Tue, 10 Aug 2004 20:56:18 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B3qEp4002419; Tue, 10 Aug 2004 20:52:14 -0700 Date: Tue, 10 Aug 2004 20:52:14 -0700 Message-Id: <200408110352.i7B3qEp4002419@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 354] New: unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3888 X-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: 536 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=354 Summary: unreplayable log after crash Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: Peter.Kelemen+sgi@cern.ch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 20:56:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 20:56:24 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B3uKCI002483 for ; Tue, 10 Aug 2004 20:56:20 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B3uK72002481 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 20:56:20 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B3uIpS002451 for ; Tue, 10 Aug 2004 20:56:19 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B3KVvU001840; Tue, 10 Aug 2004 20:20:31 -0700 Date: Tue, 10 Aug 2004 20:20:31 -0700 Message-Id: <200408110320.i7B3KVvU001840@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 353] New: kernel BUG at fs/xfs/support/debug.c:106! X-Bugzilla-Reason: AssignedTo X-archive-position: 3887 X-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: 1470 Lines: 38 http://oss.sgi.com/bugzilla/show_bug.cgi?id=353 Summary: kernel BUG at fs/xfs/support/debug.c:106! Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: kiran@uh.edu We have a Dell 2650 running Gentoo 2004.2 and its being used as the NFS fileserver that has 1.7TB of direct attached SCSI RAID running XFS. The kernel version is 2.6.7 and XFS is built into it. The server was up and running for about 10 days when all of a sudden the machine stopped responding to NFS requests. I was able to SSH into it and then I noticed xfssyncd hogging the CPU. The CPU load was at 15!! I noticed the following lines in the syslog! Aug 9 22:25:37 [kernel] kernel BUG at fs/xfs/support/debug.c:106! Aug 9 22:25:37 [kernel] esi: c04430f0 edi: c058da9e ebp: 00000000 esp: f6e629f8 Aug 9 22:25:37 [kernel] c0273c2f 00000000 c044e950 ddc2a680 ddc2ae00 c01774ef f7eb8400 c17e9e1c Aug 9 22:25:37 [kernel] [] svcauth_unix_accept+0x258/0x291 Aug 9 22:25:37 [kernel] [] svc_process+0x4b8/0x619 That was it!! No other errors! I reset the machine and it came back up without any hitch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 21:56:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 21:56:26 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B4uL5t004940 for ; Tue, 10 Aug 2004 21:56:21 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B4uLCN004938 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 21:56:21 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B4uIGJ004896 for ; Tue, 10 Aug 2004 21:56:19 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B4A1JU003495; Tue, 10 Aug 2004 21:10:01 -0700 Date: Tue, 10 Aug 2004 21:10:01 -0700 Message-Id: <200408110410.i7B4A1JU003495@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3891 X-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: 323 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-10-08 21:10 PDT ------- *** Bug 354 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 21:56:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 21:56:25 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B4uLCc004941 for ; Tue, 10 Aug 2004 21:56:21 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B4uLXD004937 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 21:56:21 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B4uIGR004896 for ; Tue, 10 Aug 2004 21:56:19 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B47qpE003320; Tue, 10 Aug 2004 21:07:52 -0700 Date: Tue, 10 Aug 2004 21:07:52 -0700 Message-Id: <200408110407.i7B47qpE003320@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] New: unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3890 X-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: 2387 Lines: 72 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 Summary: unreplayable log after crash Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: Peter.Kelemen+sgi@cern.ch I have a ~700G filesystem that experienced a hard crash (controller failure), but the subsequent mount fails when the log would be replayed. xfs_check tells me that the filesystem is funky: bad magic # 0x421cd4bf in inode 11281887 bmbt block 66/1011263 expected level 0 got 6369 in inode 11281887 bmbt block 66/1011263 bad btree nrecs (13911, min=127, max=254) in inode 11281887 bmap block 70217279 extent count for ino 11281887 data fork too low (0) for file format bad nblocks 7169 for inode 11281887, counted 1 bad nextents 28 for inode 11281887, counted 0 bad nblocks 67585 for inode 11317715, counted 67073 bad nextents 155 for inode 11317715, counted 154 bad nblocks 98817 for inode 11343754, counted 99329 bad nextents 242 for inode 11343754, counted 244 bad nblocks 52737 for inode 11343803, counted 53761 bad nextents 185 for inode 11343803, counted 189 bad nblocks 24577 for inode 11358383, counted 24065 bad nextents 71 for inode 11358383, counted 68 ... mount says mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems ...and returns with exit code 32. xfs_repair instructs me to zero the log before attempting a repair. Device is software striped array across two 3ware hardware RAID-5s. Filesystem geometry (info from xfs_db, superblock 0): blocksize = 4096 dblocks = 175829568 agblocks = 1048512 agcount = 168 logblocks = 32768 versionnum = 0x3584 sectsize = 512 inodesize = 512 logsunit = 262144 Compressed xfs_logprint output is available at http://cern.ch/fuji/cruft/md0.logprint.bz2 [1.7 MiB, 57 MiB uncompressed] I'm currently dumping the md0 device to another machine for further analysis. Kernel is 2.4.20-31.7.2.cernsmp which is basically RedHat plus some local patches to the SCSI tape layer. Hardware is dual Xeon 2.4GHz 1G RAM 3ware 7850-8/7500-4, WD 120G disks. Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 10 21:56:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Aug 2004 21:56:27 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B4uL2J004939 for ; Tue, 10 Aug 2004 21:56:21 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B4uL6m004936 for linux-xfs@oss.sgi.com; Tue, 10 Aug 2004 21:56:21 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7B4uIGN004896 for ; Tue, 10 Aug 2004 21:56:19 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7B4A1Hp003491; Tue, 10 Aug 2004 21:10:01 -0700 Date: Tue, 10 Aug 2004 21:10:01 -0700 Message-Id: <200408110410.i7B4A1Hp003491@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 354] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3892 X-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: 606 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=354 Peter.Kelemen+sgi@cern.ch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-10-08 21:10 PDT ------- *** This bug has been marked as a duplicate of 355 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Aug 11 03:09:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Aug 2004 03:09:13 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [193.151.36.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7BA99ea016718 for ; Wed, 11 Aug 2004 03:09:10 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 8D9D293EE7; Wed, 11 Aug 2004 12:09:03 +0200 (CEST) Received: from localhost.localdomain (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 1ED0693E4A for ; Wed, 11 Aug 2004 12:08:51 +0200 (CEST) Received: from [127.0.0.1] (venus [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i7BA8Go4016834 for ; Wed, 11 Aug 2004 12:08:25 +0200 Subject: Re: Fedora Core 2 with XFS From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com In-Reply-To: <4118C077.1070209@arts.usyd.edu.au> References: <4118C077.1070209@arts.usyd.edu.au> Content-Type: text/plain Message-Id: <1092218896.2610.6.camel@venus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 11 Aug 2004 12:08:16 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 3893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 806 Lines: 20 On Tue, 2004-08-10 at 14:32, Matthew Geier wrote: > Thought I'd post just as I see this sort of thing asked a lot. > > I just upgraded a Redhat 8.0-sgi-xfs system to Fedora Core 2 by simply > booting the Fedora 2 CD. It found a Redhat 8.0 system on the XFS > formatted system and upgraded it with out issue - or with out any issue > i've so far detected, the system is up and running again, with the > latest Fedora updates applied and every thing we need the machine to do > it seems to be doing. (Except IPMI, I need to recompile the kernel to > enable it - but that's minor in the grand scheme of things). > > Fedora Core 2 and XFS - it just works.... Do you use NFS? I had crashes with fedora 2 kernel and XFS when running NFS. With vanilla kernel everything works fine. Regards, Olaf From owner-linux-xfs Wed Aug 11 06:42:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Aug 2004 06:42:41 -0700 (PDT) Received: from mail008.syd.optusnet.com.au (mail008.syd.optusnet.com.au [211.29.132.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7BDgZ8r029268 for ; Wed, 11 Aug 2004 06:42:36 -0700 Received: from saturn (c211-28-164-234.eburwd2.vic.optusnet.com.au [211.28.164.234]) by mail008.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i7BDgON30590; Wed, 11 Aug 2004 23:42:24 +1000 Received: from [192.168.1.54] (helo=kennedy ident=Debian-exim) by saturn with esmtp (Exim 3.35 #1 (Debian)) id 1ButMU-00074M-00; Wed, 11 Aug 2004 23:41:50 +1000 Received: from localhost ([127.0.0.1] helo=kennedy ident=stewart) by kennedy with esmtp (Exim 4.34) id 1ButM2-0001T7-NI; Wed, 11 Aug 2004 23:41:22 +1000 Subject: Re: Fedora Core 2 with XFS From: Stewart Smith To: Matthew Geier Cc: linux-xfs@oss.sgi.com In-Reply-To: <1092150239.3859.8.camel@kennedy> References: <4118C077.1070209@arts.usyd.edu.au> <1092150239.3859.8.camel@kennedy> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iRXWHCjAx9aho9YuMoXW" Message-Id: <1092231682.5373.7.camel@kennedy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 23:41:22 +1000 X-archive-position: 3894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Content-Length: 761 Lines: 29 --=-iRXWHCjAx9aho9YuMoXW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-08-11 at 01:04, Stewart Smith wrote: > "crashes during bootloader install if / is xfs" >=20 > Current as of FC2 release..... haven't tried FC3test1 yet, will do soon. Seems to work in FC3t1 - closing the bug. --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-iRXWHCjAx9aho9YuMoXW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBGiIC3tgLgERgy8oRAlguAKDXZHRvgTuIbFjTQyQH00Yp/d5r0gCeIuIa ic8piaCq9v1ljEeTp/NeECQ= =hMVB -----END PGP SIGNATURE----- --=-iRXWHCjAx9aho9YuMoXW-- From owner-linux-xfs Wed Aug 11 07:20:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Aug 2004 07:20:10 -0700 (PDT) Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7BEK7ta030541 for ; Wed, 11 Aug 2004 07:20:08 -0700 Received: from [10.0.0.5] (sandeen.net [209.173.210.139]) (authenticated bits=0) by lips.borg.umn.edu (8.13.0/8.13.0) with ESMTP id i7BEKZjf040630; Wed, 11 Aug 2004 09:20:39 -0500 (CDT) (envelope-from sandeen@sgi.com) Message-ID: <411A2B01.6070105@sgi.com> Date: Wed, 11 Aug 2004 09:19:45 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?T2xhZiBGcsKxY3p5aw==?= CC: linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS References: <4118C077.1070209@arts.usyd.edu.au> <1092218896.2610.6.camel@venus> In-Reply-To: <1092218896.2610.6.camel@venus> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 3895 X-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: 278 Lines: 16 That's probably the 4kstacks issue - NFS and xfs can both use a bit of stack in some places. -Eric Olaf FrÄ…czyk wrote: > Do you use NFS? > I had crashes with fedora 2 kernel and XFS when running NFS. > With vanilla kernel everything works fine. > > Regards, > > Olaf > From owner-linux-xfs Wed Aug 11 07:21:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Aug 2004 07:22:00 -0700 (PDT) Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7BELw2Q030851 for ; Wed, 11 Aug 2004 07:21:58 -0700 Received: from [10.0.0.5] (sandeen.net [209.173.210.139]) (authenticated bits=0) by lips.borg.umn.edu (8.13.0/8.13.0) with ESMTP id i7BEMXfj040696; Wed, 11 Aug 2004 09:22:34 -0500 (CDT) (envelope-from sandeen@sgi.com) Message-ID: <411A2B79.8060104@sgi.com> Date: Wed, 11 Aug 2004 09:21:45 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens CC: Matthew Geier , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS References: <22931.1092182602@ocs3.ocs.com.au> In-Reply-To: <22931.1092182602@ocs3.ocs.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3896 X-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: 476 Lines: 14 Keith Owens wrote: > One small data point. Having just done two upgrades from RH9 to FC2 > with nothing but XFS partitions, the upgrade worked fine. However > there are hints (IOW I could be talking through my hat here) that the > 2.6 kernel in FC2 is more rigorous about checking XFS file structures > than the 2.4 kernel in RH8/9. Keith, what makes you say this? I take it that you saw problems which prompted you to run repair over the filesystems? Thanks, -Eric From owner-linux-xfs Wed Aug 11 14:09:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Aug 2004 14:09:20 -0700 (PDT) Received: from ext-nj2gw-6.online-age.net (ext-nj2gw-6.online-age.net [64.14.56.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7BL9EpP021869 for ; Wed, 11 Aug 2004 14:09:15 -0700 Received: from int-nj2gw-2.online-age.net (int-nj2gw-2 [3.159.236.66]) by ext-nj2gw-6.online-age.net (8.12.11/8.12.11/990426-RLH) with ESMTP id i7BL8enu009298 for ; Wed, 11 Aug 2004 17:08:40 -0400 Received: from uswaumsxb1medge.am.med.ge.com (localhost [127.0.0.1]) by int-nj2gw-2.online-age.net (8.12.9/8.12.8/990426-RLH) with ESMTP id i7BL923D019546 for ; Wed, 11 Aug 2004 17:09:03 -0400 (EDT) Received: from USWAUMSXBHMEDGE.am.med.ge.com (uswaumsxbhmedge.med.ge.com [3.57.24.134]) by uswaumsxb1medge.am.med.ge.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id QX1B4QWT; Wed, 11 Aug 2004 15:48:40 -0500 Received: from ct.ct.med.ge.com (uswaucs03.med.ge.com [3.57.24.237]) by USWAUMSXBHMEDGE.am.med.ge.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id QQVAGJ09; Wed, 11 Aug 2004 15:48:14 -0500 Received: from [3.57.108.2] ([3.57.108.2]) by ct.ct.med.ge.com (8.8.8+Sun/8.8.8) with ESMTP id PAA06479 for ; Wed, 11 Aug 2004 15:47:46 -0500 (CDT) Message-ID: <411A8410.2030000@med.ge.com> Date: Wed, 11 Aug 2004 15:39:44 -0500 From: James Foris Reply-To: james.foris@med.ge.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS performance issues: O_DIRECT and Linux 2.6.6+ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3898 X-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.foris@med.ge.com Precedence: bulk X-list: linux-xfs Content-Length: 4343 Lines: 132 I have been using XFS in both IRIX and Linux for many years now, and overall I am quite happy with it - recommend it to everyone, run it on my home systems, etc. But, recently I ran into something that I need some help in understanding/explaining. The title says it all, really, but the details follow below. ---------------------------------------------------------------------------------------------------------------------- We have a project that requires a sustained 400 - 450 MBytes/sec data rate to/from a U320 SCSI disk array. Early performance tests demonstrated that we had to go to the Linux 2.6 kernel to get this kind of sustained performance on commodity hardware (actually, a standard Intel server motherboard) and this issue went on the backlburner as we found that we had other kernel-related problems to handle, first. Those issues are now resolved (or resolved enough - Intel will be feeding patches into the kernel mainline and Fedora Core group at Red Hat to fix things permanently). On retesting, we discovered that between kernel 2.6.5 and 2.6.6, something happened that changed the way that O_DIRECT works with XFS; instead of increasing performance, it now degrades it by ~10% (or more). As a side note; ext2, ext3, and jfs show the expected increase of performance. These tests were done on a variety of systems, a variety of kernels (both FC and pure "kernel.org"), and a variety of SCSI disks. The behavior varies a little, but they all show this same overall trends. And in general, the higher speed disk subsystems (such as S/W RAID0 on U320 SCSI drives) show the problem most. The following test were run against a set of 1 GByte partitions formatted with the indicated file systems. The test, itself, does the following sequence: while loop count < 16 start timer create file write file mark time fsync file close file stop timer For example, on a HP wx8000 with 10KRPM U320 SCSI disks (running simple partitions), Linux kernel 2.6.8-rc2-bk5 we see the following numbers: >>> standard file system writes <<<< ext2 performance numbers include fsync : 4.319 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 8.138 sec; 62.916 MB/s 53.97 % full ext3 performance numbers include fsync : 6.067 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 8.996 sec; 56.917 MB/s 55.66 % full xfs performance numbers include fsync : 6.799 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 7.927 sec; 64.590 MB/s 53.34 % full jfs performance numbers include fsync : 2.940 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 8.067 sec; 63.465 MB/s 53.33 % full >>> file system writes using O_DIRECT <<< ext2 performance numbers include fsync : 0.166 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 7.926 sec; 64.594 MB/s 53.98 % full ( 3% increase ) ext3 performance numbers include fsync : 0.003 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 8.298 sec; 61.705 MB/s 55.66 % full ( 8% increase ) xfs performance numbers include fsync : 0.000 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 8.703 sec; 58.830 MB/s 53.34 % full ( 9 % DECREASE ) jfs performance numbers include fsync : 0.000 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 7.339 sec; 69.761 MB/s 53.33 % full ( 10% increase ) In our original test case (S/W RAID0, U320 disks, Intel server motherboard), the performance degradation was: >>> standard file system writes <<<< ext2 performance numbers include fsync : 0.829 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 2.174 sec; 235.460 MB/s 0.19 % full xfs (from a report summary) about 355 MB/s on 2.6.4 about 345 MB/s on 2.6.7 >>> file system writes using O_DIRECT <<< ext2 performance numbers include fsync : 0.046 sec wrote 512.000 MB in 16 writes, 32.000 MB/write, 1.484 sec; 345.120 MB/s 0.19 % full ( 46 % increase ) xfs (from a report summary) about 410 MB/s on 2.6.4 ( 15% increase ) about 180 MB/s on 2.6.7 ( 47% DECREASE ) Obviously, the 410 MBytes/sec performance from the 2.6.4 kernel was what we had been counting on. It looke like S/W RAID + O_DIRECT really tanks XFS performance since 2.6.6 was released. Does anyone know what has changed ? And is there anything that can be cone to make the current kernels behave better ? Jim Foris Has anyone esle From owner-linux-xfs Wed Aug 11 14:31:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Aug 2004 14:31:47 -0700 (PDT) Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7BLVhCh023358 for ; Wed, 11 Aug 2004 14:31:44 -0700 Received: from xiii.bis.pasteur.fr (xiii.bis.pasteur.fr [157.99.90.14]) by electre.pasteur.fr (8.12.11/8.12.11) with ESMTP id i7BLVZKF062216; Wed, 11 Aug 2004 23:31:35 +0200 (CEST) Received: (from tru@localhost) by xiii.bis.pasteur.fr (8.11.6/8.11.6) id i7BLVYG29613; Wed, 11 Aug 2004 23:31:34 +0200 Date: Wed, 11 Aug 2004 23:31:34 +0200 From: Tru Huynh To: Eric Sandeen Cc: Dan Yocum , xfs-list Subject: Re: oops release-1.3.3-pre2/x86_64 from Scientific Linux Message-ID: <20040811233134.A29593@xiii.bis.pasteur.fr> References: <20040809121137.A16748@xiii.bis.pasteur.fr> <411781A8.80104@sgi.com> <20040809161051.B22340@xiii.bis.pasteur.fr> <20040809170335.A24256@xiii.bis.pasteur.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040809170335.A24256@xiii.bis.pasteur.fr>; from tru@pasteur.fr on Mon, Aug 09, 2004 at 05:03:35PM +0200 X-archive-position: 3899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tru@pasteur.fr Precedence: bulk X-list: linux-xfs Content-Length: 686 Lines: 23 On Mon, Aug 09, 2004 at 05:03:35PM +0200, Tru Huynh wrote: > > Yes!!!! that works (mount read-only for the moment) > but I can access the files there :D I have rebuild the SL kernel from Dan Yocum with the patches for RHEL (2.4.21-15.0.4.EL) and the ffs patch from Eric Sandeen for x86_64. it works for me so far :) x86_64+SMP+XFS I have not tried the other builds. SRPMS/RPMS are all here: ftp://ftp.pasteur.fr/pub/BIS/tru/XFS_CentOS-3.1/ Best regards, Tru -- Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France From owner-linux-xfs Wed Aug 11 15:50:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Aug 2004 15:50:23 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [202.147.117.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7BMoJul027449 for ; Wed, 11 Aug 2004 15:50:20 -0700 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 6F5E7180092; Thu, 12 Aug 2004 08:34:02 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id DD80DC2182; Thu, 12 Aug 2004 08:33:58 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 98038140117; Thu, 12 Aug 2004 08:33:58 +1000 (EST) X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.0.4 From: Keith Owens To: Eric Sandeen Cc: Matthew Geier , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 2 with XFS In-reply-to: Your message of "Wed, 11 Aug 2004 09:21:45 EST." <411A2B79.8060104@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Aug 2004 08:33:57 +1000 Message-ID: <19785.1092263637@ocs3.ocs.com.au> X-archive-position: 3900 X-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: 940 Lines: 22 On Wed, 11 Aug 2004 09:21:45 -0500, Eric Sandeen wrote: >Keith Owens wrote: > >> One small data point. Having just done two upgrades from RH9 to FC2 >> with nothing but XFS partitions, the upgrade worked fine. However >> there are hints (IOW I could be talking through my hat here) that the >> 2.6 kernel in FC2 is more rigorous about checking XFS file structures >> than the 2.4 kernel in RH8/9. > >Keith, what makes you say this? I take it that you saw problems which >prompted you to run repair over the filesystems? On two laptops, running the upgrade got an XFS shutdown on / or /usr. Both laptops had been shutdown in midflight many times while running RH9, and had not run xfs_repair for some time. RH9 had no problems with those filesystems, FC2 did. As I said, I could be talking through my hat here. OTOH, it is good practice to ensure that the filesystems are clean before doing a major OS upgrade. From owner-linux-xfs Thu Aug 12 03:56:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Aug 2004 03:56:31 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7CAuQXD024263 for ; Thu, 12 Aug 2004 03:56:26 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7CAuQ1e024262 for linux-xfs@oss.sgi.com; Thu, 12 Aug 2004 03:56:26 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7CAuP9N024248 for ; Thu, 12 Aug 2004 03:56:25 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7C9wDSg022997; Thu, 12 Aug 2004 02:58:13 -0700 Date: Thu, 12 Aug 2004 02:58:13 -0700 Message-Id: <200408120958.i7C9wDSg022997@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3901 X-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: 1121 Lines: 33 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-12-08 02:58 PDT ------- I have another machine showing the same symptoms, with the additional difficulty that it refuses to mount even with the -o norecovery,ro option. The machine had to go back to production, so I was left no other choice than zeroing the log and live with some corrupted files. However, this time I made sure to gather as much information about the fs as possible: http://cern.ch/fuji/xfs/lxfs5046.xfs_info http://cern.ch/fuji/xfs/lxfs5046.xfs_check.bz2 http://cern.ch/fuji/xfs/lxfs5046.xfs_logprint.bz2 http://cern.ch/fuji/xfs/lxfs5046.xfs_repair-L.bz2 http://cern.ch/fuji/xfs/lxfs5046.xfs_repair-n.bz2 http://cern.ch/fuji/xfs/lxfs5046.xfs_repair.bz2 Could we at least theorize what causes this, because the probability of hardware error is diminishing rather fast as more cases are developed? Same hardware, same kernel than previous entry. Thanks, Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Aug 12 12:24:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Aug 2004 12:24:40 -0700 (PDT) Received: from mail-gw.seakr.com (gw2.seakr.com [209.144.181.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7CJOWTv016864 for ; Thu, 12 Aug 2004 12:24:32 -0700 Received: from scan-gw.seakr.com (seakr5.seakr.com [192.168.100.10]) by mail-gw.seakr.com (8.12.10/8.12.10) with ESMTP id i7CIw8SY011878; Thu, 12 Aug 2004 12:58:09 -0600 Received: from seakr5.seakr.com(192.168.100.10) by scan-gw.seakr.com via csmap id 01d4d728_ec95_11d8_8f5a_0002b3db7308_13896; Thu, 12 Aug 2004 13:22:53 -0600 (MDT) Received: from nick0.it.seakr.com (nick0 [192.168.10.70]) by seakr5.seakr.com (8.10.2/8.10.2) with ESMTP id i7CJOI609569; Thu, 12 Aug 2004 13:24:18 -0600 (MDT) Subject: XFS Extended Attributes From: Nick Couchman To: a.gruenbacher@computer.org Cc: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0dS64NA6BxSX+JaXVXi0" Organization: SEAKR Engineering, Inc. Message-Id: <1092338657.11318.7.camel@nick0.it.seakr.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 13:24:18 -0600 X-archive-position: 3902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nick@seakr.com Precedence: bulk X-list: linux-xfs Content-Length: 1868 Lines: 71 --=-0dS64NA6BxSX+JaXVXi0 Content-Type: multipart/alternative; boundary="=-Qd2ClY/FxmbBe+Y0Fr97" --=-Qd2ClY/FxmbBe+Y0Fr97 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is there anywhere that I can find an actual list of the extended attributes supported under the XFS/Linux filesystem? The man page for attr(5) describes the classes, but I'm having a very hard time locating any information at all about the actual attributes. Thanks, --=20 Nick Couchman Information Technology SEAKR Engineering, Inc. Phone: (303) 790-8499 Fax: (303) 790-8720 Web: http://www.seakr.com --=-Qd2ClY/FxmbBe+Y0Fr97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is there anywhere that I can find an actual list of the extended attributes= supported under the XFS/Linux filesystem?  The man page for attr(5) d= escribes the classes, but I'm having a very hard time locating any informat= ion at all about the actual attributes.

Thanks,
--=20
Nick Couchman
Information Technology
SEAKR Engineering, Inc.
Phone: (303) 790-8499
Fax: (303) 790-8720
Web: http://www.seakr.com
--=-Qd2ClY/FxmbBe+Y0Fr97-- --=-0dS64NA6BxSX+JaXVXi0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBG8PhHiX1DHbKcHgRAqh3AJ9V34dAnD2+TRbr9x+WDTw27debTwCdHoOV UitdPJ8+Hry7hn5dh6bubII= =ZDJ+ -----END PGP SIGNATURE----- --=-0dS64NA6BxSX+JaXVXi0-- From owner-linux-xfs Thu Aug 12 17:32:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Aug 2004 17:32:08 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7D0W6Bg028611 for ; Thu, 12 Aug 2004 17:32:06 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i7D1ZFYA026874 for ; Thu, 12 Aug 2004 18:35:16 -0700 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 KAA23058; Fri, 13 Aug 2004 10:30:43 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7D0UOln3154372; Fri, 13 Aug 2004 10:30:24 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7D1OsFw007907; Fri, 13 Aug 2004 11:25:11 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7D1O3Pn007905; Fri, 13 Aug 2004 11:24:03 +1000 Date: Fri, 13 Aug 2004 11:24:03 +1000 From: Nathan Scott To: Nick Couchman Cc: a.gruenbacher@computer.org, linux-xfs@oss.sgi.com Subject: Re: XFS Extended Attributes Message-ID: <20040813012403.GB7720@frodo> References: <1092338657.11318.7.camel@nick0.it.seakr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1092338657.11318.7.camel@nick0.it.seakr.com> User-Agent: Mutt/1.5.3i X-archive-position: 3903 X-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: 560 Lines: 19 On Thu, Aug 12, 2004 at 01:24:18PM -0600, Nick Couchman wrote: > Is there anywhere that I can find an actual list of the extended > attributes supported under the XFS/Linux filesystem? The man page for > attr(5) describes the classes, but I'm having a very hard time locating > any information at all about the actual attributes. XFS supports: system.posix_acl_default system.posix_acl_access arbitrary attributes in the "user" namespace arbitrary attributes in the "trusted" namespace arbitrary attributes in the "security" namespace cheers. -- Nathan From owner-linux-xfs Thu Aug 12 19:58:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Aug 2004 19:58:22 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7D2wHfa004900 for ; Thu, 12 Aug 2004 19:58:20 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i7D41R0O003446 for ; Thu, 12 Aug 2004 21:01:28 -0700 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 MAA25698; Fri, 13 Aug 2004 12:56:52 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7D2uXln3150535; Fri, 13 Aug 2004 12:56:34 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7D3pCGP001286; Fri, 13 Aug 2004 13:51:28 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7D3oTKr001284; Fri, 13 Aug 2004 13:50:29 +1000 Date: Fri, 13 Aug 2004 13:50:29 +1000 From: Nathan Scott To: James Foris Cc: linux-xfs@oss.sgi.com Subject: Re: XFS performance issues: O_DIRECT and Linux 2.6.6+ Message-ID: <20040813035029.GB983@frodo> References: <411A8410.2030000@med.ge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411A8410.2030000@med.ge.com> User-Agent: Mutt/1.5.3i X-archive-position: 3904 X-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: 793 Lines: 27 Hi James, Thanks for the detailed analysis! On Wed, Aug 11, 2004 at 03:39:44PM -0500, James Foris wrote: > ... > Does anyone know what has changed ? And is there anything that can be cone > to make the current kernels > behave better ? Looking back through the changes in XFS I can't see anything that might explain this. There were four changes to fs/direct-io.c between 2.6.5 and 2.6.6, I wonder if you could back these out one by one, re-running your test on XFS without each one, and see if its one of those changes (if you use bitkeeper, you can see and extract those individual changes - probably the easiest way to do this). Let me know which it is, if any; that'll give me a good starting point to track it down. If its not those, we'll try another tack. thanks! -- Nathan From owner-linux-xfs Thu Aug 12 20:02:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Aug 2004 20:02:51 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7D32n1G005257 for ; Thu, 12 Aug 2004 20:02:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7D32g0f016642 for ; Thu, 12 Aug 2004 22:02:43 -0500 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 i7D32W7X13060486; Fri, 13 Aug 2004 13:02:33 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7D32VlL13096754; Fri, 13 Aug 2004 13:02:31 +1000 (EST) Date: Fri, 13 Aug 2004 13:02:31 +1000 (EST) From: Nathan Scott Message-Id: <200408130302.i7D32VlL13096754@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 918230 - merge realtime fix from IRIX X-archive-position: 3905 X-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: 478 Lines: 19 Add support for unsetting realtime flag on realtime file which has no extents allocated. Date: Thu Aug 12 20:01:27 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: nathans@sgi.com gwehrman@sgi.com Author: herry.longdrop.melbourne.sgi.com Merged by: nathans Merged mods: grove2:irix:18776a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:18776a xfs_vnodeops.c - 1.626 From owner-linux-xfs Thu Aug 12 22:32:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Aug 2004 22:32:58 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7D5WuP0011227 for ; Thu, 12 Aug 2004 22:32:56 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7D6a784016195 for ; Thu, 12 Aug 2004 23:36:07 -0700 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 i7D5Wl7X13151878 for ; Fri, 13 Aug 2004 15:32:48 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7D5Wkoq13221750 for linux-xfs@oss.sgi.com; Fri, 13 Aug 2004 15:32:46 +1000 (EST) Date: Fri, 13 Aug 2004 15:32:46 +1000 (EST) From: Nathan Scott Message-Id: <200408130532.i7D5Wkoq13221750@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 915844 - minor cleanup X-archive-position: 3906 X-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: 1096 Lines: 45 Remove several macros which are no longer used anywhere. Date: Thu Aug 12 22:14:58 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: sandeen@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:177029a xfs_log.c - 1.299 xfs_buf_item.c - 1.150 xfs_vnodeops.c - 1.627 xfs_dmapi.c - 1.98 xfs_attr.c - 1.117 Use sparse whitespace approach that Al took to be more consistent. Couple more sparse fixes. Date: Thu Aug 12 22:31:26 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:177030a xfs_fs.h - 1.18 xfs_itable.c - 1.126 xfs_itable.h - 1.45 xfs_dfrag.c - 1.45 xfs_bmap.h - 1.86 xfs_bmap.c - 1.321 xfs_quota.h - 1.37 quota/xfs_qm_syscalls.c - 1.11 quota/xfs_qm.c - 1.15 linux-2.6/xfs_lrw.c - 1.214 linux-2.6/xfs_ioctl.c - 1.113 linux-2.6/xfs_file.c - 1.105 linux-2.6/xfs_iops.c - 1.219 linux-2.6/xfs_sysctl.c - 1.30 From owner-linux-xfs Fri Aug 13 10:55:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Aug 2004 10:55:36 -0700 (PDT) Received: from ncbdc.bbs ([208.0.185.14]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7DHtWjG014759 for ; Fri, 13 Aug 2004 10:55:33 -0700 Received: by NCBDC with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Aug 2004 10:56:18 -0700 Message-ID: <057889C7F1E5D61193620002A537E86902E9C035@NCBDC> From: Mark Grimes To: "'linux-xfs@oss.sgi.com'" Subject: hang release-1.3.3pre2 from ScientificLinux Date: Fri, 13 Aug 2004 10:56:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3907 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: MGrimes@snapappliance.com Precedence: bulk X-list: linux-xfs Content-Length: 644 Lines: 17 All, I've been doing a study of SLESv8 and RHEL with XFS. I installed the ScientificLinux on a Dual 3GHz Xeon server from Supermicro. I also have an IBM ProFiber JBOD attached on which I run XFS. I've been running specSFS tests. With 4GB the test runs great. When I run the same test with 8GB installed, the system hangs hard part way through my first mix (1800). No console, nothing. I'm forced to use the reset button. I ran it twice just to make sure. Then, on the same system I changed to my SLESv8 disk. With SLES, the same test did not fail. It continued on to very nice results. Has anyone else seen problems with 8GB? -Mark From owner-linux-xfs Fri Aug 13 11:04:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Aug 2004 11:04:46 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7DI4hVh015140 for ; Fri, 13 Aug 2004 11:04:43 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7DJ80Mp019434 for ; Fri, 13 Aug 2004 12:08:00 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7DI3bOV44946509; Fri, 13 Aug 2004 13:03:37 -0500 (CDT) Message-ID: <411D0279.9010203@sgi.com> Date: Fri, 13 Aug 2004 13:03:37 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Grimes CC: "'linux-xfs@oss.sgi.com'" Subject: Re: hang release-1.3.3pre2 from ScientificLinux References: <057889C7F1E5D61193620002A537E86902E9C035@NCBDC> In-Reply-To: <057889C7F1E5D61193620002A537E86902E9C035@NCBDC> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3908 X-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: 906 Lines: 30 8G==memory? Hm, how is xfs config'd - `modinfo xfs` .... Also which kernels from each distro, RHEL has -bigmem etc... Can you enable KDB, and see if you can break in? echo 1 > /proc/sys/kernel/kdb -Eric Mark Grimes wrote: > All, > > I've been doing a study of SLESv8 and RHEL with XFS. > I installed the ScientificLinux on a Dual 3GHz Xeon server from Supermicro. > I also have an IBM ProFiber JBOD attached on which I run XFS. > I've been running specSFS tests. > With 4GB the test runs great. > When I run the same test with 8GB installed, the system hangs hard part way > through my first mix (1800). No console, nothing. I'm forced to use the > reset button. I ran it twice just to make sure. Then, on the same system I > changed to my SLESv8 disk. With SLES, the same test did not fail. It > continued on to very nice results. Has anyone else seen problems with 8GB? > > -Mark > > > From owner-linux-xfs Fri Aug 13 11:25:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Aug 2004 11:25:41 -0700 (PDT) Received: from web51806.mail.yahoo.com (web51806.mail.yahoo.com [206.190.38.237]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7DIPbhH017975 for ; Fri, 13 Aug 2004 11:25:37 -0700 Message-ID: <20040813182526.7230.qmail@web51806.mail.yahoo.com> Received: from [158.140.2.102] by web51806.mail.yahoo.com via HTTP; Fri, 13 Aug 2004 11:25:26 PDT Date: Fri, 13 Aug 2004 11:25:26 -0700 (PDT) From: Phy Prabab Subject: Re: hang release-1.3.3pre2 from ScientificLinux To: Eric Sandeen , Mark Grimes Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <411D0279.9010203@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: phyprabab@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1325 Lines: 58 Just to add confusion, I have SL linux on a machine with 16G RAM and no issues with XFS on several file systems (including a FC 4T volume). Phy --- Eric Sandeen wrote: > 8G==memory? > > Hm, how is xfs config'd - `modinfo xfs` .... > Also which kernels from each distro, RHEL has > -bigmem etc... > > Can you enable KDB, and see if you can break in? > > echo 1 > /proc/sys/kernel/kdb > > -Eric > > Mark Grimes wrote: > > All, > > > > I've been doing a study of SLESv8 and RHEL with > XFS. > > I installed the ScientificLinux on a Dual 3GHz > Xeon server from Supermicro. > > I also have an IBM ProFiber JBOD attached on which > I run XFS. > > I've been running specSFS tests. > > With 4GB the test runs great. > > When I run the same test with 8GB installed, the > system hangs hard part way > > through my first mix (1800). No console, nothing. > I'm forced to use the > > reset button. I ran it twice just to make sure. > Then, on the same system I > > changed to my SLESv8 disk. With SLES, the same > test did not fail. It > > continued on to very nice results. Has anyone > else seen problems with 8GB? > > > > -Mark > > > > > > > > > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-linux-xfs Fri Aug 13 13:38:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Aug 2004 13:38:13 -0700 (PDT) Received: from ncbdc.bbs ([208.0.185.14]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7DKc7vD026133 for ; Fri, 13 Aug 2004 13:38:09 -0700 Received: by NCBDC with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Aug 2004 13:38:53 -0700 Message-ID: <057889C7F1E5D61193620002A537E86902E9C038@NCBDC> From: Mark Grimes To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: hang release-1.3.3pre2 from ScientificLinux Date: Fri, 13 Aug 2004 13:38:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: MGrimes@snapappliance.com Precedence: bulk X-list: linux-xfs Content-Length: 2255 Lines: 78 Yes, 8GB 133MHz ECC DDR memory. Also, I have an 8GB swap partition. modinfo xfs output: filename: /lib/modules/2.4.21-15.EL.sgi3smp/kernel/fs/xfs/xfs.o description: "SGI XFS 1.3.3 with ACLs, large block numbers, no debug enabled" author: "Silicon Graphics, Inc." license: "GPL" uname -r output: 2.4.21-15.EL.sgi3smp Does an 8GB memory system require the bigmem kernel? I thought that started at 16GB? I had to hand copy the bt from the kdb: Entering kdb (current=0xc0410000, pid 0) on processor 0 due to Keyboard Entry [0]kdb> bt Stack traceback for pid 0 0xc0410000 0 0 1 0 R 0xc0010580 *swapper ESP EIP Function 0xc0411fc0 0xc0109109 default_idle+0x29 (0xc0410000, 0x998000, 0xc0107000) kernel .text 0xc0100000 0xc01090e0 0xc0109130 0xc0411fc4 0xc01091a2 cpu_idle+0x42 kernel .text 0xc0100000 0xc0109160 0xc01091c0 0xc0411fd8 0xc010704d stext+0x4d kernel .text 0xc0100000 0xc0100000 0xc0107070 0xc0411fec 0xc0413880 Start_Kernel+0x160 kernel .text.init 0xc0413000 0xc0413720 0xc04138b0 -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Friday, August 13, 2004 11:04 AM To: Mark Grimes Cc: 'linux-xfs@oss.sgi.com' Subject: Re: hang release-1.3.3pre2 from ScientificLinux 8G==memory? Hm, how is xfs config'd - `modinfo xfs` .... Also which kernels from each distro, RHEL has -bigmem etc... Can you enable KDB, and see if you can break in? echo 1 > /proc/sys/kernel/kdb -Eric Mark Grimes wrote: > All, > > I've been doing a study of SLESv8 and RHEL with XFS. > I installed the ScientificLinux on a Dual 3GHz Xeon server from Supermicro. > I also have an IBM ProFiber JBOD attached on which I run XFS. > I've been running specSFS tests. > With 4GB the test runs great. > When I run the same test with 8GB installed, the system hangs hard part way > through my first mix (1800). No console, nothing. I'm forced to use the > reset button. I ran it twice just to make sure. Then, on the same system I > changed to my SLESv8 disk. With SLES, the same test did not fail. It > continued on to very nice results. Has anyone else seen problems with 8GB? > > -Mark > > > From owner-linux-xfs Fri Aug 13 15:06:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Aug 2004 15:07:02 -0700 (PDT) Received: from ncbdc.bbs ([208.0.185.14]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7DM6tJ4029086 for ; Fri, 13 Aug 2004 15:06:57 -0700 Received: by NCBDC with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Aug 2004 15:07:39 -0700 Message-ID: <057889C7F1E5D61193620002A537E86902E9C039@NCBDC> From: Mark Grimes To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: hang release-1.3.3pre2 from ScientificLinux Date: Fri, 13 Aug 2004 15:07:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: MGrimes@snapappliance.com Precedence: bulk X-list: linux-xfs Content-Length: 4186 Lines: 135 More info on the hang. We routed the syslog to a remote machine and ssh'd into the server to run vmstat while the test was running. The syslog did not report anything anomalous. The last line below is when the system went unresponsive and ceased disk activity. Here is the last entries from the vmstat: 10 1 0 17160 192 7457928 0 0 12 23672 20904 6963 0 87 12 1 3 2 0 16948 192 7457472 0 0 8 20396 18024 6743 0 80 19 0 3 9 0 17052 192 7457036 0 0 0 20056 15591 5213 0 73 27 0 2 2 0 16592 192 7457216 0 0 8 17356 13654 4533 0 70 30 0 2 0 0 15884 192 7457324 0 0 0 22896 18982 6707 0 67 33 0 1 2 0 14440 192 7458100 0 0 0 12844 11209 4904 0 68 32 0 0 7 0 14636 192 7457768 0 0 0 13152 11577 5325 0 84 16 0 0 2 0 14488 188 7457536 0 0 8 8384 7667 3651 0 58 42 0 4 4 0 14680 192 7457420 0 0 4 15100 13252 4846 0 67 33 0 9 1 0 15088 180 7456236 0 0 0 8784 7948 4008 0 61 39 0 4 1 0 15208 180 7456060 0 0 0 11800 9225 3492 0 57 43 0 3 1 0 14524 180 7456144 0 0 8 7256 7252 4216 0 61 39 0 0 10 0 15312 180 7455208 0 0 8 9712 8984 3351 0 60 40 0 procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa 11 2 0 14696 180 7455544 0 0 8 12576 9946 4221 0 75 25 0 2 0 0 14608 180 7455212 0 0 8 12832 10840 4363 0 63 37 0 9 1 0 14468 180 7455248 0 0 0 9100 8199 3885 0 62 37 1 -----Original Message----- From: Mark Grimes Sent: Friday, August 13, 2004 1:39 PM To: 'Eric Sandeen' Cc: 'linux-xfs@oss.sgi.com' Subject: RE: hang release-1.3.3pre2 from ScientificLinux Yes, 8GB 133MHz ECC DDR memory. Also, I have an 8GB swap partition. modinfo xfs output: filename: /lib/modules/2.4.21-15.EL.sgi3smp/kernel/fs/xfs/xfs.o description: "SGI XFS 1.3.3 with ACLs, large block numbers, no debug enabled" author: "Silicon Graphics, Inc." license: "GPL" uname -r output: 2.4.21-15.EL.sgi3smp Does an 8GB memory system require the bigmem kernel? I thought that started at 16GB? I had to hand copy the bt from the kdb: Entering kdb (current=0xc0410000, pid 0) on processor 0 due to Keyboard Entry [0]kdb> bt Stack traceback for pid 0 0xc0410000 0 0 1 0 R 0xc0010580 *swapper ESP EIP Function 0xc0411fc0 0xc0109109 default_idle+0x29 (0xc0410000, 0x998000, 0xc0107000) kernel .text 0xc0100000 0xc01090e0 0xc0109130 0xc0411fc4 0xc01091a2 cpu_idle+0x42 kernel .text 0xc0100000 0xc0109160 0xc01091c0 0xc0411fd8 0xc010704d stext+0x4d kernel .text 0xc0100000 0xc0100000 0xc0107070 0xc0411fec 0xc0413880 Start_Kernel+0x160 kernel .text.init 0xc0413000 0xc0413720 0xc04138b0 -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Friday, August 13, 2004 11:04 AM To: Mark Grimes Cc: 'linux-xfs@oss.sgi.com' Subject: Re: hang release-1.3.3pre2 from ScientificLinux 8G==memory? Hm, how is xfs config'd - `modinfo xfs` .... Also which kernels from each distro, RHEL has -bigmem etc... Can you enable KDB, and see if you can break in? echo 1 > /proc/sys/kernel/kdb -Eric Mark Grimes wrote: > All, > > I've been doing a study of SLESv8 and RHEL with XFS. > I installed the ScientificLinux on a Dual 3GHz Xeon server from Supermicro. > I also have an IBM ProFiber JBOD attached on which I run XFS. > I've been running specSFS tests. > With 4GB the test runs great. > When I run the same test with 8GB installed, the system hangs hard part way > through my first mix (1800). No console, nothing. I'm forced to use the > reset button. I ran it twice just to make sure. Then, on the same system I > changed to my SLESv8 disk. With SLES, the same test did not fail. It > continued on to very nice results. Has anyone else seen problems with 8GB? > > -Mark > > > From owner-linux-xfs Fri Aug 13 15:21:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Aug 2004 15:21:20 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7DMLFKA029673 for ; Fri, 13 Aug 2004 15:21:16 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7DNOVJs024070 for ; Fri, 13 Aug 2004 16:24:31 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7DMK7OV45003120; Fri, 13 Aug 2004 17:20:07 -0500 (CDT) Message-ID: <411D3E96.1070705@sgi.com> Date: Fri, 13 Aug 2004 17:20:06 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Grimes CC: "'linux-xfs@oss.sgi.com'" Subject: Re: hang release-1.3.3pre2 from ScientificLinux References: <057889C7F1E5D61193620002A537E86902E9C039@NCBDC> In-Reply-To: <057889C7F1E5D61193620002A537E86902E9C039@NCBDC> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3912 X-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: 227 Lines: 7 for the kdb backtrace, it'd be more useful to do a "ps" to see what's running, and backtrace the interesting processes with btp - the backtrace you sent is not particularly interesting, it's just an idle swapper. :) -Eric From owner-linux-xfs Fri Aug 13 16:29:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Aug 2004 16:29:24 -0700 (PDT) Received: from SLACKWARE-1.officenet (milliman.dsl.xmission.com [166.70.226.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7DNTM5E002018 for ; Fri, 13 Aug 2004 16:29:22 -0700 Received: from [192.168.1.15] (SLACKWARE-1.officenet [192.168.1.15]) by SLACKWARE-1.officenet (8.12.11/8.12.10) with ESMTP id i7DNTBS7011973 for ; Fri, 13 Aug 2004 17:29:11 -0600 Message-ID: <411D4EC7.4060003@xmission.com> Date: Fri, 13 Aug 2004 17:29:11 -0600 From: Douglas Mayne User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: CVS Compile Help Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ddmayne@xmission.com Precedence: bulk X-list: linux-xfs Content-Length: 643 Lines: 22 I downloaded the CVS, per the instructions on your website: cvs checkout linux-2.4-xfs When I tried to compile (with gcc 3.3.4), I get an error at make modules_install: if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.27; fi depmod: *** Unresolved symbols in /lib/modules/2.4.27/kernel/fs/xfs/xfs.o depmod: sync_buffers In tracking this down, it appears only part of the split-patches have been applied to the CVS. Should all of these patches have already been applied? Is this documented somewhere? Pardon me if this is the way it is supposed to be (this is my first time here.) Thank You, Douglas Mayne From owner-linux-xfs Sat Aug 14 07:05:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Aug 2004 07:05:20 -0700 (PDT) Received: from SRV-COB-00-0009.elaxy.org ([62.159.121.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7EE5CP8001594 for ; Sat, 14 Aug 2004 07:05:14 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Page failure allocation - in-memory data corruption X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Date: Sat, 14 Aug 2004 16:05:00 +0200 Message-ID: <146F748F2A59E44CBD1C51957344B31207F6AF@srv-cob-00-0009.elaxy.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Page failure allocation - in-memory data corruption Thread-Index: AcSCB7EGHAB7Ot9pSkOfSMdaiY3BvA== From: =?iso-8859-1?Q?H=FCmmer_Andreas?= To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i7EE5EP8001595 X-archive-position: 3914 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andreas.huemmer@elaxy.com Precedence: bulk X-list: linux-xfs Content-Length: 3158 Lines: 55 Hi there, Recently I observed some annoying errors: "Corruption of in-memory data detected" along with page faillure allocations of ohter applications (smbd or nfsd). Basicly I m running a suse 9.1 (2.6.5-7.104-smp) on a dual athlon with 4 Gigs of RAM and "some" storage devices attached. A Gbit Networkinterface is also part of the system and all filesystems run on an encryted loop-device. Well, fortunately it is currently only partial in production state, so that I had the chance to do some investigations. In every case the failures occured under load via the fileserver application. Therefore I started observing the MemFree state of the machine and found, that it goes down (as expected) to the limit defined in vm.nin_free_kbytes whitch is in this case set to 1914. Every failure started with an "page allocation failure" mostly from smbd. This process was dead afterwards. Then followed by in-memory datacorruptions reported by xfs. Thus finally (after a handfull of tests) resulting in a 50% data-loss on a completely garbled 1.8TB xfs-partition. After doing some investigations the following behaviour was observed: - changing eth interface speed from 1GB to 100MB: The errors were occuring less often - changing the sync-bahaviour (strictsync, etc) in smbd: The errors occured less often - Nevertheless there was no clear picture unter what circumsdances these errors can occure - As mentioned above the vm.min_free_kbyte is set to about 2MB (default suse oder 2.6 setting), so the idea was to rize this to a higher value to give the system a little more space for its bufferhandling. And: It worked for now, setting this value to about 20M, all problems even under full-load-conditions up to the systems limit were gone. The behauvior I observed after setting vm.min_free to 20 MB was that some processes (for the most part smbd, xfs) were allocating memory really quick. And it seems (unfortunately I have no proof for it) that there can be a race condition while concurrent applications allocate memory buffers. I cant state clearly by now where the problem originaly comes from (kernel, samba, xfs or intel e100/1000 driver), but the ones mentioned before are my favorites. The questions I have now are: - Is there a "known" problem with xfs and memory-allocation ? - Even if this bug which is not originated by xfs itself, is there or can there be a function to avoid damage to the filesystems in case another app goes "wild"? - Can this issue be used by an attacker to damage a system? - Is there a table or list stating some basic (known to be good or best choice) (kernel|fs|application)parameters for given filesystem(sizes)? If usefull, I can provide more infos and do some more tests - well I can do this until end of august, the the machine will go to production state. Ciao Andi Andreas Hümmer IT-Service Mobile: +49 (0) 1 60.90 53 02 04 Mailto:andreas.huemmer@elaxy.com _____________________________________ ELAXY GmbH Spitalgasse 23 D - 96450 Coburg Phone: +49 (0) 95 61.5543.0 FAX: +49 (0) 95 61.5543.344 http://www.elaxy.com _____________________________________ From owner-linux-xfs Sun Aug 15 15:56:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 15:56:44 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7FMufRu022568 for ; Sun, 15 Aug 2004 15:56:41 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7FMufmP022567 for linux-xfs@oss.sgi.com; Sun, 15 Aug 2004 15:56:41 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7FMuejG022553 for ; Sun, 15 Aug 2004 15:56:40 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7FMaCR6022282; Sun, 15 Aug 2004 15:36:12 -0700 Date: Sun, 15 Aug 2004 15:36:12 -0700 Message-Id: <200408152236.i7FMaCR6022282@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 356] New: xfsdump crashes system when dumping to a XFS partition X-Bugzilla-Reason: AssignedTo X-archive-position: 3915 X-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: 1066 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=356 Summary: xfsdump crashes system when dumping to a XFS partition Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: blocker Priority: High Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: hans.lampl@dynaware.de Whenever I try to make a dump (using xfsdump 2.2.21) to a XFS-partition, my system (kernel 2.4.22) crashes after having written some GB to the destination file. There are neither any specific messages in the syslog (except some binary zeros, but only sometimes) nor any messages indicating what's wrong in the xfsdump-logfile (except binary zeros as well at the end of the file). The crash seems not to depend on a certain file size. Performing the same (xfs-)dump to an EXT3 partition works without any problems. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Aug 15 16:45:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 16:45:55 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7FNjrME026857 for ; Sun, 15 Aug 2004 16:45:53 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7G0nSXs022996 for ; Sun, 15 Aug 2004 17:49:28 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i7FNjjl12504 for linux-xfs@oss.sgi.com; Mon, 16 Aug 2004 09:45:45 +1000 Date: Mon, 16 Aug 2004 09:45:45 +1000 From: Nathan Scott Message-Id: <200408152345.i7FNjjl12504@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 914196 - reinstate missed split-patches X-archive-position: 3916 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 385 Lines: 15 Merge back in a couple of unapplied patches after the 2.4.27 merge. Date: Sun Aug 15 16:44:52 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:177120a Documentation/filesystems/xfs.txt - 1.7 fs/buffer.c - 1.7 lib/rwsem.c - 1.5 From owner-linux-xfs Sun Aug 15 17:40:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 17:40:21 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G0eIUt027994 for ; Sun, 15 Aug 2004 17:40:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i7G1ho1G005894 for ; Sun, 15 Aug 2004 18:43:53 -0700 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 KAA02705; Mon, 16 Aug 2004 10:40:04 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7G0e1ln3250558; Mon, 16 Aug 2004 10:40:02 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7G1ZoVp001157; Mon, 16 Aug 2004 11:35:51 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7G1ZmgY001155; Mon, 16 Aug 2004 11:35:48 +1000 Date: Mon, 16 Aug 2004 11:35:48 +1000 From: Nathan Scott To: Douglas Mayne Cc: linux-xfs@oss.sgi.com Subject: Re: CVS Compile Help Message-ID: <20040816013548.GC998@frodo> References: <411D4EC7.4060003@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411D4EC7.4060003@xmission.com> User-Agent: Mutt/1.5.3i X-archive-position: 3917 X-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: 336 Lines: 14 On Fri, Aug 13, 2004 at 05:29:11PM -0600, Douglas Mayne wrote: > ... > In tracking this down, it appears only part of the split-patches have > been applied to the CVS. > Should all of these patches have already been applied? Stuff up on my part, yes, they should all be applied in CVS. Try a fresh checkout now. cheers. -- Nathan From owner-linux-xfs Sun Aug 15 17:56:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 17:56:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G0uhpp028456 for ; Sun, 15 Aug 2004 17:56:43 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7G0uh6p028455 for linux-xfs@oss.sgi.com; Sun, 15 Aug 2004 17:56:43 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G0ueOW028440 for ; Sun, 15 Aug 2004 17:56:40 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7G0btiT027956; Sun, 15 Aug 2004 17:37:55 -0700 Date: Sun, 15 Aug 2004 17:37:55 -0700 Message-Id: <200408160037.i7G0btiT027956@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 356] xfsdump crashes system when dumping to a XFS partition X-Bugzilla-Reason: AssignedTo X-archive-position: 3918 X-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: 656 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=356 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From nathans@sgi.com 2004-15-08 17:37 PDT ------- This has been fixed for awhile, upgrading to a more recent kernel should resolve this issue for you - let us know if not. thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Aug 15 18:56:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 18:56:45 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G1uhh2029808 for ; Sun, 15 Aug 2004 18:56:43 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7G1uhVO029807 for linux-xfs@oss.sgi.com; Sun, 15 Aug 2004 18:56:43 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G1ufVH029793 for ; Sun, 15 Aug 2004 18:56:41 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7G0x8pO028784; Sun, 15 Aug 2004 17:59:08 -0700 Date: Sun, 15 Aug 2004 17:59:08 -0700 Message-Id: <200408160059.i7G0x8pO028784@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3919 X-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: 1344 Lines: 41 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 ------- Additional Comments From nathans@sgi.com 2004-15-08 17:59 PDT ------- hi Peter, > but the subsequent mount fails when the log would be replayed. xfs_check tells > me that the filesystem is funky: Most likely because the log not replayed, so this isn't useful information unless it persists after a mount/umount (more recent xfsprogs will warn), or repair in this case. > Kernel is 2.4.20-31.7.2.cernsmp which is basically RedHat plus some local > patches to the SCSI tape layer. Where did the XFS code come from (which version? cvs?) > sure to gather as much information about the fs as possible: Thanks! (fyi - one other useful piece - the -C option to xfs_logprint can capture the log off to a file for later post-processing). > Could we at least theorize what causes this, because the probability of > hardware error is diminishing rather fast as more cases are developed? Lots of variables here - if we can eliminate some, we could come up with a theory. Things to exclude if possible - software RAID, large inodes vs default, v2 log vs defaults, stripe alignment vs none, etc. Any additional info will help. Any mount options in use? thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Aug 15 22:01:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 22:01:40 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G51bgf010822 for ; Sun, 15 Aug 2004 22:01:37 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7G65DVi030991 for ; Sun, 15 Aug 2004 23:05:15 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i7G50Sd11569 for linux-xfs@oss.sgi.com; Mon, 16 Aug 2004 15:00:28 +1000 Date: Mon, 16 Aug 2004 15:00:28 +1000 From: Nathan Scott Message-Id: <200408160500.i7G50Sd11569@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 914196 - kdb fixups X-archive-position: 3921 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 358 Lines: 15 Fix up some kdb issues with 2.6.8. Date: Sun Aug 15 22:00:04 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:177126a kernel/sysctl.c - 1.17 kdb/modules/kdbm_vm.c - 1.8 split-patches/kdb-common - 1.6 From owner-linux-xfs Sun Aug 15 21:59:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 22:00:31 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G4xsKI010588 for ; Sun, 15 Aug 2004 21:59:54 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7G63JE9030205 for ; Sun, 15 Aug 2004 23:03:21 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i7G4wY011496 for linux-xfs@oss.sgi.com; Mon, 16 Aug 2004 14:58:34 +1000 Date: Mon, 16 Aug 2004 14:58:34 +1000 From: Nathan Scott Message-Id: <200408160458.i7G4wY011496@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.8.1 X-archive-position: 3920 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 151562 Lines: 4610 Date: Sun Aug 15 20:52:41 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: torvalds@osdl.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:177122a arch/sh64/boot/compressed/head.S - 1.1 drivers/net/via-velocity.h - 1.1 drivers/net/via-velocity.c - 1.1 drivers/net/smc91x.h - 1.1 security/selinux/nlmsgtab.c - 1.1 drivers/net/smc91x.c - 1.1 drivers/net/fec_8xx/fec_mii.c - 1.1 Documentation/arm/Sharp-LH/SDRAM - 1.1 Documentation/arm/VFP/release-notes.txt - 1.1 drivers/net/fec_8xx/fec_main.c - 1.1 drivers/net/fec_8xx/fec_8xx.h - 1.1 drivers/net/fec_8xx/fec_8xx-netta.c - 1.1 Documentation/block/as-iosched.txt - 1.1 Documentation/block/deadline-iosched.txt - 1.1 drivers/net/fec_8xx/Makefile - 1.1 drivers/net/fec_8xx/Kconfig - 1.1 drivers/mtd/nand/tx4938ndfmc.c - 1.1 drivers/mtd/nand/tx4925ndfmc.c - 1.1 Documentation/device-mapper/dm-io.txt - 1.1 Documentation/device-mapper/kcopyd.txt - 1.1 Documentation/device-mapper/linear.txt - 1.1 Documentation/device-mapper/striped.txt - 1.1 Documentation/device-mapper/zero.txt - 1.1 drivers/mtd/nand/toto.c - 1.1 drivers/mtd/nand/ppchameleonevb.c - 1.1 scripts/package/mkspec - 1.1 scripts/package/builddeb - 1.1 Documentation/fb/sisfb.txt - 1.1 drivers/mtd/nand/nand_bbt.c - 1.1 Documentation/filesystems/automount-support.txt - 1.1 drivers/mtd/nand/nand_base.c - 1.1 drivers/mtd/nand/diskonchip.c - 1.1 drivers/mtd/nand/au1550nd.c - 1.1 drivers/mtd/maps/sbc8240.c - 1.1 drivers/mtd/maps/pb1550-flash.c - 1.1 Documentation/hpet.txt - 1.1 Documentation/i2c/i2c-parport - 1.1 drivers/mtd/maps/omap-toto-flash.c - 1.1 drivers/mtd/maps/mpc1211.c - 1.1 drivers/mtd/maps/integrator-flash-v24.c - 1.1 drivers/mtd/maps/ichxrom.c - 1.1 drivers/mtd/maps/dmv182.c - 1.1 drivers/mtd/maps/db1x00-flash.c - 1.1 drivers/mtd/maps/db1550-flash.c - 1.1 scripts/package/Makefile - 1.1 drivers/mtd/devices/phram.c - 1.1 drivers/mtd/chips/cfi_util.c - 1.1 drivers/net/wireless/prism54/prismcompat.h - 1.1 drivers/media/video/ovcamchip/ovcamchip_priv.h - 1.1 drivers/media/video/ovcamchip/ovcamchip_core.c - 1.1 drivers/media/video/ovcamchip/ov7x20.c - 1.1 drivers/media/video/ovcamchip/ov7x10.c - 1.1 drivers/media/video/ovcamchip/ov76be.c - 1.1 drivers/media/video/ovcamchip/ov6x30.c - 1.1 drivers/media/video/ovcamchip/ov6x20.c - 1.1 drivers/media/video/ovcamchip/Makefile - 1.1 drivers/pcmcia/pd6729.c - 1.1 drivers/pcmcia/pd6729.h - 1.1 scripts/mod/sumversion.c - 1.1 Documentation/powerpc/hvcs.txt - 1.1 Documentation/powerpc/mpc52xx.txt - 1.1 drivers/pcmcia/socket_sysfs.c - 1.1 drivers/s390/net/ctcdbug.c - 1.1 drivers/s390/net/ctcdbug.h - 1.1 drivers/scsi/3w-9xxx.c - 1.1 drivers/scsi/3w-9xxx.h - 1.1 drivers/scsi/fdomain.h - 1.1 drivers/scsi/sata_nv.c - 1.1 drivers/serial/cpm_uart/Makefile - 1.1 drivers/serial/cpm_uart/cpm_uart.h - 1.1 drivers/serial/cpm_uart/cpm_uart_core.c - 1.1 drivers/serial/cpm_uart/cpm_uart_cpm1.c - 1.1 drivers/serial/cpm_uart/cpm_uart_cpm1.h - 1.1 Documentation/usb/sn9c102.txt - 1.1 drivers/md/kcopyd.h - 1.1 scripts/mod/modpost.h - 1.1 drivers/md/kcopyd.c - 1.1 drivers/md/dm-zero.c - 1.1 drivers/md/dm-snap.h - 1.1 drivers/md/dm-snap.c - 1.1 drivers/md/dm-raid1.c - 1.1 drivers/md/dm-log.h - 1.1 drivers/md/dm-log.c - 1.1 drivers/md/dm-io.h - 1.1 drivers/md/dm-io.c - 1.1 drivers/md/dm-exception-store.c - 1.1 drivers/serial/cpm_uart/cpm_uart_cpm2.c - 1.1 drivers/serial/cpm_uart/cpm_uart_cpm2.h - 1.1 drivers/serial/mpc52xx_uart.c - 1.1 drivers/serial/serial_lh7a40x.c - 1.1 drivers/serial/sn_console.c - 1.1 drivers/usb/class/cdc-acm.h - 1.1 drivers/usb/host/ohci-lh7a404.c - 1.1 drivers/usb/media/sn9c102.h - 1.1 drivers/i2c/chips/lm77.c - 1.1 drivers/usb/media/sn9c102_core.c - 1.1 drivers/i2c/chips/adm1031.c - 1.1 drivers/i2c/chips/adm1025.c - 1.1 drivers/firmware/pcdp.h - 1.1 drivers/firmware/pcdp.c - 1.1 drivers/usb/media/sn9c102_pas106b.c - 1.1 drivers/usb/media/sn9c102_sensor.h - 1.1 drivers/usb/media/sn9c102_tas5110c1b.c - 1.1 drivers/usb/media/sn9c102_tas5130d1b.c - 1.1 drivers/usb/media/w9968cf_vpp.h - 1.1 arch/arm/boot/bootp/initrd.S - 1.1 arch/arm/boot/bootp/kernel.S - 1.1 drivers/video/riva/rivafb-i2c.c - 1.1 drivers/w1/Kconfig - 1.1 drivers/w1/Makefile - 1.1 drivers/char/watchdog/ixp2000_wdt.c - 1.1 drivers/w1/matrox_w1.c - 1.1 drivers/w1/w1.c - 1.1 arch/arm/boot/compressed/piggy.S - 1.1 drivers/char/lcd.h - 1.1 drivers/w1/w1.h - 1.1 drivers/w1/w1_family.c - 1.1 scripts/mod/modpost.c - 1.1 arch/arm/common/locomo.c - 1.1 drivers/w1/w1_family.h - 1.1 drivers/char/ip27-rtc.c - 1.1 drivers/char/hvcs.c - 1.1 arch/arm/common/time-acorn.c - 1.1 drivers/char/hpet.c - 1.1 drivers/char/ds1286.c - 1.1 drivers/w1/w1_int.c - 1.1 drivers/w1/w1_int.h - 1.1 drivers/w1/w1_io.c - 1.1 scripts/mod/mk_elfconfig.c - 1.1 drivers/w1/w1_io.h - 1.1 drivers/w1/w1_log.h - 1.1 drivers/block/sx8.c - 1.1 drivers/w1/w1_netlink.c - 1.1 drivers/w1/w1_netlink.h - 1.1 drivers/w1/w1_therm.c - 1.1 fs/isofs/export.c - 1.1 crypto/tea.c - 1.1 crypto/khazad.c - 1.1 fs/jffs2/compr.h - 1.1 arch/sparc64/mm/tlb.c - 1.1 fs/nls/nls_ascii.c - 1.1 fs/ntfs/collate.c - 1.1 arch/sparc64/lib/copy_page.S - 1.1 arch/sparc64/lib/clear_page.S - 1.1 arch/sh64/oprofile/op_model_null.c - 1.1 arch/sh64/oprofile/Makefile - 1.1 arch/sh64/oprofile/Kconfig - 1.1 arch/sh64/mm/tlbmiss.c - 1.1 scripts/mod/file2alias.c - 1.1 arch/sh64/mm/tlb.c - 1.1 arch/sh64/mm/ioremap.c - 1.1 scripts/mod/empty.c - 1.1 scripts/mod/Makefile - 1.1 arch/sh64/mm/init.c - 1.1 scripts/mkmakefile - 1.1 arch/sh64/mm/hugetlbpage.c - 1.1 net/sched/sch_netem.c - 1.1 arch/sh64/mm/fault.c - 1.1 arch/sh64/mm/extable.c - 1.1 arch/sh64/mm/cache.c - 1.1 arch/sh64/mm/Makefile - 1.1 arch/sh64/mach-sim/setup.c - 1.1 arch/sh64/mach-sim/Makefile - 1.1 arch/sh64/mach-romram/setup.c - 1.1 arch/sh64/mach-romram/Makefile - 1.1 net/sched/act_api.c - 1.1 arch/sh64/mach-harp/setup.c - 1.1 arch/sh64/mach-harp/Makefile - 1.1 net/ipv6/xfrm6_tunnel.c - 1.1 arch/sh64/mach-cayman/setup.c - 1.1 arch/sh64/mach-cayman/led.c - 1.1 arch/sh64/mach-cayman/irq.c - 1.1 net/ipv6/xfrm6_output.c - 1.1 arch/sh64/mach-cayman/Makefile - 1.1 arch/sh64/lib/udelay.c - 1.1 arch/sh64/lib/panic.c - 1.1 arch/sh64/lib/page_copy.S - 1.1 arch/sh64/lib/page_clear.S - 1.1 arch/sh64/lib/old-checksum.c - 1.1 arch/sh64/lib/memcpy.c - 1.1 arch/sh64/lib/io.c - 1.1 arch/sh64/lib/dbg.c - 1.1 arch/sh64/lib/copy_user_memcpy.S - 1.1 arch/sh64/lib/c-checksum.c - 1.1 arch/sh64/lib/Makefile - 1.1 arch/sh64/kernel/vmlinux.lds.S - 1.1 arch/sh64/kernel/unwind.c - 1.1 arch/sh64/kernel/traps.c - 1.1 arch/sh64/kernel/time.c - 1.1 arch/sh64/kernel/syscalls.S - 1.1 arch/sh64/kernel/sys_sh64.c - 1.1 arch/sh64/kernel/switchto.S - 1.1 arch/sh64/kernel/signal.c - 1.1 arch/sh64/kernel/sh_ksyms.c - 1.1 arch/sh64/kernel/setup.c - 1.1 arch/sh64/kernel/semaphore.c - 1.1 arch/sh64/kernel/ptrace.c - 1.1 arch/sh64/kernel/process.c - 1.1 arch/sh64/kernel/pcibios.c - 1.1 arch/sh64/kernel/pci_sh5.h - 1.1 arch/sh64/kernel/pci_sh5.c - 1.1 arch/sh64/kernel/pci-dma.c - 1.1 arch/sh64/kernel/led.c - 1.1 arch/sh64/kernel/irq_intc.c - 1.1 arch/sh64/kernel/irq.c - 1.1 arch/sh64/kernel/init_task.c - 1.1 arch/sh64/kernel/head.S - 1.1 arch/sh64/kernel/fpu.c - 1.1 arch/sh64/kernel/entry.S - 1.1 arch/sh64/kernel/early_printk.c - 1.1 arch/sh64/kernel/dma.c - 1.1 arch/sh64/kernel/asm-offsets.c - 1.1 arch/sh64/kernel/alphanum.c - 1.1 arch/sh64/kernel/Makefile - 1.1 arch/arm/mach-footbridge/time.c - 1.1 arch/sh64/defconfig - 1.1 arch/sh64/configs/cayman_defconfig - 1.1 arch/sh64/boot/compressed/vmlinux.lds.S - 1.1 arch/sh64/boot/compressed/misc.c - 1.1 arch/sh64/boot/compressed/install.sh - 1.1 arch/arm/mach-integrator/clock.c - 1.1 arch/arm/mach-integrator/clock.h - 1.1 arch/sh64/boot/compressed/cache.c - 1.1 arch/sh64/boot/compressed/Makefile - 1.1 arch/sh64/boot/Makefile - 1.1 net/ipv4/xfrm4_output.c - 1.1 arch/sh64/Makefile - 1.1 arch/sh64/Kconfig - 1.1 net/ipv4/netfilter/ipt_realm.c - 1.1 net/ipv4/netfilter/ipt_addrtype.c - 1.1 net/ipv4/datagram.c - 1.1 net/core/stream.c - 1.1 net/bluetooth/hidp/sock.c - 1.1 net/bluetooth/hidp/hidp.h - 1.1 net/bluetooth/hidp/core.c - 1.1 net/bluetooth/hidp/Makefile - 1.1 net/bluetooth/hidp/Kconfig - 1.1 lib/crc-ccitt.c - 1.1 kernel/power/smp.c - 1.1 arch/arm/mach-lh7a40x/time.c - 1.1 include/scsi/scsi_dbg.h - 1.1 include/net/pkt_act.h - 1.1 include/net/ip6_checksum.h - 1.1 include/mtd/nftl-user.h - 1.1 include/mtd/mtd-user.h - 1.1 include/mtd/mtd-abi.h - 1.1 include/mtd/jffs2-user.h - 1.1 arch/arm/mach-omap/time.c - 1.1 arch/sh/ramdisk/ld.script - 1.1 arch/sh/ramdisk/Makefile - 1.1 fs/ntfs/collate.h - 1.1 arch/sh/kernel/early_printk.c - 1.1 fs/ntfs/index.c - 1.1 include/mtd/inftl-user.h - 1.1 arch/arm/mach-pxa/time.c - 1.1 fs/ntfs/index.h - 1.1 include/media/ovcamchip.h - 1.1 include/linux/snmp.h - 1.1 arch/arm/mach-s3c2410/gpio.c - 1.1 include/linux/netfilter_ipv4/ipt_realm.h - 1.1 include/linux/netfilter_ipv4/ipt_addrtype.h - 1.1 include/linux/mtd/physmap.h - 1.1 include/linux/hpet.h - 1.1 include/linux/ds1286.h - 1.1 arch/arm/mach-s3c2410/time.c - 1.1 fs/ntfs/quota.c - 1.1 arch/sh/kernel/cpu/bus.c - 1.1 arch/sh/kernel/cpu/adc.c - 1.1 fs/ntfs/quota.h - 1.1 include/asm-alpha/setup.h - 1.1 include/asm-arm/arch-sa1100/collie.h - 1.1 include/asm-arm/hardware/clock.h - 1.1 arch/arm/mach-sa1100/collie.c - 1.1 include/asm-arm/hardware/locomo.h - 1.1 arch/sh/drivers/pci/ops-rts7751r2d.c - 1.1 arch/sh/drivers/pci/fixups-rts7751r2d.c - 1.1 include/asm-arm/mach/time.h - 1.1 arch/sh/drivers/dma/dma-sysfs.c - 1.1 include/asm-arm/vfp.h - 1.1 include/asm-arm/vfpmacros.h - 1.1 include/asm-i386/pgtable-2level-defs.h - 1.1 include/asm-i386/pgtable-3level-defs.h - 1.1 include/asm-ia64/setup.h - 1.1 include/asm-mips/gt64240.h - 1.1 arch/sh/configs/se7300_defconfig - 1.1 arch/sh/configs/rts7751r2d_defconfig - 1.1 include/asm-mips/mach-yosemite/cpu-feature-overrides.h - 1.1 arch/sh/cchips/voyagergx/setup.c - 1.1 arch/sh/cchips/voyagergx/irq.c - 1.1 arch/sh/cchips/voyagergx/consistent.c - 1.1 arch/sh/cchips/voyagergx/Makefile - 1.1 include/asm-mips/marvell.h - 1.1 include/asm-mips/setup.h - 1.1 include/asm-mips/vr41xx/tb0219.h - 1.1 include/asm-parisc/numnodes.h - 1.1 arch/arm/mach-sa1100/time.c - 1.1 include/asm-ppc/cpm2.h - 1.1 arch/sh/boards/se/7300/setup.c - 1.1 arch/sh/boards/se/7300/led.c - 1.1 arch/sh/boards/se/7300/irq.c - 1.1 arch/sh/boards/se/7300/io.c - 1.1 arch/sh/boards/se/7300/Makefile - 1.1 include/linux/dmi.h - 1.1 arch/arm/mach-versatile/clock.c - 1.1 arch/arm/mach-versatile/clock.h - 1.1 include/linux/crc-ccitt.h - 1.1 arch/sh/boards/renesas/systemh/setup.c - 1.1 include/asm-v850/setup.h - 1.1 arch/sh/boards/renesas/systemh/irq.c - 1.1 include/asm-um/setup.h - 1.1 arch/sh/boards/renesas/systemh/io.c - 1.1 arch/sh/boards/renesas/systemh/Makefile - 1.1 arch/sh/boards/renesas/rts7751r2d/setup.c - 1.1 arch/sh/boards/renesas/rts7751r2d/mach.c - 1.1 arch/sh/boards/renesas/rts7751r2d/led.c - 1.1 arch/sh/boards/renesas/rts7751r2d/irq.c - 1.1 arch/sh/boards/renesas/rts7751r2d/io.c - 1.1 arch/arm/vfp/Makefile - 1.1 arch/arm/vfp/entry.S - 1.1 arch/arm/vfp/vfp.h - 1.1 arch/arm/vfp/vfpdouble.c - 1.1 arch/arm/vfp/vfphw.S - 1.1 arch/arm/vfp/vfpinstr.h - 1.1 arch/arm/vfp/vfpmodule.c - 1.1 arch/arm/vfp/vfpsingle.c - 1.1 arch/sh/boards/renesas/rts7751r2d/Makefile - 1.1 arch/sh/boards/renesas/hs7751rvoip/setup.c - 1.1 arch/sh/boards/renesas/hs7751rvoip/pci.c - 1.1 arch/sh/boards/renesas/hs7751rvoip/mach.c - 1.1 arch/sh/boards/renesas/hs7751rvoip/led.c - 1.1 arch/sh/boards/renesas/hs7751rvoip/irq.c - 1.1 arch/sh/boards/renesas/hs7751rvoip/io.c - 1.1 arch/sh/boards/renesas/hs7751rvoip/Makefile - 1.1 include/asm-ppc/fsl_ocp.h - 1.1 include/asm-ppc/immap_85xx.h - 1.1 arch/s390/kernel/vtime.c - 1.1 include/asm-ppc/immap_cpm2.h - 1.1 include/asm-ppc/m8260_pci.h - 1.1 include/asm-ppc/mpc52xx.h - 1.1 include/asm-ppc/mpc52xx_psc.h - 1.1 include/asm-ppc/mpc8260_pci9.h - 1.1 arch/ppc64/mm/slb_low.S - 1.1 include/asm-sparc64/cmt.h - 1.1 arch/ppc64/mm/slb.c - 1.1 include/asm-ppc/mpc85xx.h - 1.1 arch/ppc64/lib/usercopy.c - 1.1 include/asm-sh64/user.h - 1.1 include/asm-ppc/ppc4xx_dma.h - 1.1 arch/ppc64/lib/e2a.c - 1.1 include/asm-ppc/rheap.h - 1.1 include/asm-ppc64/hvcserver.h - 1.1 arch/ppc64/kernel/vector.S - 1.1 arch/ppc64/kernel/vecemu.c - 1.1 include/asm-sh/adc.h - 1.1 include/asm-sh/bus-sh.h - 1.1 include/asm-sh/cpu-sh3/adc.h - 1.1 include/asm-sh/fixmap.h - 1.1 include/asm-sh/hp6xx/ide.h - 1.1 arch/i386/crypto/Makefile - 1.1 arch/i386/crypto/aes-i586-asm.S - 1.1 arch/i386/crypto/aes.c - 1.1 include/asm-sh/hs7751rvoip/hs7751rvoip.h - 1.1 include/asm-sh64/unistd.h - 1.1 include/asm-sh64/unaligned.h - 1.1 include/asm-sh64/ucontext.h - 1.1 include/asm-sh64/uaccess.h - 1.1 include/asm-sh64/types.h - 1.1 include/asm-sh64/topology.h - 1.1 include/asm-sh64/tlbflush.h - 1.1 include/asm-sh64/tlb.h - 1.1 include/asm-sh64/timex.h - 1.1 include/asm-sh64/thread_info.h - 1.1 include/asm-sh/hs7751rvoip/ide.h - 1.1 arch/ppc64/kernel/hvcserver.c - 1.1 include/asm-sh/hs7751rvoip/io.h - 1.1 include/asm-sh/rts7751r2d/ide.h - 1.1 include/asm-sh/rts7751r2d/io.h - 1.1 include/asm-sh/rts7751r2d/rts7751r2d.h - 1.1 include/asm-sh/rts7751r2d/voyagergx_reg.h - 1.1 arch/ppc/syslib/ppc85xx_setup.h - 1.1 arch/ppc/syslib/ppc85xx_setup.c - 1.1 arch/ppc/syslib/ppc85xx_common.h - 1.1 arch/ppc/syslib/ppc85xx_common.c - 1.1 arch/ppc/syslib/ppc4xx_sgdma.c - 1.1 include/asm-sh64/termios.h - 1.1 arch/ppc/syslib/mpc52xx_setup.c - 1.1 arch/ppc/syslib/mpc52xx_pic.c - 1.1 arch/ppc/syslib/m8260_pci_erratum9.c - 1.1 arch/ppc/syslib/m8260_pci.h - 1.1 arch/ppc/syslib/m8260_pci.c - 1.1 arch/ppc/syslib/cpm2_pic.h - 1.1 arch/ppc/syslib/cpm2_pic.c - 1.1 arch/ppc/syslib/cpm2_common.c - 1.1 include/asm-sh/se7300/io.h - 1.1 include/asm-sh/se7300/se7300.h - 1.1 arch/ppc/platforms/rpx8260.h - 1.1 arch/ppc/platforms/rpx8260.c - 1.1 arch/ppc/platforms/pq2ads_setup.c - 1.1 arch/ppc/platforms/pq2ads.h - 1.1 include/asm-sh/setup.h - 1.1 arch/ppc/platforms/mpc5200.c - 1.1 arch/ppc/platforms/lite5200.h - 1.1 arch/ppc/platforms/lite5200.c - 1.1 arch/ppc/platforms/85xx/sbc85xx.h - 1.1 arch/ppc/platforms/85xx/sbc85xx.c - 1.1 include/asm-sh64/termbits.h - 1.1 arch/ppc/platforms/85xx/sbc8560.h - 1.1 arch/ppc/platforms/85xx/sbc8560.c - 1.1 arch/ppc/platforms/85xx/mpc85xx_cds_common.h - 1.1 arch/ppc/platforms/85xx/mpc85xx_cds_common.c - 1.1 include/asm-sh64/system.h - 1.1 arch/ppc/platforms/85xx/mpc85xx_ads_common.h - 1.1 arch/ppc/platforms/85xx/mpc85xx_ads_common.c - 1.1 arch/ppc/platforms/85xx/mpc8560_ads.h - 1.1 arch/ppc/platforms/85xx/mpc8560_ads.c - 1.1 arch/i386/lib/bitops.c - 1.1 arch/ppc/platforms/85xx/mpc8560.c - 1.1 arch/ppc/platforms/85xx/mpc8555_cds.h - 1.1 arch/ppc/platforms/85xx/mpc8555.c - 1.1 arch/ppc/platforms/85xx/mpc8540_ads.h - 1.1 arch/ppc/platforms/85xx/mpc8540_ads.c - 1.1 arch/ppc/platforms/85xx/mpc8540.c - 1.1 include/asm-sh64/string.h - 1.1 arch/ppc/platforms/85xx/Makefile - 1.1 arch/ppc/platforms/85xx/Kconfig - 1.1 arch/ppc/oprofile/init.c - 1.1 arch/ppc/oprofile/Makefile - 1.1 arch/ppc/oprofile/Kconfig - 1.1 arch/ppc/mm/fsl_booke_mmu.c - 1.1 arch/ppc/lib/rheap.c - 1.1 include/asm-sh64/a.out.h - 1.1 arch/ppc/kernel/head_e500.S - 1.1 include/asm-sh64/atomic.h - 1.1 arch/ppc/configs/rpx8260_defconfig - 1.1 arch/ppc/configs/lite5200_defconfig - 1.1 include/asm-sh64/bitops.h - 1.1 arch/ppc/configs/ads8272_defconfig - 1.1 arch/ppc/boot/simple/mpc52xx_tty.c - 1.1 arch/parisc/lib/debuglocks.c - 1.1 include/asm-sh64/bug.h - 1.1 arch/parisc/configs/n4000_defconfig - 1.1 include/asm-sh64/bugs.h - 1.1 include/asm-sh64/byteorder.h - 1.1 include/asm-sh64/cache.h - 1.1 arch/mips/vr41xx/tanbac-tb0229/tb0219.c - 1.1 include/asm-sh64/cacheflush.h - 1.1 include/asm-sh64/cayman.h - 1.1 include/asm-sh64/checksum.h - 1.1 include/asm-sh64/cpumask.h - 1.1 include/asm-sh64/current.h - 1.1 include/asm-sh64/delay.h - 1.1 arch/mips/pmc-sierra/yosemite/py-console.c - 1.1 include/asm-sh64/div64.h - 1.1 include/asm-sh64/dma-mapping.h - 1.1 include/asm-sh64/dma.h - 1.1 include/asm-sh64/elf.h - 1.1 include/asm-sh64/errno.h - 1.1 include/asm-sh64/statfs.h - 1.1 include/asm-sh64/stat.h - 1.1 include/asm-sh64/spinlock.h - 1.1 include/asm-sh64/softirq.h - 1.1 arch/mips/pmc-sierra/yosemite/dbg_io.c - 1.1 include/asm-sh64/fcntl.h - 1.1 arch/mips/pci/pci-yosemite.c - 1.1 arch/mips/pci/ops-vr41xx.c - 1.1 include/asm-sh64/hardirq.h - 1.1 arch/mips/pci/ops-titan-ht.c - 1.1 include/asm-sh64/hardware.h - 1.1 include/asm-sh64/hdreg.h - 1.1 arch/mips/pci/ops-marvell.c - 1.1 include/asm-sh64/hw_irq.h - 1.1 include/asm-sh64/sockios.h - 1.1 arch/mips/pci/fixup-tb0219.c - 1.1 arch/mips/pci/fixup-ocelot-g.c - 1.1 arch/mips/pci/fixup-ocelot-c.c - 1.1 include/asm-sh64/ide.h - 1.1 arch/mips/pci/fixup-mpc30x.c - 1.1 arch/mips/pci/fixup-jaguar.c - 1.1 include/asm-sh64/io.h - 1.1 include/asm-sh64/ioctl.h - 1.1 include/asm-sh64/ioctls.h - 1.1 arch/mips/mm/tlbex64-r4k.S - 1.1 arch/mips/mm/tlbex32-r4k.S - 1.1 arch/mips/mm/tlbex32-r3k.S - 1.1 arch/mips/mm/tlb64-glue-sb1.S - 1.1 arch/mips/mm/tlb64-glue-r4k.S - 1.1 arch/mips/mm/tlb-r8k.c - 1.1 arch/mips/kernel/module.c - 1.1 include/asm-sh64/ipc.h - 1.1 include/asm-sh64/ipcbuf.h - 1.1 include/asm-sh64/irq.h - 1.1 include/asm-sh64/keyboard.h - 1.1 include/asm-sh64/kmap_types.h - 1.1 include/asm-sh64/linkage.h - 1.1 include/asm-sh64/local.h - 1.1 include/asm-sh64/mc146818rtc.h - 1.1 include/asm-sh64/mman.h - 1.1 include/asm-sh64/mmu.h - 1.1 include/asm-sh64/mmu_context.h - 1.1 include/asm-sh64/module.h - 1.1 include/asm-sh64/msgbuf.h - 1.1 include/asm-sh64/namei.h - 1.1 include/asm-sh64/page.h - 1.1 arch/mips/configs/ocelot_g_defconfig - 1.1 include/asm-sh64/param.h - 1.1 include/asm-sh64/pci.h - 1.1 include/asm-sh64/percpu.h - 1.1 include/asm-sh64/pgalloc.h - 1.1 include/asm-sh64/pgtable.h - 1.1 include/asm-sh64/platform.h - 1.1 include/asm-sh64/poll.h - 1.1 include/asm-sh64/posix_types.h - 1.1 include/asm-sh64/processor.h - 1.1 include/asm-sh64/ptrace.h - 1.1 include/asm-sh64/registers.h - 1.1 include/asm-sh64/resource.h - 1.1 include/asm-sh64/scatterlist.h - 1.1 include/asm-sh64/sections.h - 1.1 include/asm-sh64/segment.h - 1.1 include/asm-sh64/semaphore-helper.h - 1.1 include/asm-sh64/semaphore.h - 1.1 include/asm-sh64/sembuf.h - 1.1 include/asm-sh64/serial.h - 1.1 include/asm-sh64/setup.h - 1.1 include/asm-sh64/shmbuf.h - 1.1 include/asm-sh64/shmparam.h - 1.1 include/asm-sh64/sigcontext.h - 1.1 include/asm-sh64/siginfo.h - 1.1 include/asm-sh64/signal.h - 1.1 include/asm-sh64/smp.h - 1.1 include/asm-sh64/smplock.h - 1.1 include/asm-sh64/socket.h - 1.1 CREDITS - 1.9 Documentation/DMA-API.txt - 1.4 Documentation/DMA-mapping.txt - 1.4 Documentation/IPMI.txt - 1.3 Documentation/SubmittingDrivers - 1.6 Documentation/arm/Booting - 1.2 Documentation/as-iosched.txt - 1.3 Documentation/basic_profiling.txt - 1.2 Documentation/binfmt_misc.txt - 1.2 Documentation/cachetlb.txt - 1.3 Documentation/cdrom/aztcd - 1.2 Documentation/computone.txt - 1.4 Documentation/crypto/api-intro.txt - 1.4 Documentation/devices.txt - 1.4 Documentation/digiepca.txt - 1.2 Documentation/filesystems/Locking - 1.4 Documentation/filesystems/hpfs.txt - 1.2 Documentation/filesystems/ntfs.txt - 1.5 Documentation/filesystems/proc.txt - 1.5 Documentation/filesystems/udf.txt - 1.3 Documentation/filesystems/vfat.txt - 1.2 Documentation/i2c/i2c-pport - 1.2 Documentation/i2c/i2c-velleman - 1.3 Documentation/i386/boot.txt - 1.2 Documentation/i386/zero-page.txt - 1.6 Documentation/ioctl-number.txt - 1.3 Documentation/kbuild/modules.txt - 1.4 Documentation/kernel-parameters.txt - 1.9 Documentation/locks.txt - 1.2 Documentation/networking/00-INDEX - 1.3 Documentation/networking/Configurable - 1.2 Documentation/networking/comx.txt - 1.2 Documentation/networking/ip-sysctl.txt - 1.8 Documentation/networking/pktgen.txt - 1.2 Documentation/nmi_watchdog.txt - 1.2 Documentation/parisc/debugging - 1.2 Documentation/parisc/registers - 1.2 Documentation/pci.txt - 1.2 Documentation/pnp.txt - 1.2 Documentation/power/pci.txt - 1.2 Documentation/power/swsusp.txt - 1.4 Documentation/s390/3270.txt - 1.3 Documentation/scsi/scsi_mid_low_api.txt - 1.3 Documentation/sh/new-machine.txt - 1.4 Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.6 Documentation/sound/oss/INSTALL.awe - 1.3 Documentation/sound/oss/Introduction - 1.4 Documentation/sound/oss/PAS16 - 1.4 Documentation/sysctl/README - 1.2 Documentation/sysctl/vm.txt - 1.4 Documentation/usb/URB.txt - 1.2 Documentation/usb/error-codes.txt - 1.3 Documentation/usb/philips.txt - 1.2 Documentation/usb/usb-help.txt - 1.2 Documentation/video4linux/Zoran - 1.3 MAINTAINERS - 1.10 Makefile - 1.21 README - 1.4 arch/alpha/Makefile - 1.3 arch/alpha/defconfig - 1.4 arch/alpha/kernel/core_tsunami.c - 1.3 arch/alpha/kernel/entry.S - 1.2 arch/alpha/kernel/init_task.c - 1.2 arch/alpha/kernel/irq.c - 1.6 arch/alpha/kernel/osf_sys.c - 1.5 arch/alpha/kernel/process.c - 1.4 arch/alpha/kernel/setup.c - 1.4 arch/alpha/kernel/signal.c - 1.5 arch/alpha/kernel/smc37c669.c - 1.2 arch/alpha/kernel/smp.c - 1.4 arch/alpha/kernel/srm_env.c - 1.3 arch/alpha/kernel/sys_dp264.c - 1.2 arch/alpha/kernel/time.c - 1.5 arch/alpha/kernel/traps.c - 1.4 arch/alpha/mm/fault.c - 1.3 arch/alpha/mm/init.c - 1.3 arch/alpha/mm/numa.c - 1.4 arch/arm/Kconfig - 1.7 arch/arm/Makefile - 1.7 arch/arm/boot/Makefile - 1.5 arch/arm/boot/bootp/Makefile - 1.2 arch/arm/boot/bootp/bootp.lds - 1.2 arch/arm/boot/bootp/init.S - 1.2 arch/arm/boot/compressed/Makefile - 1.5 arch/arm/boot/compressed/head-clps7500.S - 1.2 arch/arm/boot/compressed/head-ftvpci.S - 1.2 arch/arm/boot/compressed/head-sa1100.S - 1.2 arch/arm/boot/compressed/head-xscale.S - 1.2 arch/arm/boot/compressed/head.S - 1.6 arch/arm/boot/compressed/vmlinux.lds.in - 1.2 arch/arm/boot/install.sh - 1.2 arch/arm/common/Makefile - 1.4 arch/arm/common/platform.c - 1.2 arch/arm/common/plx90x0.c - 1.2 arch/arm/common/sa1111.c - 1.6 arch/arm/configs/a5k_defconfig - 1.3 arch/arm/configs/adi_evb_defconfig - 1.3 arch/arm/configs/adsbitsy_defconfig - 1.3 arch/arm/configs/assabet_defconfig - 1.4 arch/arm/configs/badge4_defconfig - 1.3 arch/arm/configs/cerfcube_defconfig - 1.4 arch/arm/configs/clps7500_defconfig - 1.3 arch/arm/configs/ebsa110_defconfig - 1.4 arch/arm/configs/edb7211_defconfig - 1.2 arch/arm/configs/empeg_defconfig - 1.2 arch/arm/configs/epxa10db_defconfig - 1.4 arch/arm/configs/flexanet_defconfig - 1.3 arch/arm/configs/footbridge_defconfig - 1.4 arch/arm/configs/fortunet_defconfig - 1.3 arch/arm/configs/freebird_defconfig - 1.2 arch/arm/configs/freebird_new_defconfig - 1.2 arch/arm/configs/graphicsclient_defconfig - 1.3 arch/arm/configs/graphicsmaster_defconfig - 1.3 arch/arm/configs/h3600_defconfig - 1.3 arch/arm/configs/hackkit_defconfig - 1.3 arch/arm/configs/huw_webpanel_defconfig - 1.2 arch/arm/configs/integrator_defconfig - 1.3 arch/arm/configs/iq80310_defconfig - 1.3 arch/arm/configs/iq80321_defconfig - 1.4 arch/arm/configs/jornada720_defconfig - 1.3 arch/arm/configs/lart_defconfig - 1.3 arch/arm/configs/lubbock_defconfig - 1.4 arch/arm/configs/neponset_defconfig - 1.4 arch/arm/configs/omnimeter_defconfig - 1.2 arch/arm/configs/pangolin_defconfig - 1.3 arch/arm/configs/pfs168_mqtft_defconfig - 1.3 arch/arm/configs/pfs168_mqvga_defconfig - 1.3 arch/arm/configs/pfs168_sastn_defconfig - 1.3 arch/arm/configs/pfs168_satft_defconfig - 1.3 arch/arm/configs/pleb_defconfig - 1.3 arch/arm/configs/rpc_defconfig - 1.3 arch/arm/configs/shannon_defconfig - 1.3 arch/arm/configs/shark_defconfig - 1.4 arch/arm/configs/stork_defconfig - 1.3 arch/arm/configs/system3_defconfig - 1.3 arch/arm/configs/trizeps_defconfig - 1.3 arch/arm/defconfig - 1.2 arch/arm/kernel/Makefile - 1.4 arch/arm/kernel/apm.c - 1.2 arch/arm/kernel/asm-offsets.c - 1.4 arch/arm/kernel/debug.S - 1.5 arch/arm/kernel/ecard.c - 1.3 arch/arm/kernel/entry-armv.S - 1.6 arch/arm/kernel/entry-common.S - 1.3 arch/arm/kernel/entry-header.S - 1.3 arch/arm/kernel/head.S - 1.2 arch/arm/kernel/init_task.c - 1.2 arch/arm/kernel/io.c - 1.2 arch/arm/kernel/irq.c - 1.5 arch/arm/kernel/process.c - 1.6 arch/arm/kernel/ptrace.c - 1.5 arch/arm/kernel/setup.c - 1.6 arch/arm/kernel/signal.c - 1.4 arch/arm/kernel/sys_arm.c - 1.6 arch/arm/kernel/time-acorn.c - 1.2 arch/arm/kernel/time.c - 1.5 arch/arm/kernel/traps.c - 1.5 arch/arm/lib/ecard.S - 1.2 arch/arm/mach-adifcc/Makefile - 1.2 arch/arm/mach-adifcc/arch.c - 1.2 arch/arm/mach-adifcc/irq.c - 1.3 arch/arm/mach-adifcc/mm.c - 1.2 arch/arm/mach-clps711x/autcpu12.c - 1.2 arch/arm/mach-clps711x/cdb89712.c - 1.2 arch/arm/mach-clps711x/ceiva.c - 1.2 arch/arm/mach-clps711x/clep7312.c - 1.3 arch/arm/mach-clps711x/edb7211-arch.c - 1.2 arch/arm/mach-clps711x/fortunet.c - 1.3 arch/arm/mach-clps711x/p720t.c - 1.2 arch/arm/mach-clps711x/time.c - 1.3 arch/arm/mach-clps7500/core.c - 1.2 arch/arm/mach-ebsa110/core.c - 1.2 arch/arm/mach-ebsa110/io.c - 1.3 arch/arm/mach-epxa10db/arch.c - 1.2 arch/arm/mach-epxa10db/time.c - 1.2 arch/arm/mach-footbridge/Makefile - 1.2 arch/arm/mach-footbridge/arch.c - 1.2 arch/arm/mach-ftvpci/Makefile - 1.2 arch/arm/mach-ftvpci/core.c - 1.2 arch/arm/mach-ftvpci/leds.c - 1.2 arch/arm/mach-ftvpci/pci.c - 1.2 arch/arm/mach-integrator/Makefile - 1.3 arch/arm/mach-integrator/core.c - 1.4 arch/arm/mach-integrator/impd1.c - 1.3 arch/arm/mach-integrator/integrator_ap.c - 1.5 arch/arm/mach-iop3xx/arch.c - 1.2 arch/arm/mach-iop3xx/iop321-time.c - 1.3 arch/arm/mach-pxa/Makefile - 1.3 arch/arm/mach-pxa/generic.c - 1.4 arch/arm/mach-pxa/generic.h - 1.2 arch/arm/mach-pxa/idp.c - 1.5 arch/arm/mach-pxa/lubbock.c - 1.6 arch/arm/mach-rpc/riscpc.c - 1.2 arch/arm/mach-sa1100/Kconfig - 1.6 arch/arm/mach-sa1100/Makefile - 1.2 arch/arm/mach-sa1100/adsbitsy.c - 1.3 arch/arm/mach-sa1100/assabet.c - 1.3 arch/arm/mach-sa1100/badge4.c - 1.3 arch/arm/mach-sa1100/brutus.c - 1.2 arch/arm/mach-sa1100/cerf.c - 1.3 arch/arm/mach-sa1100/empeg.c - 1.2 arch/arm/mach-sa1100/flexanet.c - 1.2 arch/arm/mach-sa1100/freebird.c - 1.2 arch/arm/mach-sa1100/generic.h - 1.3 arch/arm/mach-sa1100/graphicsclient.c - 1.2 arch/arm/mach-sa1100/graphicsmaster.c - 1.3 arch/arm/mach-sa1100/h3600.c - 1.3 arch/arm/mach-sa1100/hackkit.c - 1.2 arch/arm/mach-sa1100/huw_webpanel.c - 1.2 arch/arm/mach-sa1100/itsy.c - 1.2 arch/arm/mach-sa1100/jornada720.c - 1.3 arch/arm/mach-sa1100/lart.c - 1.2 arch/arm/mach-sa1100/nanoengine.c - 1.2 arch/arm/mach-sa1100/omnimeter.c - 1.2 arch/arm/mach-sa1100/pangolin.c - 1.2 arch/arm/mach-sa1100/pfs168.c - 1.3 arch/arm/mach-sa1100/pleb.c - 1.2 arch/arm/mach-sa1100/shannon.c - 1.2 arch/arm/mach-sa1100/sherman.c - 1.2 arch/arm/mach-sa1100/simpad.c - 1.2 arch/arm/mach-sa1100/stork.c - 1.2 arch/arm/mach-sa1100/system3.c - 1.3 arch/arm/mach-sa1100/trizeps.c - 1.2 arch/arm/mach-sa1100/xp860.c - 1.3 arch/arm/mach-sa1100/yopy.c - 1.2 arch/arm/mach-shark/core.c - 1.2 arch/arm/mach-tbox/Makefile - 1.2 arch/arm/mach-tbox/core.c - 1.2 arch/arm/mm/Kconfig - 1.7 arch/arm/mm/consistent.c - 1.4 arch/arm/mm/init.c - 1.4 arch/arm/mm/proc-sa1100.S - 1.2 arch/arm/nwfpe/fpa11.h - 1.2 arch/arm/nwfpe/fpa11_cpdt.c - 1.2 arch/arm/nwfpe/fpmodule.c - 1.3 arch/arm/nwfpe/fpmodule.inl - 1.2 arch/arm/tools/mach-types - 1.6 arch/arm26/kernel/init_task.c - 1.2 arch/arm26/kernel/irq.c - 1.3 arch/arm26/kernel/setup.c - 1.2 arch/arm26/mm/init.c - 1.2 arch/cris/arch-v10/defconfig - 1.3 arch/cris/arch-v10/kernel/time.c - 1.3 arch/cris/defconfig - 1.3 arch/cris/kernel/irq.c - 1.4 arch/cris/kernel/process.c - 1.4 arch/cris/kernel/setup.c - 1.3 arch/cris/mm/init.c - 1.3 arch/h8300/Kconfig - 1.7 arch/h8300/defconfig - 1.3 arch/h8300/kernel/init_task.c - 1.2 arch/h8300/kernel/ptrace.c - 1.3 arch/h8300/kernel/setup.c - 1.5 arch/h8300/platform/h8s/entry.S - 1.5 arch/i386/Kconfig - 1.13 arch/i386/Makefile - 1.9 arch/i386/boot/compressed/misc.c - 1.3 arch/i386/boot98/Makefile - 1.2 arch/i386/boot98/bootsect.S - 1.2 arch/i386/boot98/compressed/Makefile - 1.2 arch/i386/boot98/compressed/head.S - 1.2 arch/i386/boot98/compressed/misc.c - 1.2 arch/i386/boot98/compressed/vmlinux.scr - 1.2 arch/i386/boot98/install.sh - 1.2 arch/i386/boot98/mtools.conf.in - 1.2 arch/i386/boot98/setup.S - 1.3 arch/i386/boot98/tools/build.c - 1.2 arch/i386/boot98/video.S - 1.2 arch/i386/defconfig - 1.8 arch/i386/kernel/Makefile - 1.6 arch/i386/kernel/acpi/boot.c - 1.11 arch/i386/kernel/apic.c - 1.4 arch/i386/kernel/apm.c - 1.6 arch/i386/kernel/cpu/common.c - 1.5 arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.7 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c - 1.5 arch/i386/kernel/cpu/mtrr/generic.c - 1.3 arch/i386/kernel/cpu/mtrr/if.c - 1.3 arch/i386/kernel/cpu/proc.c - 1.3 arch/i386/kernel/cpuid.c - 1.4 arch/i386/kernel/dmi_scan.c - 1.7 arch/i386/kernel/head.S - 1.6 arch/i386/kernel/i386_ksyms.c - 1.4 arch/i386/kernel/i8259.c - 1.12 arch/i386/kernel/init_task.c - 1.3 arch/i386/kernel/io_apic.c - 1.14 arch/i386/kernel/irq.c - 1.6 arch/i386/kernel/ldt.c - 1.2 arch/i386/kernel/microcode.c - 1.4 arch/i386/kernel/module.c - 1.2 arch/i386/kernel/mpparse.c - 1.10 arch/i386/kernel/msr.c - 1.4 arch/i386/kernel/numaq.c - 1.2 arch/i386/kernel/process.c - 1.8 arch/i386/kernel/reboot.c - 1.10 arch/i386/kernel/scx200.c - 1.3 arch/i386/kernel/setup.c - 1.9 arch/i386/kernel/signal.c - 1.5 arch/i386/kernel/smp.c - 1.9 arch/i386/kernel/smpboot.c - 1.12 arch/i386/kernel/srat.c - 1.2 arch/i386/kernel/sys_i386.c - 1.3 arch/i386/kernel/sysenter.c - 1.2 arch/i386/kernel/time_hpet.c - 1.3 arch/i386/kernel/timers/timer_none.c - 1.3 arch/i386/kernel/timers/timer_tsc.c - 1.7 arch/i386/kernel/traps.c - 1.11 arch/i386/kernel/vm86.c - 1.4 arch/i386/lib/Makefile - 1.3 arch/i386/lib/delay.c - 1.2 arch/i386/lib/memcpy.c - 1.2 arch/i386/lib/usercopy.c - 1.4 arch/i386/mach-default/setup.c - 1.3 arch/i386/mach-pc9800/Makefile - 1.4 arch/i386/mach-pc9800/setup.c - 1.2 arch/i386/mach-pc9800/topology.c - 1.2 arch/i386/mach-visws/mpparse.c - 1.3 arch/i386/mach-visws/traps.c - 1.2 arch/i386/mach-voyager/setup.c - 1.3 arch/i386/mach-voyager/voyager_basic.c - 1.2 arch/i386/mach-voyager/voyager_smp.c - 1.6 arch/i386/mach-voyager/voyager_thread.c - 1.3 arch/i386/math-emu/errors.c - 1.3 arch/i386/math-emu/fpu_arith.c - 1.2 arch/i386/math-emu/fpu_aux.c - 1.2 arch/i386/math-emu/fpu_entry.c - 1.2 arch/i386/math-emu/fpu_etc.c - 1.2 arch/i386/math-emu/fpu_proto.h - 1.3 arch/i386/math-emu/fpu_system.h - 1.2 arch/i386/math-emu/get_address.c - 1.2 arch/i386/math-emu/load_store.c - 1.2 arch/i386/math-emu/reg_compare.c - 1.2 arch/i386/math-emu/reg_ld_str.c - 1.2 arch/i386/math-emu/reg_round.S - 1.2 arch/i386/mm/discontig.c - 1.3 arch/i386/mm/fault.c - 1.3 arch/i386/mm/hugetlbpage.c - 1.6 arch/i386/mm/init.c - 1.6 arch/i386/mm/ioremap.c - 1.2 arch/i386/mm/pageattr.c - 1.4 arch/i386/mm/pgtable.c - 1.3 arch/i386/oprofile/op_model_p4.c - 1.3 arch/i386/pci/acpi.c - 1.4 arch/i386/pci/irq.c - 1.7 arch/i386/pci/visws.c - 1.2 arch/i386/power/cpu.c - 1.3 arch/i386/power/swsusp.S - 1.4 arch/ia64/Kconfig - 1.9 arch/ia64/Makefile - 1.5 arch/ia64/defconfig - 1.9 arch/ia64/hp/common/sba_iommu.c - 1.7 arch/ia64/hp/sim/hpsim_irq.c - 1.2 arch/ia64/hp/sim/simeth.c - 1.4 arch/ia64/ia32/binfmt_elf32.c - 1.6 arch/ia64/ia32/ia32_entry.S - 1.6 arch/ia64/ia32/ia32_support.c - 1.3 arch/ia64/ia32/ia32priv.h - 1.4 arch/ia64/ia32/sys_ia32.c - 1.8 arch/ia64/kernel/acpi.c - 1.11 arch/ia64/kernel/efi.c - 1.7 arch/ia64/kernel/efi_stub.S - 1.2 arch/ia64/kernel/entry.S - 1.6 arch/ia64/kernel/fsys.S - 1.4 arch/ia64/kernel/head.S - 1.6 arch/ia64/kernel/init_task.c - 1.2 arch/ia64/kernel/iosapic.c - 1.8 arch/ia64/kernel/irq.c - 1.7 arch/ia64/kernel/ivt.S - 1.5 arch/ia64/kernel/machvec.c - 1.5 arch/ia64/kernel/mca.c - 1.5 arch/ia64/kernel/module.c - 1.2 arch/ia64/kernel/pal.S - 1.2 arch/ia64/kernel/palinfo.c - 1.3 arch/ia64/kernel/perfmon.c - 1.7 arch/ia64/kernel/process.c - 1.7 arch/ia64/kernel/ptrace.c - 1.4 arch/ia64/kernel/sal.c - 1.5 arch/ia64/kernel/salinfo.c - 1.4 arch/ia64/kernel/setup.c - 1.6 arch/ia64/kernel/smpboot.c - 1.8 arch/ia64/kernel/unwind.c - 1.7 arch/ia64/mm/contig.c - 1.3 arch/ia64/mm/discontig.c - 1.6 arch/ia64/mm/hugetlbpage.c - 1.7 arch/ia64/mm/init.c - 1.8 arch/ia64/pci/pci.c - 1.8 arch/ia64/sn/fakeprom/fw-emu.c - 1.3 arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.7 arch/ia64/sn/io/platform_init/sgi_io_init.c - 1.5 arch/ia64/sn/io/sn2/bte_error.c - 1.4 arch/ia64/sn/io/sn2/klgraph.c - 1.5 arch/ia64/sn/io/sn2/ml_iograph.c - 1.5 arch/ia64/sn/io/sn2/module.c - 1.5 arch/ia64/sn/kernel/bte.c - 1.4 arch/ia64/sn/kernel/irq.c - 1.7 arch/ia64/sn/kernel/mca.c - 1.6 arch/ia64/sn/kernel/setup.c - 1.9 arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.7 arch/m68k/Makefile - 1.4 arch/m68k/atari/stram.c - 1.4 arch/m68k/bvme6000/config.c - 1.2 arch/m68k/defconfig - 1.3 arch/m68k/ifpsp060/iskeleton.S - 1.4 arch/m68k/kernel/process.c - 1.4 arch/m68k/kernel/setup.c - 1.5 arch/m68k/kernel/signal.c - 1.5 arch/m68k/kernel/traps.c - 1.6 arch/m68k/lib/checksum.c - 1.2 arch/m68k/mac/iop.c - 1.5 arch/m68k/mac/macints.c - 1.6 arch/m68k/mm/init.c - 1.4 arch/m68k/mm/kmap.c - 1.3 arch/m68k/mm/memory.c - 1.4 arch/m68k/mvme147/config.c - 1.3 arch/m68k/mvme16x/config.c - 1.2 arch/m68k/q40/config.c - 1.4 arch/m68knommu/defconfig - 1.3 arch/m68knommu/kernel/init_task.c - 1.2 arch/m68knommu/kernel/setup.c - 1.3 arch/mips/Kconfig - 1.8 arch/mips/Makefile - 1.5 arch/mips/baget/irq.c - 1.2 arch/mips/baget/time.c - 1.2 arch/mips/boot/Makefile - 1.3 arch/mips/ddb5xxx/ddb5074/irq.c - 1.2 arch/mips/ddb5xxx/ddb5476/irq.c - 1.2 arch/mips/ddb5xxx/ddb5477/irq.c - 1.2 arch/mips/defconfig - 1.5 arch/mips/jmr3927/rbhma3100/irq.c - 1.3 arch/mips/kernel/Makefile - 1.4 arch/mips/kernel/cpu-bugs64.c - 1.3 arch/mips/kernel/cpu-probe.c - 1.4 arch/mips/kernel/init_task.c - 1.3 arch/mips/kernel/irq.c - 1.4 arch/mips/kernel/linux32.c - 1.5 arch/mips/kernel/module-elf32.c - 1.3 arch/mips/kernel/module-elf64.c - 1.4 arch/mips/kernel/scall32-o32.S - 1.4 arch/mips/kernel/scall64-64.S - 1.4 arch/mips/kernel/scall64-n32.S - 1.5 arch/mips/kernel/scall64-o32.S - 1.4 arch/mips/kernel/semaphore.c - 1.4 arch/mips/kernel/setup.c - 1.3 arch/mips/kernel/syscall.c - 1.4 arch/mips/kernel/sysirix.c - 1.6 arch/mips/kernel/time.c - 1.3 arch/mips/kernel/traps.c - 1.4 arch/mips/lasat/sysctl.c - 1.2 arch/mips/lib-32/Makefile - 1.3 arch/mips/lib-64/Makefile - 1.3 arch/mips/mips-boards/generic/cmdline.c - 1.3 arch/mips/mips-boards/generic/printf.c - 1.3 arch/mips/mm-32/Makefile - 1.3 arch/mips/mm-32/tlbex-r4k.S - 1.4 arch/mips/mm-64/Makefile - 1.3 arch/mips/mm-64/tlb-dbg-r4k.c - 1.3 arch/mips/mm-64/tlb-glue-r4k.S - 1.2 arch/mips/mm-64/tlb-glue-sb1.S - 1.2 arch/mips/mm-64/tlbex-r4k.S - 1.4 arch/mips/mm/Makefile - 1.5 arch/mips/mm/pgtable.c - 1.3 arch/mips/mm/sc-rm7k.c - 1.4 arch/mips/mm/tlb-sb1.c - 1.3 arch/mips/mm/tlbex-r3k.S - 1.3 arch/mips/momentum/ocelot_c/Makefile - 1.3 arch/mips/momentum/ocelot_c/irq.c - 1.4 arch/mips/momentum/ocelot_c/pci-irq.c - 1.3 arch/mips/momentum/ocelot_c/prom.c - 1.4 arch/mips/momentum/ocelot_c/setup.c - 1.4 arch/mips/momentum/ocelot_g/Makefile - 1.2 arch/mips/momentum/ocelot_g/gt-irq.c - 1.3 arch/mips/momentum/ocelot_g/gt64240.h - 1.2 arch/mips/momentum/ocelot_g/gt64240_dep.h - 1.2 arch/mips/momentum/ocelot_g/pci-irq.c - 1.3 arch/mips/momentum/ocelot_g/prom.c - 1.4 arch/mips/momentum/ocelot_g/setup.c - 1.4 arch/mips/pci/Makefile - 1.4 arch/mips/pci/fixup-capcella.c - 1.3 arch/mips/pci/fixup-eagle.c - 1.3 arch/mips/pci/fixup-tb0226.c - 1.3 arch/mips/pci/fixup-tb0229.c - 1.3 arch/mips/pci/fixup-victor-mpc30x.c - 1.3 arch/mips/pci/ops-vrc4173.c - 1.2 arch/mips/pci/pci-ocelot-c.c - 1.3 arch/mips/pci/pci-ocelot-g.c - 1.3 arch/mips/pci/pci-vr41xx.c - 1.4 arch/mips/pci/pci-vr41xx.h - 1.3 arch/mips/pci/pci.c - 1.3 arch/mips/ramdisk/Makefile - 1.3 arch/mips/sgi-ip22/ip22-setup.c - 1.3 arch/mips/sgi-ip32/ip32-irq.c - 1.4 arch/mips/sibyte/sb1250/irq.c - 1.3 arch/mips/sibyte/sb1250/irq_handler.S - 1.3 arch/mips/tx4927/common/tx4927_irq.c - 1.3 arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c - 1.3 arch/mips/vr4181/common/irq.c - 1.2 arch/mips/vr41xx/common/bcu.c - 1.3 arch/mips/vr41xx/common/cmu.c - 1.4 arch/mips/vr41xx/common/giu.c - 1.4 arch/mips/vr41xx/common/icu.c - 1.4 arch/mips/vr41xx/common/serial.c - 1.5 arch/mips/vr41xx/common/vrc4173.c - 1.3 arch/mips/vr41xx/nec-eagle/Makefile - 1.4 arch/mips/vr41xx/nec-eagle/irq.c - 1.3 arch/mips/vr41xx/nec-eagle/setup.c - 1.5 arch/mips/vr41xx/tanbac-tb0226/setup.c - 1.5 arch/mips/vr41xx/tanbac-tb0229/Makefile - 1.4 arch/mips/vr41xx/tanbac-tb0229/reboot.c - 1.3 arch/mips/vr41xx/tanbac-tb0229/setup.c - 1.5 arch/mips/vr41xx/victor-mpc30x/setup.c - 1.5 arch/mips/vr41xx/zao-capcella/setup.c - 1.5 arch/parisc/Kconfig - 1.6 arch/parisc/defconfig - 1.5 arch/parisc/kernel/cache.c - 1.5 arch/parisc/kernel/entry.S - 1.5 arch/parisc/kernel/firmware.c - 1.5 arch/parisc/kernel/hardware.c - 1.5 arch/parisc/kernel/head.S - 1.5 arch/parisc/kernel/head64.S - 1.6 arch/parisc/kernel/init_task.c - 1.4 arch/parisc/kernel/inventory.c - 1.4 arch/parisc/kernel/irq.c - 1.3 arch/parisc/kernel/parisc_ksyms.c - 1.6 arch/parisc/kernel/pci-dma.c - 1.5 arch/parisc/kernel/pdc_chassis.c - 1.4 arch/parisc/kernel/process.c - 1.6 arch/parisc/kernel/processor.c - 1.4 arch/parisc/kernel/real2.S - 1.4 arch/parisc/kernel/setup.c - 1.3 arch/parisc/kernel/smp.c - 1.5 arch/parisc/kernel/sys_parisc32.c - 1.7 arch/parisc/kernel/traps.c - 1.4 arch/parisc/lib/Makefile - 1.2 arch/parisc/lib/bitops.c - 1.3 arch/parisc/lib/io.c - 1.2 arch/parisc/mm/init.c - 1.3 arch/ppc/8260_io/Kconfig - 1.2 arch/ppc/8260_io/Makefile - 1.2 arch/ppc/8260_io/commproc.c - 1.2 arch/ppc/8260_io/enet.c - 1.4 arch/ppc/8260_io/fcc_enet.c - 1.4 arch/ppc/8260_io/uart.c - 1.5 arch/ppc/8xx_io/commproc.c - 1.3 arch/ppc/8xx_io/cs4218_tdm.c - 1.3 arch/ppc/8xx_io/enet.c - 1.3 arch/ppc/8xx_io/uart.c - 1.3 arch/ppc/Kconfig - 1.9 arch/ppc/Makefile - 1.3 arch/ppc/boot/common/misc-common.c - 1.2 arch/ppc/boot/simple/Makefile - 1.6 arch/ppc/boot/simple/embed_config.c - 1.4 arch/ppc/boot/simple/head.S - 1.3 arch/ppc/boot/simple/m8260_tty.c - 1.2 arch/ppc/boot/simple/misc-embedded.c - 1.3 arch/ppc/boot/simple/misc.c - 1.5 arch/ppc/boot/utils/mktree.c - 1.2 arch/ppc/configs/FADS_defconfig - 1.2 arch/ppc/configs/IVMS8_defconfig - 1.2 arch/ppc/configs/SM850_defconfig - 1.2 arch/ppc/configs/SPD823TS_defconfig - 1.2 arch/ppc/configs/TQM823L_defconfig - 1.2 arch/ppc/configs/TQM8260_defconfig - 1.2 arch/ppc/configs/TQM850L_defconfig - 1.2 arch/ppc/configs/TQM860L_defconfig - 1.2 arch/ppc/configs/adir_defconfig - 1.3 arch/ppc/configs/apus_defconfig - 1.2 arch/ppc/configs/ash_defconfig - 1.4 arch/ppc/configs/beech_defconfig - 1.2 arch/ppc/configs/bseip_defconfig - 1.2 arch/ppc/configs/cedar_defconfig - 1.3 arch/ppc/configs/common_defconfig - 1.6 arch/ppc/configs/cpci405_defconfig - 1.4 arch/ppc/configs/ebony_defconfig - 1.4 arch/ppc/configs/ep405_defconfig - 1.3 arch/ppc/configs/est8260_defconfig - 1.2 arch/ppc/configs/ev64260_defconfig - 1.2 arch/ppc/configs/gemini_defconfig - 1.2 arch/ppc/configs/ibmchrp_defconfig - 1.3 arch/ppc/configs/k2_defconfig - 1.3 arch/ppc/configs/lopec_defconfig - 1.4 arch/ppc/configs/mbx_defconfig - 1.2 arch/ppc/configs/menf1_defconfig - 1.2 arch/ppc/configs/mvme5100_defconfig - 1.2 arch/ppc/configs/oak_defconfig - 1.2 arch/ppc/configs/ocotea_defconfig - 1.3 arch/ppc/configs/pcore_defconfig - 1.3 arch/ppc/configs/pmac_defconfig - 1.6 arch/ppc/configs/power3_defconfig - 1.4 arch/ppc/configs/pplus_defconfig - 1.3 arch/ppc/configs/prpmc750_defconfig - 1.3 arch/ppc/configs/prpmc800_defconfig - 1.3 arch/ppc/configs/rainier_defconfig - 1.3 arch/ppc/configs/redwood5_defconfig - 1.4 arch/ppc/configs/redwood6_defconfig - 1.3 arch/ppc/configs/redwood_defconfig - 1.2 arch/ppc/configs/rpxcllf_defconfig - 1.2 arch/ppc/configs/rpxlite_defconfig - 1.2 arch/ppc/configs/sandpoint_defconfig - 1.4 arch/ppc/configs/spruce_defconfig - 1.4 arch/ppc/configs/sycamore_defconfig - 1.3 arch/ppc/configs/walnut_defconfig - 1.4 arch/ppc/defconfig - 1.6 arch/ppc/kernel/Makefile - 1.5 arch/ppc/kernel/align.c - 1.3 arch/ppc/kernel/asm-offsets.c - 1.2 arch/ppc/kernel/cpu_setup_6xx.S - 1.3 arch/ppc/kernel/cputable.c - 1.5 arch/ppc/kernel/entry.S - 1.5 arch/ppc/kernel/head.S - 1.8 arch/ppc/kernel/head_44x.S - 1.6 arch/ppc/kernel/head_4xx.S - 1.3 arch/ppc/kernel/irq.c - 1.5 arch/ppc/kernel/misc.S - 1.8 arch/ppc/kernel/pci-dma.c - 1.2 arch/ppc/kernel/pci.c - 1.6 arch/ppc/kernel/ppc-stub.c - 1.2 arch/ppc/kernel/ppc_htab.c - 1.3 arch/ppc/kernel/ppc_ksyms.c - 1.7 arch/ppc/kernel/process.c - 1.5 arch/ppc/kernel/ptrace.c - 1.3 arch/ppc/kernel/setup.c - 1.6 arch/ppc/kernel/signal.c - 1.5 arch/ppc/kernel/syscalls.c - 1.4 arch/ppc/kernel/time.c - 1.3 arch/ppc/kernel/traps.c - 1.4 arch/ppc/kernel/vmlinux.lds.S - 1.3 arch/ppc/lib/Makefile - 1.2 arch/ppc/mm/44x_mmu.c - 1.3 arch/ppc/mm/Makefile - 1.4 arch/ppc/mm/fault.c - 1.3 arch/ppc/mm/init.c - 1.4 arch/ppc/mm/mmu_decl.h - 1.2 arch/ppc/mm/pgtable.c - 1.6 arch/ppc/platforms/4xx/Kconfig - 1.4 arch/ppc/platforms/4xx/ebony.h - 1.3 arch/ppc/platforms/4xx/redwood5.c - 1.3 arch/ppc/platforms/4xx/redwood5.h - 1.2 arch/ppc/platforms/4xx/redwood6.c - 1.2 arch/ppc/platforms/4xx/redwood6.h - 1.2 arch/ppc/platforms/Makefile - 1.7 arch/ppc/platforms/error_log.c - 1.2 arch/ppc/platforms/error_log.h - 1.2 arch/ppc/platforms/est8260.h - 1.2 arch/ppc/platforms/lopec_setup.c - 1.3 arch/ppc/platforms/pmac_cpufreq.c - 1.3 arch/ppc/platforms/pmac_feature.c - 1.7 arch/ppc/platforms/pmac_pci.c - 1.3 arch/ppc/platforms/pmac_pic.c - 1.5 arch/ppc/platforms/pmac_setup.c - 1.4 arch/ppc/platforms/pmac_smp.c - 1.4 arch/ppc/platforms/powerpmc250.c - 1.2 arch/ppc/platforms/prep_pci.c - 1.4 arch/ppc/platforms/prep_setup.c - 1.5 arch/ppc/platforms/proc_rtas.c - 1.3 arch/ppc/platforms/residual.c - 1.2 arch/ppc/platforms/rpxsuper.h - 1.2 arch/ppc/platforms/sandpoint.c - 1.4 arch/ppc/platforms/sbs8260.h - 1.2 arch/ppc/platforms/tqm8260.h - 1.2 arch/ppc/platforms/tqm8260_setup.c - 1.2 arch/ppc/syslib/Makefile - 1.6 arch/ppc/syslib/ibm440gp_common.c - 1.3 arch/ppc/syslib/m8260_setup.c - 1.2 arch/ppc/syslib/mpc10x_common.c - 1.2 arch/ppc/syslib/open_pic.c - 1.5 arch/ppc/syslib/ppc4xx_dma.c - 1.2 arch/ppc/syslib/ppc4xx_pic.c - 1.3 arch/ppc/syslib/ppc8260_pic.c - 1.2 arch/ppc/syslib/ppc8260_pic.h - 1.2 arch/ppc/syslib/prom.c - 1.3 arch/ppc/syslib/prom_init.c - 1.4 arch/ppc/xmon/ppc-opc.c - 1.2 arch/ppc/xmon/start.c - 1.2 arch/ppc/xmon/xmon.c - 1.2 arch/ppc64/Kconfig - 1.9 arch/ppc64/boot/div64.S - 1.2 arch/ppc64/defconfig - 1.6 arch/ppc64/kernel/ItLpQueue.c - 1.3 arch/ppc64/kernel/LparData.c - 1.3 arch/ppc64/kernel/Makefile - 1.8 arch/ppc64/kernel/align.c - 1.3 arch/ppc64/kernel/asm-offsets.c - 1.5 arch/ppc64/kernel/bitops.c - 1.3 arch/ppc64/kernel/chrp_setup.c - 1.7 arch/ppc64/kernel/cputable.c - 1.6 arch/ppc64/kernel/eeh.c - 1.7 arch/ppc64/kernel/entry.S - 1.6 arch/ppc64/kernel/head.S - 1.10 arch/ppc64/kernel/iSeries_proc.c - 1.4 arch/ppc64/kernel/iSeries_setup.c - 1.7 arch/ppc64/kernel/idle.c - 1.7 arch/ppc64/kernel/init_task.c - 1.2 arch/ppc64/kernel/ioctl32.c - 1.5 arch/ppc64/kernel/irq.c - 1.8 arch/ppc64/kernel/mf_proc.c - 1.6 arch/ppc64/kernel/misc.S - 1.8 arch/ppc64/kernel/open_pic.c - 1.6 arch/ppc64/kernel/open_pic_defs.h - 1.3 arch/ppc64/kernel/pSeries_htab.c - 1.5 arch/ppc64/kernel/pSeries_lpar.c - 1.8 arch/ppc64/kernel/pSeries_pci.c - 1.8 arch/ppc64/kernel/pacaData.c - 1.4 arch/ppc64/kernel/pci.h - 1.3 arch/ppc64/kernel/pci_dn.c - 1.6 arch/ppc64/kernel/ppc_ksyms.c - 1.8 arch/ppc64/kernel/proc_ppc64.c - 1.6 arch/ppc64/kernel/process.c - 1.9 arch/ppc64/kernel/prom.c - 1.10 arch/ppc64/kernel/ptrace.c - 1.4 arch/ppc64/kernel/ptrace32.c - 1.3 arch/ppc64/kernel/ras.c - 1.6 arch/ppc64/kernel/rtas-proc.c - 1.8 arch/ppc64/kernel/rtas.c - 1.7 arch/ppc64/kernel/rtas_flash.c - 1.7 arch/ppc64/kernel/rtasd.c - 1.8 arch/ppc64/kernel/rtc.c - 1.3 arch/ppc64/kernel/scanlog.c - 1.6 arch/ppc64/kernel/setup.c - 1.10 arch/ppc64/kernel/signal.c - 1.6 arch/ppc64/kernel/signal32.c - 1.7 arch/ppc64/kernel/smp.c - 1.9 arch/ppc64/kernel/stab.c - 1.7 arch/ppc64/kernel/sys_ppc32.c - 1.9 arch/ppc64/kernel/syscalls.c - 1.5 arch/ppc64/kernel/time.c - 1.6 arch/ppc64/kernel/traps.c - 1.8 arch/ppc64/kernel/udbg.c - 1.4 arch/ppc64/kernel/xics.c - 1.8 arch/ppc64/lib/Makefile - 1.3 arch/ppc64/lib/string.S - 1.2 arch/ppc64/mm/Makefile - 1.4 arch/ppc64/mm/fault.c - 1.5 arch/ppc64/mm/hugetlbpage.c - 1.9 arch/ppc64/mm/init.c - 1.8 arch/ppc64/mm/numa.c - 1.8 arch/ppc64/xmon/xmon.c - 1.9 arch/s390/Kconfig - 1.6 arch/s390/defconfig - 1.8 arch/s390/kernel/Makefile - 1.3 arch/s390/kernel/compat_linux.h - 1.5 arch/s390/kernel/compat_signal.c - 1.6 arch/s390/kernel/debug.c - 1.3 arch/s390/kernel/entry.S - 1.6 arch/s390/kernel/entry64.S - 1.6 arch/s390/kernel/head.S - 1.4 arch/s390/kernel/head64.S - 1.4 arch/s390/kernel/init_task.c - 1.2 arch/s390/kernel/process.c - 1.6 arch/s390/kernel/ptrace.c - 1.6 arch/s390/kernel/s390_ksyms.c - 1.6 arch/s390/kernel/setup.c - 1.7 arch/s390/kernel/signal.c - 1.5 arch/s390/kernel/smp.c - 1.5 arch/s390/kernel/time.c - 1.5 arch/s390/kernel/traps.c - 1.7 arch/s390/mm/fault.c - 1.4 arch/s390/mm/init.c - 1.6 arch/sh/Kconfig - 1.7 arch/sh/Makefile - 1.4 arch/sh/boot/compressed/Makefile - 1.3 arch/sh/boot/compressed/misc.c - 1.2 arch/sh/cchips/hd6446x/hd64461/setup.c - 1.4 arch/sh/cchips/hd6446x/hd64465/setup.c - 1.3 arch/sh/defconfig - 1.4 arch/sh/kernel/Makefile - 1.3 arch/sh/kernel/cpu/Makefile - 1.3 arch/sh/kernel/cpu/irq_ipr.c - 1.3 arch/sh/kernel/entry.S - 1.5 arch/sh/kernel/init_task.c - 1.2 arch/sh/kernel/io_generic.c - 1.2 arch/sh/kernel/irq.c - 1.5 arch/sh/kernel/process.c - 1.7 arch/sh/kernel/ptrace.c - 1.3 arch/sh/kernel/setup.c - 1.3 arch/sh/kernel/sh_ksyms.c - 1.4 arch/sh/kernel/time.c - 1.4 arch/sh/kernel/traps.c - 1.5 arch/sh/kernel/vmlinux.lds.S - 1.3 arch/sh/lib/delay.c - 1.2 arch/sh/mm/cache-sh3.c - 1.4 arch/sh/mm/cache-sh4.c - 1.4 arch/sh/mm/init.c - 1.4 arch/sh/mm/pg-sh4.c - 1.2 arch/sh/mm/tlb-sh3.c - 1.3 arch/sh/tools/mach-types - 1.3 arch/sparc/Kconfig - 1.7 arch/sparc/defconfig - 1.3 arch/sparc/kernel/init_task.c - 1.4 arch/sparc/kernel/ioport.c - 1.3 arch/sparc/kernel/irq.c - 1.7 arch/sparc/kernel/process.c - 1.8 arch/sparc/kernel/setup.c - 1.5 arch/sparc/kernel/signal.c - 1.6 arch/sparc/kernel/smp.c - 1.5 arch/sparc/kernel/sparc_ksyms.c - 1.6 arch/sparc/kernel/sun4c_irq.c - 1.3 arch/sparc/kernel/sun4d_irq.c - 1.5 arch/sparc/kernel/sun4d_smp.c - 1.3 arch/sparc/kernel/sun4m_smp.c - 1.3 arch/sparc/kernel/sun4setup.c - 1.2 arch/sparc/kernel/sys_sparc.c - 1.4 arch/sparc/kernel/sys_sunos.c - 1.5 arch/sparc/kernel/time.c - 1.3 arch/sparc/kernel/trampoline.S - 1.3 arch/sparc/kernel/traps.c - 1.6 arch/sparc/kernel/unaligned.c - 1.4 arch/sparc/lib/copy_user.S - 1.3 arch/sparc/lib/memcpy.S - 1.3 arch/sparc/mm/fault.c - 1.7 arch/sparc/mm/init.c - 1.6 arch/sparc/mm/io-unit.c - 1.3 arch/sparc/mm/iommu.c - 1.3 arch/sparc/mm/nosrmmu.c - 1.2 arch/sparc/mm/srmmu.c - 1.9 arch/sparc/mm/sun4c.c - 1.7 arch/sparc64/Kconfig - 1.9 arch/sparc64/defconfig - 1.9 arch/sparc64/kernel/auxio.c - 1.2 arch/sparc64/kernel/binfmt_aout32.c - 1.4 arch/sparc64/kernel/ebus.c - 1.4 arch/sparc64/kernel/entry.S - 1.5 arch/sparc64/kernel/head.S - 1.5 arch/sparc64/kernel/init_task.c - 1.3 arch/sparc64/kernel/ioctl32.c - 1.5 arch/sparc64/kernel/irq.c - 1.5 arch/sparc64/kernel/itlb_base.S - 1.2 arch/sparc64/kernel/power.c - 1.5 arch/sparc64/kernel/process.c - 1.5 arch/sparc64/kernel/rtrap.S - 1.2 arch/sparc64/kernel/sbus.c - 1.4 arch/sparc64/kernel/setup.c - 1.7 arch/sparc64/kernel/signal32.c - 1.5 arch/sparc64/kernel/smp.c - 1.7 arch/sparc64/kernel/sparc64_ksyms.c - 1.6 arch/sparc64/kernel/sys_sparc.c - 1.5 arch/sparc64/kernel/sys_sparc32.c - 1.7 arch/sparc64/kernel/sys_sunos32.c - 1.5 arch/sparc64/kernel/systbls.S - 1.6 arch/sparc64/kernel/time.c - 1.4 arch/sparc64/kernel/traps.c - 1.6 arch/sparc64/lib/Makefile - 1.3 arch/sparc64/lib/U3copy_from_user.S - 1.2 arch/sparc64/lib/U3copy_in_user.S - 1.2 arch/sparc64/lib/U3copy_to_user.S - 1.2 arch/sparc64/lib/U3memcpy.S - 1.2 arch/sparc64/lib/VISbzero.S - 1.2 arch/sparc64/lib/VIScopy.S - 1.3 arch/sparc64/lib/atomic.S - 1.2 arch/sparc64/lib/bitops.S - 1.2 arch/sparc64/lib/blockops.S - 1.2 arch/sparc64/lib/rwlock.S - 1.2 arch/sparc64/mm/Makefile - 1.2 arch/sparc64/mm/fault.c - 1.3 arch/sparc64/mm/init.c - 1.8 arch/sparc64/mm/ultra.S - 1.2 arch/sparc64/solaris/conv.h - 1.2 arch/sparc64/solaris/fs.c - 1.2 arch/sparc64/solaris/ioctl.c - 1.3 arch/sparc64/solaris/ipc.c - 1.2 arch/sparc64/solaris/misc.c - 1.3 arch/sparc64/solaris/signal.c - 1.2 arch/sparc64/solaris/socket.c - 1.2 arch/sparc64/solaris/timod.c - 1.4 arch/um/config.release - 1.2 arch/um/defconfig - 1.2 arch/um/drivers/harddog_kern.c - 1.3 arch/um/kernel/init_task.c - 1.2 arch/um/kernel/irq.c - 1.4 arch/um/kernel/mem.c - 1.3 arch/um/kernel/sysrq.c - 1.3 arch/um/kernel/user_util.c - 1.2 arch/v850/kernel/as85ep1.c - 1.2 arch/v850/kernel/as85ep1.ld - 1.2 arch/v850/kernel/fpga85e2c.c - 1.2 arch/v850/kernel/init_task.c - 1.2 arch/v850/kernel/irq.c - 1.3 arch/v850/kernel/setup.c - 1.3 arch/v850/kernel/time.c - 1.3 arch/v850/kernel/vmlinux.lds.S - 1.4 arch/v850/lib/memset.c - 1.2 arch/x86_64/Makefile - 1.6 arch/x86_64/defconfig - 1.9 arch/x86_64/ia32/ia32_signal.c - 1.7 arch/x86_64/ia32/sys_ia32.c - 1.9 arch/x86_64/kernel/e820.c - 1.3 arch/x86_64/kernel/head64.c - 1.4 arch/x86_64/kernel/i8259.c - 1.5 arch/x86_64/kernel/init_task.c - 1.2 arch/x86_64/kernel/io_apic.c - 1.8 arch/x86_64/kernel/irq.c - 1.5 arch/x86_64/kernel/ldt.c - 1.4 arch/x86_64/kernel/module.c - 1.2 arch/x86_64/kernel/mpparse.c - 1.9 arch/x86_64/kernel/pci-gart.c - 1.10 arch/x86_64/kernel/setup.c - 1.8 arch/x86_64/kernel/signal.c - 1.4 arch/x86_64/kernel/smp.c - 1.3 arch/x86_64/kernel/smpboot.c - 1.6 arch/x86_64/kernel/suspend.c - 1.3 arch/x86_64/kernel/time.c - 1.6 arch/x86_64/kernel/traps.c - 1.8 arch/x86_64/kernel/x8664_ksyms.c - 1.7 arch/x86_64/lib/csum-wrappers.c - 1.3 arch/x86_64/lib/usercopy.c - 1.4 arch/x86_64/mm/fault.c - 1.7 arch/x86_64/mm/init.c - 1.7 arch/x86_64/mm/numa.c - 1.5 arch/x86_64/mm/pageattr.c - 1.3 crypto/Kconfig - 1.5 crypto/Makefile - 1.5 crypto/cipher.c - 1.4 crypto/deflate.c - 1.2 crypto/tcrypt.c - 1.6 crypto/tcrypt.h - 1.5 crypto/twofish.c - 1.2 drivers/Kconfig - 1.5 drivers/Makefile - 1.4 drivers/acpi/Kconfig - 1.6 drivers/acpi/namespace/nsalloc.c - 1.4 drivers/acpi/namespace/nsdumpdv.c - 1.3 drivers/acpi/namespace/nsload.c - 1.3 drivers/acpi/namespace/nswalk.c - 1.3 drivers/acpi/pci_irq.c - 1.6 drivers/acpi/pci_link.c - 1.8 drivers/acpi/pci_root.c - 1.5 drivers/acpi/scan.c - 1.6 drivers/acpi/sleep/main.c - 1.2 drivers/acpi/sleep/proc.c - 1.5 drivers/acpi/system.c - 1.3 drivers/acpi/tables.c - 1.7 drivers/acpi/thermal.c - 1.6 drivers/acpi/toshiba_acpi.c - 1.7 drivers/atm/ambassador.c - 1.4 drivers/atm/firestream.c - 1.3 drivers/atm/fore200e.c - 1.6 drivers/atm/he.c - 1.6 drivers/atm/horizon.c - 1.5 drivers/atm/idt77105.c - 1.4 drivers/atm/idt77252.c - 1.4 drivers/atm/iphase.c - 1.4 drivers/atm/iphase.h - 1.3 drivers/atm/lanai.c - 1.4 drivers/atm/suni.c - 1.5 drivers/atm/uPD98402.c - 1.4 drivers/base/Kconfig - 1.4 drivers/base/base.h - 1.2 drivers/base/bus.c - 1.6 drivers/base/class.c - 1.8 drivers/base/core.c - 1.6 drivers/base/cpu.c - 1.4 drivers/base/driver.c - 1.4 drivers/base/firmware.c - 1.2 drivers/base/firmware_class.c - 1.6 drivers/base/init.c - 1.3 drivers/base/interface.c - 1.2 drivers/base/node.c - 1.5 drivers/base/platform.c - 1.5 drivers/base/power/main.c - 1.4 drivers/base/power/power.h - 1.2 drivers/base/power/resume.c - 1.3 drivers/base/power/runtime.c - 1.4 drivers/base/power/shutdown.c - 1.5 drivers/base/power/suspend.c - 1.3 drivers/base/power/sysfs.c - 1.3 drivers/base/sys.c - 1.5 drivers/block/Kconfig - 1.6 drivers/block/Makefile - 1.5 drivers/block/ataflop.c - 1.2 drivers/block/cciss.c - 1.7 drivers/block/cciss_scsi.c - 1.4 drivers/block/cryptoloop.c - 1.3 drivers/block/deadline-iosched.c - 1.2 drivers/block/elevator.c - 1.6 drivers/block/floppy.c - 1.8 drivers/block/floppy98.c - 1.6 drivers/block/genhd.c - 1.7 drivers/block/ll_rw_blk.c - 1.10 drivers/block/loop.c - 1.7 drivers/block/nbd.c - 1.3 drivers/block/paride/bpck6.c - 1.3 drivers/block/paride/paride.c - 1.3 drivers/block/paride/pcd.c - 1.3 drivers/block/paride/pf.c - 1.3 drivers/block/paride/ppc6lnx.c - 1.2 drivers/block/scsi_ioctl.c - 1.6 drivers/block/swim3.c - 1.5 drivers/block/xd.c - 1.3 drivers/bluetooth/bluecard_cs.c - 1.5 drivers/bluetooth/bt3c_cs.c - 1.6 drivers/bluetooth/btuart_cs.c - 1.5 drivers/bluetooth/dtl1_cs.c - 1.5 drivers/bluetooth/hci_bcsp.c - 1.5 drivers/bluetooth/hci_usb.c - 1.7 drivers/bluetooth/hci_vhci.c - 1.4 drivers/cdrom/aztcd.c - 1.3 drivers/cdrom/cdrom.c - 1.8 drivers/cdrom/cdu31a.c - 1.4 drivers/cdrom/cm206.c - 1.3 drivers/cdrom/isp16.c - 1.2 drivers/cdrom/mcd.c - 1.2 drivers/cdrom/mcdx.c - 1.3 drivers/cdrom/optcd.c - 1.3 drivers/cdrom/sbpcd.c - 1.3 drivers/cdrom/sbpcd.h - 1.2 drivers/char/Kconfig - 1.8 drivers/char/Makefile - 1.6 drivers/char/README.scc - 1.2 drivers/char/agp/Kconfig - 1.5 drivers/char/agp/amd64-agp.c - 1.6 drivers/char/agp/generic.c - 1.4 drivers/char/agp/hp-agp.c - 1.3 drivers/char/agp/intel-agp.c - 1.6 drivers/char/agp/sis-agp.c - 1.5 drivers/char/agp/sworks-agp.c - 1.4 drivers/char/agp/via-agp.c - 1.5 drivers/char/applicom.c - 1.4 drivers/char/cyclades.c - 1.5 drivers/char/defkeymap.c_shipped - 1.2 drivers/char/drm/Kconfig - 1.3 drivers/char/drm/drm.h - 1.3 drivers/char/drm/drmP.h - 1.4 drivers/char/drm/drm_agpsupport.h - 1.3 drivers/char/drm/drm_auth.h - 1.2 drivers/char/drm/drm_bufs.h - 1.3 drivers/char/drm/drm_context.h - 1.3 drivers/char/drm/drm_dma.h - 1.3 drivers/char/drm/drm_drawable.h - 1.2 drivers/char/drm/drm_drv.h - 1.3 drivers/char/drm/drm_fops.h - 1.3 drivers/char/drm/drm_ioctl.h - 1.3 drivers/char/drm/drm_lock.h - 1.2 drivers/char/drm/drm_scatter.h - 1.2 drivers/char/drm/drm_vm.h - 1.4 drivers/char/drm/ffb_context.c - 1.2 drivers/char/drm/gamma_context.h - 1.3 drivers/char/drm/gamma_dma.c - 1.3 drivers/char/drm/gamma_lock.h - 1.2 drivers/char/drm/gamma_old_dma.h - 1.2 drivers/char/drm/i810_dma.c - 1.4 drivers/char/drm/i830_dma.c - 1.4 drivers/char/drm/i830_irq.c - 1.4 drivers/char/drm/mga_dma.c - 1.3 drivers/char/drm/mga_drm.h - 1.3 drivers/char/drm/mga_state.c - 1.2 drivers/char/drm/r128_cce.c - 1.3 drivers/char/drm/r128_drm.h - 1.3 drivers/char/drm/r128_state.c - 1.4 drivers/char/drm/radeon.h - 1.3 drivers/char/drm/radeon_cp.c - 1.3 drivers/char/drm/radeon_drm.h - 1.3 drivers/char/drm/radeon_drv.h - 1.3 drivers/char/drm/radeon_irq.c - 1.3 drivers/char/drm/radeon_mem.c - 1.3 drivers/char/drm/radeon_state.c - 1.5 drivers/char/drm/sis_ds.c - 1.2 drivers/char/drm/sis_mm.c - 1.2 drivers/char/ds1620.c - 1.2 drivers/char/dsp56k.c - 1.3 drivers/char/dtlk.c - 1.2 drivers/char/epca.c - 1.3 drivers/char/esp.c - 1.3 drivers/char/ftape/compressor/lzrw3.c - 1.3 drivers/char/ftape/compressor/zftape-compress.c - 1.3 drivers/char/ftape/lowlevel/fdc-io.c - 1.2 drivers/char/ftape/lowlevel/ftape-init.c - 1.2 drivers/char/ftape/lowlevel/ftape-proc.c - 1.2 drivers/char/ftape/zftape/zftape-ctl.c - 1.2 drivers/char/ftape/zftape/zftape-ctl.h - 1.2 drivers/char/ftape/zftape/zftape-init.c - 1.3 drivers/char/ftape/zftape/zftape-init.h - 1.2 drivers/char/ftape/zftape/zftape-read.c - 1.2 drivers/char/ftape/zftape/zftape-read.h - 1.2 drivers/char/ftape/zftape/zftape-write.c - 1.2 drivers/char/ftape/zftape/zftape-write.h - 1.2 drivers/char/generic_serial.c - 1.2 drivers/char/genrtc.c - 1.5 drivers/char/h8.c - 1.3 drivers/char/h8.h - 1.2 drivers/char/ip2main.c - 1.4 drivers/char/ipmi/ipmi_devintf.c - 1.3 drivers/char/ipmi/ipmi_kcs_sm.c - 1.4 drivers/char/ipmi/ipmi_msghandler.c - 1.4 drivers/char/ipmi/ipmi_watchdog.c - 1.3 drivers/char/isicom.c - 1.4 drivers/char/istallion.c - 1.5 drivers/char/keyboard.c - 1.15 drivers/char/lcd.c - 1.2 drivers/char/lp_old98.c - 1.2 drivers/char/mem.c - 1.7 drivers/char/misc.c - 1.5 drivers/char/moxa.c - 1.5 drivers/char/mwave/3780i.c - 1.2 drivers/char/mwave/3780i.h - 1.2 drivers/char/mwave/mwavedd.c - 1.3 drivers/char/mwave/tp3780i.c - 1.2 drivers/char/mwave/tp3780i.h - 1.2 drivers/char/mxser.c - 1.6 drivers/char/n_hdlc.c - 1.2 drivers/char/n_r3964.c - 1.2 drivers/char/n_tty.c - 1.5 drivers/char/nvram.c - 1.3 drivers/char/nwbutton.c - 1.2 drivers/char/nwbutton.h - 1.2 drivers/char/nwflash.c - 1.2 drivers/char/pcmcia/synclink_cs.c - 1.6 drivers/char/pty.c - 1.4 drivers/char/random.c - 1.5 drivers/char/raw.c - 1.6 drivers/char/riscom8.c - 1.3 drivers/char/rocket.c - 1.4 drivers/char/rtc.c - 1.5 drivers/char/scx200_gpio.c - 1.3 drivers/char/selection.c - 1.4 drivers/char/ser_a2232.c - 1.2 drivers/char/sn_serial.c - 1.16 drivers/char/sonypi.c - 1.4 drivers/char/sonypi.h - 1.4 drivers/char/specialix.c - 1.5 drivers/char/stallion.c - 1.4 drivers/char/sx.c - 1.5 drivers/char/synclink.c - 1.5 drivers/char/synclinkmp.c - 1.5 drivers/char/tipar.c - 1.5 drivers/char/tpqic02.c - 1.4 drivers/char/tty_io.c - 1.9 drivers/char/upd4990a.c - 1.2 drivers/char/vc_screen.c - 1.4 drivers/char/vt.c - 1.8 drivers/char/vt_ioctl.c - 1.7 drivers/char/watchdog/Kconfig - 1.8 drivers/char/watchdog/Makefile - 1.7 drivers/char/watchdog/acquirewdt.c - 1.4 drivers/char/watchdog/advantechwdt.c - 1.5 drivers/char/watchdog/alim1535_wdt.c - 1.6 drivers/char/watchdog/alim7101_wdt.c - 1.6 drivers/char/watchdog/cpu5wdt.c - 1.6 drivers/char/watchdog/eurotechwdt.c - 1.5 drivers/char/watchdog/ib700wdt.c - 1.7 drivers/char/watchdog/indydog.c - 1.5 drivers/char/watchdog/machzwd.c - 1.7 drivers/char/watchdog/mixcomwd.c - 1.5 drivers/char/watchdog/pcwd.c - 1.7 drivers/char/watchdog/sa1100_wdt.c - 1.5 drivers/char/watchdog/sbc60xxwdt.c - 1.5 drivers/char/watchdog/sc1200wdt.c - 1.6 drivers/char/watchdog/sc520_wdt.c - 1.5 drivers/char/watchdog/scx200_wdt.c - 1.5 drivers/char/watchdog/shwdt.c - 1.6 drivers/char/watchdog/softdog.c - 1.6 drivers/char/watchdog/w83877f_wdt.c - 1.5 drivers/char/watchdog/wafer5823wdt.c - 1.5 drivers/char/watchdog/wdt.c - 1.6 drivers/char/watchdog/wdt285.c - 1.4 drivers/char/watchdog/wdt977.c - 1.5 drivers/char/watchdog/wdt_pci.c - 1.5 drivers/cpufreq/cpufreq_userspace.c - 1.5 drivers/fc4/fc.c - 1.4 drivers/fc4/soc.c - 1.2 drivers/fc4/socal.c - 1.2 drivers/i2c/busses/i2c-elektor.c - 1.4 drivers/i2c/busses/i2c-ibm_iic.c - 1.6 drivers/i2c/busses/i2c-piix4.c - 1.7 drivers/i2c/busses/i2c-rpx.c - 1.4 drivers/i2c/busses/scx200_acb.c - 1.5 drivers/i2c/chips/Kconfig - 1.8 drivers/i2c/chips/Makefile - 1.8 drivers/i2c/chips/it87.c - 1.8 drivers/i2c/chips/lm75.c - 1.8 drivers/i2c/chips/lm78.c - 1.8 drivers/i2c/chips/lm85.c - 1.8 drivers/i2c/chips/via686a.c - 1.7 drivers/i2c/chips/w83781d.c - 1.7 drivers/i2c/i2c-core.c - 1.7 drivers/i2c/i2c-dev.c - 1.6 drivers/ide/Kconfig - 1.9 drivers/ide/Makefile - 1.6 drivers/ide/ide-cd.c - 1.11 drivers/ide/ide-cd.h - 1.4 drivers/ide/ide-disk.c - 1.8 drivers/ide/ide-dma.c - 1.8 drivers/ide/ide-floppy.c - 1.6 drivers/ide/ide-proc.c - 1.6 drivers/ide/ide-tape.c - 1.6 drivers/ide/ide-taskfile.c - 1.7 drivers/ide/ide.c - 1.13 drivers/ide/legacy/hd.c - 1.2 drivers/ide/legacy/hd98.c - 1.2 drivers/ide/legacy/ide-cs.c - 1.4 drivers/ide/legacy/pc9800.c - 1.2 drivers/ide/legacy/pdc4030.c - 1.6 drivers/ide/pci/amd74xx.c - 1.7 drivers/ide/pci/generic.c - 1.7 drivers/ide/pci/hpt366.c - 1.8 drivers/ide/pci/hpt366.h - 1.5 drivers/ide/pci/pdc202xx_old.c - 1.8 drivers/ide/pci/piix.c - 1.8 drivers/ide/pci/siimage.c - 1.8 drivers/ide/pci/trm290.c - 1.7 drivers/ide/ppc/pmac.c - 1.6 drivers/ieee1394/Kconfig - 1.6 drivers/ieee1394/amdtp.c - 1.7 drivers/ieee1394/dv1394.c - 1.7 drivers/ieee1394/eth1394.c - 1.8 drivers/ieee1394/nodemgr.c - 1.6 drivers/ieee1394/raw1394-private.h - 1.4 drivers/ieee1394/raw1394.c - 1.8 drivers/ieee1394/raw1394.h - 1.4 drivers/ieee1394/sbp2.c - 1.9 drivers/ieee1394/video1394.c - 1.9 drivers/ieee1394/video1394.h - 1.3 drivers/input/input.c - 1.6 drivers/input/joydev.c - 1.5 drivers/input/joystick/analog.c - 1.4 drivers/input/joystick/grip.c - 1.3 drivers/input/joystick/grip_mp.c - 1.3 drivers/input/keyboard/98kbd.c - 1.4 drivers/input/keyboard/Kconfig - 1.4 drivers/input/keyboard/atkbd.c - 1.6 drivers/input/keyboard/sunkbd.c - 1.4 drivers/input/misc/98spkr.c - 1.3 drivers/input/misc/Kconfig - 1.4 drivers/input/misc/uinput.c - 1.3 drivers/input/mouse/98busmouse.c - 1.4 drivers/input/mouse/Kconfig - 1.6 drivers/input/mouse/Makefile - 1.3 drivers/input/mouse/pc110pad.c - 1.2 drivers/input/serio/98kbd-io.c - 1.3 drivers/input/serio/Kconfig - 1.4 drivers/input/serio/ambakmi.c - 1.3 drivers/input/serio/i8042-io.h - 1.4 drivers/input/tsdev.c - 1.3 drivers/isdn/act2000/act2000.h - 1.3 drivers/isdn/act2000/act2000_isa.c - 1.3 drivers/isdn/act2000/act2000_isa.h - 1.2 drivers/isdn/act2000/module.c - 1.3 drivers/isdn/capi/capi.c - 1.5 drivers/isdn/capi/capidrv.c - 1.3 drivers/isdn/capi/capilib.c - 1.2 drivers/isdn/capi/capiutil.c - 1.2 drivers/isdn/capi/kcapi.c - 1.5 drivers/isdn/capi/kcapi_proc.c - 1.3 drivers/isdn/divert/divert_procfs.c - 1.2 drivers/isdn/hardware/avm/b1.c - 1.3 drivers/isdn/hardware/eicon/capifunc.c - 1.5 drivers/isdn/hardware/eicon/capimain.c - 1.2 drivers/isdn/hardware/eicon/dadapter.c - 1.2 drivers/isdn/hardware/eicon/debug.c - 1.2 drivers/isdn/hardware/eicon/di.c - 1.2 drivers/isdn/hardware/eicon/diddfunc.c - 1.2 drivers/isdn/hardware/eicon/diva.c - 1.4 drivers/isdn/hardware/eicon/diva.h - 1.2 drivers/isdn/hardware/eicon/diva_dma.c - 1.2 drivers/isdn/hardware/eicon/divamnt.c - 1.3 drivers/isdn/hardware/eicon/divasfunc.c - 1.3 drivers/isdn/hardware/eicon/divasi.c - 1.2 drivers/isdn/hardware/eicon/divasmain.c - 1.7 drivers/isdn/hardware/eicon/divasproc.c - 1.3 drivers/isdn/hardware/eicon/dqueue.c - 1.2 drivers/isdn/hardware/eicon/idifunc.c - 1.4 drivers/isdn/hardware/eicon/maintidi.c - 1.2 drivers/isdn/hardware/eicon/message.c - 1.3 drivers/isdn/hardware/eicon/mntfunc.c - 1.3 drivers/isdn/hardware/eicon/os_4bri.c - 1.3 drivers/isdn/hardware/eicon/os_bri.c - 1.3 drivers/isdn/hardware/eicon/os_pri.c - 1.3 drivers/isdn/hardware/eicon/platform.h - 1.4 drivers/isdn/hardware/eicon/um_idi.c - 1.4 drivers/isdn/hisax/Kconfig - 1.3 drivers/isdn/hisax/avm_pci.c - 1.3 drivers/isdn/hisax/callc.c - 1.3 drivers/isdn/hisax/config.c - 1.3 drivers/isdn/hisax/diva.c - 1.3 drivers/isdn/hisax/elsa.c - 1.3 drivers/isdn/hisax/elsa_cs.c - 1.4 drivers/isdn/hisax/elsa_ser.c - 1.3 drivers/isdn/hisax/hfc_2bds0.c - 1.3 drivers/isdn/hisax/hfc_pci.c - 1.3 drivers/isdn/hisax/isac.c - 1.3 drivers/isdn/hisax/isar.c - 1.3 drivers/isdn/hisax/isdnl1.c - 1.3 drivers/isdn/hisax/isdnl2.c - 1.3 drivers/isdn/hisax/isdnl3.c - 1.3 drivers/isdn/hisax/l3_1tr6.c - 1.3 drivers/isdn/hisax/l3dss1.c - 1.3 drivers/isdn/hisax/netjet.c - 1.3 drivers/isdn/hisax/st5481_d.c - 1.5 drivers/isdn/hisax/st5481_hdlc.c - 1.2 drivers/isdn/hisax/tei.c - 1.3 drivers/isdn/hysdn/Kconfig - 1.3 drivers/isdn/hysdn/hycapi.c - 1.2 drivers/isdn/hysdn/hysdn_procconf.c - 1.2 drivers/isdn/hysdn/hysdn_proclog.c - 1.3 drivers/isdn/i4l/isdn_common.c - 1.4 drivers/isdn/i4l/isdn_net.c - 1.3 drivers/isdn/i4l/isdn_net.h - 1.4 drivers/isdn/i4l/isdn_ppp.c - 1.4 drivers/isdn/i4l/isdn_ppp.h - 1.3 drivers/isdn/i4l/isdn_tty.c - 1.3 drivers/isdn/i4l/isdn_x25iface.c - 1.3 drivers/isdn/icn/icn.c - 1.3 drivers/isdn/isdnloop/isdnloop.c - 1.3 drivers/isdn/pcbit/Kconfig - 1.3 drivers/isdn/pcbit/drv.c - 1.3 drivers/isdn/pcbit/module.c - 1.2 drivers/isdn/sc/command.c - 1.3 drivers/isdn/sc/hardware.h - 1.3 drivers/isdn/sc/ioctl.c - 1.4 drivers/isdn/sc/message.c - 1.3 drivers/isdn/sc/packet.c - 1.3 drivers/isdn/sc/scioc.h - 1.2 drivers/isdn/sc/shmem.c - 1.3 drivers/isdn/tpam/Kconfig - 1.3 drivers/isdn/tpam/tpam.h - 1.2 drivers/isdn/tpam/tpam_commands.c - 1.2 drivers/isdn/tpam/tpam_crcpc.c - 1.2 drivers/isdn/tpam/tpam_memory.c - 1.2 drivers/macintosh/adb.c - 1.5 drivers/macintosh/adbhid.c - 1.5 drivers/macintosh/ans-lcd.c - 1.2 drivers/macintosh/macio-adb.c - 1.2 drivers/macintosh/macserial.c - 1.4 drivers/macintosh/mediabay.c - 1.4 drivers/macintosh/via-cuda.c - 1.2 drivers/macintosh/via-pmu.c - 1.7 drivers/macintosh/via-pmu68k.c - 1.2 drivers/md/Kconfig - 1.5 drivers/md/Makefile - 1.5 drivers/md/dm-table.c - 1.7 drivers/md/dm.c - 1.8 drivers/md/multipath.c - 1.6 drivers/md/raid1.c - 1.7 drivers/md/raid5.c - 1.9 drivers/md/xor.c - 1.2 drivers/media/common/saa7146_fops.c - 1.6 drivers/media/common/saa7146_vbi.c - 1.4 drivers/media/common/saa7146_video.c - 1.7 drivers/media/dvb/b2c2/Kconfig - 1.2 drivers/media/dvb/b2c2/skystar2.c - 1.5 drivers/media/dvb/dvb-core/dmxdev.c - 1.2 drivers/media/dvb/dvb-core/dvb_demux.c - 1.5 drivers/media/dvb/dvb-core/dvb_functions.c - 1.2 drivers/media/dvb/dvb-core/dvb_i2c.c - 1.3 drivers/media/dvb/dvb-core/dvb_net.c - 1.4 drivers/media/dvb/dvb-core/dvb_ringbuffer.c - 1.5 drivers/media/dvb/dvb-core/dvb_ringbuffer.h - 1.4 drivers/media/dvb/dvb-core/dvbdev.c - 1.3 drivers/media/dvb/dvb-core/dvbdev.h - 1.3 drivers/media/dvb/frontends/alps_tdlb7.c - 1.5 drivers/media/dvb/frontends/sp887x.c - 1.6 drivers/media/dvb/frontends/stv0299.c - 1.5 drivers/media/dvb/frontends/tda1004x.c - 1.7 drivers/media/dvb/ttpci/av7110.c - 1.6 drivers/media/dvb/ttpci/av7110_ir.c - 1.3 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c - 1.5 drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.8 drivers/media/radio/Kconfig - 1.4 drivers/media/radio/miropcm20-radio.c - 1.2 drivers/media/radio/miropcm20-rds.c - 1.2 drivers/media/radio/radio-cadet.c - 1.3 drivers/media/radio/radio-gemtek.c - 1.2 drivers/media/radio/radio-zoltrix.c - 1.2 drivers/media/video/Kconfig - 1.7 drivers/media/video/Makefile - 1.4 drivers/media/video/bttv-cards.c - 1.4 drivers/media/video/bttv-driver.c - 1.4 drivers/media/video/bttv-risc.c - 1.3 drivers/media/video/bttv-vbi.c - 1.3 drivers/media/video/bttv.h - 1.3 drivers/media/video/bttvp.h - 1.4 drivers/media/video/bw-qcam.c - 1.3 drivers/media/video/c-qcam.c - 1.3 drivers/media/video/cpia.c - 1.2 drivers/media/video/dpc7146.c - 1.5 drivers/media/video/hexium_orion.c - 1.5 drivers/media/video/meye.c - 1.4 drivers/media/video/meye.h - 1.4 drivers/media/video/msp3400.c - 1.6 drivers/media/video/mxb.c - 1.5 drivers/media/video/pms.c - 1.2 drivers/media/video/saa7134/saa6752hs.c - 1.4 drivers/media/video/saa7134/saa7134-cards.c - 1.5 drivers/media/video/saa7134/saa7134-core.c - 1.4 drivers/media/video/saa7134/saa7134-oss.c - 1.4 drivers/media/video/saa7134/saa7134-ts.c - 1.3 drivers/media/video/saa7134/saa7134-tvaudio.c - 1.5 drivers/media/video/saa7134/saa7134-video.c - 1.4 drivers/media/video/saa7134/saa7134.h - 1.5 drivers/media/video/stradis.c - 1.2 drivers/media/video/tda9840.c - 1.2 drivers/media/video/tda9887.c - 1.5 drivers/media/video/tea6415c.c - 1.2 drivers/media/video/tea6420.c - 1.2 drivers/media/video/tuner.c - 1.8 drivers/media/video/tvmixer.c - 1.5 drivers/media/video/v4l1-compat.c - 1.5 drivers/media/video/video-buf.c - 1.6 drivers/media/video/videocodec.c - 1.3 drivers/media/video/videodev.c - 1.5 drivers/media/video/w9966.c - 1.5 drivers/media/video/zoran_driver.c - 1.3 drivers/media/video/zoran_procfs.c - 1.3 drivers/message/fusion/isense.c - 1.4 drivers/message/fusion/linux_compat.h - 1.3 drivers/message/fusion/lsi/mpi_type.h - 1.3 drivers/message/fusion/mptbase.c - 1.8 drivers/message/fusion/mptbase.h - 1.9 drivers/message/fusion/mptctl.c - 1.6 drivers/message/fusion/mptctl.h - 1.5 drivers/message/fusion/mptlan.c - 1.5 drivers/message/fusion/mptscsih.c - 1.9 drivers/message/fusion/mptscsih.h - 1.6 drivers/message/i2o/i2o_block.c - 1.4 drivers/message/i2o/i2o_config.c - 1.3 drivers/message/i2o/i2o_core.c - 1.5 drivers/message/i2o/i2o_proc.c - 1.3 drivers/message/i2o/i2o_scsi.c - 1.4 drivers/mtd/Kconfig - 1.2 drivers/mtd/Makefile - 1.2 drivers/mtd/afs.c - 1.3 drivers/mtd/chips/Kconfig - 1.2 drivers/mtd/chips/Makefile - 1.2 drivers/mtd/chips/amd_flash.c - 1.3 drivers/mtd/chips/cfi_cmdset_0001.c - 1.5 drivers/mtd/chips/cfi_cmdset_0002.c - 1.2 drivers/mtd/chips/cfi_cmdset_0020.c - 1.4 drivers/mtd/chips/cfi_probe.c - 1.2 drivers/mtd/chips/chipreg.c - 1.2 drivers/mtd/chips/gen_probe.c - 1.2 drivers/mtd/chips/jedec.c - 1.2 drivers/mtd/chips/jedec_probe.c - 1.4 drivers/mtd/chips/map_ram.c - 1.2 drivers/mtd/chips/map_rom.c - 1.2 drivers/mtd/chips/sharp.c - 1.3 drivers/mtd/cmdlinepart.c - 1.3 drivers/mtd/devices/Kconfig - 1.3 drivers/mtd/devices/Makefile - 1.2 drivers/mtd/devices/blkmtd.c - 1.5 drivers/mtd/devices/doc2000.c - 1.2 drivers/mtd/devices/doc2001.c - 1.2 drivers/mtd/devices/doc2001plus.c - 1.2 drivers/mtd/devices/docprobe.c - 1.2 drivers/mtd/devices/lart.c - 1.2 drivers/mtd/devices/ms02-nv.c - 1.2 drivers/mtd/devices/ms02-nv.h - 1.2 drivers/mtd/devices/mtdram.c - 1.2 drivers/mtd/devices/pmc551.c - 1.2 drivers/mtd/devices/slram.c - 1.2 drivers/mtd/ftl.c - 1.2 drivers/mtd/inftlcore.c - 1.2 drivers/mtd/inftlmount.c - 1.2 drivers/mtd/maps/Kconfig - 1.4 drivers/mtd/maps/Makefile - 1.3 drivers/mtd/maps/amd76xrom.c - 1.2 drivers/mtd/maps/arctic-mtd.c - 1.2 drivers/mtd/maps/autcpu12-nvram.c - 1.2 drivers/mtd/maps/beech-mtd.c - 1.2 drivers/mtd/maps/cdb89712.c - 1.2 drivers/mtd/maps/ceiva.c - 1.2 drivers/mtd/maps/cfi_flagadm.c - 1.2 drivers/mtd/maps/cstm_mips_ixx.c - 1.2 drivers/mtd/maps/dbox2-flash.c - 1.2 drivers/mtd/maps/dc21285.c - 1.2 drivers/mtd/maps/dilnetpc.c - 1.2 drivers/mtd/maps/ebony.c - 1.2 drivers/mtd/maps/edb7312.c - 1.2 drivers/mtd/maps/elan-104nc.c - 1.3 drivers/mtd/maps/epxa10db-flash.c - 1.2 drivers/mtd/maps/fortunet.c - 1.2 drivers/mtd/maps/h720x-flash.c - 1.2 drivers/mtd/maps/ich2rom.c - 1.2 drivers/mtd/maps/impa7.c - 1.2 drivers/mtd/maps/integrator-flash.c - 1.3 drivers/mtd/maps/iq80310.c - 1.2 drivers/mtd/maps/l440gx.c - 1.2 drivers/mtd/maps/lasat.c - 1.2 drivers/mtd/maps/lubbock-flash.c - 1.5 drivers/mtd/maps/map_funcs.c - 1.3 drivers/mtd/maps/mbx860.c - 1.2 drivers/mtd/maps/netsc520.c - 1.2 drivers/mtd/maps/nettel.c - 1.2 drivers/mtd/maps/ocelot.c - 1.2 drivers/mtd/maps/octagon-5066.c - 1.2 drivers/mtd/maps/pb1xxx-flash.c - 1.2 drivers/mtd/maps/pci.c - 1.2 drivers/mtd/maps/pcmciamtd.c - 1.3 drivers/mtd/maps/physmap.c - 1.2 drivers/mtd/maps/pnc2000.c - 1.2 drivers/mtd/maps/redwood.c - 1.2 drivers/mtd/maps/rpxlite.c - 1.2 drivers/mtd/maps/sa1100-flash.c - 1.3 drivers/mtd/maps/sbc_gxx.c - 1.3 drivers/mtd/maps/sc520cdp.c - 1.2 drivers/mtd/maps/scb2_flash.c - 1.2 drivers/mtd/maps/scx200_docflash.c - 1.2 drivers/mtd/maps/solutionengine.c - 1.3 drivers/mtd/maps/sun_uflash.c - 1.3 drivers/mtd/maps/tqm8xxl.c - 1.3 drivers/mtd/maps/tsunami_flash.c - 1.2 drivers/mtd/maps/uclinux.c - 1.3 drivers/mtd/maps/vmax301.c - 1.2 drivers/mtd/mtd_blkdevs.c - 1.3 drivers/mtd/mtdblock.c - 1.2 drivers/mtd/mtdchar.c - 1.2 drivers/mtd/mtdconcat.c - 1.3 drivers/mtd/mtdcore.c - 1.2 drivers/mtd/mtdpart.c - 1.2 drivers/mtd/nand/Kconfig - 1.3 drivers/mtd/nand/Makefile - 1.2 drivers/mtd/nand/autcpu12.c - 1.2 drivers/mtd/nand/edb7312.c - 1.2 drivers/mtd/nand/nand.c - 1.3 drivers/mtd/nand/nand_ecc.c - 1.2 drivers/mtd/nand/nand_ids.c - 1.2 drivers/mtd/nand/spia.c - 1.2 drivers/mtd/nftlcore.c - 1.2 drivers/mtd/nftlmount.c - 1.2 drivers/mtd/redboot.c - 1.2 drivers/net/3c501.c - 1.4 drivers/net/3c503.c - 1.5 drivers/net/3c505.c - 1.4 drivers/net/3c507.c - 1.4 drivers/net/3c509.c - 1.6 drivers/net/3c515.c - 1.4 drivers/net/3c523.c - 1.3 drivers/net/3c527.c - 1.6 drivers/net/3c59x.c - 1.6 drivers/net/8139too.c - 1.7 drivers/net/82596.c - 1.4 drivers/net/Kconfig - 1.8 drivers/net/Makefile - 1.8 drivers/net/Space.c - 1.6 drivers/net/ac3200.c - 1.5 drivers/net/acenic.c - 1.5 drivers/net/acenic.h - 1.3 drivers/net/acenic_firmware.h - 1.2 drivers/net/amd8111e.c - 1.6 drivers/net/apne.c - 1.6 drivers/net/appletalk/ltpc.c - 1.3 drivers/net/arcnet/arcnet.c - 1.3 drivers/net/arm/Kconfig - 1.2 drivers/net/arm/etherh.c - 1.6 drivers/net/at1700.c - 1.5 drivers/net/bonding/bond_main.c - 1.6 drivers/net/cs89x0.c - 1.5 drivers/net/defxx.c - 1.3 drivers/net/dgrs.c - 1.4 drivers/net/dgrs.h - 1.2 drivers/net/dgrs_asstruct.h - 1.2 drivers/net/dgrs_i82596.h - 1.2 drivers/net/dl2k.c - 1.5 drivers/net/dummy.c - 1.5 drivers/net/e1000/e1000.h - 1.6 drivers/net/e1000/e1000_ethtool.c - 1.6 drivers/net/e1000/e1000_hw.c - 1.5 drivers/net/e1000/e1000_hw.h - 1.6 drivers/net/e1000/e1000_main.c - 1.6 drivers/net/e1000/e1000_osdep.h - 1.4 drivers/net/e2100.c - 1.5 drivers/net/eepro.c - 1.4 drivers/net/eepro100.c - 1.4 drivers/net/eexpress.c - 1.4 drivers/net/epic100.c - 1.4 drivers/net/eql.c - 1.4 drivers/net/es3210.c - 1.5 drivers/net/eth16i.c - 1.4 drivers/net/ethertap.c - 1.4 drivers/net/ewrk3.c - 1.4 drivers/net/fc/iph5526.c - 1.6 drivers/net/fealnx.c - 1.5 drivers/net/fmv18x.c - 1.3 drivers/net/hamachi.c - 1.4 drivers/net/hamradio/6pack.c - 1.5 drivers/net/hamradio/Kconfig - 1.3 drivers/net/hamradio/baycom_epp.c - 1.7 drivers/net/hamradio/hdlcdrv.c - 1.4 drivers/net/hamradio/mkiss.c - 1.3 drivers/net/hamradio/scc.c - 1.5 drivers/net/hp-plus.c - 1.5 drivers/net/hp.c - 1.5 drivers/net/hp100.c - 1.4 drivers/net/ibmlana.c - 1.4 drivers/net/irda/Kconfig - 1.4 drivers/net/irda/ali-ircc.c - 1.7 drivers/net/irda/donauboe.c - 1.4 drivers/net/irda/irtty-sir.c - 1.4 drivers/net/irda/nsc-ircc.c - 1.6 drivers/net/irda/smsc-ircc2.c - 1.6 drivers/net/irda/via-ircc.c - 1.6 drivers/net/irda/via-ircc.h - 1.3 drivers/net/irda/vlsi_ir.c - 1.5 drivers/net/irda/w83977af_ir.c - 1.6 drivers/net/isa-skeleton.c - 1.4 drivers/net/ixgb/ixgb.h - 1.4 drivers/net/ixgb/ixgb_hw.c - 1.3 drivers/net/ixgb/ixgb_main.c - 1.5 drivers/net/ixgb/ixgb_osdep.h - 1.3 drivers/net/jazzsonic.c - 1.3 drivers/net/lance.c - 1.4 drivers/net/lasi_82596.c - 1.5 drivers/net/lne390.c - 1.5 drivers/net/loopback.c - 1.4 drivers/net/lp486e.c - 1.3 drivers/net/mace.c - 1.6 drivers/net/macsonic.c - 1.4 drivers/net/myri_sbus.c - 1.3 drivers/net/natsemi.c - 1.6 drivers/net/ne.c - 1.6 drivers/net/ne2.c - 1.5 drivers/net/ne2k-pci.c - 1.6 drivers/net/ne2k_cbus.c - 1.5 drivers/net/ne2k_cbus.h - 1.3 drivers/net/ne3210.c - 1.4 drivers/net/ni52.c - 1.3 drivers/net/ns83820.c - 1.6 drivers/net/oaknet.c - 1.5 drivers/net/pci-skeleton.c - 1.4 drivers/net/pcmcia/3c574_cs.c - 1.9 drivers/net/pcmcia/3c589_cs.c - 1.7 drivers/net/pcmcia/axnet_cs.c - 1.6 drivers/net/pcmcia/com20020_cs.c - 1.6 drivers/net/pcmcia/fmvj18x_cs.c - 1.7 drivers/net/pcmcia/ibmtr_cs.c - 1.6 drivers/net/pcmcia/nmclan_cs.c - 1.6 drivers/net/pcmcia/pcnet_cs.c - 1.8 drivers/net/pcmcia/smc91c92_cs.c - 1.8 drivers/net/pcmcia/xirc2ps_cs.c - 1.7 drivers/net/pcnet32.c - 1.7 drivers/net/ppp_async.c - 1.4 drivers/net/ppp_generic.c - 1.6 drivers/net/ppp_synctty.c - 1.3 drivers/net/pppoe.c - 1.6 drivers/net/pppox.c - 1.2 drivers/net/r8169.c - 1.5 drivers/net/rrunner.c - 1.4 drivers/net/sb1000.c - 1.4 drivers/net/sb1250-mac.c - 1.7 drivers/net/seeq8005.c - 1.4 drivers/net/sgiseeq.c - 1.5 drivers/net/sis900.c - 1.6 drivers/net/sk98lin/h/skdrv1st.h - 1.5 drivers/net/sk98lin/h/skdrv2nd.h - 1.5 drivers/net/sk98lin/skge.c - 1.9 drivers/net/sk98lin/sktimer.c - 1.5 drivers/net/sk98lin/skvpd.c - 1.5 drivers/net/skfp/cfm.c - 1.2 drivers/net/skfp/drvfbi.c - 1.2 drivers/net/skfp/ecm.c - 1.2 drivers/net/skfp/ess.c - 1.2 drivers/net/skfp/fplustm.c - 1.2 drivers/net/skfp/h/cmtdef.h - 1.2 drivers/net/skfp/h/smtstate.h - 1.2 drivers/net/skfp/h/targetos.h - 1.2 drivers/net/skfp/hwmtm.c - 1.2 drivers/net/skfp/hwt.c - 1.2 drivers/net/skfp/lnkstat.c - 1.2 drivers/net/skfp/pcmplc.c - 1.2 drivers/net/skfp/pmf.c - 1.2 drivers/net/skfp/queue.c - 1.2 drivers/net/skfp/rmt.c - 1.2 drivers/net/skfp/skfddi.c - 1.4 drivers/net/skfp/smt.c - 1.2 drivers/net/skfp/smtdef.c - 1.2 drivers/net/skfp/smtinit.c - 1.2 drivers/net/skfp/smtparse.c - 1.2 drivers/net/skfp/smttimer.c - 1.2 drivers/net/skfp/srf.c - 1.2 drivers/net/slip.c - 1.4 drivers/net/smc-mca.c - 1.4 drivers/net/smc-ultra.c - 1.5 drivers/net/smc-ultra32.c - 1.5 drivers/net/smc9194.c - 1.4 drivers/net/starfire.c - 1.5 drivers/net/stnic.c - 1.6 drivers/net/sun3_82586.c - 1.4 drivers/net/sun3lance.c - 1.6 drivers/net/sunbmac.c - 1.3 drivers/net/sundance.c - 1.6 drivers/net/sungem.c - 1.6 drivers/net/sungem.h - 1.3 drivers/net/sunhme.c - 1.3 drivers/net/sunlance.c - 1.3 drivers/net/sunqe.c - 1.2 drivers/net/tc35815.c - 1.4 drivers/net/tg3.c - 1.9 drivers/net/tg3.h - 1.5 drivers/net/tlan.c - 1.4 drivers/net/tokenring/Kconfig - 1.3 drivers/net/tokenring/ibmtr.c - 1.4 drivers/net/tokenring/lanstreamer.c - 1.3 drivers/net/tokenring/olympic.c - 1.7 drivers/net/tokenring/smctr.c - 1.5 drivers/net/tokenring/tms380tr.c - 1.5 drivers/net/tulip/Kconfig - 1.3 drivers/net/tulip/de4x5.c - 1.5 drivers/net/tulip/dmfe.c - 1.5 drivers/net/tulip/eeprom.c - 1.4 drivers/net/tulip/tulip_core.c - 1.6 drivers/net/tulip/winbond-840.c - 1.5 drivers/net/tulip/xircom_cb.c - 1.4 drivers/net/tulip/xircom_tulip_cb.c - 1.5 drivers/net/typhoon.c - 1.6 drivers/net/via-rhine.c - 1.5 drivers/net/wan/Kconfig - 1.7 drivers/net/wan/c101.c - 1.4 drivers/net/wan/cosa.c - 1.5 drivers/net/wan/cosa.h - 1.2 drivers/net/wan/dscc4.c - 1.4 drivers/net/wan/farsync.c - 1.5 drivers/net/wan/hdlc_cisco.c - 1.4 drivers/net/wan/hdlc_fr.c - 1.4 drivers/net/wan/hdlc_raw.c - 1.3 drivers/net/wan/hdlc_raw_eth.c - 1.3 drivers/net/wan/lmc/lmc_ioctl.h - 1.2 drivers/net/wan/lmc/lmc_main.c - 1.3 drivers/net/wan/lmc/lmc_proto.c - 1.3 drivers/net/wan/n2.c - 1.3 drivers/net/wan/pc300_tty.c - 1.4 drivers/net/wan/sbni.c - 1.5 drivers/net/wan/sbni.h - 1.2 drivers/net/wan/syncppp.c - 1.2 drivers/net/wan/x25_asy.c - 1.4 drivers/net/wd.c - 1.5 drivers/net/wireless/Kconfig - 1.6 drivers/net/wireless/airo.c - 1.8 drivers/net/wireless/airo_cs.c - 1.4 drivers/net/wireless/airport.c - 1.4 drivers/net/wireless/arlan-proc.c - 1.2 drivers/net/wireless/arlan.h - 1.3 drivers/net/wireless/atmel.c - 1.7 drivers/net/wireless/atmel_cs.c - 1.5 drivers/net/wireless/orinoco.c - 1.4 drivers/net/wireless/orinoco_pci.c - 1.6 drivers/net/wireless/orinoco_plx.c - 1.5 drivers/net/wireless/orinoco_tmd.c - 1.5 drivers/net/wireless/ray_cs.c - 1.5 drivers/net/wireless/strip.c - 1.5 drivers/net/yellowfin.c - 1.5 drivers/net/zorro8390.c - 1.7 drivers/oprofile/buffer_sync.c - 1.2 drivers/oprofile/cpu_buffer.c - 1.3 drivers/oprofile/oprofile_files.c - 1.3 drivers/oprofile/oprofilefs.c - 1.3 drivers/parisc/ccio-dma.c - 1.5 drivers/parisc/ccio-rm-dma.c - 1.3 drivers/parisc/dino.c - 1.5 drivers/parisc/iosapic.c - 1.3 drivers/parisc/lba_pci.c - 1.4 drivers/parisc/led.c - 1.4 drivers/parisc/sba_iommu.c - 1.4 drivers/parisc/superio.c - 1.6 drivers/parport/ChangeLog - 1.2 drivers/parport/parport_pc.c - 1.7 drivers/parport/parport_serial.c - 1.2 drivers/parport/procfs.c - 1.5 drivers/pci/Kconfig - 1.3 drivers/pci/Makefile - 1.5 drivers/pci/hotplug.c - 1.4 drivers/pci/hotplug/acpiphp_glue.c - 1.7 drivers/pci/hotplug/cpci_hotplug_core.c - 1.3 drivers/pci/hotplug/cpqphp_ctrl.c - 1.5 drivers/pci/hotplug/ibmphp_hpc.c - 1.2 drivers/pci/pci-driver.c - 1.4 drivers/pci/pci-sysfs.c - 1.5 drivers/pci/pci.c - 1.6 drivers/pci/pci.h - 1.3 drivers/pci/pci.ids - 1.8 drivers/pci/probe.c - 1.11 drivers/pci/quirks.c - 1.6 drivers/pcmcia/Kconfig - 1.4 drivers/pcmcia/Makefile - 1.4 drivers/pcmcia/cardbus.c - 1.3 drivers/pcmcia/cistpl.c - 1.5 drivers/pcmcia/cs.c - 1.7 drivers/pcmcia/cs_internal.h - 1.5 drivers/pcmcia/ds.c - 1.5 drivers/pcmcia/i82092.c - 1.2 drivers/pcmcia/i82365.c - 1.6 drivers/pcmcia/o2micro.h - 1.2 drivers/pcmcia/rsrc_mgr.c - 1.4 drivers/pcmcia/sa1100_generic.c - 1.3 drivers/pcmcia/tcic.c - 1.5 drivers/pcmcia/yenta_socket.c - 1.6 drivers/pnp/isapnp/core.c - 1.5 drivers/pnp/pnpbios/bioscalls.c - 1.4 drivers/pnp/pnpbios/core.c - 1.5 drivers/s390/block/dasd.c - 1.7 drivers/s390/block/dasd_3990_erp.c - 1.6 drivers/s390/block/dasd_devmap.c - 1.5 drivers/s390/block/dasd_diag.c - 1.5 drivers/s390/block/dasd_eckd.c - 1.7 drivers/s390/block/dasd_erp.c - 1.3 drivers/s390/block/dasd_fba.c - 1.4 drivers/s390/block/dasd_genhd.c - 1.5 drivers/s390/block/dasd_int.h - 1.7 drivers/s390/char/sclp.c - 1.5 drivers/s390/char/tape_char.c - 1.6 drivers/s390/cio/Makefile - 1.3 drivers/s390/cio/chsc.c - 1.6 drivers/s390/cio/chsc.h - 1.5 drivers/s390/cio/cio.c - 1.6 drivers/s390/cio/cio.h - 1.4 drivers/s390/cio/css.c - 1.6 drivers/s390/cio/device_fsm.c - 1.7 drivers/s390/cio/device_id.c - 1.4 drivers/s390/cio/device_ops.c - 1.5 drivers/s390/cio/device_pgid.c - 1.6 drivers/s390/cio/device_status.c - 1.5 drivers/s390/cio/qdio.c - 1.6 drivers/s390/cio/qdio.h - 1.4 drivers/s390/cio/requestirq.c - 1.3 drivers/s390/net/Makefile - 1.4 drivers/s390/net/ctcmain.c - 1.6 drivers/s390/net/ctctty.c - 1.7 drivers/s390/net/cu3088.c - 1.3 drivers/s390/net/iucv.c - 1.7 drivers/s390/net/iucv.h - 1.4 drivers/s390/net/lcs.c - 1.7 drivers/s390/net/lcs.h - 1.4 drivers/s390/net/netiucv.c - 1.7 drivers/s390/net/qeth.h - 1.6 drivers/s390/net/qeth_mpc.h - 1.5 drivers/s390/scsi/zfcp_aux.c - 1.6 drivers/s390/scsi/zfcp_ccw.c - 1.6 drivers/s390/scsi/zfcp_def.h - 1.6 drivers/s390/scsi/zfcp_erp.c - 1.7 drivers/s390/scsi/zfcp_ext.h - 1.6 drivers/s390/scsi/zfcp_fsf.c - 1.6 drivers/s390/scsi/zfcp_scsi.c - 1.6 drivers/s390/scsi/zfcp_sysfs_port.c - 1.6 drivers/sbus/char/Kconfig - 1.2 drivers/sbus/char/bbc_envctrl.c - 1.2 drivers/sbus/char/bpp.c - 1.3 drivers/sbus/char/cpwatchdog.c - 1.2 drivers/sbus/char/display7seg.c - 1.2 drivers/sbus/char/envctrl.c - 1.2 drivers/sbus/char/flash.c - 1.2 drivers/sbus/char/openprom.c - 1.2 drivers/sbus/char/riowatchdog.c - 1.2 drivers/sbus/char/rtc.c - 1.3 drivers/sbus/char/vfc_dev.c - 1.4 drivers/sbus/dvma.c - 1.2 drivers/sbus/sbus.c - 1.2 drivers/scsi/3w-xxxx.c - 1.3 drivers/scsi/53c700.c - 1.4 drivers/scsi/53c700.h - 1.5 drivers/scsi/53c7xx.c - 1.3 drivers/scsi/BusLogic.c - 1.7 drivers/scsi/Kconfig - 1.10 drivers/scsi/Makefile - 1.8 drivers/scsi/NCR5380.c - 1.3 drivers/scsi/NCR53C9x.c - 1.3 drivers/scsi/NCR53c406a.c - 1.3 drivers/scsi/NCR_D700.c - 1.2 drivers/scsi/NCR_Q720.c - 1.2 drivers/scsi/a2091.c - 1.2 drivers/scsi/a3000.c - 1.2 drivers/scsi/aacraid/README - 1.4 drivers/scsi/aacraid/TODO - 1.2 drivers/scsi/aacraid/aachba.c - 1.4 drivers/scsi/aacraid/aacraid.h - 1.6 drivers/scsi/aacraid/commctrl.c - 1.4 drivers/scsi/aacraid/comminit.c - 1.4 drivers/scsi/aacraid/linit.c - 1.8 drivers/scsi/aacraid/rx.c - 1.5 drivers/scsi/aacraid/sa.c - 1.6 drivers/scsi/advansys.c - 1.3 drivers/scsi/advansys.h - 1.2 drivers/scsi/aha152x.c - 1.6 drivers/scsi/aha1542.c - 1.4 drivers/scsi/aha1740.c - 1.3 drivers/scsi/aic7xxx/aic79xx_core.c - 1.3 drivers/scsi/aic7xxx/aic79xx_osm.h - 1.3 drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.6 drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.4 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.4 drivers/scsi/aic7xxx/aiclib.c - 1.2 drivers/scsi/aic7xxx_old.c - 1.4 drivers/scsi/amiga7xx.c - 1.3 drivers/scsi/arm/acornscsi.c - 1.3 drivers/scsi/arm/arxescsi.c - 1.3 drivers/scsi/arm/cumana_1.c - 1.2 drivers/scsi/arm/cumana_2.c - 1.3 drivers/scsi/arm/ecoscsi.c - 1.2 drivers/scsi/arm/eesox.c - 1.3 drivers/scsi/arm/fas216.c - 1.2 drivers/scsi/arm/oak.c - 1.2 drivers/scsi/arm/powertec.c - 1.3 drivers/scsi/ata_piix.c - 1.8 drivers/scsi/atari_scsi.c - 1.2 drivers/scsi/atp870u.c - 1.5 drivers/scsi/atp870u.h - 1.3 drivers/scsi/blz1230.c - 1.3 drivers/scsi/blz2060.c - 1.3 drivers/scsi/bvme6000.c - 1.3 drivers/scsi/constants.c - 1.4 drivers/scsi/cpqfcTScontrol.c - 1.3 drivers/scsi/cpqfcTSinit.c - 1.4 drivers/scsi/cpqfcTSworker.c - 1.3 drivers/scsi/cyberstorm.c - 1.3 drivers/scsi/cyberstormII.c - 1.3 drivers/scsi/dc390.h - 1.4 drivers/scsi/dc395x.c - 1.3 drivers/scsi/dec_esp.c - 1.4 drivers/scsi/dmx3191d.c - 1.2 drivers/scsi/dpt_i2o.c - 1.5 drivers/scsi/dpti.h - 1.3 drivers/scsi/dtc.c - 1.2 drivers/scsi/eata.c - 1.3 drivers/scsi/eata_generic.h - 1.2 drivers/scsi/eata_pio.c - 1.2 drivers/scsi/fastlane.c - 1.3 drivers/scsi/fcal.c - 1.3 drivers/scsi/fd_mcs.c - 1.2 drivers/scsi/fdomain.c - 1.2 drivers/scsi/g_NCR5380.c - 1.4 drivers/scsi/gdth.c - 1.5 drivers/scsi/gvp11.c - 1.2 drivers/scsi/hosts.c - 1.5 drivers/scsi/hosts.h - 1.2 drivers/scsi/i60uscsi.c - 1.3 drivers/scsi/ibmmca.c - 1.2 drivers/scsi/ide-scsi.c - 1.7 drivers/scsi/imm.c - 1.5 drivers/scsi/imm.h - 1.4 drivers/scsi/in2000.c - 1.3 drivers/scsi/ini9100u.c - 1.7 drivers/scsi/ips.c - 1.4 drivers/scsi/jazz_esp.c - 1.3 drivers/scsi/lasi700.c - 1.2 drivers/scsi/libata-core.c - 1.9 drivers/scsi/libata-scsi.c - 1.8 drivers/scsi/mac_esp.c - 1.4 drivers/scsi/mac_scsi.c - 1.3 drivers/scsi/mca_53c9x.c - 1.3 drivers/scsi/megaraid.c - 1.7 drivers/scsi/megaraid.h - 1.3 drivers/scsi/mvme147.c - 1.2 drivers/scsi/mvme16x.c - 1.3 drivers/scsi/ncr53c8xx.c - 1.4 drivers/scsi/ncr53c8xx.h - 1.2 drivers/scsi/nsp32.c - 1.3 drivers/scsi/oktagon_esp.c - 1.4 drivers/scsi/osst.c - 1.5 drivers/scsi/pas16.c - 1.2 drivers/scsi/pc980155.c - 1.2 drivers/scsi/pc980155.h - 1.2 drivers/scsi/pci2000.c - 1.4 drivers/scsi/pci2220i.c - 1.3 drivers/scsi/pcmcia/aha152x_stub.c - 1.4 drivers/scsi/pcmcia/fdomain_stub.c - 1.3 drivers/scsi/pcmcia/nsp_cs.c - 1.4 drivers/scsi/pcmcia/qlogic_stub.c - 1.5 drivers/scsi/pluto.c - 1.3 drivers/scsi/ppa.c - 1.5 drivers/scsi/ppa.h - 1.4 drivers/scsi/psi240i.c - 1.2 drivers/scsi/qla1280.c - 1.5 drivers/scsi/qlogicfas.c - 1.4 drivers/scsi/qlogicfc.c - 1.6 drivers/scsi/qlogicisp.c - 1.3 drivers/scsi/sata_promise.c - 1.8 drivers/scsi/sata_sil.c - 1.7 drivers/scsi/sata_svw.c - 1.7 drivers/scsi/sata_via.c - 1.7 drivers/scsi/scsi.c - 1.8 drivers/scsi/scsi.h - 1.3 drivers/scsi/scsi_debug.c - 1.5 drivers/scsi/scsi_debug.h - 1.2 drivers/scsi/scsi_devinfo.c - 1.5 drivers/scsi/scsi_error.c - 1.6 drivers/scsi/scsi_ioctl.c - 1.3 drivers/scsi/scsi_lib.c - 1.7 drivers/scsi/scsi_module.c - 1.2 drivers/scsi/scsi_pc98.c - 1.2 drivers/scsi/scsi_priv.h - 1.5 drivers/scsi/scsi_proc.c - 1.3 drivers/scsi/scsi_scan.c - 1.6 drivers/scsi/scsi_syms.c - 1.2 drivers/scsi/scsi_sysfs.c - 1.6 drivers/scsi/scsicam.c - 1.2 drivers/scsi/scsiiom.c - 1.5 drivers/scsi/sd.c - 1.7 drivers/scsi/seagate.c - 1.2 drivers/scsi/sg.c - 1.8 drivers/scsi/sgiwd93.c - 1.3 drivers/scsi/sim710.c - 1.2 drivers/scsi/sr.c - 1.9 drivers/scsi/sr.h - 1.4 drivers/scsi/sr_ioctl.c - 1.3 drivers/scsi/sr_vendor.c - 1.3 drivers/scsi/st.c - 1.8 drivers/scsi/sun3_scsi.c - 1.2 drivers/scsi/sun3_scsi_vme.c - 1.2 drivers/scsi/sun3x_esp.c - 1.3 drivers/scsi/sym53c416.c - 1.2 drivers/scsi/sym53c8xx_2/sym_fw.c - 1.4 drivers/scsi/sym53c8xx_2/sym_glue.c - 1.6 drivers/scsi/sym53c8xx_2/sym_glue.h - 1.5 drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.6 drivers/scsi/sym53c8xx_2/sym_hipd.h - 1.4 drivers/scsi/sym53c8xx_2/sym_malloc.c - 1.3 drivers/scsi/sym53c8xx_2/sym_misc.h - 1.3 drivers/scsi/sym53c8xx_2/sym_nvram.c - 1.4 drivers/scsi/sym53c8xx_comm.h - 1.4 drivers/scsi/sym53c8xx_defs.h - 1.2 drivers/scsi/t128.c - 1.2 drivers/scsi/tmscsim.c - 1.6 drivers/scsi/tmscsim.h - 1.4 drivers/scsi/u14-34f.c - 1.3 drivers/scsi/ultrastor.c - 1.2 drivers/scsi/wd33c93.c - 1.3 drivers/scsi/wd33c93.h - 1.2 drivers/scsi/wd7000.c - 1.3 drivers/scsi/zalon.c - 1.2 drivers/serial/8250.c - 1.16 drivers/serial/8250_acorn.c - 1.2 drivers/serial/8250_acpi.c - 1.5 drivers/serial/8250_hcdp.c - 1.5 drivers/serial/8250_hcdp.h - 1.3 drivers/serial/8250_pci.c - 1.6 drivers/serial/8250_pnp.c - 1.8 drivers/serial/Kconfig - 1.7 drivers/serial/Makefile - 1.5 drivers/serial/pmac_zilog.c - 1.8 drivers/serial/serial98.c - 1.2 drivers/serial/serial_core.c - 1.9 drivers/serial/suncore.c - 1.2 drivers/serial/sunsu.c - 1.4 drivers/tc/zs.c - 1.4 drivers/telephony/ixj.c - 1.2 drivers/telephony/ixj.h - 1.4 drivers/telephony/phonedev.c - 1.2 drivers/usb/Kconfig - 1.4 drivers/usb/class/audio.c - 1.4 drivers/usb/class/cdc-acm.c - 1.7 drivers/usb/class/usb-midi.c - 1.3 drivers/usb/class/usblp.c - 1.6 drivers/usb/core/buffer.c - 1.5 drivers/usb/core/config.c - 1.5 drivers/usb/core/devices.c - 1.4 drivers/usb/core/devio.c - 1.5 drivers/usb/core/file.c - 1.2 drivers/usb/core/hcd-pci.c - 1.6 drivers/usb/core/hcd.c - 1.8 drivers/usb/core/hcd.h - 1.6 drivers/usb/core/hub.c - 1.9 drivers/usb/core/hub.h - 1.5 drivers/usb/core/inode.c - 1.4 drivers/usb/core/message.c - 1.8 drivers/usb/core/urb.c - 1.5 drivers/usb/core/usb.c - 1.9 drivers/usb/core/usb.h - 1.5 drivers/usb/gadget/Kconfig - 1.7 drivers/usb/gadget/ether.c - 1.9 drivers/usb/gadget/inode.c - 1.4 drivers/usb/gadget/net2280.c - 1.7 drivers/usb/gadget/zero.c - 1.7 drivers/usb/host/ehci-dbg.c - 1.7 drivers/usb/host/ehci-hcd.c - 1.8 drivers/usb/host/ehci-hub.c - 1.6 drivers/usb/host/ehci-mem.c - 1.5 drivers/usb/host/ehci-q.c - 1.6 drivers/usb/host/ehci-sched.c - 1.6 drivers/usb/host/hc_simple.c - 1.2 drivers/usb/host/hc_sl811_rh.c - 1.3 drivers/usb/host/ohci-dbg.c - 1.5 drivers/usb/host/ohci-hcd.c - 1.8 drivers/usb/host/ohci-hub.c - 1.4 drivers/usb/host/ohci-mem.c - 1.4 drivers/usb/host/ohci-pci.c - 1.5 drivers/usb/host/ohci-q.c - 1.7 drivers/usb/host/ohci-sa1111.c - 1.4 drivers/usb/host/ohci.h - 1.5 drivers/usb/host/uhci-debug.c - 1.5 drivers/usb/host/uhci-hcd.c - 1.9 drivers/usb/host/uhci-hub.c - 1.3 drivers/usb/image/hpusbscsi.c - 1.3 drivers/usb/image/mdc800.c - 1.4 drivers/usb/image/microtek.c - 1.3 drivers/usb/input/Kconfig - 1.6 drivers/usb/input/aiptek.c - 1.6 drivers/usb/input/hid-core.c - 1.7 drivers/usb/input/hid-tmff.c - 1.2 drivers/usb/input/hiddev.c - 1.7 drivers/usb/input/powermate.c - 1.5 drivers/usb/media/Kconfig - 1.8 drivers/usb/media/Makefile - 1.3 drivers/usb/media/dabusb.c - 1.3 drivers/usb/media/konicawc.c - 1.3 drivers/usb/media/ov511.c - 1.3 drivers/usb/media/ov511.h - 1.2 drivers/usb/media/pwc-ctrl.c - 1.3 drivers/usb/media/pwc-if.c - 1.4 drivers/usb/media/pwc-ioctl.h - 1.3 drivers/usb/media/pwc-misc.c - 1.3 drivers/usb/media/pwc-uncompress.c - 1.2 drivers/usb/media/pwc-uncompress.h - 1.2 drivers/usb/media/pwc.h - 1.3 drivers/usb/media/se401.c - 1.4 drivers/usb/media/stv680.c - 1.4 drivers/usb/media/usbvideo.c - 1.2 drivers/usb/media/vicam.c - 1.4 drivers/usb/misc/auerswald.c - 1.3 drivers/usb/misc/emi26_fw.h - 1.3 drivers/usb/misc/speedtch.c - 1.5 drivers/usb/misc/tiglusb.c - 1.5 drivers/usb/misc/usbtest.c - 1.7 drivers/usb/net/kaweth.c - 1.4 drivers/usb/net/pegasus.c - 1.4 drivers/usb/net/pegasus.h - 1.5 drivers/usb/net/rtl8150.c - 1.5 drivers/usb/net/usbnet.c - 1.9 drivers/usb/serial/Kconfig - 1.3 drivers/usb/serial/Makefile - 1.2 drivers/usb/serial/belkin_sa.c - 1.4 drivers/usb/serial/bus.c - 1.2 drivers/usb/serial/cyberjack.c - 1.5 drivers/usb/serial/digi_acceleport.c - 1.3 drivers/usb/serial/empeg.c - 1.4 drivers/usb/serial/ezusb.c - 1.2 drivers/usb/serial/ftdi_sio.c - 1.8 drivers/usb/serial/ftdi_sio.h - 1.7 drivers/usb/serial/generic.c - 1.3 drivers/usb/serial/io_edgeport.c - 1.4 drivers/usb/serial/io_ti.c - 1.4 drivers/usb/serial/ipaq.c - 1.3 drivers/usb/serial/ipaq.h - 1.2 drivers/usb/serial/ir-usb.c - 1.4 drivers/usb/serial/keyspan.c - 1.3 drivers/usb/serial/keyspan_pda.c - 1.3 drivers/usb/serial/kl5kusb105.c - 1.4 drivers/usb/serial/kobil_sct.c - 1.6 drivers/usb/serial/mct_u232.c - 1.5 drivers/usb/serial/omninet.c - 1.4 drivers/usb/serial/pl2303.c - 1.7 drivers/usb/serial/pl2303.h - 1.5 drivers/usb/serial/safe_serial.c - 1.4 drivers/usb/serial/usb-serial.c - 1.4 drivers/usb/serial/usb-serial.h - 1.4 drivers/usb/serial/visor.c - 1.8 drivers/usb/serial/visor.h - 1.7 drivers/usb/serial/whiteheat.c - 1.6 drivers/usb/storage/Kconfig - 1.4 drivers/usb/storage/jumpshot.c - 1.5 drivers/usb/storage/scsiglue.c - 1.8 drivers/usb/storage/sddr09.c - 1.5 drivers/usb/storage/transport.c - 1.8 drivers/usb/storage/unusual_devs.h - 1.10 drivers/usb/storage/usb.c - 1.7 drivers/usb/storage/usb.h - 1.4 drivers/video/Kconfig - 1.11 drivers/video/Makefile - 1.8 drivers/video/acornfb.c - 1.5 drivers/video/amifb.c - 1.3 drivers/video/aty/aty128fb.c - 1.5 drivers/video/aty/atyfb_base.c - 1.3 drivers/video/aty/mach64_cursor.c - 1.2 drivers/video/aty/mach64_gx.c - 1.2 drivers/video/cg14.c - 1.3 drivers/video/chipsfb.c - 1.2 drivers/video/cirrusfb.c - 1.4 drivers/video/console/Kconfig - 1.3 drivers/video/console/dummycon.c - 1.3 drivers/video/console/fbcon.c - 1.9 drivers/video/console/fbcon.h - 1.3 drivers/video/console/mdacon.c - 1.4 drivers/video/console/newport_con.c - 1.3 drivers/video/console/promcon.c - 1.4 drivers/video/console/sticon.c - 1.4 drivers/video/console/sticore.c - 1.3 drivers/video/console/vgacon.c - 1.4 drivers/video/dnfb.c - 1.3 drivers/video/fbcmap.c - 1.4 drivers/video/fbmem.c - 1.11 drivers/video/i810/i810_gtf.c - 1.2 drivers/video/imsttfb.c - 1.3 drivers/video/logo/logo.c - 1.3 drivers/video/matrox/matroxfb_base.c - 1.3 drivers/video/matrox/matroxfb_base.h - 1.3 drivers/video/matrox/matroxfb_crtc2.c - 1.3 drivers/video/modedb.c - 1.4 drivers/video/offb.c - 1.3 drivers/video/radeonfb.c - 1.7 drivers/video/riva/Makefile - 1.2 drivers/video/riva/fbdev.c - 1.7 drivers/video/riva/riva_hw.c - 1.2 drivers/video/riva/rivafb.h - 1.2 drivers/video/sa1100fb.c - 1.6 drivers/video/sbuslib.c - 1.3 drivers/video/sis/300vtbl.h - 1.3 drivers/video/sis/310vtbl.h - 1.3 drivers/video/sis/init.c - 1.3 drivers/video/sis/init.h - 1.3 drivers/video/sis/init301.c - 1.5 drivers/video/sis/init301.h - 1.3 drivers/video/sis/initdef.h - 1.3 drivers/video/sis/oem300.h - 1.3 drivers/video/sis/oem310.h - 1.3 drivers/video/sis/osdef.h - 1.3 drivers/video/sis/sis.h - 1.2 drivers/video/sis/sis_accel.c - 1.3 drivers/video/sis/sis_accel.h - 1.3 drivers/video/sis/sis_main.c - 1.3 drivers/video/sis/sis_main.h - 1.3 drivers/video/sis/vgatypes.h - 1.3 drivers/video/sis/vstruct.h - 1.3 drivers/video/skeletonfb.c - 1.2 drivers/video/softcursor.c - 1.4 drivers/video/sstfb.c - 1.2 drivers/video/tdfxfb.c - 1.4 drivers/video/valkyriefb.c - 1.2 drivers/video/vesafb.c - 1.3 drivers/video/vga16fb.c - 1.5 fs/Kconfig - 1.16 fs/affs/amigaffs.c - 1.2 fs/affs/bitmap.c - 1.2 fs/affs/inode.c - 1.2 fs/affs/super.c - 1.4 fs/affs/symlink.c - 1.2 fs/afs/cmservice.c - 1.3 fs/afs/fsclient.c - 1.3 fs/afs/internal.h - 1.3 fs/afs/mntpt.c - 1.3 fs/afs/super.c - 1.5 fs/afs/vlclient.c - 1.3 fs/afs/vlocation.c - 1.3 fs/aio.c - 1.5 fs/attr.c - 1.2 fs/autofs/root.c - 1.2 fs/autofs/symlink.c - 1.2 fs/autofs/waitq.c - 1.2 fs/autofs4/symlink.c - 1.2 fs/autofs4/waitq.c - 1.3 fs/bad_inode.c - 1.2 fs/befs/linuxvfs.c - 1.4 fs/binfmt_aout.c - 1.4 fs/binfmt_elf.c - 1.9 fs/binfmt_flat.c - 1.4 fs/binfmt_misc.c - 1.5 fs/binfmt_script.c - 1.3 fs/bio.c - 1.6 fs/block_dev.c - 1.8 fs/buffer.c - 1.9 fs/cifs/AUTHORS - 1.4 fs/cifs/CHANGES - 1.4 fs/cifs/README - 1.4 fs/cifs/TODO - 1.4 fs/cifs/asn1.c - 1.2 fs/cifs/cifs_debug.c - 1.4 fs/cifs/cifs_fs_sb.h - 1.2 fs/cifs/cifs_uniupr.h - 1.2 fs/cifs/cifsfs.c - 1.5 fs/cifs/cifsfs.h - 1.4 fs/cifs/cifsglob.h - 1.4 fs/cifs/cifspdu.h - 1.4 fs/cifs/cifsproto.h - 1.4 fs/cifs/cifssmb.c - 1.4 fs/cifs/connect.c - 1.5 fs/cifs/dir.c - 1.4 fs/cifs/file.c - 1.5 fs/cifs/inode.c - 1.4 fs/cifs/link.c - 1.4 fs/cifs/misc.c - 1.4 fs/cifs/smbencrypt.c - 1.3 fs/cifs/smberr.h - 1.2 fs/cifs/transport.c - 1.4 fs/cifs/xattr.c - 1.3 fs/coda/cnode.c - 1.2 fs/coda/inode.c - 1.5 fs/coda/psdev.c - 1.4 fs/coda/sysctl.c - 1.3 fs/compat.c - 1.7 fs/compat_ioctl.c - 1.10 fs/dcache.c - 1.8 fs/dcookies.c - 1.3 fs/devfs/base.c - 1.7 fs/direct-io.c - 1.5 fs/dnotify.c - 1.5 fs/dquot.c - 1.6 fs/eventpoll.c - 1.7 fs/exec.c - 1.7 fs/ext2/acl.c - 1.4 fs/ext2/dir.c - 1.3 fs/ext2/inode.c - 1.5 fs/ext2/symlink.c - 1.2 fs/ext2/xattr.c - 1.3 fs/ext3/acl.c - 1.4 fs/ext3/balloc.c - 1.4 fs/ext3/dir.c - 1.3 fs/ext3/inode.c - 1.5 fs/ext3/namei.c - 1.5 fs/ext3/super.c - 1.7 fs/ext3/symlink.c - 1.2 fs/ext3/xattr.c - 1.3 fs/fat/inode.c - 1.6 fs/fcntl.c - 1.7 fs/fifo.c - 1.2 fs/file.c - 1.2 fs/file_table.c - 1.6 fs/freevxfs/vxfs_immed.c - 1.3 fs/fs-writeback.c - 1.8 fs/hfs/btree.c - 1.3 fs/hfs/super.c - 1.5 fs/hpfs/alloc.c - 1.3 fs/hpfs/anode.c - 1.3 fs/hpfs/buffer.c - 1.4 fs/hpfs/ea.c - 1.3 fs/hpfs/hpfs.h - 1.2 fs/hpfs/hpfs_fn.h - 1.3 fs/hpfs/inode.c - 1.3 fs/hpfs/map.c - 1.3 fs/hpfs/super.c - 1.4 fs/hugetlbfs/inode.c - 1.7 fs/inode.c - 1.6 fs/ioctl.c - 1.4 fs/isofs/Makefile - 1.2 fs/isofs/compress.c - 1.2 fs/isofs/dir.c - 1.2 fs/isofs/inode.c - 1.5 fs/isofs/namei.c - 1.2 fs/isofs/rock.c - 1.3 fs/jbd/commit.c - 1.5 fs/jbd/journal.c - 1.4 fs/jbd/revoke.c - 1.4 fs/jbd/transaction.c - 1.5 fs/jffs/inode-v23.c - 1.6 fs/jffs/intrep.c - 1.3 fs/jffs/jffs_fm.c - 1.2 fs/jffs/jffs_proc.c - 1.2 fs/jffs2/Makefile - 1.3 fs/jffs2/background.c - 1.3 fs/jffs2/build.c - 1.2 fs/jffs2/compr.c - 1.2 fs/jffs2/compr_rtime.c - 1.2 fs/jffs2/compr_rubin.c - 1.2 fs/jffs2/compr_zlib.c - 1.2 fs/jffs2/erase.c - 1.2 fs/jffs2/file.c - 1.2 fs/jffs2/fs.c - 1.3 fs/jffs2/gc.c - 1.2 fs/jffs2/ioctl.c - 1.2 fs/jffs2/malloc.c - 1.2 fs/jffs2/nodelist.c - 1.2 fs/jffs2/nodelist.h - 1.2 fs/jffs2/nodemgmt.c - 1.2 fs/jffs2/os-linux.h - 1.2 fs/jffs2/read.c - 1.2 fs/jffs2/readinode.c - 1.2 fs/jffs2/scan.c - 1.2 fs/jffs2/super.c - 1.4 fs/jffs2/symlink.c - 1.2 fs/jffs2/wbuf.c - 1.2 fs/jffs2/write.c - 1.2 fs/jffs2/writev.c - 1.2 fs/jfs/acl.c - 1.3 fs/jfs/file.c - 1.2 fs/jfs/jfs_btree.h - 1.3 fs/jfs/jfs_dmap.c - 1.5 fs/jfs/jfs_dtree.c - 1.6 fs/jfs/jfs_extent.c - 1.3 fs/jfs/jfs_imap.c - 1.5 fs/jfs/jfs_incore.h - 1.4 fs/jfs/jfs_logmgr.c - 1.7 fs/jfs/jfs_metapage.c - 1.4 fs/jfs/jfs_mount.c - 1.4 fs/jfs/jfs_txnmgr.c - 1.7 fs/jfs/jfs_uniupr.c - 1.2 fs/jfs/jfs_xtree.c - 1.4 fs/jfs/namei.c - 1.7 fs/jfs/super.c - 1.6 fs/jfs/symlink.c - 1.2 fs/jfs/xattr.c - 1.5 fs/libfs.c - 1.5 fs/lockd/host.c - 1.3 fs/lockd/svclock.c - 1.3 fs/lockd/svcshare.c - 1.2 fs/lockd/xdr.c - 1.2 fs/lockd/xdr4.c - 1.2 fs/locks.c - 1.7 fs/minix/inode.c - 1.2 fs/mpage.c - 1.3 fs/namei.c - 1.8 fs/namespace.c - 1.6 fs/ncpfs/dir.c - 1.3 fs/ncpfs/inode.c - 1.5 fs/ncpfs/ioctl.c - 1.2 fs/ncpfs/ncplib_kernel.c - 1.3 fs/ncpfs/ncplib_kernel.h - 1.4 fs/ncpfs/sock.c - 1.4 fs/nfs/direct.c - 1.5 fs/nfs/file.c - 1.7 fs/nfs/idmap.c - 1.3 fs/nfs/inode.c - 1.7 fs/nfs/nfs2xdr.c - 1.5 fs/nfs/nfs3xdr.c - 1.5 fs/nfs/nfs4proc.c - 1.5 fs/nfs/nfs4xdr.c - 1.6 fs/nfsctl.c - 1.2 fs/nfsd/nfs3xdr.c - 1.5 fs/nfsd/nfs4proc.c - 1.5 fs/nfsd/nfs4state.c - 1.5 fs/nfsd/nfs4xdr.c - 1.5 fs/nfsd/nfscache.c - 1.2 fs/nfsd/nfsctl.c - 1.4 fs/nfsd/nfsxdr.c - 1.4 fs/nfsd/vfs.c - 1.6 fs/nls/Kconfig - 1.3 fs/nls/Makefile - 1.2 fs/ntfs/ChangeLog - 1.5 fs/ntfs/Makefile - 1.5 fs/ntfs/aops.c - 1.4 fs/ntfs/attrib.c - 1.4 fs/ntfs/compress.c - 1.4 fs/ntfs/dir.c - 1.4 fs/ntfs/inode.c - 1.5 fs/ntfs/inode.h - 1.4 fs/ntfs/layout.h - 1.4 fs/ntfs/malloc.h - 1.4 fs/ntfs/mft.c - 1.3 fs/ntfs/namei.c - 1.4 fs/ntfs/ntfs.h - 1.5 fs/ntfs/super.c - 1.4 fs/ntfs/volume.h - 1.4 fs/open.c - 1.7 fs/openpromfs/inode.c - 1.4 fs/partitions/Kconfig - 1.2 fs/partitions/check.c - 1.5 fs/partitions/msdos.c - 1.3 fs/partitions/nec98.c - 1.2 fs/partitions/nec98.h - 1.2 fs/pipe.c - 1.5 fs/proc/array.c - 1.5 fs/proc/base.c - 1.8 fs/proc/generic.c - 1.5 fs/proc/kcore.c - 1.3 fs/proc/kmsg.c - 1.3 fs/proc/proc_devtree.c - 1.3 fs/proc/proc_misc.c - 1.8 fs/proc/proc_tty.c - 1.4 fs/proc/root.c - 1.3 fs/qnx4/inode.c - 1.3 fs/quota.c - 1.3 fs/read_write.c - 1.6 fs/reiserfs/bitmap.c - 1.3 fs/reiserfs/dir.c - 1.4 fs/reiserfs/do_balan.c - 1.4 fs/reiserfs/file.c - 1.6 fs/reiserfs/fix_node.c - 1.5 fs/reiserfs/ibalance.c - 1.3 fs/reiserfs/inode.c - 1.6 fs/reiserfs/item_ops.c - 1.3 fs/reiserfs/journal.c - 1.7 fs/reiserfs/lbalance.c - 1.3 fs/reiserfs/namei.c - 1.5 fs/reiserfs/prints.c - 1.5 fs/reiserfs/procfs.c - 1.5 fs/reiserfs/stree.c - 1.4 fs/reiserfs/super.c - 1.5 fs/reiserfs/tail_conversion.c - 1.4 fs/seq_file.c - 1.3 fs/smbfs/file.c - 1.6 fs/smbfs/inode.c - 1.4 fs/smbfs/proc.c - 1.5 fs/smbfs/proto.h - 1.2 fs/smbfs/request.h - 1.2 fs/smbfs/smbiod.c - 1.4 fs/smbfs/sock.c - 1.3 fs/smbfs/symlink.c - 1.2 fs/super.c - 1.7 fs/sysfs/file.c - 1.3 fs/sysfs/inode.c - 1.3 fs/sysv/inode.c - 1.3 fs/sysv/itree.c - 1.2 fs/sysv/symlink.c - 1.2 fs/udf/crc.c - 1.2 fs/udf/dir.c - 1.3 fs/udf/misc.c - 1.3 fs/udf/namei.c - 1.4 fs/udf/super.c - 1.5 fs/ufs/balloc.c - 1.2 fs/ufs/symlink.c - 1.2 include/acpi/acpi_drivers.h - 1.3 include/asm-alpha/bitops.h - 1.2 include/asm-alpha/checksum.h - 1.3 include/asm-alpha/core_lca.h - 1.2 include/asm-alpha/fcntl.h - 1.2 include/asm-alpha/fpu.h - 1.2 include/asm-alpha/init.h - 1.2 include/asm-alpha/pgalloc.h - 1.3 include/asm-alpha/resource.h - 1.2 include/asm-alpha/signal.h - 1.3 include/asm-alpha/smp.h - 1.3 include/asm-alpha/spinlock.h - 1.3 include/asm-alpha/system.h - 1.2 include/asm-alpha/topology.h - 1.4 include/asm-alpha/uaccess.h - 1.3 include/asm-arm/arch-adifcc/adi_evb.h - 1.2 include/asm-arm/arch-adifcc/dma.h - 1.2 include/asm-arm/arch-adifcc/hardware.h - 1.2 include/asm-arm/arch-adifcc/io.h - 1.2 include/asm-arm/arch-adifcc/irqs.h - 1.2 include/asm-arm/arch-adifcc/memory.h - 1.3 include/asm-arm/arch-adifcc/param.h - 1.2 include/asm-arm/arch-adifcc/serial.h - 1.2 include/asm-arm/arch-adifcc/system.h - 1.2 include/asm-arm/arch-adifcc/time.h - 1.2 include/asm-arm/arch-adifcc/timex.h - 1.2 include/asm-arm/arch-adifcc/uncompress.h - 1.2 include/asm-arm/arch-adifcc/vmalloc.h - 1.3 include/asm-arm/arch-cl7500/time.h - 1.2 include/asm-arm/arch-ebsa110/io.h - 1.4 include/asm-arm/arch-ebsa110/time.h - 1.2 include/asm-arm/arch-ebsa110/uncompress.h - 1.3 include/asm-arm/arch-ebsa285/time.h - 1.3 include/asm-arm/arch-epxa10db/time.h - 1.2 include/asm-arm/arch-integrator/impd1.h - 1.2 include/asm-arm/arch-integrator/platform.h - 1.2 include/asm-arm/arch-iop3xx/time.h - 1.2 include/asm-arm/arch-nexuspci/dma.h - 1.2 include/asm-arm/arch-nexuspci/hardware.h - 1.2 include/asm-arm/arch-nexuspci/io.h - 1.3 include/asm-arm/arch-nexuspci/irqs.h - 1.2 include/asm-arm/arch-nexuspci/memory.h - 1.3 include/asm-arm/arch-nexuspci/param.h - 1.2 include/asm-arm/arch-nexuspci/system.h - 1.2 include/asm-arm/arch-nexuspci/time.h - 1.2 include/asm-arm/arch-nexuspci/timex.h - 1.2 include/asm-arm/arch-nexuspci/uncompress.h - 1.2 include/asm-arm/arch-nexuspci/vmalloc.h - 1.3 include/asm-arm/arch-pxa/hardware.h - 1.3 include/asm-arm/arch-pxa/time.h - 1.3 include/asm-arm/arch-rpc/time.h - 1.2 include/asm-arm/arch-rpc/uncompress.h - 1.2 include/asm-arm/arch-sa1100/dma.h - 1.2 include/asm-arm/arch-sa1100/irqs.h - 1.2 include/asm-arm/arch-sa1100/memory.h - 1.3 include/asm-arm/arch-sa1100/time.h - 1.3 include/asm-arm/arch-shark/dma.h - 1.2 include/asm-arm/arch-shark/memory.h - 1.3 include/asm-arm/arch-shark/time.h - 1.3 include/asm-arm/arch-tbox/dma.h - 1.2 include/asm-arm/arch-tbox/hardware.h - 1.2 include/asm-arm/arch-tbox/io.h - 1.2 include/asm-arm/arch-tbox/irqs.h - 1.2 include/asm-arm/arch-tbox/memory.h - 1.3 include/asm-arm/arch-tbox/param.h - 1.2 include/asm-arm/arch-tbox/serial.h - 1.2 include/asm-arm/arch-tbox/system.h - 1.2 include/asm-arm/arch-tbox/time.h - 1.2 include/asm-arm/arch-tbox/timex.h - 1.2 include/asm-arm/arch-tbox/uncompress.h - 1.2 include/asm-arm/arch-tbox/vmalloc.h - 1.3 include/asm-arm/bitops.h - 1.4 include/asm-arm/cacheflush.h - 1.6 include/asm-arm/checksum.h - 1.2 include/asm-arm/cpu-multi32.h - 1.2 include/asm-arm/cpu-single.h - 1.2 include/asm-arm/dma-mapping.h - 1.5 include/asm-arm/dma.h - 1.2 include/asm-arm/ecard.h - 1.3 include/asm-arm/fcntl.h - 1.2 include/asm-arm/fpstate.h - 1.2 include/asm-arm/ide.h - 1.4 include/asm-arm/io.h - 1.3 include/asm-arm/ipc.h - 1.2 include/asm-arm/mach/arch.h - 1.3 include/asm-arm/memory.h - 1.4 include/asm-arm/proc-fns.h - 1.4 include/asm-arm/processor.h - 1.2 include/asm-arm/resource.h - 1.2 include/asm-arm/scatterlist.h - 1.2 include/asm-arm/setup.h - 1.5 include/asm-arm/signal.h - 1.2 include/asm-arm/thread_info.h - 1.6 include/asm-arm/uaccess.h - 1.4 include/asm-arm26/fcntl.h - 1.2 include/asm-arm26/io.h - 1.3 include/asm-arm26/resource.h - 1.2 include/asm-arm26/setup.h - 1.2 include/asm-arm26/tlb.h - 1.2 include/asm-cris/fcntl.h - 1.2 include/asm-cris/resource.h - 1.2 include/asm-cris/setup.h - 1.2 include/asm-generic/bitops.h - 1.2 include/asm-generic/cpumask_arith.h - 1.4 include/asm-generic/cpumask_array.h - 1.4 include/asm-generic/cpumask_const_reference.h - 1.2 include/asm-generic/cpumask_const_value.h - 1.3 include/asm-generic/cpumask_up.h - 1.3 include/asm-generic/pgtable.h - 1.4 include/asm-generic/rtc.h - 1.2 include/asm-generic/siginfo.h - 1.4 include/asm-generic/tlb.h - 1.3 include/asm-h8300/fcntl.h - 1.2 include/asm-h8300/h8300_ne.h - 1.3 include/asm-h8300/init.h - 1.2 include/asm-h8300/io.h - 1.6 include/asm-h8300/resource.h - 1.2 include/asm-h8300/setup.h - 1.2 include/asm-i386/apic.h - 1.4 include/asm-i386/bitops.h - 1.4 include/asm-i386/checksum.h - 1.2 include/asm-i386/cpufeature.h - 1.3 include/asm-i386/delay.h - 1.2 include/asm-i386/desc.h - 1.2 include/asm-i386/dma-mapping.h - 1.4 include/asm-i386/elf.h - 1.2 include/asm-i386/fcntl.h - 1.2 include/asm-i386/genapic.h - 1.4 include/asm-i386/hpet.h - 1.3 include/asm-i386/ide.h - 1.4 include/asm-i386/init.h - 1.2 include/asm-i386/io_apic.h - 1.3 include/asm-i386/mach-bigsmp/mach_apic.h - 1.5 include/asm-i386/mach-bigsmp/mach_mpspec.h - 1.2 include/asm-i386/mach-default/mach_apic.h - 1.4 include/asm-i386/mach-default/mach_mpspec.h - 1.2 include/asm-i386/mach-default/setup_arch_post.h - 1.2 include/asm-i386/mach-es7000/mach_apic.h - 1.5 include/asm-i386/mach-es7000/mach_ipi.h - 1.3 include/asm-i386/mach-es7000/mach_mpspec.h - 1.2 include/asm-i386/mach-generic/mach_apic.h - 1.4 include/asm-i386/mach-generic/mach_mpspec.h - 1.3 include/asm-i386/mach-numaq/mach_apic.h - 1.3 include/asm-i386/mach-numaq/mach_mpspec.h - 1.2 include/asm-i386/mach-pc9800/apm.h - 1.2 include/asm-i386/mach-pc9800/bios_ebda.h - 1.2 include/asm-i386/mach-pc9800/do_timer.h - 1.2 include/asm-i386/mach-pc9800/io_ports.h - 1.2 include/asm-i386/mach-pc9800/irq_vectors.h - 1.3 include/asm-i386/mach-pc9800/mach_reboot.h - 1.2 include/asm-i386/mach-pc9800/mach_time.h - 1.2 include/asm-i386/mach-pc9800/mach_timer.h - 1.2 include/asm-i386/mach-pc9800/mach_traps.h - 1.2 include/asm-i386/mach-pc9800/mach_wakecpu.h - 1.2 include/asm-i386/mach-pc9800/pci-functions.h - 1.2 include/asm-i386/mach-pc9800/setup_arch_post.h - 1.2 include/asm-i386/mach-pc9800/setup_arch_pre.h - 1.2 include/asm-i386/mach-pc9800/smpboot_hooks.h - 1.2 include/asm-i386/mach-summit/mach_apic.h - 1.3 include/asm-i386/mach-summit/mach_mpspec.h - 1.3 include/asm-i386/mach-visws/mach_apic.h - 1.3 include/asm-i386/mach-visws/setup_arch_post.h - 1.2 include/asm-i386/mach-voyager/setup_arch_post.h - 1.2 include/asm-i386/mmzone.h - 1.4 include/asm-i386/mpspec.h - 1.5 include/asm-i386/mpspec_def.h - 1.2 include/asm-i386/msr.h - 1.2 include/asm-i386/page.h - 1.2 include/asm-i386/param.h - 1.4 include/asm-i386/pc9800.h - 1.2 include/asm-i386/pc9800_sca.h - 1.2 include/asm-i386/pgtable-2level.h - 1.2 include/asm-i386/pgtable-3level.h - 1.2 include/asm-i386/pgtable.h - 1.6 include/asm-i386/processor.h - 1.6 include/asm-i386/resource.h - 1.2 include/asm-i386/serial.h - 1.2 include/asm-i386/setup.h - 1.5 include/asm-i386/signal.h - 1.2 include/asm-i386/spinlock.h - 1.4 include/asm-i386/string.h - 1.4 include/asm-i386/suspend.h - 1.2 include/asm-i386/system.h - 1.4 include/asm-i386/timex.h - 1.3 include/asm-i386/uaccess.h - 1.4 include/asm-i386/unistd.h - 1.7 include/asm-i386/upd4990a.h - 1.2 include/asm-ia64/atomic.h - 1.3 include/asm-ia64/dma-mapping.h - 1.3 include/asm-ia64/elf.h - 1.2 include/asm-ia64/fcntl.h - 1.3 include/asm-ia64/gcc_intrin.h - 1.4 include/asm-ia64/ia32.h - 1.4 include/asm-ia64/iosapic.h - 1.4 include/asm-ia64/irq.h - 1.3 include/asm-ia64/machvec.h - 1.5 include/asm-ia64/machvec_sn2.h - 1.5 include/asm-ia64/numnodes.h - 1.3 include/asm-ia64/page.h - 1.5 include/asm-ia64/pgalloc.h - 1.2 include/asm-ia64/pgtable.h - 1.6 include/asm-ia64/processor.h - 1.8 include/asm-ia64/resource.h - 1.3 include/asm-ia64/smp.h - 1.4 include/asm-ia64/sn/bte.h - 1.4 include/asm-ia64/sn/module.h - 1.6 include/asm-ia64/sn/pda.h - 1.4 include/asm-ia64/sn/sn2/io.h - 1.3 include/asm-ia64/sn/sn_cpuid.h - 1.3 include/asm-ia64/sn/sn_sal.h - 1.5 include/asm-ia64/system.h - 1.4 include/asm-ia64/thread_info.h - 1.2 include/asm-ia64/tlb.h - 1.4 include/asm-ia64/unistd.h - 1.6 include/asm-m68k/atomic.h - 1.2 include/asm-m68k/bitops.h - 1.6 include/asm-m68k/fcntl.h - 1.2 include/asm-m68k/hardirq.h - 1.2 include/asm-m68k/init.h - 1.2 include/asm-m68k/io.h - 1.6 include/asm-m68k/math-emu.h - 1.2 include/asm-m68k/motorola_pgalloc.h - 1.2 include/asm-m68k/page.h - 1.4 include/asm-m68k/resource.h - 1.2 include/asm-m68k/semaphore.h - 1.3 include/asm-m68k/setup.h - 1.3 include/asm-m68k/string.h - 1.4 include/asm-m68k/sun3_pgalloc.h - 1.3 include/asm-m68k/ucontext.h - 1.2 include/asm-m68knommu/init.h - 1.2 include/asm-m68knommu/setup.h - 1.2 include/asm-mips/asmmacro.h - 1.2 include/asm-mips/atomic.h - 1.4 include/asm-mips/bootinfo.h - 1.4 include/asm-mips/cache.h - 1.3 include/asm-mips/checksum.h - 1.4 include/asm-mips/fcntl.h - 1.2 include/asm-mips/init.h - 1.2 include/asm-mips/mipsregs.h - 1.4 include/asm-mips/mmu_context.h - 1.4 include/asm-mips/module.h - 1.3 include/asm-mips/mv64340.h - 1.4 include/asm-mips/page.h - 1.4 include/asm-mips/pci.h - 1.7 include/asm-mips/pgtable-32.h - 1.4 include/asm-mips/pgtable-64.h - 1.5 include/asm-mips/pgtable-bits.h - 1.3 include/asm-mips/pgtable.h - 1.3 include/asm-mips/processor.h - 1.5 include/asm-mips/resource.h - 1.2 include/asm-mips/semaphore.h - 1.3 include/asm-mips/serial.h - 1.4 include/asm-mips/smp.h - 1.5 include/asm-mips/stackframe.h - 1.4 include/asm-mips/system.h - 1.3 include/asm-mips/thread_info.h - 1.4 include/asm-mips/unistd.h - 1.5 include/asm-mips/vr41xx/capcella.h - 1.2 include/asm-mips/vr41xx/eagle.h - 1.2 include/asm-mips/vr41xx/mpc30x.h - 1.3 include/asm-mips/vr41xx/tb0226.h - 1.2 include/asm-mips/vr41xx/tb0229.h - 1.2 include/asm-mips/vr41xx/vr41xx.h - 1.5 include/asm-mips/vr41xx/vrc4173.h - 1.3 include/asm-parisc/assembly.h - 1.2 include/asm-parisc/bitops.h - 1.3 include/asm-parisc/cacheflush.h - 1.4 include/asm-parisc/checksum.h - 1.2 include/asm-parisc/dma-mapping.h - 1.5 include/asm-parisc/fcntl.h - 1.2 include/asm-parisc/hardware.h - 1.3 include/asm-parisc/io.h - 1.4 include/asm-parisc/mmzone.h - 1.2 include/asm-parisc/page.h - 1.3 include/asm-parisc/pci.h - 1.5 include/asm-parisc/pdc.h - 1.4 include/asm-parisc/pdcpat.h - 1.2 include/asm-parisc/pgalloc.h - 1.3 include/asm-parisc/pgtable.h - 1.4 include/asm-parisc/resource.h - 1.2 include/asm-parisc/setup.h - 1.2 include/asm-parisc/smp.h - 1.4 include/asm-parisc/spinlock.h - 1.3 include/asm-parisc/system.h - 1.3 include/asm-parisc/thread_info.h - 1.2 include/asm-parisc/unistd.h - 1.6 include/asm-ppc/checksum.h - 1.2 include/asm-ppc/commproc.h - 1.2 include/asm-ppc/cpm_8260.h - 1.2 include/asm-ppc/cputable.h - 1.4 include/asm-ppc/elf.h - 1.4 include/asm-ppc/fcntl.h - 1.2 include/asm-ppc/highmem.h - 1.5 include/asm-ppc/immap_8260.h - 1.2 include/asm-ppc/io.h - 1.5 include/asm-ppc/irq.h - 1.3 include/asm-ppc/machdep.h - 1.5 include/asm-ppc/mmu.h - 1.3 include/asm-ppc/mmu_context.h - 1.3 include/asm-ppc/mpc10x.h - 1.2 include/asm-ppc/mpc8260.h - 1.4 include/asm-ppc/ocp.h - 1.3 include/asm-ppc/ocp_ids.h - 1.3 include/asm-ppc/open_pic.h - 1.4 include/asm-ppc/pgtable.h - 1.6 include/asm-ppc/pmac_feature.h - 1.4 include/asm-ppc/ppc405_dma.h - 1.2 include/asm-ppc/ppc_asm.h - 1.3 include/asm-ppc/ppcboot.h - 1.2 include/asm-ppc/processor.h - 1.3 include/asm-ppc/ptrace.h - 1.3 include/asm-ppc/reg.h - 1.5 include/asm-ppc/reg_booke.h - 1.5 include/asm-ppc/resource.h - 1.2 include/asm-ppc/serial.h - 1.3 include/asm-ppc/setup.h - 1.2 include/asm-ppc/signal.h - 1.2 include/asm-ppc/smp.h - 1.3 include/asm-ppc/system.h - 1.4 include/asm-ppc/tlbflush.h - 1.3 include/asm-ppc/uaccess.h - 1.3 include/asm-ppc/ucontext.h - 1.2 include/asm-ppc/uninorth.h - 1.3 include/asm-ppc64/bitops.h - 1.3 include/asm-ppc64/cputable.h - 1.5 include/asm-ppc64/current.h - 1.3 include/asm-ppc64/eeh.h - 1.6 include/asm-ppc64/fcntl.h - 1.2 include/asm-ppc64/hardirq.h - 1.2 include/asm-ppc64/iSeries/HvCall.h - 1.3 include/asm-ppc64/iSeries/HvTypes.h - 1.3 include/asm-ppc64/init.h - 1.2 include/asm-ppc64/irq.h - 1.6 include/asm-ppc64/machdep.h - 1.7 include/asm-ppc64/mmu.h - 1.7 include/asm-ppc64/mmu_context.h - 1.6 include/asm-ppc64/paca.h - 1.7 include/asm-ppc64/page.h - 1.7 include/asm-ppc64/pci-bridge.h - 1.4 include/asm-ppc64/pgalloc.h - 1.5 include/asm-ppc64/pgtable.h - 1.7 include/asm-ppc64/ppc_asm.h - 1.4 include/asm-ppc64/processor.h - 1.8 include/asm-ppc64/prom.h - 1.7 include/asm-ppc64/ptrace.h - 1.4 include/asm-ppc64/resource.h - 1.2 include/asm-ppc64/rtas.h - 1.6 include/asm-ppc64/setup.h - 1.2 include/asm-ppc64/signal.h - 1.3 include/asm-ppc64/smp.h - 1.6 include/asm-ppc64/spinlock.h - 1.3 include/asm-ppc64/system.h - 1.7 include/asm-ppc64/systemcfg.h - 1.3 include/asm-ppc64/thread_info.h - 1.5 include/asm-ppc64/time.h - 1.2 include/asm-ppc64/uaccess.h - 1.5 include/asm-ppc64/udbg.h - 1.2 include/asm-ppc64/xics.h - 1.2 include/asm-s390/byteorder.h - 1.5 include/asm-s390/debug.h - 1.4 include/asm-s390/fcntl.h - 1.2 include/asm-s390/init.h - 1.2 include/asm-s390/percpu.h - 1.3 include/asm-s390/pgtable.h - 1.6 include/asm-s390/processor.h - 1.6 include/asm-s390/resource.h - 1.2 include/asm-s390/setup.h - 1.4 include/asm-s390/sigp.h - 1.3 include/asm-s390/smp.h - 1.4 include/asm-s390/thread_info.h - 1.4 include/asm-s390/vtoc.h - 1.2 include/asm-sh/bugs.h - 1.2 include/asm-sh/cache.h - 1.4 include/asm-sh/checksum.h - 1.2 include/asm-sh/cpu-sh4/dma.h - 1.4 include/asm-sh/dma-mapping.h - 1.3 include/asm-sh/dma.h - 1.4 include/asm-sh/fcntl.h - 1.2 include/asm-sh/ide.h - 1.4 include/asm-sh/init.h - 1.2 include/asm-sh/irq.h - 1.5 include/asm-sh/machvec.h - 1.3 include/asm-sh/pgalloc.h - 1.4 include/asm-sh/pgtable.h - 1.5 include/asm-sh/processor.h - 1.5 include/asm-sh/resource.h - 1.2 include/asm-sh/serial.h - 1.2 include/asm-sh/sigcontext.h - 1.3 include/asm-sh/ubc.h - 1.2 include/asm-sh/unistd.h - 1.5 include/asm-sparc/bitops.h - 1.2 include/asm-sparc/bpp.h - 1.2 include/asm-sparc/bug.h - 1.2 include/asm-sparc/checksum.h - 1.3 include/asm-sparc/dma.h - 1.2 include/asm-sparc/fcntl.h - 1.2 include/asm-sparc/init.h - 1.2 include/asm-sparc/openpromio.h - 1.2 include/asm-sparc/pci.h - 1.5 include/asm-sparc/pgtable.h - 1.6 include/asm-sparc/pgtsrmmu.h - 1.6 include/asm-sparc/pgtsun4.h - 1.3 include/asm-sparc/processor.h - 1.4 include/asm-sparc/resource.h - 1.2 include/asm-sparc/sun4prom.h - 1.2 include/asm-sparc/system.h - 1.4 include/asm-sparc/vfc_ioctls.h - 1.2 include/asm-sparc64/asi.h - 1.2 include/asm-sparc64/bitops.h - 1.3 include/asm-sparc64/bpp.h - 1.2 include/asm-sparc64/bug.h - 1.2 include/asm-sparc64/byteorder.h - 1.2 include/asm-sparc64/cacheflush.h - 1.3 include/asm-sparc64/checksum.h - 1.2 include/asm-sparc64/fbio.h - 1.2 include/asm-sparc64/fcntl.h - 1.2 include/asm-sparc64/floppy.h - 1.3 include/asm-sparc64/init.h - 1.2 include/asm-sparc64/io.h - 1.5 include/asm-sparc64/mmu_context.h - 1.3 include/asm-sparc64/openpromio.h - 1.2 include/asm-sparc64/page.h - 1.4 include/asm-sparc64/pgalloc.h - 1.4 include/asm-sparc64/pgtable.h - 1.5 include/asm-sparc64/resource.h - 1.2 include/asm-sparc64/siginfo.h - 1.5 include/asm-sparc64/signal.h - 1.4 include/asm-sparc64/spinlock.h - 1.4 include/asm-sparc64/string.h - 1.2 include/asm-sparc64/system.h - 1.3 include/asm-sparc64/thread_info.h - 1.4 include/asm-sparc64/tlb.h - 1.2 include/asm-sparc64/tlbflush.h - 1.3 include/asm-sparc64/ttable.h - 1.2 include/asm-um/init.h - 1.2 include/asm-v850/bitops.h - 1.3 include/asm-v850/fcntl.h - 1.2 include/asm-v850/irq.h - 1.3 include/asm-v850/resource.h - 1.2 include/asm-v850/unistd.h - 1.4 include/asm-x86_64/acpi.h - 1.7 include/asm-x86_64/bootsetup.h - 1.3 include/asm-x86_64/compat.h - 1.5 include/asm-x86_64/fcntl.h - 1.2 include/asm-x86_64/hw_irq.h - 1.5 include/asm-x86_64/i387.h - 1.4 include/asm-x86_64/init.h - 1.2 include/asm-x86_64/io_apic.h - 1.3 include/asm-x86_64/irq.h - 1.4 include/asm-x86_64/mpspec.h - 1.4 include/asm-x86_64/pgtable.h - 1.6 include/asm-x86_64/processor.h - 1.7 include/asm-x86_64/resource.h - 1.2 include/asm-x86_64/setup.h - 1.2 include/asm-x86_64/signal.h - 1.2 include/asm-x86_64/smp.h - 1.8 include/asm-x86_64/string.h - 1.2 include/asm-x86_64/suspend.h - 1.2 include/asm-x86_64/topology.h - 1.4 include/asm-x86_64/uaccess.h - 1.3 include/asm-x86_64/vsyscall32.h - 1.4 include/linux/802_11.h - 1.2 include/linux/acct.h - 1.2 include/linux/acpi.h - 1.6 include/linux/acpi_serial.h - 1.2 include/linux/adb_mouse.h - 1.2 include/linux/affs_fs.h - 1.2 include/linux/affs_fs_sb.h - 1.2 include/linux/aio.h - 1.5 include/linux/ata.h - 1.5 include/linux/atapi.h - 1.2 include/linux/atm.h - 1.3 include/linux/atmdev.h - 1.5 include/linux/atmlec.h - 1.2 include/linux/binfmts.h - 1.3 include/linux/bio.h - 1.6 include/linux/bitmap.h - 1.7 include/linux/blkdev.h - 1.9 include/linux/blockgroup_lock.h - 1.2 include/linux/bootmem.h - 1.2 include/linux/byteorder/swab.h - 1.3 include/linux/capi.h - 1.2 include/linux/cciss_ioctl.h - 1.4 include/linux/cd1400.h - 1.2 include/linux/cdk.h - 1.2 include/linux/cdrom.h - 1.6 include/linux/coda_proc.h - 1.3 include/linux/compat_ioctl.h - 1.9 include/linux/compiler-gcc+.h - 1.3 include/linux/compiler-gcc3.h - 1.5 include/linux/compiler.h - 1.8 include/linux/comstats.h - 1.2 include/linux/console.h - 1.12 include/linux/console_struct.h - 1.2 include/linux/cpu.h - 1.7 include/linux/cpumask.h - 1.7 include/linux/dcache.h - 1.5 include/linux/dcookies.h - 1.2 include/linux/device.h - 1.8 include/linux/dma-mapping.h - 1.4 include/linux/dvb/osd.h - 1.2 include/linux/dvb/video.h - 1.3 include/linux/efi.h - 1.7 include/linux/elf.h - 1.4 include/linux/errqueue.h - 1.2 include/linux/ext3_fs.h - 1.2 include/linux/fb.h - 1.8 include/linux/fd.h - 1.4 include/linux/filter.h - 1.2 include/linux/fs.h - 1.9 include/linux/fsfilter.h - 1.3 include/linux/ftape.h - 1.2 include/linux/generic_serial.h - 1.2 include/linux/genhd.h - 1.4 include/linux/hugetlb.h - 1.7 include/linux/i2c-id.h - 1.6 include/linux/i2o-dev.h - 1.4 include/linux/i2o.h - 1.4 include/linux/icmpv6.h - 1.3 include/linux/ide.h - 1.14 include/linux/idr.h - 1.5 include/linux/if.h - 1.4 include/linux/if_pppox.h - 1.2 include/linux/if_vlan.h - 1.4 include/linux/in_systm.h - 1.2 include/linux/init.h - 1.5 include/linux/init_task.h - 1.5 include/linux/interrupt.h - 1.3 include/linux/ip.h - 1.3 include/linux/ipmi.h - 1.3 include/linux/ipmi_msgdefs.h - 1.3 include/linux/ipmi_smi.h - 1.3 include/linux/isdn_lzscomp.h - 1.2 include/linux/isdn_ppp.h - 1.3 include/linux/isdnif.h - 1.3 include/linux/iso_fs.h - 1.2 include/linux/iso_fs_i.h - 1.2 include/linux/istallion.h - 1.3 include/linux/ixjuser.h - 1.2 include/linux/jbd.h - 1.3 include/linux/jffs2.h - 1.2 include/linux/jffs2_fs_i.h - 1.2 include/linux/kallsyms.h - 1.3 include/linux/kd.h - 1.3 include/linux/kernel.h - 1.8 include/linux/kernelcapi.h - 1.3 include/linux/libata.h - 1.8 include/linux/list.h - 1.5 include/linux/mca.h - 1.3 include/linux/miscdevice.h - 1.4 include/linux/mm.h - 1.11 include/linux/mmzone.h - 1.9 include/linux/module.h - 1.6 include/linux/mount.h - 1.2 include/linux/mpp.h - 1.2 include/linux/mtd/cfi.h - 1.2 include/linux/mtd/doc2000.h - 1.2 include/linux/mtd/flashchip.h - 1.2 include/linux/mtd/ftl.h - 1.2 include/linux/mtd/gen_probe.h - 1.2 include/linux/mtd/inftl.h - 1.2 include/linux/mtd/map.h - 1.2 include/linux/mtd/mtd.h - 1.2 include/linux/mtd/nand.h - 1.2 include/linux/mtd/nand_ecc.h - 1.2 include/linux/mtd/nftl.h - 1.2 include/linux/mtd/partitions.h - 1.2 include/linux/mtio.h - 1.2 include/linux/namei.h - 1.2 include/linux/namespace.h - 1.2 include/linux/ncp_fs.h - 1.2 include/linux/net.h - 1.5 include/linux/netbeui.h - 1.2 include/linux/netdevice.h - 1.10 include/linux/netfilter.h - 1.4 include/linux/netfilter_arp/arp_tables.h - 1.3 include/linux/netfilter_ddp.h - 1.2 include/linux/netfilter_ipv4/ip_conntrack.h - 1.4 include/linux/netfilter_ipv4/ip_tables.h - 1.3 include/linux/netfilter_ipv6/ip6_tables.h - 1.3 include/linux/netfilter_ipx.h - 1.2 include/linux/netfilter_x25.h - 1.2 include/linux/netlink.h - 1.4 include/linux/nfs4_mount.h - 1.2 include/linux/nfsd/cache.h - 1.2 include/linux/nfsd/nfsd.h - 1.5 include/linux/nfsd/state.h - 1.4 include/linux/nfsd/xdr.h - 1.2 include/linux/nfsd/xdr3.h - 1.3 include/linux/nfsd/xdr4.h - 1.3 include/linux/oprofile.h - 1.3 include/linux/page-flags.h - 1.6 include/linux/pagemap.h - 1.5 include/linux/pci.h - 1.9 include/linux/pci_ids.h - 1.11 include/linux/percpu_counter.h - 1.3 include/linux/personality.h - 1.2 include/linux/pkt_cls.h - 1.3 include/linux/pkt_sched.h - 1.4 include/linux/pm.h - 1.3 include/linux/pnpbios.h - 1.2 include/linux/posix-timers.h - 1.2 include/linux/ppp_defs.h - 1.2 include/linux/prctl.h - 1.2 include/linux/quotaops.h - 1.4 include/linux/rcupdate.h - 1.3 include/linux/reiserfs_fs.h - 1.7 include/linux/reiserfs_fs_i.h - 1.4 include/linux/route.h - 1.2 include/linux/rtnetlink.h - 1.5 include/linux/sc26198.h - 1.2 include/linux/sched.h - 1.9 include/linux/security.h - 1.8 include/linux/serialP.h - 1.3 include/linux/serial_core.h - 1.6 include/linux/serio.h - 1.4 include/linux/signal.h - 1.3 include/linux/skbuff.h - 1.7 include/linux/smb_fs_sb.h - 1.2 include/linux/stallion.h - 1.3 include/linux/sunrpc/svc.h - 1.3 include/linux/sunrpc/svcauth.h - 1.4 include/linux/sunrpc/xdr.h - 1.5 include/linux/suspend.h - 1.5 include/linux/swap.h - 1.5 include/linux/sysctl.h - 1.17 include/linux/sysfs.h - 1.4 include/linux/tcp.h - 1.7 include/linux/uio.h - 1.2 include/linux/upd4990a.h - 1.2 include/linux/usb.h - 1.8 include/linux/usb_gadget.h - 1.5 include/linux/usbdevice_fs.h - 1.3 include/linux/videodev.h - 1.5 include/linux/videodev2.h - 1.4 include/linux/videotext.h - 1.2 include/linux/vmalloc.h - 1.2 include/linux/vt_kern.h - 1.4 include/linux/wait.h - 1.3 include/linux/writeback.h - 1.3 include/linux/xfrm.h - 1.3 include/media/saa7146_vv.h - 1.5 include/media/video-buf.h - 1.2 include/net/addrconf.h - 1.5 include/net/bluetooth/bluetooth.h - 1.4 include/net/bluetooth/hci.h - 1.6 include/net/bluetooth/hci_core.h - 1.7 include/net/bluetooth/l2cap.h - 1.3 include/net/checksum.h - 1.3 include/net/dst.h - 1.3 include/net/esp.h - 1.2 include/net/icmp.h - 1.2 include/net/inet_common.h - 1.4 include/net/inet_ecn.h - 1.2 include/net/ip.h - 1.3 include/net/ip6_route.h - 1.4 include/net/ipv6.h - 1.6 include/net/irda/crc.h - 1.3 include/net/irda/irda_device.h - 1.3 include/net/irda/irttp.h - 1.2 include/net/ndisc.h - 1.3 include/net/netrom.h - 1.3 include/net/pkt_cls.h - 1.3 include/net/pkt_sched.h - 1.4 include/net/protocol.h - 1.2 include/net/route.h - 1.3 include/net/sctp/command.h - 1.4 include/net/sctp/constants.h - 1.5 include/net/sctp/sm.h - 1.5 include/net/snmp.h - 1.3 include/net/sock.h - 1.6 include/net/tcp.h - 1.7 include/net/udp.h - 1.3 include/net/xfrm.h - 1.5 include/pcmcia/cs_types.h - 1.2 include/pcmcia/ss.h - 1.3 include/rxrpc/call.h - 1.3 include/rxrpc/message.h - 1.3 include/scsi/scsi.h - 1.7 include/scsi/scsi_devinfo.h - 1.4 include/scsi/scsi_eh.h - 1.2 include/scsi/scsi_host.h - 1.4 include/scsi/scsi_ioctl.h - 1.3 include/scsi/sg.h - 1.3 include/sound/asound.h - 1.5 include/sound/info.h - 1.5 include/video/sisfb.h - 1.3 include/video/sstfb.h - 1.2 include/video/vga.h - 1.2 init/Kconfig - 1.6 init/do_mounts_initrd.c - 1.3 init/initramfs.c - 1.5 init/main.c - 1.17 ipc/msg.c - 1.5 ipc/sem.c - 1.6 ipc/shm.c - 1.6 ipc/util.c - 1.6 kernel/Makefile - 1.4 kernel/acct.c - 1.6 kernel/compat.c - 1.5 kernel/configs.c - 1.3 kernel/cpu.c - 1.6 kernel/dma.c - 1.3 kernel/exit.c - 1.16 kernel/extable.c - 1.3 kernel/fork.c - 1.8 kernel/futex.c - 1.6 kernel/itimer.c - 1.2 kernel/kallsyms.c - 1.12 kernel/kmod.c - 1.7 kernel/module.c - 1.16 kernel/posix-timers.c - 1.6 kernel/power/Makefile - 1.2 kernel/power/pm.c - 1.2 kernel/power/pmdisk.c - 1.5 kernel/power/poweroff.c - 1.3 kernel/power/process.c - 1.4 kernel/power/swsusp.c - 1.7 kernel/printk.c - 1.15 kernel/rcupdate.c - 1.6 kernel/sched.c - 1.16 kernel/signal.c - 1.12 kernel/sysctl.c - 1.16 kernel/timer.c - 1.7 kernel/uid16.c - 1.4 kernel/user.c - 1.3 lib/Kconfig - 1.3 lib/Makefile - 1.7 lib/idr.c - 1.4 lib/kobject.c - 1.7 lib/radix-tree.c - 1.5 lib/rbtree.c - 1.2 lib/rwsem-spinlock.c - 1.4 lib/rwsem.c - 1.6 lib/string.c - 1.4 lib/vsprintf.c - 1.5 lib/zlib_deflate/deflate.c - 1.2 lib/zlib_inflate/inftrees.c - 1.2 mm/bootmem.c - 1.4 mm/filemap.c - 1.11 mm/fremap.c - 1.6 mm/highmem.c - 1.4 mm/memory.c - 1.15 mm/mempool.c - 1.4 mm/mincore.c - 1.4 mm/mmap.c - 1.10 mm/mprotect.c - 1.7 mm/mremap.c - 1.8 mm/msync.c - 1.4 mm/nommu.c - 1.4 mm/oom_kill.c - 1.4 mm/page-writeback.c - 1.6 mm/page_alloc.c - 1.9 mm/readahead.c - 1.7 mm/rmap.c - 1.7 mm/shmem.c - 1.7 mm/slab.c - 1.8 mm/swap.c - 1.6 mm/swapfile.c - 1.7 mm/truncate.c - 1.4 mm/vmalloc.c - 1.4 mm/vmscan.c - 1.8 net/802/fc.c - 1.2 net/802/tr.c - 1.2 net/8021q/vlan.c - 1.4 net/8021q/vlan.h - 1.4 net/8021q/vlan_dev.c - 1.3 net/Kconfig - 1.6 net/appletalk/ddp.c - 1.7 net/atm/br2684.c - 1.4 net/atm/clip.c - 1.7 net/atm/common.c - 1.5 net/atm/lec.c - 1.5 net/atm/lec.h - 1.5 net/atm/lec_arpc.h - 1.2 net/atm/mpc.c - 1.3 net/atm/mpc.h - 1.3 net/atm/mpoa_proc.c - 1.4 net/atm/pppoatm.c - 1.3 net/atm/resources.c - 1.3 net/atm/signaling.c - 1.2 net/atm/svc.c - 1.3 net/ax25/ax25_ds_timer.c - 1.2 net/ax25/ax25_route.c - 1.4 net/bluetooth/Kconfig - 1.5 net/bluetooth/Makefile - 1.5 net/bluetooth/af_bluetooth.c - 1.8 net/bluetooth/bnep/bnep.h - 1.2 net/bluetooth/bnep/core.c - 1.7 net/bluetooth/hci_conn.c - 1.6 net/bluetooth/hci_core.c - 1.6 net/bluetooth/hci_event.c - 1.7 net/bluetooth/l2cap.c - 1.6 net/bluetooth/rfcomm/core.c - 1.8 net/bridge/br.c - 1.4 net/bridge/br_device.c - 1.4 net/bridge/br_fdb.c - 1.4 net/bridge/br_forward.c - 1.3 net/bridge/br_if.c - 1.6 net/bridge/br_input.c - 1.3 net/bridge/br_ioctl.c - 1.4 net/bridge/br_netfilter.c - 1.5 net/bridge/br_notify.c - 1.4 net/bridge/br_private.h - 1.4 net/bridge/br_stp.c - 1.3 net/bridge/br_stp_if.c - 1.4 net/core/Makefile - 1.4 net/core/dev.c - 1.10 net/core/dst.c - 1.4 net/core/ethtool.c - 1.5 net/core/link_watch.c - 1.2 net/core/net-sysfs.c - 1.4 net/core/pktgen.c - 1.5 net/core/rtnetlink.c - 1.3 net/core/skbuff.c - 1.3 net/core/sock.c - 1.7 net/core/sysctl_net_core.c - 1.4 net/decnet/dn_dev.c - 1.4 net/decnet/dn_nsp_in.c - 1.2 net/decnet/dn_route.c - 1.4 net/decnet/sysctl_net_decnet.c - 1.3 net/econet/af_econet.c - 1.7 net/ethernet/eth.c - 1.2 net/ipv4/Kconfig - 1.5 net/ipv4/Makefile - 1.2 net/ipv4/af_inet.c - 1.6 net/ipv4/ah4.c - 1.4 net/ipv4/arp.c - 1.7 net/ipv4/devinet.c - 1.8 net/ipv4/esp4.c - 1.5 net/ipv4/fib_frontend.c - 1.2 net/ipv4/icmp.c - 1.4 net/ipv4/igmp.c - 1.9 net/ipv4/ip_forward.c - 1.3 net/ipv4/ip_fragment.c - 1.3 net/ipv4/ip_gre.c - 1.3 net/ipv4/ip_input.c - 1.3 net/ipv4/ip_output.c - 1.7 net/ipv4/ip_sockglue.c - 1.5 net/ipv4/ipcomp.c - 1.5 net/ipv4/ipconfig.c - 1.4 net/ipv4/ipip.c - 1.4 net/ipv4/ipmr.c - 1.5 net/ipv4/ipvs/ip_vs_ctl.c - 1.5 net/ipv4/ipvs/ip_vs_ftp.c - 1.3 net/ipv4/ipvs/ip_vs_proto_tcp.c - 1.3 net/ipv4/ipvs/ip_vs_proto_udp.c - 1.2 net/ipv4/ipvs/ip_vs_sync.c - 1.4 net/ipv4/ipvs/ip_vs_xmit.c - 1.4 net/ipv4/netfilter/Kconfig - 1.5 net/ipv4/netfilter/Makefile - 1.3 net/ipv4/netfilter/ip_conntrack_amanda.c - 1.4 net/ipv4/netfilter/ip_conntrack_core.c - 1.6 net/ipv4/netfilter/ip_conntrack_ftp.c - 1.4 net/ipv4/netfilter/ip_conntrack_irc.c - 1.3 net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.5 net/ipv4/netfilter/ip_conntrack_standalone.c - 1.5 net/ipv4/netfilter/ip_conntrack_tftp.c - 1.4 net/ipv4/netfilter/ip_fw_compat_masq.c - 1.4 net/ipv4/netfilter/ip_fw_compat_redir.c - 1.3 net/ipv4/netfilter/ip_nat_core.c - 1.4 net/ipv4/netfilter/ip_nat_ftp.c - 1.3 net/ipv4/netfilter/ip_nat_irc.c - 1.2 net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.3 net/ipv4/netfilter/ip_nat_standalone.c - 1.5 net/ipv4/netfilter/ip_nat_tftp.c - 1.4 net/ipv4/netfilter/ip_tables.c - 1.6 net/ipv4/netfilter/ipt_CLASSIFY.c - 1.3 net/ipv4/netfilter/ipt_LOG.c - 1.4 net/ipv4/netfilter/ipt_MASQUERADE.c - 1.5 net/ipv4/netfilter/ipt_REJECT.c - 1.5 net/ipv4/netfilter/ipt_ULOG.c - 1.4 net/ipv4/netfilter/ipt_helper.c - 1.3 net/ipv4/netfilter/ipt_owner.c - 1.4 net/ipv4/netfilter/iptable_mangle.c - 1.3 net/ipv4/proc.c - 1.3 net/ipv4/protocol.c - 1.2 net/ipv4/raw.c - 1.4 net/ipv4/route.c - 1.6 net/ipv4/syncookies.c - 1.2 net/ipv4/sysctl_net_ipv4.c - 1.6 net/ipv4/tcp.c - 1.7 net/ipv4/tcp_input.c - 1.6 net/ipv4/tcp_ipv4.c - 1.6 net/ipv4/tcp_minisocks.c - 1.4 net/ipv4/tcp_output.c - 1.4 net/ipv4/tcp_timer.c - 1.3 net/ipv4/udp.c - 1.6 net/ipv4/xfrm4_policy.c - 1.4 net/ipv4/xfrm4_state.c - 1.3 net/ipv4/xfrm4_tunnel.c - 1.3 net/ipv6/Kconfig - 1.2 net/ipv6/Makefile - 1.3 net/ipv6/addrconf.c - 1.9 net/ipv6/af_inet6.c - 1.7 net/ipv6/ah6.c - 1.5 net/ipv6/anycast.c - 1.4 net/ipv6/datagram.c - 1.6 net/ipv6/esp6.c - 1.5 net/ipv6/exthdrs.c - 1.9 net/ipv6/icmp.c - 1.6 net/ipv6/ip6_fib.c - 1.4 net/ipv6/ip6_flowlabel.c - 1.3 net/ipv6/ip6_input.c - 1.5 net/ipv6/ip6_output.c - 1.9 net/ipv6/ip6_tunnel.c - 1.5 net/ipv6/ipcomp6.c - 1.3 net/ipv6/mcast.c - 1.8 net/ipv6/ndisc.c - 1.9 net/ipv6/netfilter/ip6_tables.c - 1.6 net/ipv6/netfilter/ip6t_LOG.c - 1.4 net/ipv6/netfilter/ip6t_owner.c - 1.4 net/ipv6/proc.c - 1.3 net/ipv6/raw.c - 1.7 net/ipv6/reassembly.c - 1.5 net/ipv6/route.c - 1.5 net/ipv6/sit.c - 1.4 net/ipv6/tcp_ipv6.c - 1.6 net/ipv6/udp.c - 1.7 net/ipv6/xfrm6_input.c - 1.3 net/ipv6/xfrm6_policy.c - 1.5 net/ipv6/xfrm6_state.c - 1.3 net/irda/Kconfig - 1.3 net/irda/Makefile - 1.3 net/irda/af_irda.c - 1.7 net/irda/crc.c - 1.3 net/irda/discovery.c - 1.2 net/irda/ircomm/ircomm_core.c - 1.2 net/irda/ircomm/ircomm_tty.c - 1.5 net/irda/irda_device.c - 1.4 net/irda/iriap.c - 1.3 net/irda/irlmp.c - 1.5 net/irda/irsysctl.c - 1.4 net/key/af_key.c - 1.7 net/lapb/lapb_iface.c - 1.3 net/netlink/af_netlink.c - 1.6 net/netrom/af_netrom.c - 1.7 net/rose/af_rose.c - 1.7 net/rose/rose_route.c - 1.3 net/rxrpc/call.c - 1.3 net/rxrpc/connection.c - 1.3 net/rxrpc/transport.c - 1.4 net/sched/Kconfig - 1.6 net/sched/Makefile - 1.4 net/sched/cls_api.c - 1.4 net/sched/cls_fw.c - 1.3 net/sched/cls_route.c - 1.3 net/sched/cls_rsvp.h - 1.3 net/sched/cls_tcindex.c - 1.3 net/sched/cls_u32.c - 1.3 net/sched/estimator.c - 1.2 net/sched/police.c - 1.2 net/sched/sch_api.c - 1.3 net/sched/sch_atm.c - 1.4 net/sched/sch_cbq.c - 1.4 net/sched/sch_csz.c - 1.4 net/sched/sch_dsmark.c - 1.5 net/sched/sch_fifo.c - 1.3 net/sched/sch_generic.c - 1.2 net/sched/sch_gred.c - 1.3 net/sched/sch_htb.c - 1.5 net/sched/sch_ingress.c - 1.4 net/sched/sch_prio.c - 1.4 net/sched/sch_red.c - 1.3 net/sched/sch_sfq.c - 1.3 net/sched/sch_tbf.c - 1.6 net/sched/sch_teql.c - 1.4 net/sctp/Kconfig - 1.5 net/sctp/associola.c - 1.6 net/sctp/chunk.c - 1.4 net/sctp/endpointola.c - 1.4 net/sctp/input.c - 1.4 net/sctp/inqueue.c - 1.2 net/sctp/ipv6.c - 1.4 net/sctp/output.c - 1.5 net/sctp/outqueue.c - 1.5 net/sctp/proc.c - 1.2 net/sctp/protocol.c - 1.5 net/sctp/sm_make_chunk.c - 1.5 net/sctp/sm_sideeffect.c - 1.5 net/sctp/sm_statefuns.c - 1.6 net/sctp/socket.c - 1.8 net/sctp/ulpevent.c - 1.4 net/sctp/ulpqueue.c - 1.3 net/socket.c - 1.6 net/sunrpc/auth_gss/auth_gss.c - 1.6 net/sunrpc/cache.c - 1.5 net/sunrpc/pmap_clnt.c - 1.4 net/sunrpc/rpc_pipe.c - 1.4 net/sunrpc/stats.c - 1.3 net/sunrpc/svc.c - 1.3 net/sunrpc/svcauth_unix.c - 1.5 net/sunrpc/svcsock.c - 1.4 net/sunrpc/sysctl.c - 1.5 net/sunrpc/xdr.c - 1.5 net/sunrpc/xprt.c - 1.7 net/unix/af_unix.c - 1.8 net/xfrm/Makefile - 1.2 net/xfrm/xfrm_export.c - 1.2 net/xfrm/xfrm_output.c - 1.2 net/xfrm/xfrm_policy.c - 1.7 net/xfrm/xfrm_state.c - 1.4 net/xfrm/xfrm_user.c - 1.5 scripts/Makefile - 1.12 scripts/Makefile.modinst - 1.4 scripts/Makefile.modpost - 1.5 scripts/empty.c - 1.2 scripts/extract-ikconfig - 1.2 scripts/file2alias.c - 1.3 scripts/genksyms/parse.c_shipped - 1.2 scripts/kallsyms.c - 1.11 scripts/kconfig/mconf.c - 1.5 scripts/kernel-doc - 1.4 scripts/lxdialog/menubox.c - 1.2 scripts/mk_elfconfig.c - 1.3 scripts/mkconfigs - 1.2 scripts/mkspec - 1.4 scripts/modpost.c - 1.9 scripts/modpost.h - 1.5 security/dummy.c - 1.8 security/root_plug.c - 1.3 security/selinux/Makefile - 1.4 security/selinux/avc.c - 1.5 security/selinux/hooks.c - 1.9 security/selinux/include/av_inherit.h - 1.2 security/selinux/include/av_perm_to_string.h - 1.5 security/selinux/include/av_permissions.h - 1.5 security/selinux/include/avc.h - 1.5 security/selinux/include/class_to_string.h - 1.2 security/selinux/include/flask.h - 1.3 security/selinux/include/security.h - 1.5 security/selinux/ss/ebitmap.c - 1.3 security/selinux/ss/mls.c - 1.4 security/selinux/ss/policydb.c - 1.6 security/selinux/ss/services.c - 1.8 sound/Kconfig - 1.2 sound/core/control.c - 1.4 sound/core/info.c - 1.4 sound/core/ioctl32/hwdep32.c - 1.2 sound/core/ioctl32/ioctl32.c - 1.3 sound/core/ioctl32/ioctl32.h - 1.2 sound/core/ioctl32/pcm32.c - 1.2 sound/core/memalloc.c - 1.5 sound/core/oss/pcm_oss.c - 1.5 sound/core/oss/pcm_plugin.c - 1.3 sound/core/oss/route.c - 1.2 sound/core/pcm.c - 1.5 sound/core/pcm_lib.c - 1.5 sound/core/pcm_native.c - 1.5 sound/core/seq/Makefile - 1.2 sound/core/seq/instr/Makefile - 1.2 sound/core/seq/seq_clientmgr.c - 1.5 sound/drivers/mpu401/mpu401.c - 1.5 sound/drivers/opl3/opl3_lib.c - 1.3 sound/drivers/opl4/opl4_proc.c - 1.4 sound/drivers/serial-u16550.c - 1.5 sound/drivers/vx/vx_pcm.c - 1.4 sound/isa/Kconfig - 1.3 sound/isa/cs423x/Makefile - 1.2 sound/isa/cs423x/pc98.c - 1.4 sound/isa/cs423x/pc9801_118_magic.h - 1.2 sound/isa/cs423x/sound_pc9800.h - 1.2 sound/isa/gus/gus_mem.c - 1.3 sound/isa/gus/gus_mem_proc.c - 1.3 sound/isa/gus/interwave.c - 1.5 sound/isa/sb/emu8000_pcm.c - 1.3 sound/isa/sb/sb8_main.c - 1.3 sound/isa/wavefront/wavefront_fx.c - 1.3 sound/isa/wavefront/wavefront_synth.c - 1.5 sound/oss/Kconfig - 1.7 sound/oss/aci.c - 1.3 sound/oss/ad1816.c - 1.3 sound/oss/ad1848.c - 1.3 sound/oss/ad1889.c - 1.4 sound/oss/ali5455.c - 1.3 sound/oss/au1000.c - 1.4 sound/oss/cmpci.c - 1.5 sound/oss/cs4281/cs4281m.c - 1.4 sound/oss/cs46xx.c - 1.5 sound/oss/cs46xxpm-24.h - 1.2 sound/oss/dmasound/dmasound.h - 1.4 sound/oss/dmasound/dmasound_atari.c - 1.2 sound/oss/dmasound/dmasound_awacs.c - 1.4 sound/oss/dmasound/dmasound_core.c - 1.4 sound/oss/dmasound/dmasound_paula.c - 1.2 sound/oss/dmasound/dmasound_q40.c - 1.2 sound/oss/dmasound/tas3001c.c - 1.3 sound/oss/dmasound/tas3001c_tables.c - 1.3 sound/oss/dmasound/tas3004.c - 1.3 sound/oss/dmasound/trans_16.c - 1.3 sound/oss/emu10k1/audio.c - 1.4 sound/oss/emu10k1/main.c - 1.2 sound/oss/emu10k1/midi.c - 1.3 sound/oss/es1370.c - 1.4 sound/oss/es1371.c - 1.4 sound/oss/esssolo1.c - 1.4 sound/oss/forte.c - 1.3 sound/oss/gus_card.c - 1.2 sound/oss/gus_wave.c - 1.3 sound/oss/hal2.c - 1.2 sound/oss/hal2.h - 1.2 sound/oss/i810_audio.c - 1.5 sound/oss/ite8172.c - 1.4 sound/oss/kahlua.c - 1.3 sound/oss/maestro.c - 1.3 sound/oss/maestro3.c - 1.3 sound/oss/msnd_pinnacle.c - 1.3 sound/oss/nec_vrc5477.c - 1.4 sound/oss/rme96xx.c - 1.6 sound/oss/sb_audio.c - 1.4 sound/oss/sb_card.c - 1.3 sound/oss/sb_common.c - 1.3 sound/oss/sonicvibes.c - 1.4 sound/oss/sscape.c - 1.3 sound/oss/swarm_cs4297a.c - 1.2 sound/oss/trident.c - 1.4 sound/oss/via82cxxx_audio.c - 1.5 sound/oss/vwsnd.c - 1.5 sound/oss/wavfront.c - 1.5 sound/oss/ymfpci.c - 1.3 sound/pci/azt3328.c - 1.5 sound/pci/cs4281.c - 1.5 sound/pci/cs46xx/cs46xx_lib.c - 1.5 sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.3 sound/pci/emu10k1/emuproc.c - 1.5 sound/pci/es1968.c - 1.5 sound/pci/ice1712/ice1712.c - 1.5 sound/pci/ice1712/ice1724.c - 1.5 sound/pci/intel8x0.c - 1.6 sound/pci/maestro3.c - 1.5 sound/pci/nm256/nm256.c - 1.4 sound/pci/rme9652/hdsp.c - 1.5 sound/pci/sonicvibes.c - 1.5 sound/ppc/Kconfig - 1.3 sound/ppc/pmac.c - 1.4 sound/usb/usbaudio.c - 1.6 sound/usb/usbmixer.c - 1.4 drivers/usb/media/w9968cf.c - 1.6 drivers/usb/media/w9968cf.h - 1.4 Documentation/MSI-HOWTO.txt - 1.3 drivers/usb/media/w9968cf_externaldef.h - 1.3 drivers/usb/misc/legousbtower.c - 1.3 Documentation/dvb/firmware.txt - 1.3 Documentation/dvb/ttusb-dec.txt - 1.3 include/asm-alpha/cpumask.h - 1.2 include/asm-arm/cpumask.h - 1.2 include/asm-arm26/cpumask.h - 1.2 include/asm-cris/cpumask.h - 1.2 include/asm-generic/cpumask.h - 1.2 include/asm-h8300/cpumask.h - 1.2 include/asm-i386/cpumask.h - 1.2 include/asm-ia64/cpumask.h - 1.2 include/asm-m68k/cpumask.h - 1.2 include/asm-m68knommu/cpumask.h - 1.2 include/asm-mips/cpumask.h - 1.2 include/asm-parisc/cpumask.h - 1.2 include/asm-ppc/cpumask.h - 1.2 include/asm-ppc64/cpumask.h - 1.2 include/asm-s390/cpumask.h - 1.2 include/asm-sh/cpumask.h - 1.2 include/asm-sparc/cpumask.h - 1.2 include/asm-sparc/setup.h - 1.2 include/asm-sparc64/cpumask.h - 1.2 include/asm-sparc64/setup.h - 1.2 include/asm-um/cpumask.h - 1.2 include/asm-v850/cpumask.h - 1.2 include/asm-x86_64/cpumask.h - 1.2 Documentation/usb/w9968cf.txt - 1.3 drivers/pci/msi.c - 1.5 arch/arm/configs/netwinder_defconfig - 1.4 drivers/media/dvb/bt8xx/dvb-bt8xx.c - 1.3 drivers/char/watchdog/w83627hf_wdt.c - 1.6 arch/x86_64/ia32/ia32_aout.c - 1.4 arch/ia64/configs/sn2_defconfig - 1.5 arch/i386/kernel/efi.c - 1.4 drivers/scsi/qla2xxx/Makefile - 1.3 drivers/scsi/qla2xxx/ql2100.c - 1.3 drivers/scsi/qla2xxx/ql2200.c - 1.3 security/selinux/netif.c - 1.2 drivers/scsi/qla2xxx/ql2300.c - 1.4 drivers/scsi/qla2xxx/ql2300_fw.c - 1.5 drivers/scsi/qla2xxx/qla_dbg.c - 1.6 drivers/scsi/qla2xxx/qla_dbg.h - 1.4 drivers/scsi/qla2xxx/qla_def.h - 1.5 drivers/scsi/qla2xxx/qla_gbl.h - 1.5 drivers/scsi/qla2xxx/qla_gs.c - 1.5 drivers/scsi/qla2xxx/qla_init.c - 1.6 Documentation/power/video.txt - 1.4 drivers/scsi/qla2xxx/qla_inline.h - 1.3 drivers/scsi/qla2xxx/qla_iocb.c - 1.5 drivers/scsi/qla2xxx/qla_isr.c - 1.6 net/bluetooth/cmtp/core.c - 1.4 drivers/scsi/qla2xxx/qla_mbx.c - 1.6 drivers/scsi/qla2xxx/qla_os.c - 1.7 drivers/scsi/qla2xxx/qla_os.h - 1.4 drivers/scsi/qla2xxx/qla_rscn.c - 1.4 drivers/scsi/qla2xxx/qla_sup.c - 1.5 drivers/scsi/qla2xxx/qla_version.h - 1.5 drivers/usb/gadget/pxa2xx_udc.c - 1.6 drivers/usb/gadget/serial.c - 1.5 drivers/video/kyro/fbdev.c - 1.2 include/asm-ppc64/vio.h - 1.7 arch/ia64/configs/generic_defconfig - 1.5 include/media/ir-common.h - 1.2 drivers/net/wan/pci200syn.c - 1.3 drivers/net/forcedeth.c - 1.5 drivers/media/video/saa7134/saa7134-input.c - 1.5 drivers/media/video/ir-kbd-i2c.c - 1.3 drivers/media/video/ir-kbd-gpio.c - 1.4 drivers/media/video/cx88/cx88.h - 1.3 drivers/media/video/cx88/cx88-video.c - 1.3 drivers/media/video/cx88/cx88-tvaudio.c - 1.3 drivers/media/video/cx88/cx88-reg.h - 1.3 drivers/media/video/cx88/cx88-i2c.c - 1.4 drivers/media/video/cx88/cx88-cards.c - 1.3 drivers/media/dvb/ttpci/av7110_hw.c - 1.4 drivers/media/dvb/ttpci/av7110_ca.c - 1.2 drivers/media/dvb/ttpci/av7110_av.c - 1.3 drivers/media/common/ir-common.c - 1.2 drivers/md/raid6main.c - 1.7 lib/bitmap.c - 1.7 drivers/i2c/chips/w83l785ts.c - 1.6 drivers/i2c/chips/lm90.c - 1.5 drivers/i2c/chips/asb100.c - 1.5 drivers/bluetooth/bfusb.c - 1.6 drivers/base/class_simple.c - 1.5 arch/sh/kernel/cpu/sh4/sq.c - 1.3 arch/sh/kernel/cpu/sh3/ex.S - 1.2 arch/sh/kernel/cpu/init.c - 1.3 arch/sh/drivers/pci/pci.c - 1.3 arch/sh/drivers/pci/pci-sh7751.h - 1.2 arch/sh/drivers/pci/pci-sh7751.c - 1.2 arch/sh/drivers/pci/pci-auto.c - 1.2 arch/sh/drivers/pci/ops-snapgear.c - 1.2 arch/sh/drivers/pci/Makefile - 1.3 arch/sh/drivers/dma/dma-sh.c - 1.3 arch/sh/drivers/dma/dma-isa.c - 1.2 arch/sh/drivers/dma/dma-api.c - 1.3 arch/sh/drivers/dma/Makefile - 1.2 arch/sh/cchips/Kconfig - 1.3 arch/sh/boards/systemh/setup.c - 1.2 arch/sh/boards/systemh/irq.c - 1.2 arch/sh/boards/systemh/io.c - 1.2 arch/sh/boards/systemh/Makefile - 1.3 arch/ppc64/mm/hash_utils.c - 1.5 arch/ppc64/kernel/viopath.c - 1.6 arch/ppc64/kernel/vio.c - 1.7 arch/ppc64/kernel/lparcfg.c - 1.5 arch/ppc64/kernel/iSeries_htab.c - 1.3 drivers/usb/gadget/file_storage.c - 1.5 drivers/usb/host/ohci-omap.c - 1.4 drivers/scsi/qla2xxx/ql6312_fw.c - 1.4 drivers/scsi/qla2xxx/ql6312.c - 1.3 drivers/scsi/qla2xxx/ql2322_fw.c - 1.4 drivers/scsi/qla2xxx/ql2322.c - 1.3 drivers/scsi/qla2xxx/ql6322.c - 1.3 drivers/scsi/qla2xxx/ql6322_fw.c - 1.4 drivers/macintosh/therm_pm72.c - 1.4 drivers/macintosh/Kconfig - 1.6 net/sched/sch_hfsc.c - 1.4 sound/i2c/other/tea575x-tuner.c - 1.2 arch/ppc64/kernel/hvconsole.c - 1.2 arch/parisc/configs/c3000_defconfig - 1.5 arch/parisc/configs/a500_defconfig - 1.4 arch/arm/mach-integrator/integrator_cp.c - 1.2 drivers/pci/msi.h - 1.4 drivers/base/dmapool.c - 1.3 drivers/char/watchdog/i8xx_tco.c - 1.2 drivers/char/watchdog/pcwd_pci.c - 1.4 drivers/video/aty/radeon_accel.c - 1.4 drivers/video/aty/radeon_base.c - 1.5 drivers/video/aty/radeon_pm.c - 1.3 drivers/video/aty/radeonfb.h - 1.4 arch/ppc64/kernel/pmac_smp.c - 1.4 arch/ppc64/kernel/pmac_pci.c - 1.3 arch/ppc64/kernel/pSeries_nvram.c - 1.4 arch/ppc64/configs/pSeries_defconfig - 1.5 arch/ppc64/configs/g5_defconfig - 1.5 kdb/modules/kdbm_x86.c - 1.7 include/asm-i386/kdbprivate.h - 1.7 arch/i386/kdb/ChangeLog - 1.9 arch/i386/kdb/Makefile - 1.7 arch/i386/kdb/i386-dis.c - 1.7 arch/i386/kdb/kdba_bp.c - 1.7 arch/i386/kdb/kdba_bt.c - 1.7 arch/i386/kdb/kdba_id.c - 1.7 arch/i386/kdb/kdba_io.c - 1.7 arch/i386/kdb/kdbasupport.c - 1.7 arch/i386/kdb/pc_keyb.h - 1.7 include/asm-i386/kdb.h - 1.7 drivers/pci/hotplug/pciehp_ctrl.c - 1.4 drivers/pci/hotplug/pciehp_hpc.c - 1.5 scripts/sumversion.c - 1.4 net/sunrpc/auth_gss/svcauth_gss.c - 1.5 drivers/pci/hotplug/pciehprm_acpi.c - 1.4 drivers/pci/hotplug/pciehprm_nonacpi.c - 1.3 drivers/pci/hotplug/rpadlpar_core.c - 1.5 drivers/pci/hotplug/rpaphp.h - 1.5 drivers/pci/hotplug/rpaphp_core.c - 1.5 drivers/pci/hotplug/rpaphp_pci.c - 1.5 drivers/pci/hotplug/shpchp.h - 1.3 drivers/pci/hotplug/shpchp_ctrl.c - 1.4 drivers/pci/hotplug/shpchp_hpc.c - 1.3 drivers/pci/hotplug/shpchp_pci.c - 1.4 drivers/pci/hotplug/shpchprm_acpi.c - 1.4 drivers/pci/hotplug/shpchprm_nonacpi.c - 1.3 drivers/misc/ibmasm/ibmasmfs.c - 1.2 drivers/s390/cio/cmf.c - 1.2 drivers/scsi/aacraid/rkt.c - 1.3 drivers/serial/au1x00_uart.c - 1.2 drivers/serial/pxa.c - 1.3 fs/hfsplus/bnode.c - 1.2 fs/hfsplus/btree.c - 1.2 drivers/media/video/saa5246a.h - 1.2 drivers/media/video/saa5246a.c - 1.3 fs/hfsplus/inode.c - 1.4 fs/hfsplus/wrapper.c - 1.2 include/asm-ia64/cyclone.h - 1.2 include/asm-mips/hazards.h - 1.3 arch/arm/mm/blockops.c - 1.3 drivers/isdn/hisax/teles_cs.c - 1.2 drivers/isdn/hisax/isdnhdlc.c - 1.2 drivers/isdn/hisax/hfc_usb.c - 1.4 drivers/char/watchdog/pcwd_usb.c - 1.4 drivers/cdrom/viocd.c - 1.4 include/asm-mips/titan_dep.h - 1.2 drivers/block/viodasd.c - 1.3 arch/s390/mm/cmm.c - 1.2 arch/s390/appldata/appldata_os.c - 1.3 arch/s390/appldata/appldata_base.c - 1.4 arch/i386/kernel/timers/timer_pm.c - 1.2 arch/ppc64/mm/tlb.c - 1.3 include/linux/syscalls.h - 1.5 arch/ppc64/kernel/pSeries_iommu.c - 1.4 kernel/kthread.c - 1.4 arch/ppc64/configs/iSeries_defconfig - 1.4 net/bluetooth/hci_sysfs.c - 1.4 arch/mips/vr41xx/common/rtc.c - 1.3 arch/ia64/kernel/cyclone.c - 1.2 arch/mips/vr41xx/common/pmu.c - 1.2 arch/mips/vr41xx/common/ksyms.c - 1.2 arch/mips/pmc-sierra/yosemite/setup.h - 1.2 arch/mips/pmc-sierra/yosemite/setup.c - 1.3 arch/mips/pmc-sierra/yosemite/prom.c - 1.3 arch/mips/pmc-sierra/yosemite/irq.c - 1.3 arch/mips/pmc-sierra/yosemite/irq-handler.S - 1.2 arch/mips/pmc-sierra/yosemite/i2c-yosemite.h - 1.2 arch/mips/pmc-sierra/yosemite/i2c-yosemite.c - 1.3 arch/mips/pmc-sierra/yosemite/Makefile - 1.3 arch/mips/pci/ops-titan.c - 1.2 arch/mips/pci/ops-mv64340.c - 1.3 arch/mips/pci/ops-msc.c - 1.2 arch/mips/pci/fixup-yosemite.c - 1.2 arch/mips/momentum/jaguar_atx/setup.c - 1.3 arch/mips/momentum/jaguar_atx/prom.c - 1.4 arch/mips/momentum/jaguar_atx/irq.c - 1.3 arch/mips/gt64120/common/time.c - 1.2 arch/mips/configs/yosemite_defconfig - 1.4 arch/mips/configs/xxs1500_defconfig - 1.4 arch/mips/configs/workpad_defconfig - 1.5 arch/mips/configs/tb0229_defconfig - 1.4 arch/mips/configs/tb0226_defconfig - 1.5 arch/mips/configs/sead_defconfig - 1.4 arch/mips/configs/sb1250-swarm_defconfig - 1.4 arch/mips/configs/rm200_defconfig - 1.5 arch/mips/configs/pb1500_defconfig - 1.5 arch/mips/configs/pb1100_defconfig - 1.4 arch/mips/configs/pb1000_defconfig - 1.4 arch/mips/configs/osprey_defconfig - 1.4 arch/mips/configs/ocelot_defconfig - 1.4 arch/mips/configs/mtx1_defconfig - 1.4 arch/mips/configs/mpc30x_defconfig - 1.4 arch/mips/configs/mirage_defconfig - 1.4 arch/mips/configs/malta_defconfig - 1.4 arch/mips/configs/lasat200_defconfig - 1.5 arch/mips/configs/jmr3927_defconfig - 1.4 arch/mips/configs/jaguar-atx_defconfig - 1.4 arch/mips/configs/ivr_defconfig - 1.5 arch/mips/configs/it8172_defconfig - 1.5 arch/mips/configs/ip32_defconfig - 1.4 arch/mips/configs/ip27_defconfig - 1.4 arch/mips/configs/ip22_defconfig - 1.4 arch/mips/configs/ev96100_defconfig - 1.4 arch/mips/configs/ev64120_defconfig - 1.4 arch/mips/configs/eagle_defconfig - 1.5 arch/mips/configs/atlas_defconfig - 1.4 arch/mips/configs/bosporus_defconfig - 1.4 arch/mips/configs/capcella_defconfig - 1.5 arch/mips/configs/cobalt_defconfig - 1.5 arch/mips/configs/db1000_defconfig - 1.4 arch/mips/configs/db1100_defconfig - 1.4 arch/mips/configs/db1500_defconfig - 1.5 arch/mips/configs/ddb5476_defconfig - 1.5 arch/mips/configs/ddb5477_defconfig - 1.4 arch/mips/configs/decstation_defconfig - 1.4 arch/mips/configs/e55_defconfig - 1.5 drivers/net/wireless/prism54/isl_38xx.c - 1.3 drivers/net/wireless/prism54/isl_38xx.h - 1.3 drivers/net/wireless/prism54/isl_ioctl.c - 1.3 drivers/net/wireless/prism54/isl_ioctl.h - 1.3 drivers/net/wireless/prism54/islpci_dev.c - 1.3 drivers/net/wireless/prism54/islpci_dev.h - 1.3 drivers/net/wireless/prism54/islpci_eth.c - 1.3 drivers/net/wireless/prism54/islpci_hotplug.c - 1.3 drivers/net/wireless/prism54/islpci_mgt.c - 1.3 drivers/net/wireless/prism54/islpci_mgt.h - 1.3 drivers/net/wireless/prism54/oid_mgt.c - 1.3 drivers/net/wireless/prism54/oid_mgt.h - 1.3 drivers/parisc/iommu-helpers.h - 1.2 drivers/pci/hotplug/rpaphp_slot.c - 1.4 drivers/pci/hotplug/rpaphp_vio.c - 1.3 drivers/scsi/sata_vsc.c - 1.4 drivers/i2c/chips/w83627hf.c - 1.3 drivers/scsi/scsi_transport_spi.c - 1.3 drivers/serial/sh-sci.c - 1.4 drivers/serial/sh-sci.h - 1.3 drivers/usb/input/ati_remote.c - 1.3 drivers/firmware/edd.c - 1.4 drivers/firmware/Makefile - 1.3 drivers/firmware/Kconfig - 1.4 drivers/char/viotape.c - 1.3 drivers/char/agp/intel-mch-agp.c - 1.4 include/asm-sh/cpu-sh3/dac.h - 1.2 include/asm-sh/hp6xx/hp6xx.h - 1.2 drivers/block/carmel.c - 1.3 include/linux/edd.h - 1.3 arch/sh/mm/consistent.c - 1.2 ipc/compat.c - 1.3 net/core/netpoll.c - 1.4 net/sched/sch_delay.c - 1.3 arch/sh/configs/snapgear_defconfig - 1.2 arch/sh/configs/se7751_defconfig - 1.2 arch/sh/configs/dreamcast_defconfig - 1.2 security/selinux/ss/conditional.c - 1.2 sound/pci/au88x0/au88x0.h - 1.3 sound/pci/au88x0/au88x0_a3d.c - 1.3 arch/ppc64/kernel/dma.c - 1.3 arch/ppc/platforms/pplus.c - 1.3 arch/parisc/configs/b180_defconfig - 1.3 sound/pci/intel8x0m.c - 1.3 sound/pci/mixart/mixart.c - 1.3 arch/i386/boot/edd.S - 1.2 arch/ia64/configs/zx1_defconfig - 1.3 split-patches/dmapi-enable - 1.8 split-patches/kdb-common - 1.5 split-patches/kdb-i386 - 1.5 split-patches/xfs-debug - 1.4 split-patches/xfs-modules - 1.4 Documentation/laptop-mode.txt - 1.3 arch/arm/common/dmabounce.c - 1.3 arch/arm/configs/bast_defconfig - 1.2 arch/arm/configs/lpd7a400_defconfig - 1.3 arch/arm/configs/lpd7a404_defconfig - 1.3 arch/arm/configs/s3c2410_defconfig - 1.2 arch/arm/configs/versatile_defconfig - 1.2 arch/arm/mach-lh7a40x/Kconfig - 1.3 arch/arm/mach-lh7a40x/Makefile - 1.2 arch/arm/mach-lh7a40x/arch-kev7a400.c - 1.2 arch/arm/mach-lh7a40x/arch-lpd7a40x.c - 1.3 arch/arm/mach-lh7a40x/fiq.S - 1.2 arch/arm/mach-lh7a40x/ide-lpd7a40x.c - 1.2 arch/arm/mach-omap/Makefile - 1.2 arch/arm/mach-omap/board-generic.c - 1.3 arch/arm/mach-omap/board-innovator.c - 1.3 arch/arm/mach-omap/board-osk.c - 1.3 arch/arm/mach-omap/board-perseus2.c - 1.3 arch/arm/mach-omap/bus.c - 1.3 arch/arm/mach-omap/common.h - 1.2 arch/arm/mach-s3c2410/Kconfig - 1.3 arch/arm/mach-s3c2410/Makefile - 1.3 arch/arm/mach-s3c2410/mach-bast.c - 1.2 arch/arm/mach-s3c2410/mach-h1940.c - 1.2 arch/arm/mach-s3c2410/mach-vr1000.c - 1.2 arch/arm/mach-s3c2410/s3c2410.h - 1.2 arch/arm/mach-versatile/Makefile - 1.2 arch/arm/mach-versatile/core.c - 1.3 arch/arm/mm/fault.c - 1.3 arch/h8300/platform/h8s/ptrace_h8s.c - 1.2 arch/i386/kernel/std_resources.c - 1.2 arch/i386/mach-pc9800/std_resources.c - 1.2 arch/mips/configs/ocelot_c_defconfig - 1.3 arch/mips/configs/pb1550_defconfig - 1.3 arch/mips/kernel/irq-mv6434x.c - 1.2 arch/mips/pci/fixup-mv64340.c - 1.2 drivers/s390/net/qeth_fs.h - 1.3 arch/mips/vr41xx/common/init.c - 1.2 arch/ppc64/kernel/sysfs.c - 1.3 arch/ppc64/oprofile/common.c - 1.3 arch/ppc64/oprofile/op_model_power4.c - 1.3 drivers/block/cfq-iosched.c - 1.2 drivers/char/ipmi/ipmi_bt_sm.c - 1.3 drivers/char/ipmi/ipmi_si_intf.c - 1.3 drivers/char/ipmi/ipmi_smic_sm.c - 1.2 drivers/firmware/efivars.c - 1.3 drivers/media/dvb/dvb-core/dvb_ca_en50221.c - 1.2 drivers/media/video/cx88/cx88-vbi.c - 1.2 drivers/net/irda/ali-ircc.h - 1.2 drivers/net/irda/nsc-ircc.h - 1.2 drivers/net/irda/w83977af_ir.h - 1.2 drivers/net/iseries_veth.c - 1.3 drivers/net/iseries_veth.h - 1.2 drivers/net/s2io.c - 1.3 drivers/net/s2io.h - 1.3 drivers/s390/net/qeth_main.c - 1.3 drivers/s390/net/qeth_sys.c - 1.3 drivers/scsi/sata_sis.c - 1.3 drivers/serial/amba-pl011.c - 1.2 drivers/serial/bast_sio.c - 1.2 drivers/usb/gadget/dummy_hcd.c - 1.3 drivers/usb/gadget/epautoconf.c - 1.3 drivers/usb/gadget/ndis.h - 1.2 drivers/usb/gadget/rndis.c - 1.3 drivers/usb/gadget/rndis.h - 1.3 fs/cifs/fcntl.c - 1.3 fs/ntfs/logfile.c - 1.3 include/asm-arm/arch-lh7a40x/ide.h - 1.3 include/asm-arm/arch-lh7a40x/memory.h - 1.3 include/asm-arm/arch-lh7a40x/time.h - 1.2 include/asm-arm/arch-omap/memory.h - 1.3 include/asm-arm/arch-omap/pm.h - 1.2 include/asm-arm/arch-omap/time.h - 1.3 include/asm-arm/arch-s3c2410/hardware.h - 1.2 include/asm-arm/arch-s3c2410/regs-gpio.h - 1.3 include/asm-arm/arch-s3c2410/regs-serial.h - 1.2 include/asm-arm/arch-s3c2410/time.h - 1.3 include/asm-arm/arch-versatile/time.h - 1.2 include/asm-arm/arch-versatile/uncompress.h - 1.2 include/asm-i386/mach-default/irq_vectors_limits.h - 1.2 include/asm-i386/msi.h - 1.2 include/asm-i386/std_resources.h - 1.2 include/asm-x86_64/msi.h - 1.2 include/linux/mqueue.h - 1.2 ipc/mqueue.c - 1.3 ipc/compat_mq.c - 1.3 kernel/auditsc.c - 1.2 mm/hugetlb.c - 1.3 net/ipv4/netfilter/iptable_raw.c - 1.2 net/ipv6/netfilter/ip6table_raw.c - 1.2 split-patches/free_more_memory - 1.2 arch/ppc/platforms/sbc82xx.c - 1.2 arch/ppc/platforms/sbc82xx.h - 1.2 arch/ppc/kernel/vecemu.c - 1.2 arch/ppc/kernel/dma-mapping.c - 1.2 arch/ppc/configs/bubinga_defconfig - 1.2 arch/parisc/kernel/unwind.c - 1.2 arch/ppc64/lib/locks.c - 1.2 scripts/checkstack.pl - 1.2 arch/s390/lib/string.c - 1.2 drivers/net/ne-h8300.c - 1.2 arch/sparc64/lib/find_bit.c - 1.2 arch/sparc64/lib/splock.S - 1.2 mm/mempolicy.c - 1.2 drivers/char/drm/drm_irq.h - 1.2 include/linux/mempolicy.h - 1.2 drivers/char/watchdog/ixp4xx_wdt.c - 1.2 net/bridge/br_sysfs_br.c - 1.2 include/asm-parisc/unwind.h - 1.2 include/asm-mips/pmon.h - 1.2 net/bridge/br_sysfs_if.c - 1.2 drivers/mtd/maps/ixp4xx.c - 1.2 drivers/mtd/maps/wr_sbc82xx_flash.c - 1.2 drivers/scsi/ipr.c - 1.2 drivers/scsi/ipr.h - 1.2 drivers/scsi/qlogicfas408.c - 1.2 arch/ia64/configs/sim_defconfig - 1.2 drivers/scsi/sata_sx4.c - 1.2 drivers/usb/core/sysfs.c - 1.2 drivers/usb/misc/phidgetservo.c - 1.2 arch/i386/kdb/kdb_cmds - 1.2 drivers/video/asiliantfb.c - 1.2 drivers/video/pxafb.c - 1.2 arch/arm/configs/ixp4xx_defconfig - 1.2 include/asm-i386/bfd.h - 1.2 arch/arm/configs/mainstone_defconfig - 1.2 arch/arm/configs/smdk2410_defconfig - 1.2 arch/arm/mach-s3c2410/mach-smdk2410.c - 1.2 include/asm-arm/arch-ixp4xx/dma.h - 1.2 arch/arm/mach-pxa/mainstone.c - 1.2 include/asm-arm/arch-ixp4xx/memory.h - 1.2 include/asm-arm/arch-ixp4xx/platform.h - 1.2 include/asm-arm/arch-ixp4xx/time.h - 1.2 arch/arm/mach-ixp4xx/common-pci.c - 1.2 arch/arm/mach-ixp4xx/common.c - 1.2 arch/arm/mach-ixp4xx/coyote-setup.c - 1.2 arch/arm/mach-ixp4xx/ixdp425-setup.c - 1.2 arch/arm/mach-ixp4xx/prpmc1100-setup.c - 1.2 include/asm-i386/ansidecl.h - 1.2 From owner-linux-xfs Sun Aug 15 23:45:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 23:45:50 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G6jlm7016603 for ; Sun, 15 Aug 2004 23:45:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7G7nOMI002464 for ; Mon, 16 Aug 2004 00:49:25 -0700 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 i7G6jQ7X14541504; Mon, 16 Aug 2004 16:45:27 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7G6jOn814484960; Mon, 16 Aug 2004 16:45:24 +1000 (EST) Date: Mon, 16 Aug 2004 16:45:24 +1000 (EST) From: Nathan Scott Message-Id: <200408160645.i7G6jOn814484960@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 919129 - realtime inheritance flag X-archive-position: 3922 X-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: 18 Add a "realtime inheritance" bit for directory inodes so new files can be automatically created as realtime files. Date: Sun Aug 15 23:43:29 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: overby@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:177129a xfsidbg.c - 1.264 xfs_vnodeops.c - 1.628 xfs_fs.h - 1.19 xfs_inode.c - 1.403 xfs_dinode.h - 1.71 From owner-linux-xfs Sun Aug 15 23:54:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Aug 2004 23:54:32 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7G6sU5e017014 for ; Sun, 15 Aug 2004 23:54:30 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7G7w4Hk005482 for ; Mon, 16 Aug 2004 00:58:06 -0700 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 i7G6sF7X14534215; Mon, 16 Aug 2004 16:54:15 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7G6sDLi14624702; Mon, 16 Aug 2004 16:54:13 +1000 (EST) Date: Mon, 16 Aug 2004 16:54:13 +1000 (EST) From: Nathan Scott Message-Id: <200408160654.i7G6sDLi14624702@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 919129 - update docs X-archive-position: 3923 X-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: 358 Lines: 14 Update documentation about the additional XFS inode flags. Date: Sun Aug 15 23:53:44 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:177130a xfsprogs/doc/CHANGES - 1.159 xfsprogs/man/man3/xfsctl.3 - 1.4 From owner-linux-xfs Mon Aug 16 09:43:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 09:43:33 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GGhTdE022966 for ; Mon, 16 Aug 2004 09:43:30 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7GGhN0f012426 for ; Mon, 16 Aug 2004 11:43:24 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7GGhMOV45156713; Mon, 16 Aug 2004 11:43:22 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1BwkZu-0006v9-00; Mon, 16 Aug 2004 11:43:22 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 919705 - Add 32bit ioctl translation Message-Id: From: Christoph Hellwig Date: Mon, 16 Aug 2004 11:43:22 -0500 X-archive-position: 3924 X-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: 770 Lines: 32 Date: Mon Aug 16 09:43:08 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:177164a fs/xfs/linux-2.6/xfs_ioctl32.c - 1.1 - Add 32bit ioctl translation fs/xfs/linux-2.6/xfs_ioctl32.h - 1.1 - Add 32bit ioctl translation fs/xfs/xfs_fs.h - 1.20 - move file flag ioctl defintions to xfs_fs.h fs/xfs/Makefile-linux-2.6 - 1.192 - Add xfs_ioctl32.o to the build fs/xfs/linux-2.6/xfs_ioctl.c - 1.114 - move file flag ioctl defintions to xfs_fs.h fs/xfs/linux-2.6/xfs_super.c - 1.312 - Add 32bit ioctl translation fs/xfs/linux-2.4/xfs_ioctl.c - 1.110 - move file flag ioctl defintions to xfs_fs.h From owner-linux-xfs Mon Aug 16 09:49:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 09:50:00 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GGntdr023414 for ; Mon, 16 Aug 2004 09:49:56 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Bwkg8-0003Oa-AJ; Mon, 16 Aug 2004 17:49:48 +0100 Date: Mon, 16 Aug 2004 17:49:48 +0100 From: Christoph Hellwig To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: TAKE 919705 - Add 32bit ioctl translation Message-ID: <20040816174948.A13052@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from hch@sgi.com on Mon, Aug 16, 2004 at 11:43:22AM -0500 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 3925 X-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: 225 Lines: 9 This is currently 2.6-only. If someone is eager enough to find out a) which architectures support register_ioctl32_conversion b) under what per-arch ifdef that is and c) in what header a 2.4 variant should be doable. From owner-linux-xfs Mon Aug 16 09:55:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 09:55:48 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GGtj3X023860 for ; Mon, 16 Aug 2004 09:55:46 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7GHxS2S007230 for ; Mon, 16 Aug 2004 10:59:28 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7GGscOV45142717; Mon, 16 Aug 2004 11:54:38 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Bwkko-0007D6-00; Mon, 16 Aug 2004 11:54:38 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 919707 - avoid using pid_t in ioctl ABI Message-Id: From: Christoph Hellwig Date: Mon, 16 Aug 2004 11:54:38 -0500 X-archive-position: 3926 X-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: 312 Lines: 14 Date: Mon Aug 16 09:54:27 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:177165a fs/xfs/xfs_fs.h - 1.21 - switch xfs_lock_t.l_pid to __u32 From owner-linux-xfs Mon Aug 16 13:19:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 13:19:59 -0700 (PDT) Received: from rock.activestate.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GKJtc5003352 for ; Mon, 16 Aug 2004 13:19:57 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.12.11/8.12.11) with ESMTP id i7GKJhA2006272 for ; Mon, 16 Aug 2004 13:19:43 -0700 (envelope-from daves@activestate.com) Message-ID: <412116DF.7060809@activestate.com> Date: Mon, 16 Aug 2004 13:19:43 -0700 From: David Sparks User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040812) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: What does "xlog_state_do_callback: looping " mean? X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3927 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Content-Length: 1042 Lines: 35 I have a server where the `dmesg` is full of: Filesystem "hda4": xlog_state_do_callback: looping 10 Filesystem "hda4": xlog_state_do_callback: looping 20 Filesystem "hda4": xlog_state_do_callback: looping 10 Filesystem "hda4": xlog_state_do_callback: looping 10 Filesystem "hda4": xlog_state_do_callback: looping 10 Filesystem "hda4": xlog_state_do_callback: looping 20 [...] The hda4 partition contains the /var tree. I ran xfs_check and it didn't find any problems. The machine is a gateway MTA and doesn't have any noticeable issues. Kernel version: Linux mx3 2.6.5-gentoo-r1 #1 Wed Jun 16 11:27:10 Local time zone must be set--see zic manu i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Filesystem Size Used Avail Use% Mounted on /dev/hda3 15G 2.8G 13G 19% / none 189M 0 189M 0% /dev/shm /dev/hda4 14G 4.0G 9.4G 30% /var Googling for 'xlog_state_do_callback' didn't really go into any depth of what this means. Can anyone enlighten me? Thanks, ds From owner-linux-xfs Mon Aug 16 13:39:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 13:39:40 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GKdb5A004070 for ; Mon, 16 Aug 2004 13:39:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7GKdV0f003549 for ; Mon, 16 Aug 2004 15:39:31 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7GKdVOV44989812; Mon, 16 Aug 2004 15:39:31 -0500 (CDT) Received: (from overby@localhost) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) id i7GKdU6D17503753; Mon, 16 Aug 2004 15:39:30 -0500 (CDT) Date: Mon, 16 Aug 2004 15:39:30 -0500 (CDT) Message-Id: <200408162039.i7GKdU6D17503753@daisy-e236.americas.sgi.com> From: Glen Overby To: daves@activestate.com Cc: linux-xfs@oss.sgi.com Reply-To: linux-xfs@oss.sgi.com Subject: Re: What does "xlog_state_do_callback: looping " mean? In-Reply-To: message from David Sparks sent 16 August 2004 References: <412116DF.7060809@activestate.com> X-archive-position: 3928 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1850 Lines: 43 On August 16, David Sparks wrote: > I have a server where the `dmesg` is full of: > > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 20 > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 20 > [...] > > The hda4 partition contains the /var tree. First, the purpose of that function is to execute I/O completion callbacks from XFS log buffer writes. The callbacks have to be run in log block sequence order; that is, if writes complete out of order, it is this function's job to make sure the calls are called in order (the faster I/O completion has it's callbacks delayed until the slower one completes). It is theoreticly possible for this function to never complete. If the filesystem is under an intense metadata load and the log device is fast enough, one CPU could spend all of it's time running callbacks while other CPUs are creating transactions and writing them to disk. Since callbacks are an interrupt-time event, a CPU or interrupt handler could be forever locked up. That, in turn, could result in other interrupts not being serviced. I didn't come up with a way to avoid this livelock that wasn't racy, so instead I chose to let it exist, but to put a warning message in if the function looped excessively. The count printed is the number of times that the function has looped over all log buffers and is printed every 10 loops. Nothing is wrong with your filesystem. I'm curious what your system config is: CPU speed, how many CPUs, what type of disk and controler are under your XFS filesystems. It could be time to revisit my defintion of "looping excessively" in this context. Glen Overby From owner-linux-xfs Mon Aug 16 15:44:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 15:45:25 -0700 (PDT) Received: from mail.shadowconnect.com (s0003.shadowconnect.net [213.239.201.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GMiHue008312 for ; Mon, 16 Aug 2004 15:44:18 -0700 Received: from pd9e0ad7f.dip.t-dialin.net ([217.224.173.127] helo=[192.168.0.2]) by mail.shadowconnect.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1BwqD1-0003UW-Uv; Tue, 17 Aug 2004 00:44:08 +0200 Message-ID: <412136CC.5070708@shadowconnect.com> Date: Tue, 17 Aug 2004 00:35:56 +0200 From: Markus Lidel Organization: Shadow Connect User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: how to free a used ag? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3929 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Markus.Lidel@shadowconnect.com Precedence: bulk X-list: linux-xfs Content-Length: 1385 Lines: 45 Hi... could someone help me with freeing a used ag? I want to do it inside the kernel and while the fs is mounted. I've already looked at the code, and it looks to me that freeing the agi of an ag is the easier part, so i want to start with it. I thought i could look at each inode of the agi i want to free, but i think i must iterate over each inode when freeing the used blocks anyway. So i iterate over each inode (starting with the root inode) and move the inode to a new one if it is inside the ag which should be freed. The second step is to look at the inode itself. If the data block is inside the ag it could be moved outside the ag too. If i missed something until here, please let me know:-) My questions are: 1. Is there a facility to iterate over each used inode? 2. how could i easily copy the inode to a free space outside the current agi (i thought of setting pag.pagf_freeblks, pag.pagf_flcount, pag.pagf_longest to 0). 3. have i missed something or is there a better way to do it? Any help is appreciated. Thank you very much in advance. Best regards, Markus Lidel ------------------------------------------ Markus Lidel (Senior IT Consultant) Shadow Connect GmbH Carl-Reisch-Weg 12 D-86381 Krumbach Germany Phone: +49 82 82/99 51-0 Fax: +49 82 82/99 51-11 E-Mail: Markus.Lidel@shadowconnect.com URL: http://www.shadowconnect.com From owner-linux-xfs Mon Aug 16 15:54:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 15:54:18 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GMsCCE008739 for ; Mon, 16 Aug 2004 15:54:13 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BwqMf-0004Ca-UE; Mon, 16 Aug 2004 23:54:05 +0100 Date: Mon, 16 Aug 2004 23:54:05 +0100 From: Christoph Hellwig To: Markus Lidel Cc: linux-xfs@oss.sgi.com Subject: Re: how to free a used ag? Message-ID: <20040816235405.A16123@infradead.org> References: <412136CC.5070708@shadowconnect.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: <412136CC.5070708@shadowconnect.com>; from Markus.Lidel@shadowconnect.com on Tue, Aug 17, 2004 at 12:35:56AM +0200 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 3930 X-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: 751 Lines: 19 On Tue, Aug 17, 2004 at 12:35:56AM +0200, Markus Lidel wrote: > 1. Is there a facility to iterate over each used inode? xfs_bulkstat. although I doubt it fits your needs. > 2. how could i easily copy the inode to a free space outside the current > agi (i thought of setting pag.pagf_freeblks, pag.pagf_flcount, > pag.pagf_longest to 0). You could try by marking the AG unavailable to the allocator and use xfs_swapext() > 3. have i missed something or is there a better way to do it? As it seems you're trying to implement online shrinking of a filesystem, remember that moving an inode around actually changes the inode number in XFS, which will you get all kinds of funnies not only with the kernel but also userspace and nfs clients. From owner-linux-xfs Mon Aug 16 16:18:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Aug 2004 16:18:10 -0700 (PDT) Received: from rock.activestate.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7GNI36Q009992 for ; Mon, 16 Aug 2004 16:18:08 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.12.11/8.12.11) with ESMTP id i7GNHq3W007249 for ; Mon, 16 Aug 2004 16:17:52 -0700 (envelope-from daves@activestate.com) Message-ID: <412140A0.6070102@activestate.com> Date: Mon, 16 Aug 2004 16:17:52 -0700 From: David Sparks User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040812) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: What does "xlog_state_do_callback: looping " mean? References: <412116DF.7060809@activestate.com> <200408162039.i7GKdU6D17503753@daisy-e236.americas.sgi.com> In-Reply-To: <200408162039.i7GKdU6D17503753@daisy-e236.americas.sgi.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3931 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Content-Length: 3454 Lines: 108 [...] > Nothing is wrong with your filesystem. Thanks for the explanation. > I'm curious what your system config is: CPU speed, how many CPUs, what > type of disk and controler are under your XFS filesystems. It could > be time to revisit my defintion of "looping excessively" in this > context. It is a single P3 running bind 9 and sendmail under medium-heavy load. I've tried to cut-n-paste the relevant diagnostic outputs below. I've just noticed a problem that the machine has a VIA chipset but the kernel only had Intel/generic support so it wasn't running in a DMA mode. The buffered read rate from hdparm -t was only 4 MB/s. When using the generic IDE driver that log line would be written every few minutes. I haven't seen it since switching to using the VIA driver. I guess the problem is the classic operator error. :'/ Thanks for the help! ds Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:04.1 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci0000:00:04.1 ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:DMA, hdd:pio hda: QUANTUM FIREBALLP AS30.0, ATA DISK drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: Pioneer DVD-ROM ATAPIModel DVD-116 0107, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 60233564 sectors (30839 MB) w/1902KiB Cache, CHS=59755/16/63, UDMA(66) /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 hdc: ATAPI 40X DVD-ROM drive, 256kB Cache, UDMA(33) 0000:00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, stepping, medium devsel, latency 32 I/O ports at b800 [size=16] Capabilities: [c0] Power Management version 2 mx3 root # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 870.633 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1716.22 mx3 root # cat /proc/meminfo MemTotal: 387520 kB MemFree: 71572 kB Buffers: 43728 kB Cached: 116852 kB SwapCached: 0 kB Active: 171312 kB Inactive: 32692 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 387520 kB LowFree: 71572 kB SwapTotal: 506036 kB SwapFree: 506036 kB Dirty: 4308 kB Writeback: 0 kB Mapped: 50484 kB Slab: 109908 kB Committed_AS: 85384 kB PageTables: 412 kB VmallocTotal: 638968 kB VmallocUsed: 292 kB VmallocChunk: 638676 kB mx3 root # hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 612 MB in 2.00 seconds = 305.89 MB/sec Timing buffered disk reads: 92 MB in 3.01 seconds = 30.60 MB/sec From owner-linux-xfs Tue Aug 17 01:44:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Aug 2004 01:44:55 -0700 (PDT) Received: from mail.shadowconnect.com (s0003.shadowconnect.net [213.239.201.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7H8io06008045 for ; Tue, 17 Aug 2004 01:44:51 -0700 Received: from p548720bd.dip.t-dialin.net ([84.135.32.189] helo=[192.168.1.52]) by mail.shadowconnect.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1BwzaD-0004ru-Mb; Tue, 17 Aug 2004 10:44:41 +0200 Message-ID: <4121C89B.2000507@shadowconnect.com> Date: Tue, 17 Aug 2004 10:58:03 +0200 From: Markus Lidel User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: how to free a used ag? References: <412136CC.5070708@shadowconnect.com> <20040816235405.A16123@infradead.org> In-Reply-To: <20040816235405.A16123@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Markus.Lidel@shadowconnect.com Precedence: bulk X-list: linux-xfs Content-Length: 1523 Lines: 50 Hi... Christoph Hellwig wrote: > On Tue, Aug 17, 2004 at 12:35:56AM +0200, Markus Lidel wrote: >>1. Is there a facility to iterate over each used inode? > xfs_bulkstat. although I doubt it fits your needs. Thanks the function is a good starting point. >>2. how could i easily copy the inode to a free space outside the current >> agi (i thought of setting pag.pagf_freeblks, pag.pagf_flcount, >> pag.pagf_longest to 0). > You could try by marking the AG unavailable to the allocator and use > xfs_swapext() Is it enough to set the pag values descirbed above to 0 or is there anything else to do? >>3. have i missed something or is there a better way to do it? > As it seems you're trying to implement online shrinking of a filesystem, > remember that moving an inode around actually changes the inode number > in XFS, which will you get all kinds of funnies not only with the kernel > but also userspace and nfs clients. Thanks to remeber me... For now i would be glad if i could verify that an AG is empty and only remove it if it is :-D If things get too complicated (e. g. a file is opened in the AG, which should be freed) i would simply do nothing for now... Thank you very much for your help! Best regards, Markus Lidel ------------------------------------------ Markus Lidel (Senior IT Consultant) Shadow Connect GmbH Carl-Reisch-Weg 12 D-86381 Krumbach Germany Phone: +49 82 82/99 51-0 Fax: +49 82 82/99 51-11 E-Mail: Markus.Lidel@shadowconnect.com URL: http://www.shadowconnect.com From owner-linux-xfs Tue Aug 17 08:25:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Aug 2004 08:25:51 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7HFPlsn031068 for ; Tue, 17 Aug 2004 08:25:48 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Bx5qG-00060q-HI; Tue, 17 Aug 2004 16:25:40 +0100 Date: Tue, 17 Aug 2004 16:25:40 +0100 From: Christoph Hellwig To: Markus Lidel Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: how to free a used ag? Message-ID: <20040817162540.A23090@infradead.org> References: <412136CC.5070708@shadowconnect.com> <20040816235405.A16123@infradead.org> <4121C89B.2000507@shadowconnect.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: <4121C89B.2000507@shadowconnect.com>; from Markus.Lidel@shadowconnect.com on Tue, Aug 17, 2004 at 10:58:03AM +0200 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 3933 X-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: 441 Lines: 11 > >>2. how could i easily copy the inode to a free space outside the current > >> agi (i thought of setting pag.pagf_freeblks, pag.pagf_flcount, > >> pag.pagf_longest to 0). > > You could try by marking the AG unavailable to the allocator and use > > xfs_swapext() > > Is it enough to set the pag values descirbed above to 0 or is there > anything else to do? I'm not sure, Glen probably knows the allocator much better than I do. From owner-linux-xfs Tue Aug 17 09:20:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Aug 2004 09:20:15 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7HGK8XT003685 for ; Tue, 17 Aug 2004 09:20:10 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Aug 2004 09:19:57 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Aug 2004 09:19:57 -0700 Message-ID: <41222FD4.9060601@xfs.org> Date: Tue, 17 Aug 2004 11:18:28 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Lidel CC: linux-xfs@oss.sgi.com Subject: Re: how to free a used ag? References: <412136CC.5070708@shadowconnect.com> In-Reply-To: <412136CC.5070708@shadowconnect.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2004 16:19:57.0297 (UTC) FILETIME=[09764610:01C48476] X-archive-position: 3934 X-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@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 2789 Lines: 78 Markus Lidel wrote: > Hi... > > could someone help me with freeing a used ag? > > I want to do it inside the kernel and while the fs is mounted. I've > already looked at the code, and it looks to me that freeing the agi of > an ag is the easier part, so i want to start with it. I thought i could > look at each inode of the agi i want to free, but i think i must iterate > over each inode when freeing the used blocks anyway. So i iterate over > each inode (starting with the root inode) and move the inode to a new > one if it is inside the ag which should be freed. The second step is to > look at the inode itself. If the data block is inside the ag it could be > moved outside the ag too. > > If i missed something until here, please let me know:-) Make sure you traverse all the inodes - there will probably be inodes in different allocation groups which have extents in the targeted ag. When you move an inode you need to fix up all the directories which point at it. It is going to get a new inode number, so you need to walk the directory tree looking for that inode number and replacing it. Remember, hard links mean an inode number could show up more than once. > > My questions are: > 1. Is there a facility to iterate over each used inode? Bulkstat as Christoph said. > 2. how could i easily copy the inode to a free space outside the current > agi (i thought of setting pag.pagf_freeblks, pag.pagf_flcount, > pag.pagf_longest to 0). You need a mechanism to drain all the transactions in progress (look at the freeze code), then flag the per ag structures in some way so that the allocator will not use them. A temporary in memory flag in the per ag headers is probably best. Then start up transactions again. > 3. have i missed something or is there a better way to do it? > You might want to try this from user space with some kernel assist rather than doing it all in the kernel. The bulkstat and swap extent calls provide the meat of the tools you need to do this. Of course, you need sufficient free space to recreate everything outside those allocation groups. If you are removing some space from the filesystem, the allocator probably needs to be told that the filesystem is smaller than it actually is, or you may get into states where one part of the allocator thinks there is room, but it cannot actually find the space. Steve > Any help is appreciated. > > Thank you very much in advance. > > Best regards, > > > Markus Lidel > ------------------------------------------ > Markus Lidel (Senior IT Consultant) > > Shadow Connect GmbH > Carl-Reisch-Weg 12 > D-86381 Krumbach > Germany > > Phone: +49 82 82/99 51-0 > Fax: +49 82 82/99 51-11 > > E-Mail: Markus.Lidel@shadowconnect.com > URL: http://www.shadowconnect.com > From owner-linux-xfs Tue Aug 17 17:25:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Aug 2004 17:25:13 -0700 (PDT) Received: from mail.inostor.com (w130.z209220038.sjc-ca.dsl.cnc.net [209.220.38.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7I0P9Ue023016 for ; Tue, 17 Aug 2004 17:25:10 -0700 Received: from [10.73.0.103] (unknown [172.16.1.75]) by mail.inostor.com (Postfix) with ESMTP id 1C4AF2B523 for ; Tue, 17 Aug 2004 17:07:06 -0700 (PDT) Subject: errata list available? From: "James G. Sack (jim)" To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1092788719.2368.37.camel@jgs3> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Aug 2004 17:25:20 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 3935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsack@inostor.com Precedence: bulk X-list: linux-xfs Content-Length: 860 Lines: 23 I am interested in tracing entries in the Linux 2.4.27 Changelog to actual code changes. Is there any ~easy way to do that? Is there an list that ties fixes to code -- an "errata list" perhaps. The question arises because I have experienced an unexpected loss of data (on 2.4.26 kernel) without any good clues except for a message including "xlog_recover_process_data: bad clientid". In searching for this error message I recall seeing suggestions that there was nothing much that could be done except run xfs_repair. But, upon performing an xfs_repair ... the entire fs was cleared-out when it finally finished . It would be "somewhat soothing" to find there were recently-fixed problems conceivably related to our data loss. I would much appreciate any answers being directly cc'd to my email, as I am not presently "on the list". Thanks, ..jim From owner-linux-xfs Wed Aug 18 02:38:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Aug 2004 02:38:16 -0700 (PDT) Received: from mail.shadowconnect.com (s0003.shadowconnect.net [213.239.201.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7I9c92x032245 for ; Wed, 18 Aug 2004 02:38:10 -0700 Received: from pd9523ee1.dip.t-dialin.net ([217.82.62.225] helo=[192.168.1.52]) by mail.shadowconnect.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1BxMtG-0004SN-DU; Wed, 18 Aug 2004 11:37:55 +0200 Message-ID: <41232698.2050103@shadowconnect.com> Date: Wed, 18 Aug 2004 11:51:20 +0200 From: Markus Lidel User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: how to free a used ag? References: <412136CC.5070708@shadowconnect.com> <41222FD4.9060601@xfs.org> In-Reply-To: <41222FD4.9060601@xfs.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010302010108060609090007" X-archive-position: 3936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Markus.Lidel@shadowconnect.com Precedence: bulk X-list: linux-xfs Content-Length: 8232 Lines: 172 This is a cryptographically signed message in MIME format. --------------ms010302010108060609090007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, Steve Lord wrote: > Markus Lidel wrote: >> could someone help me with freeing a used ag? >> I want to do it inside the kernel and while the fs is mounted. I've >> already looked at the code, and it looks to me that freeing the agi of >> an ag is the easier part, so i want to start with it. I thought i >> could look at each inode of the agi i want to free, but i think i must >> iterate over each inode when freeing the used blocks anyway. So i >> iterate over each inode (starting with the root inode) and move the >> inode to a new one if it is inside the ag which should be freed. The >> second step is to look at the inode itself. If the data block is >> inside the ag it could be moved outside the ag too. >> If i missed something until here, please let me know:-) > Make sure you traverse all the inodes - there will probably be inodes > in different allocation groups which have extents in the targeted ag. > When you move an inode you need to fix up all the directories which > point at it. It is going to get a new inode number, so you need to walk > the directory tree looking for that inode number and replacing it. > Remember, > hard links mean an inode number could show up more than once. Thanks you very much for the advice... But do you think it's better to work on the on-disk structure, or do you think it's better to work with the in-core inodes? >> 2. how could i easily copy the inode to a free space outside the current >> agi (i thought of setting pag.pagf_freeblks, pag.pagf_flcount, >> pag.pagf_longest to 0). > You need a mechanism to drain all the transactions in progress (look at > the freeze code), then flag the per ag structures in some way so that > the allocator will not use them. A temporary in memory flag in the > per ag headers is probably best. Then start up transactions again. Hmmm, if i work on the in-core structures, do i have to care about transactions too? >> 3. have i missed something or is there a better way to do it? > You might want to try this from user space with some kernel assist rather > than doing it all in the kernel. The bulkstat and swap extent calls provide > the meat of the tools you need to do this. > Of course, you need sufficient free space to recreate everything > outside those Okay... > allocation groups. If you are removing some space from the filesystem, the > allocator probably needs to be told that the filesystem is smaller than it > actually is, or you may get into states where one part of the allocator > thinks > there is room, but it cannot actually find the space. This is the only thing which is working right now :-) Thank you very much for your help! Best regards, Markus Lidel ------------------------------------------ Markus Lidel (Senior IT Consultant) Shadow Connect GmbH Carl-Reisch-Weg 12 D-86381 Krumbach Germany Phone: +49 82 82/99 51-0 Fax: +49 82 82/99 51-11 E-Mail: Markus.Lidel@shadowconnect.com URL: http://www.shadowconnect.com --------------ms010302010108060609090007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIKPzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0x MzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/ Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVt YWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggN6MIIC46ADAgEC AgML8dEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDMxODE0MzM0 MVoXDTA1MDMxODE0MzM0MVowgeAxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZC YXllcm4xETAPBgNVBAcTCEtydW1iYWNoMScwJQYDVQQKEx5TaGFkb3cgQ29u bmVjdCBHbWJIIChJbnRlcm5ldCkxHTAbBgNVBAwTFFNlbmlvciBJVCBDb25z dWx0YW50MQ4wDAYDVQQEEwVMaWRlbDEPMA0GA1UEKhMGTWFya3VzMRUwEwYD VQQDEwxNYXJrdXMgTGlkZWwxLTArBgkqhkiG9w0BCQEWHk1hcmt1cy5MaWRl bEBzaGFkb3djb25uZWN0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAPmIWQ2zrKutnkd7iB3AQTEwE9q9p7Cs7F3f92dh29+RHpDpAGMv ZlVxLBNPBkvPdhcVeWLHbKI2XKfjzLzXhVPZEs41KkSecQ9bOLMSu+T6y2SK vcnf0Qxw8pZ1KJwkIJ0RcLyIUPE0RI/RG0DaBY6toApoLQEJOzKsdxuTUOK9 4m9kwSCRNJdjuZtYCAOihAVCfl9vJJNFUw9h4mmZ4RWsjh85kvvqKK3Bo6eY ia74AuXH6kWgvuvkyW0w8S9J8f62KXcVNQ8NZr9Gd4rclfNj55i73p+FL6op HjhryKa9GIV7IzpEp6q1LQ1OD/glJEaR/Vl0l1YQVWU24dURNtsCAwEAAaM7 MDkwKQYDVR0RBCIwIIEeTWFya3VzLkxpZGVsQHNoYWRvd2Nvbm5lY3QuY29t MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEADutiuioIWfT1dzLD 72TWc2y3yxg2sJOZhJQYvZYxdwFh3MOht+Jd/JizLQvOsM+HXuU4qLTyCpYB +AfPpQH3xObQVBWV23d6nBkA2QWie/BD18wl8Xv2bKykXyvW66l2Kk9VsROU lAQi2GyLiFGd9SvNJcTwNtbqV/8ojXmu7XIwggN6MIIC46ADAgECAgML8dEw DQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDMxODE0MzM0MVoXDTA1 MDMxODE0MzM0MVowgeAxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCYXllcm4x ETAPBgNVBAcTCEtydW1iYWNoMScwJQYDVQQKEx5TaGFkb3cgQ29ubmVjdCBH bWJIIChJbnRlcm5ldCkxHTAbBgNVBAwTFFNlbmlvciBJVCBDb25zdWx0YW50 MQ4wDAYDVQQEEwVMaWRlbDEPMA0GA1UEKhMGTWFya3VzMRUwEwYDVQQDEwxN YXJrdXMgTGlkZWwxLTArBgkqhkiG9w0BCQEWHk1hcmt1cy5MaWRlbEBzaGFk b3djb25uZWN0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB APmIWQ2zrKutnkd7iB3AQTEwE9q9p7Cs7F3f92dh29+RHpDpAGMvZlVxLBNP BkvPdhcVeWLHbKI2XKfjzLzXhVPZEs41KkSecQ9bOLMSu+T6y2SKvcnf0Qxw 8pZ1KJwkIJ0RcLyIUPE0RI/RG0DaBY6toApoLQEJOzKsdxuTUOK94m9kwSCR NJdjuZtYCAOihAVCfl9vJJNFUw9h4mmZ4RWsjh85kvvqKK3Bo6eYia74AuXH 6kWgvuvkyW0w8S9J8f62KXcVNQ8NZr9Gd4rclfNj55i73p+FL6opHjhryKa9 GIV7IzpEp6q1LQ1OD/glJEaR/Vl0l1YQVWU24dURNtsCAwEAAaM7MDkwKQYD VR0RBCIwIIEeTWFya3VzLkxpZGVsQHNoYWRvd2Nvbm5lY3QuY29tMAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEADutiuioIWfT1dzLD72TWc2y3 yxg2sJOZhJQYvZYxdwFh3MOht+Jd/JizLQvOsM+HXuU4qLTyCpYB+AfPpQH3 xObQVBWV23d6nBkA2QWie/BD18wl8Xv2bKykXyvW66l2Kk9VsROUlAQi2GyL iFGd9SvNJcTwNtbqV/8ojXmu7XIxggM7MIIDNwIBATBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C/HRMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDgxODA5NTEyMFowIwYJKoZIhvcNAQkEMRYE FKz3S8F0fpjiL5BQrXNmB6IrHseMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgML 8dEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC/HRMA0GCSqGSIb3 DQEBAQUABIIBAF4M8ew654LItSjjOwOVgR4svnIeFg0ePc+D6gX+i5VbuffQ XauEHmz4ycV0OWum71XyoiHf4ojCIL4m0cBAAzCFPEbJDy2Uu8pxoFoSslnY qGyAawE4zG239KJ36IQWwKfCxsgXLWd/MS+fiFN6nPVfoyPL8gGqXDm8mDrG S3rdVxdpfG+exb9hGC1tSAaqZ5g3ANImogVr2tQ/Up1HJYhxHKjjj1V9hCLt T3scvdV8g5jtrPDRM9+EARSDYm1f7b3TqWHADPSo5mfN1piwlzi+GqlAnymm ZQ/nnjnwLyNknVWNFQLv+4qZ0PUesaOiTtIeL25dTWBs1ojEZp1ntp4AAAAA AAA= --------------ms010302010108060609090007-- From owner-linux-xfs Wed Aug 18 07:44:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Aug 2004 07:44:55 -0700 (PDT) Received: from mail00hq.adic.com (mail00hq.adic.com [63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7IEijmx015740 for ; Wed, 18 Aug 2004 07:44:45 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Aug 2004 07:44:34 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Aug 2004 07:44:33 -0700 Message-ID: <41236AF7.4030708@xfs.org> Date: Wed, 18 Aug 2004 09:43:03 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Lidel CC: linux-xfs@oss.sgi.com Subject: Re: how to free a used ag? References: <412136CC.5070708@shadowconnect.com> <41222FD4.9060601@xfs.org> <41232698.2050103@shadowconnect.com> In-Reply-To: <41232698.2050103@shadowconnect.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2004 14:44:33.0824 (UTC) FILETIME=[E06B5A00:01C48531] X-archive-position: 3937 X-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@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 3347 Lines: 74 Markus Lidel wrote: > Hello, > > Steve Lord wrote: > >> Markus Lidel wrote: >> >>> could someone help me with freeing a used ag? >>> I want to do it inside the kernel and while the fs is mounted. I've >>> already looked at the code, and it looks to me that freeing the agi >>> of an ag is the easier part, so i want to start with it. I thought i >>> could look at each inode of the agi i want to free, but i think i >>> must iterate over each inode when freeing the used blocks anyway. So >>> i iterate over each inode (starting with the root inode) and move the >>> inode to a new one if it is inside the ag which should be freed. The >>> second step is to look at the inode itself. If the data block is >>> inside the ag it could be moved outside the ag too. >>> If i missed something until here, please let me know:-) >> >> Make sure you traverse all the inodes - there will probably be inodes >> in different allocation groups which have extents in the targeted ag. >> When you move an inode you need to fix up all the directories which >> point at it. It is going to get a new inode number, so you need to walk >> the directory tree looking for that inode number and replacing it. >> Remember, >> hard links mean an inode number could show up more than once. > > > Thanks you very much for the advice... But do you think it's better to > work on the on-disk structure, or do you think it's better to work with > the in-core inodes? You had said you wanted to do this on a live filesystem. I think running everything through transactions is going to be more robust, and being able to offline part of a running filesystem is a more useful feature than doing it on an unmounted fs. The two potential approaches here are really to add some extensions to the kernel and use thinks like bulkstat and swapext to do the work on the live filesystem. Everything will be transactional, if the machine goes down or crashes in the middle, you should end up with a working filesystem. The alternative is to use something like libxfs and manipulate the fs from user space - if you crash you are left with bits and pieces of a filesystem. So taking the use the transaction system approach: Add the logic to turn off new allocates in the allocation group, sounds like you are making progress on this. The defragmenter uses swapext to move extents from one file to another. I would build on this approach, so have a user space app which scans the fs for target inodes. Use the code from the defragmenter, without the logic which says it has to be less fragmented afterwards, to move the space to elsewhere in the fs - since allocations will not be allowed in the ag you are emptying, you end up with an inode and extents which are in other allocation groups. This leaves directories with blocks in the ag to rebuild, a mkdir of a temporary dir and some renames should take care of that. Other things to watch out for: There is the log in the middle allocation group, you cannot empty that one. Sometimes when you free space it actually wants to allocate blocks in that ag to put the free space tree into. Eventually the free space btree will collapse, but there could be some interim steps where an allocate is required to free space. There will need to be special logic to allow these allocates to happen. Steve From owner-linux-xfs Wed Aug 18 08:42:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Aug 2004 08:42:18 -0700 (PDT) Received: from mail.shadowconnect.com (s0003.shadowconnect.net [213.239.201.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7IFgCeU023441 for ; Wed, 18 Aug 2004 08:42:13 -0700 Received: from pd9523ee1.dip.t-dialin.net ([217.82.62.225] helo=[192.168.1.52]) by mail.shadowconnect.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1BxSZe-0005Wv-JL; Wed, 18 Aug 2004 17:42:03 +0200 Message-ID: <41237BF2.1050500@shadowconnect.com> Date: Wed, 18 Aug 2004 17:55:30 +0200 From: Markus Lidel User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: how to free a used ag? References: <412136CC.5070708@shadowconnect.com> <41222FD4.9060601@xfs.org> <41232698.2050103@shadowconnect.com> <41236AF7.4030708@xfs.org> In-Reply-To: <41236AF7.4030708@xfs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Markus.Lidel@shadowconnect.com Precedence: bulk X-list: linux-xfs Content-Length: 4670 Lines: 109 Hello, Steve Lord wrote: > Markus Lidel wrote: >> Steve Lord wrote: >>> Markus Lidel wrote: >>>> could someone help me with freeing a used ag? >>>> I want to do it inside the kernel and while the fs is mounted. I've >>>> already looked at the code, and it looks to me that freeing the agi >>>> of an ag is the easier part, so i want to start with it. I thought i >>>> could look at each inode of the agi i want to free, but i think i >>>> must iterate over each inode when freeing the used blocks anyway. So >>>> i iterate over each inode (starting with the root inode) and move >>>> the inode to a new one if it is inside the ag which should be freed. >>>> The second step is to look at the inode itself. If the data block is >>>> inside the ag it could be moved outside the ag too. >>>> If i missed something until here, please let me know:-) >>> Make sure you traverse all the inodes - there will probably be inodes >>> in different allocation groups which have extents in the targeted ag. >>> When you move an inode you need to fix up all the directories which >>> point at it. It is going to get a new inode number, so you need to walk >>> the directory tree looking for that inode number and replacing it. >>> Remember, >>> hard links mean an inode number could show up more than once. >> Thanks you very much for the advice... But do you think it's better to >> work on the on-disk structure, or do you think it's better to work >> with the in-core inodes? > You had said you wanted to do this on a live filesystem. I think running > everything through transactions is going to be more robust, and being > able to offline part of a running filesystem is a more useful feature > than doing it on an unmounted fs. Okay, i want to do it transactional... But to e. g. locate an inode i could do it using xfs_iget (in-core) or split the inode into agno and agino and locate the inode using the on-disk API, right? Probably in my previous e-mail i've wrote a little bit confusing :-) > The two potential approaches here are really to add some extensions to > the kernel and use thinks like bulkstat and swapext to do the work on > the live filesystem. Everything will be transactional, if the machine > goes down or crashes in the middle, you should end up with a working Think i prefer this way :-) > filesystem. The alternative is to use something like libxfs and manipulate > the fs from user space - if you crash you are left with bits and pieces of > a filesystem. If the kernel approach is to expensive (in term of code size), it should be not a big deal to split it and put some logic into user space... So i think i take the first way, and decide later if it is necessary to remove some parts from kernel... > So taking the use the transaction system approach: > Add the logic to turn off new allocates in the allocation group, > sounds like you are making progress on this. Oh, no i could remove a unused AG from the filesystem, but i do this on the on-disk structure (like the growfs stuff)... I don't know if setting the per AG freelist to 0 would prevent the allocator to allocate something in this AG... It only work in best case, e. g. nothing is allocated in the AG :-) > The defragmenter uses swapext to move extents from one file to another. > I would build on this approach, so have a user space app which scans > the fs for target inodes. Use the code from the defragmenter, > without the logic which says it has to be less fragmented afterwards, > to move the space to elsewhere in the fs - since allocations will not > be allowed in the ag you are emptying, you end up with an inode and > extents which are in other allocation groups. Okay, i will look at the swapext to find out how it works... > This leaves directories with blocks in the ag to rebuild, a mkdir > of a temporary dir and some renames should take care of that. > Other things to watch out for: > There is the log in the middle allocation group, you cannot empty > that one. > Sometimes when you free space it actually wants to allocate blocks > in that ag to put the free space tree into. Eventually the free space > btree will collapse, but there could be some interim steps where an > allocate is required to free space. There will need to be special > logic to allow these allocates to happen. Okay, thanks for the advice! Best regards, Markus Lidel ------------------------------------------ Markus Lidel (Senior IT Consultant) Shadow Connect GmbH Carl-Reisch-Weg 12 D-86381 Krumbach Germany Phone: +49 82 82/99 51-0 Fax: +49 82 82/99 51-11 E-Mail: Markus.Lidel@shadowconnect.com URL: http://www.shadowconnect.com From owner-linux-xfs Thu Aug 19 04:44:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Aug 2004 04:45:17 -0700 (PDT) Received: from email.eva.mpg.de (monolith.eva.mpg.de [194.94.96.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7JBiopE006091 for ; Thu, 19 Aug 2004 04:44:50 -0700 Received: from localhost (localhost [127.0.0.1]) by email.eva.mpg.de (MPI EVAN Mailserver) with ESMTP id AA82620666 for ; Thu, 19 Aug 2004 13:44:30 +0200 (CEST) Received: from [192.168.2.58] (zentral58.eva.mpg.de [192.168.2.58]) by email.eva.mpg.de (MPI EVAN Mailserver) with ESMTP id 99EAA20566 for ; Thu, 19 Aug 2004 13:44:27 +0200 (CEST) Message-ID: <412492AC.3030605@eva.mpg.de> Date: Thu, 19 Aug 2004 13:44:44 +0200 From: Michael Gasch User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.2) Gecko/20040803 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Does XFS Support UNICODE ????? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 3939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gasch@eva.mpg.de Precedence: bulk X-list: linux-xfs Content-Length: 595 Lines: 32 hi list, i'm not very familar with filesystems and codepages, so please apologize any wrong statements my question is: we use samba v3 on xfs filesystems samba is setup to store files in utf-8 format is xfs able to store files in utf-8 unicode ???? thanks a lot... bye micha -- "Matrix - more than a vision" ************************************************** Michael Gasch - Central IT Department - Max Planck Institute for Evolutionary Anthropology Deutscher Platz 6 04103 Leipzig Germany ************************************************** From owner-linux-xfs Thu Aug 19 12:42:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Aug 2004 12:42:39 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [193.151.36.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7JJgPvh006282 for ; Thu, 19 Aug 2004 12:42:26 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 9482F9410B; Thu, 19 Aug 2004 21:42:19 +0200 (CEST) Received: from localhost.localdomain (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 2A982940E6; Thu, 19 Aug 2004 21:42:19 +0200 (CEST) Received: from [127.0.0.1] (venus [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i7JJgH7P002350; Thu, 19 Aug 2004 21:42:17 +0200 Subject: Re: Does XFS Support UNICODE ????? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Michael Gasch Cc: linux-xfs@oss.sgi.com In-Reply-To: <412492AC.3030605@eva.mpg.de> References: <412492AC.3030605@eva.mpg.de> Content-Type: text/plain Message-Id: <1092944536.2129.0.camel@venus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 19 Aug 2004 21:42:17 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 3940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 348 Lines: 18 On Thu, 2004-08-19 at 13:44, Michael Gasch wrote: > hi list, > > i'm not very familar with filesystems and codepages, so please apologize > any wrong statements > > my question is: > > we use samba v3 on xfs filesystems > samba is setup to store files in utf-8 format > > is xfs able to store files in utf-8 unicode ???? Yes. Regards, Olaf From owner-linux-xfs Thu Aug 19 12:49:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Aug 2004 12:49:35 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7JJnPTE007126 for ; Thu, 19 Aug 2004 12:49:26 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BxsuT-0003LL-Mt; Thu, 19 Aug 2004 20:49:17 +0100 Date: Thu, 19 Aug 2004 20:49:17 +0100 From: Christoph Hellwig To: Michael Gasch Cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS Support UNICODE ????? Message-ID: <20040819204917.A12819@infradead.org> References: <412492AC.3030605@eva.mpg.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: <412492AC.3030605@eva.mpg.de>; from gasch@eva.mpg.de on Thu, Aug 19, 2004 at 01:44:44PM +0200 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 3941 X-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: 529 Lines: 17 On Thu, Aug 19, 2004 at 01:44:44PM +0200, Michael Gasch wrote: > hi list, > > i'm not very familar with filesystems and codepages, so please apologize > any wrong statements > > my question is: > > we use samba v3 on xfs filesystems > samba is setup to store files in utf-8 format > > is xfs able to store files in utf-8 unicode ???? XFS stores data as byte arrays, so it doesn't care what enconding they are in. Similar for file names, except for a '.', '..' and '/' in ASCII-encoding filenames are completly up to you. From owner-linux-xfs Thu Aug 19 13:54:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Aug 2004 13:54:47 -0700 (PDT) Received: from emba.kicks-ass.net (port-195-158-173-189.dynamic.qsc.de [195.158.173.189]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7JKsj2f009491 for ; Thu, 19 Aug 2004 13:54:45 -0700 Received: by emba.kicks-ass.net (Postfix, from userid 0) id 87729103CC; Thu, 19 Aug 2004 23:03:02 +0200 (CEST) Date: Thu, 19 Aug 2004 23:03:02 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Does XFS Support UNICODE ????? Message-ID: <41251586.mail4BR11H6CX@linux> User-Agent: nail 10.6 11/15/03 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gasch@eva.mpg.de (root) X-archive-position: 3942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gasch@eva.mpg.de Precedence: bulk X-list: linux-xfs Content-Length: 136 Lines: 6 so is there any option i have to enable/set to store filenames on XFS in utf-8 ????? you helped me very much so far, thx !!!!! greez From owner-linux-xfs Thu Aug 19 14:37:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Aug 2004 14:38:05 -0700 (PDT) Received: from plato.arts.usyd.edu.au (plato.arts.usyd.edu.au [129.78.16.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7JLbu33010743 for ; Thu, 19 Aug 2004 14:37:57 -0700 Received: by plato.arts.usyd.edu.au (Postfix, from userid 65534) id D93321432; Fri, 20 Aug 2004 07:37:42 +1000 (EST) Received: from [129.78.226.234] (holly.aitch.ucc.usyd.edu.au [129.78.226.234]) by plato.arts.usyd.edu.au (Postfix) with ESMTP id 85C4C1431; Fri, 20 Aug 2004 07:37:41 +1000 (EST) Message-ID: <41251DA5.9000401@arts.usyd.edu.au> Date: Fri, 20 Aug 2004 07:37:41 +1000 From: Matthew Geier User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Gasch Cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS Support UNICODE ????? References: <412492AC.3030605@eva.mpg.de> In-Reply-To: <412492AC.3030605@eva.mpg.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080509070000060204000504" X-archive-position: 3943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matthew@arts.usyd.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 6027 Lines: 118 This is a cryptographically signed message in MIME format. --------------ms080509070000060204000504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Gasch wrote: > we use samba v3 on xfs filesystems > samba is setup to store files in utf-8 format I works. I have done this for 12 months and have not seen any problem. We have users storing filenames in just about every written language. > is xfs able to store files in utf-8 unicode ???? Assuming that UTF-8 avoids having NULL, and / appearing in it's multibyte sequences, pretty well all Unix file systems are UTF-8 ready and have been since before Unicode was thought of. Except for the meaning assigned to ASCII /, isn't a Unix file name simply a list of bytes NULL terminated ? It's all the supporting utilities you have to worry about. While we have users storing Chinese file names on our Samba server, my ablity to key those file names in to retrieve them from backups is some what limited... (Although now Fedora gterminal is shipped utf-8 compatable, I can probably cu-n-past names in non latin character sets into the command line of the restore program...) --------------ms080509070000060204000504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIJmzCCAygwggKRoAMCAQICAwxAwjANBgkqhkiG9w0BAQQFADBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDQwNTA1MDUwMTUwWhcNMDUwNTA1MDUwMTUwWjB3MR8wHQYD VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhht YXR0aGV3QGFydHMudXN5ZC5lZHUuYXUxKzApBgkqhkiG9w0BCQEWHG1hdHRo ZXdAc2xlZXBlci5hcGFuYS5vcmcuYXUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDwAd1tx+TWOfa5VADB99s2pAaccqVbTISUBoOdIaPeOR+H gHeRg0VbYc0c1+8x6ed/bBeEk8Ve6V8vQ3lq7PwwBHFXSUn1vqSPtPwm+ti/ mhCu/ZqdMs+pTGRbcPng7pABRkKNyDujDELu4H6FvFSBYkXFVHiMCRUzaETb gGZIGY8qKqRUgSWeRpTEkqsr8HdtIhtMzkT2oXC8nnQGGK0UIF60EqUUKpFM HyKsmZXx2Vjk8qosYIoD0mTvisYLYY8MHKaXgxt4qLNJ6Ts6ZwLmmHv6uPuU y4dU8YWttOhI6mug/lT4BHE3Oz2jy/Geanancg8bFWRrSphuGekv0wGRAgMB AAGjUzBRMEEGA1UdEQQ6MDiBGG1hdHRoZXdAYXJ0cy51c3lkLmVkdS5hdYEc bWF0dGhld0BzbGVlcGVyLmFwYW5hLm9yZy5hdTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAKYUVmleWefqGmH5SeQMX8M89Tt9l6qr6b+rQN6S 8SgSoLziOW1ND+y3Ph78BV9v82QWNBM2G65TFsFd64fgptwYdnj4/hYrlkJF UeghOQE9zS4+LWOwlS1f/tn5SuuP7c2lb1+MNlGsnI6mwpCjqbPGpGMhsS1v CBgTrYinXeb1MIIDKDCCApGgAwIBAgIDDEDCMA0GCSqGSIb3DQEBBAUAMGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNDA1MDUwNTAxNTBaFw0wNTA1MDUwNTAxNTBaMHcxHzAd BgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJzAlBgkqhkiG9w0BCQEW GG1hdHRoZXdAYXJ0cy51c3lkLmVkdS5hdTErMCkGCSqGSIb3DQEJARYcbWF0 dGhld0BzbGVlcGVyLmFwYW5hLm9yZy5hdTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAPAB3W3H5NY59rlUAMH32zakBpxypVtMhJQGg50ho945 H4eAd5GDRVthzRzX7zHp539sF4STxV7pXy9DeWrs/DAEcVdJSfW+pI+0/Cb6 2L+aEK79mp0yz6lMZFtw+eDukAFGQo3IO6MMQu7gfoW8VIFiRcVUeIwJFTNo RNuAZkgZjyoqpFSBJZ5GlMSSqyvwd20iG0zORPahcLyedAYYrRQgXrQSpRQq kUwfIqyZlfHZWOTyqixgigPSZO+KxgthjwwcppeDG3ios0npOzpnAuaYe/q4 +5TLh1Txha206Ejqa6D+VPgEcTc7PaPL8Z5qdqdyDxsVZGtKmG4Z6S/TAZEC AwEAAaNTMFEwQQYDVR0RBDowOIEYbWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1 gRxtYXR0aGV3QHNsZWVwZXIuYXBhbmEub3JnLmF1MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAphRWaV5Z5+oaYflJ5Axfwzz1O32Xqqvpv6tA 3pLxKBKgvOI5bU0P7Lc+HvwFX2/zZBY0EzYbrlMWwV3rh+Cm3Bh2ePj+FiuW QkVR6CE5AT3NLj4tY7CVLV/+2flK64/tzaVvX4w2UaycjqbCkKOps8akYyGx LW8IGBOtiKdd5vUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQD ExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEW HHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8M OmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPP K9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxG cmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM 0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9 reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcC AQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwxAwjAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4MTkyMTM3NDFa MCMGCSqGSIb3DQEJBDEWBBRwVockM+04qPyle1OnpvPNSLnKQTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQx azBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIDDEDCMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECAwxAwjANBgkqhkiG9w0BAQEFAASCAQDlI8InwJg/vpPch43qRTKSoohn F4v+E/XpZd1amXs+ynyuQNWoZcgFvCvJNv3JqFNOCa5r2KyMU9pcemmYcRzH WvwzCkzDarhLufZDtQXhwFIfggHdd9vzjv1bNeG/OsplVHY7XZip5UltMyil OJMVqevzLeSzdMGOsFKIorB6WNBqpKGE3B/2Zc+GgAIlV4rD/CoDbBQF8lu7 uU+XZIb469cjNaGAXyVEbhKgPCEK4gHwmap/8//O2B7HfOXH7QPkn6Yz7uOJ mVXZNU1mMHikSZ7Qu3R1ETnR4ZUTg0/uN0FqqDiw//7McMaUBa9XwZ65d6+a cwAgm89I+5HdSfAiAAAAAAAA --------------ms080509070000060204000504-- From owner-linux-xfs Thu Aug 19 23:38:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Aug 2004 23:38:57 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7K6crRq029905 for ; Thu, 19 Aug 2004 23:38:54 -0700 Received: from taniwha.stupidest.org (adsl-68-120-152-2.dsl.snfc21.pacbell.net [68.120.152.2]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7K6cgfA055172; Fri, 20 Aug 2004 02:38:43 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 460C3115C875; Thu, 19 Aug 2004 23:38:42 -0700 (PDT) Date: Thu, 19 Aug 2004 23:38:42 -0700 From: Chris Wedgwood To: root Cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS Support UNICODE ????? Message-ID: <20040820063842.GA15905@taniwha.stupidest.org> References: <41251586.mail4BR11H6CX@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41251586.mail4BR11H6CX@linux> X-archive-position: 3945 X-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: 227 Lines: 8 On Thu, Aug 19, 2004 at 11:03:02PM +0200, root wrote: > so is there any option i have to enable/set to store filenames on > XFS in utf-8 ????? no, part of the point behind utf-8 is that it just works as-is for the most part From owner-linux-xfs Thu Aug 19 23:44:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Aug 2004 23:44:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7K6irNe030312 for ; Thu, 19 Aug 2004 23:44:54 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA03230 for ; Fri, 20 Aug 2004 16:44:40 +1000 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i7K6iR54004173 for ; Fri, 20 Aug 2004 16:44:28 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i7K6iRx8004172 for linux-xfs@oss.sgi.com; Fri, 20 Aug 2004 16:44:27 +1000 Date: Fri, 20 Aug 2004 16:44:27 +1000 From: FSG QA Message-Id: <200408200644.i7K6iRx8004172@bruce.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests X-archive-position: 3946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 802 Lines: 33 Update configure scripts in xfstests directory. Date: Thu Jul 8 22:23:32 PDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:174871a xfstests/configure.in - 1.17 xfstests/m4/package_attrdev.m4 - 1.3 xfstests/m4/package_xfslibs.m4 - 1.6 xfstests/aclocal.m4 - 1.8 Regression test exercising realtime inheritance behavior. Date: Thu Aug 19 23:44:08 PDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:177454a xfstests/094 - 1.1 xfstests/094.out - 1.1 xfstests/common.rc - 1.46 xfstests/group - 1.60 From owner-linux-xfs Fri Aug 20 07:07:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 07:07:16 -0700 (PDT) Received: from mail.najdi.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KE73rZ018242 for ; Fri, 20 Aug 2004 07:07:06 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 1FE9C1B91A for ; Fri, 20 Aug 2004 16:06:42 +0200 (CEST) Received: from elbereth.noviforum.si (elbereth.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id E48FA1B912 for ; Fri, 20 Aug 2004 16:06:41 +0200 (CEST) Received: from elbereth.noviforum.si (localhost [127.0.0.1]) by elbereth.noviforum.si (8.12.10/8.12.10) with ESMTP id i7KE2vJ7001392 for ; Fri, 20 Aug 2004 16:02:57 +0200 Received: (from gregab@localhost) by elbereth.noviforum.si (8.12.10/8.12.10/Submit) id i7KE2vwx001391 for linux-xfs@oss.sgi.com; Fri, 20 Aug 2004 16:02:57 +0200 Date: Fri, 20 Aug 2004 16:02:57 +0200 From: Grega Bremec To: linux-xfs@oss.sgi.com Subject: Replaying logs on a different machine Message-ID: <20040820140257.GA1367@elbereth.noviforum.si> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline User-Agent: Mutt/1.4.2i Organization: Noviforum, Ltd., Software & Media X-Virus-Scanned: by Najdi.si X-archive-position: 3948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grega.bremec@noviforum.si Precedence: bulk X-list: linux-xfs Content-Length: 2338 Lines: 58 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, list. I've searched the archives superficially but I was unable to get a glance of any promising subjects WRT this matter. We're setting up a failover storage system in our company, and we thought that, instead of having the failover host online all the time, using some sort of realtime synchronization thing (nbd or rsync or whatnot), we would prefer it to be brought into sync every n hours, with the disks shut off in the meantime, which would not only preserve disk lifetime, but also simplify maintenance and improve safety of such backups if we were able to copy the second latest set of data upon every sync. Having the failover experience a n hour lag is no issue, it is more important to us to have a failover storage location which is at least a couple of degrees more reliable than the one we're using for data and is easily interchangeable with the current one. Now, after having had brainstormed for a while, we came to the following idea: would it be possible to have xfs_logprint dump the transaction logs between event X and event Y from a log device set at filesystem creation time, then these logs be transferred onto another machine and replayed there somehow ? Machines would be identical, both hardware and software- -wise, there would be mechanisms for ensuring the standby machine does never get modified from userland (-o ro). We feel strongly that this would be the cheapest way of synchronizing two storage devices that both have capacities of a couple of TB of data, especially since the volume of transactions on these devices would not have been too high, but it is important to avoid any kind of scan-like difference checks in the manner of rsync and such, as this would be a performance hit too great to handle. Thank you very much in advance, --=20 Grega Bremec Senior Administrator Noviforum Ltd., Software & Media http://www.noviforum.si/ --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBJgSRDo/EMYD4+osRAhqVAKCWczyqWcNf9Fm9LWPFEnPgFxoW0ACdGHym D+EHSZFiunQrQSxBSbdGGIs= =41Se -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-linux-xfs Fri Aug 20 08:16:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 08:16:30 -0700 (PDT) Received: from cernmxlb.cern.ch (cernmx06.cern.ch [137.138.166.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KFGO6T020283 for ; Fri, 20 Aug 2004 08:16:25 -0700 Keywords: CERN SpamKiller Note: -52 Charset: west-latin X-Filter: CERNMX06 SMTPGW CERN Spam Sink v1.0 Received: from pcitadc13.cern.ch ([137.138.41.226]) by cernmxlb.cern.ch with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 17:16:12 +0200 Received: by pcitadc13.cern.ch (Postfix, from userid 32266) id 3F6831B85A; Fri, 20 Aug 2004 17:16:12 +0200 (CEST) Date: Fri, 20 Aug 2004 17:16:12 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: Replaying logs on a different machine Message-ID: <20040820151612.GE7217@chihiro.cern.ch> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040820140257.GA1367@elbereth.noviforum.si> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040820140257.GA1367@elbereth.noviforum.si> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.6+20040803i X-OriginalArrivalTime: 20 Aug 2004 15:16:12.0329 (UTC) FILETIME=[A0D7B990:01C486C8] X-archive-position: 3949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: linux-xfs Content-Length: 1093 Lines: 26 * Grega Bremec (grega.bremec@noviforum.si) [20040820 16:02]: Grega, > Now, after having had brainstormed for a while, we came to > the following idea: would it be possible to have xfs_logprint > dump the transaction logs between event X and event Y from a > log device set at filesystem creation time, then these logs be > transferred onto another machine and replayed there somehow ? As far as I understand, you are talking about two independent machines here, without a shared storage device. XFS journals metadata only, which means changes to file *content* are not reflected in the log. xfs_logprint(8) would get you metadata changes only, which are worthless on the other machine without file data. Not to mention that xfs_logprint(8) can print the *actual* log entries only, which means that changes that happened before a log wrap cannot be "remembered". Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs Fri Aug 20 08:45:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 08:45:40 -0700 (PDT) Received: from netra28.desy.de (netra28.desy.de [131.169.40.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KFjaBZ024234 for ; Fri, 20 Aug 2004 08:45:37 -0700 Received: from mx2.desy.de (mx2.desy.de [131.169.69.102]) by netra28 (DesyMail_Map_28) with ESMTP id 3A335FA01 for ; Fri, 20 Aug 2004 17:45:24 +0200 (MEST) Received: from netra27.desy.de (netra27.desy.de [131.169.40.141]) by mx2.desy.de (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Fri, 20 Aug 2004 17:45:23 +0200 Received: from [131.169.214.214] (thor.desy.de [131.169.214.214]) by netra27 (DesyMail_In_27) with ESMTP id BC59BFB908 for ; Fri, 20 Aug 2004 17:45:23 +0200 (MEST) Message-ID: <41261BCF.10601@desy.de> Date: Fri, 20 Aug 2004 17:42:07 +0200 From: Martin Gasthuber Reply-To: Martin.Gasthuber@desy.de Organization: Deutsches Elektronen Synchrotron DESY User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040812) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: are xfs handles persistent X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Gasthuber@desy.de Precedence: bulk X-list: linux-xfs Content-Length: 709 Lines: 20 Hi, in order to use xfs as a fast hierarchical namespace service (just the nameservice, no data) we need to have an external reference for an xfs file object. The '*_by_handle()' suite of functions seems to generate a unique handle for referencing xfs objects. Unclear is - are these handles persistent ??? i.e. retrieve handle - store it externally - dismount/mount filesystem - use external stored handle to access file (and attributes). Or did XFS provide other external unique references (magic inodes ;-) thanxs in advance Martin -- Martin Gasthuber -- DESY/Hamburg IT-Group snail Notkestrasse 85 22607 Hamburg/Germany e-mail Martin.Gasthuber@desy.de - fon/fax +49 40 [8998/8994] 2564 From owner-linux-xfs Fri Aug 20 08:56:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 08:56:24 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KFuLfC024721 for ; Fri, 20 Aug 2004 08:56:21 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7KFuF0f021389 for ; Fri, 20 Aug 2004 10:56:15 -0500 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7KFuEOV45404109; Fri, 20 Aug 2004 10:56:14 -0500 (CDT) Received: from sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i7KFuE81122237673; Fri, 20 Aug 2004 10:56:14 -0500 (CDT) Message-Id: <200408201556.i7KFuE81122237673@tulip-e236.americas.sgi.com> To: Martin.Gasthuber@desy.de cc: linux-xfs@oss.sgi.com Subject: Re: are xfs handles persistent Date: Fri, 20 Aug 2004 10:56:14 -0500 From: Dean Roehrich X-archive-position: 3951 X-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: 614 Lines: 15 >From: Martin Gasthuber >Hi, > > in order to use xfs as a fast hierarchical namespace service (just >the nameservice, no data) we need to have an external reference for an >xfs file object. The '*_by_handle()' suite of functions seems to >generate a unique handle for referencing xfs objects. Unclear is - are >these handles persistent ??? i.e. retrieve handle - store it externally Yes, the handle is unique to a particular generation of the inode. As long as the inode isn't unlinked and reused for a new file that handle will always lead you back to that same inode. Dean From owner-linux-xfs Fri Aug 20 12:57:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 12:57:07 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KJv4Dm007071 for ; Fri, 20 Aug 2004 12:57:04 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7KJv4eT007070 for linux-xfs@oss.sgi.com; Fri, 20 Aug 2004 12:57:04 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KJv2v3007056 for ; Fri, 20 Aug 2004 12:57:03 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7KJnGeo006683; Fri, 20 Aug 2004 12:49:16 -0700 Date: Fri, 20 Aug 2004 12:49:16 -0700 Message-Id: <200408201949.i7KJnGeo006683@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3952 X-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: 1197 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-20-08 12:49 PDT ------- Thanks for the tip. XFS code in that kernel was 1.3.1. But now I reproduced the bug with RHES3 U2 kernel and XFS from SGI RHES patch. One of the links was describing the filesystem layout: meta-data=/shift/lxfs5046/data01 isize=512 agcount=168, agsize=1048512 blks = sectsz=512 data = bsize=4096 blocks=175829568, imaxpct=25 = sunit=64 swidth=128 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=64 blks realtime =none extsz=524288 blocks=0, rtextents=0 Mount options were "logbufs=8,logbsize=262144". Filesystem is sitting on top of software RAID0 array with 256k chunks. I've seen the problem with 2.6.5 vanilla as well, I will see if I can get a kgdb-enabled kernel up. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Aug 20 13:44:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 13:44:12 -0700 (PDT) Received: from spiderman.spectsoft.com (superman.spectsoft.com [64.71.189.250]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KKi8kU008847 for ; Fri, 20 Aug 2004 13:44:08 -0700 Received: from bmagic.spectsoft.local (adsl-67-124-142-21.dsl.sktn01.pacbell.net [67.124.142.21]) by spiderman.spectsoft.com (Postfix) with ESMTP id 533981E70C5 for ; Fri, 20 Aug 2004 13:31:44 -0700 (PDT) From: Jason Howard Reply-To: jason@spectsoft.com Organization: SpectSoft, LLC To: linux-xfs@oss.sgi.com Subject: Slow read performance Date: Fri, 20 Aug 2004 13:42:53 -0700 User-Agent: KMail/1.6.2 X-HUH: Bet you were never expecting to find this in a header! X-URL: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Message-Id: <200408201342.53409.jason@spectsoft.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i7KKi8kU008848 X-archive-position: 3953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jason@spectsoft.com Precedence: bulk X-list: linux-xfs Content-Length: 2086 Lines: 65 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello All, I am wondering if anyone can offer any insight into a problem I have been seeing with XFS included in the 2.4.27 kernel. I am seeing a huge difference between a raw device (/dev/md0) read and a filesystem read when reading from an array that is capable of >500 MBytes/sec. The reads and writes are sequential, both on the raw disk device and XFS filesystem (using sequential files). Here is an example of what we normally see on a fairly slow array: RAW PERFORMANCE Read Average : 212.674 MB/SEC over 1000 frames Write Average: 234.769 MB/SEC over 1000 frames FS PERFORMANCE Read Average : 148.125 MB/SEC over 1000 frames Write Average: 286.031 MB/SEC over 1000 frames Now here is the problem I am seeing on a fast array: RAW PERFORMANCE Read Average : 594.965 MB/SEC over 1000 frames Write Average: 350.604 MB/SEC over 1000 frames FS PERFORMANCE Read Average : 67.280 MB/SEC over 1000 frames Write Average: 305.363 MB/SEC over 1000 frames I have seen similar results on two separate arrays, one a software raid of dual U320 arrays, the other is a software raid of dual 2G fibre w/ 16 disks. I don't suspect it is a problem with the physical interfaces, as I am seeing the same issue on multiple technologies. Also, I have pretty much ruled out a problem with Linux software raid as we are getting expected performance from the raw /dev/md0 device. That is not to say that it couldn't very well be a nasty interaction between software raid and XFS. Thanks much! Jason - -- Jason Howard Professional: SpectSoft, LLC 593 Hi-Tech Pkwy, Suite B Oakdale, CA 95361, USA http://www.spectsoft.com jason a-t spectsoft.com Phone: +1.209.847.7812 Fax: +1.209.847.7859 Personal: http://www.psinux.org jason a-t psinux.org Cell: +1.209.968.1289 Text Message: jasonsphone a-t psinux.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBJmJNMghdcvnd+m4RAtOWAKC7D/vHK/7VnqUGZGfFvsoGXHffXACfQFb0 8LMleSveUvH/vfR3Vkps+ho= =4+aP -----END PGP SIGNATURE----- From owner-linux-xfs Fri Aug 20 14:28:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 14:28:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7KLSPnE011445 for ; Fri, 20 Aug 2004 14:28:26 -0700 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 HAA19751; Sat, 21 Aug 2004 07:28:08 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7KLS6ln3331659; Sat, 21 Aug 2004 07:28:07 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7KLS55F3396645; Sat, 21 Aug 2004 07:28:05 +1000 (EST) Date: Sat, 21 Aug 2004 07:28:05 +1000 From: Nathan Scott To: Jason Howard Cc: linux-xfs@oss.sgi.com Subject: Re: Slow read performance Message-ID: <20040821072805.C3393262@wobbly.melbourne.sgi.com> References: <200408201342.53409.jason@spectsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200408201342.53409.jason@spectsoft.com>; from jason@spectsoft.com on Fri, Aug 20, 2004 at 01:42:53PM -0700 X-archive-position: 3954 X-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: 2127 Lines: 54 On Fri, Aug 20, 2004 at 01:42:53PM -0700, Jason Howard wrote: > Hello All, hi there, > I am wondering if anyone can offer any insight into a problem I have been > seeing with XFS included in the 2.4.27 kernel. I am seeing a huge difference > between a raw device (/dev/md0) read and a filesystem read when reading from > an array that is capable of >500 MBytes/sec. The reads and writes are > sequential, both on the raw disk device and XFS filesystem (using sequential > files). Buffered or direct reads? (could you try both?) Is this MD RAID5? (if so, could you send xfs_info output for this filesystem as well?) > Here is an example of what we normally see on a fairly slow array: > RAW PERFORMANCE > Read Average : 212.674 MB/SEC over 1000 frames > Write Average: 234.769 MB/SEC over 1000 frames > FS PERFORMANCE > Read Average : 148.125 MB/SEC over 1000 frames > Write Average: 286.031 MB/SEC over 1000 frames > > Now here is the problem I am seeing on a fast array: > RAW PERFORMANCE > Read Average : 594.965 MB/SEC over 1000 frames > Write Average: 350.604 MB/SEC over 1000 frames > FS PERFORMANCE > Read Average : 67.280 MB/SEC over 1000 frames > Write Average: 305.363 MB/SEC over 1000 frames > > I have seen similar results on two separate arrays, one a software raid of > dual U320 arrays, the other is a software raid of dual 2G fibre w/ 16 disks. > I don't suspect it is a problem with the physical interfaces, as I am seeing > the same issue on multiple technologies. Also, I have pretty much ruled out > a problem with Linux software raid as we are getting expected performance > from the raw /dev/md0 device. That is not to say that it couldn't very well > be a nasty interaction between software raid and XFS. If it is a RAID5 device, make sure your filesystem sector and block sizes are the same (both are mkfs.xfs options). Otherwise, not sure... could be a readahead oddity if this is buffered IO. As another data point, what do the ext2 numbers look like? (this will point to an XFS-specific problem, or a more generic - eg. readahead - type of problem). cheers. -- Nathan From owner-linux-xfs Fri Aug 20 16:00:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Aug 2004 16:00:11 -0700 (PDT) Received: from spiderman.spectsoft.com (superman.spectsoft.com [64.71.189.250]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7KN08xS013640 for ; Fri, 20 Aug 2004 16:00:08 -0700 Received: from bmagic.spectsoft.local (adsl-67-124-142-21.dsl.sktn01.pacbell.net [67.124.142.21]) by spiderman.spectsoft.com (Postfix) with ESMTP id 13FF11E70C5; Fri, 20 Aug 2004 15:47:43 -0700 (PDT) From: Jason Howard Reply-To: jason@spectsoft.com Organization: SpectSoft, LLC To: Nathan Scott Subject: Re: Slow read performance Date: Fri, 20 Aug 2004 15:58:52 -0700 User-Agent: KMail/1.6.2 References: <200408201342.53409.jason@spectsoft.com> <20040821072805.C3393262@wobbly.melbourne.sgi.com> In-Reply-To: <20040821072805.C3393262@wobbly.melbourne.sgi.com> Cc: linux-xfs@oss.sgi.com X-HUH: Bet you were never expecting to find this in a header! X-URL: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200408201558.52290.jason@spectsoft.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i7KN08xS013642 X-archive-position: 3955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jason@spectsoft.com Precedence: bulk X-list: linux-xfs Content-Length: 2774 Lines: 81 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 20 August 2004 14:28, you wrote: > On Fri, Aug 20, 2004 at 01:42:53PM -0700, Jason Howard wrote: > > Hello All, > > hi there, > > > I am wondering if anyone can offer any insight into a problem I have been > > seeing with XFS included in the 2.4.27 kernel. I am seeing a huge > > difference between a raw device (/dev/md0) read and a filesystem read > > when reading from an array that is capable of >500 MBytes/sec. The reads > > and writes are sequential, both on the raw disk device and XFS filesystem > > (using sequential files). > > Buffered or direct reads? (could you try both?) Buffered right now. I did try direct reads a while back and I don't recall them making any difference. I will give it another shot later this evening. > Is this MD RAID5? (if so, could you send xfs_info output for this > filesystem as well?) Both arrays (the scsi and fc) are RAID 0 using the linux MD driver. The SCSI setup uses a two channel raid 3 array (see http://www.hugesystems.com/Products/MVault-U320-RX.cfm). Each side has 5 disks using hardware raid 3. The two channels are then RAID 0ed together using the MD driver. The fibre channel setup uses 16 disks and a controller w/ 2x 2gb interfaces. The first six drives are accessed via the first fc interface, and the second six are accessed via the second controller. All 16 drives are RAID 0ed together via the Linux MD driver. > If it is a RAID5 device, make sure your filesystem sector and > block sizes are the same (both are mkfs.xfs options). They are. On the SCSI setup we are using 2K SCSI transfers, so the data and log sectorsizes are set to 2K (or 4K). > Otherwise, not sure... could be a readahead oddity if this is > buffered IO. As another data point, what do the ext2 numbers > look like? (this will point to an XFS-specific problem, or a > more generic - eg. readahead - type of problem). I tested Ext3 and JFS on the array we have here (the SCSI) and, while I'm not seeing as good write speeds as XFS, the read speeds are much better than the 67MB/s I was getting with XFS. JFS gives me about 150 MB/s on both the read and write. Ext3 give me slightly less. Thanks much! Jason - -- Jason Howard Professional: SpectSoft, LLC 593 Hi-Tech Pkwy, Suite B Oakdale, CA 95361, USA http://www.spectsoft.com jason a-t spectsoft.com Phone: +1.209.847.7812 Fax: +1.209.847.7859 Personal: http://www.psinux.org jason a-t psinux.org Cell: +1.209.968.1289 Text Message: jasonsphone a-t psinux.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBJoIsMghdcvnd+m4RAhZHAJ9TpyeT6Q2V1s9jGeHI976aAEaFpwCgjxPC aHoxte1lYYbi+ZYe7YlYgBQ= =+DsN -----END PGP SIGNATURE----- From owner-linux-xfs Sun Aug 22 01:08:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Aug 2004 01:08:18 -0700 (PDT) Received: from mail018.syd.optusnet.com.au (mail018.syd.optusnet.com.au [211.29.132.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7M88Cn8021849 for ; Sun, 22 Aug 2004 01:08:13 -0700 Received: from saturn (c211-28-164-234.eburwd2.vic.optusnet.com.au [211.28.164.234]) by mail018.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i7M87sF06773; Sun, 22 Aug 2004 18:07:55 +1000 Received: from [192.168.0.56] (helo=kennedy ident=Debian-exim) by saturn with esmtp (Exim 3.35 #1 (Debian)) id 1BynOM-0002z3-00; Sun, 22 Aug 2004 18:07:54 +1000 Received: from localhost ([127.0.0.1] helo=kennedy ident=stewart) by kennedy with esmtp (Exim 4.34) id 1BynLv-0001uV-GF; Sun, 22 Aug 2004 18:05:23 +1000 Subject: XFS and FC3t1 2.6.7-1.517smp From: Stewart Smith To: nathans@sgi.com Cc: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ELzI+85ovfhs2blmrMEj" Message-Id: <1093161923.7205.22.camel@kennedy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 22 Aug 2004 18:05:23 +1000 X-archive-position: 3956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Content-Length: 1090 Lines: 43 --=-ELzI+85ovfhs2blmrMEj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Nathan, as described in my mail to you a few days ago, with and updated FC3t1 kernel, XFS / fails to mount. Below is relevant output while booting. Red hat nash version 4.0.4 starting ... Loading xfs.ko module SGI XFS with ACLs, security attributes, large block numbers, no debug enabled SGI XFS Quota Management subsystem Creating block devices Creating root device Mounting root filesystem mount: error 6 mounting xfs Switching to new root switchroot: mount failed: 22 Kernel panic: Attempted to kill init! error 6 is interesting... any ideas? --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-ELzI+85ovfhs2blmrMEj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBKFPC3tgLgERgy8oRAhhoAJ9ZRp+yiSwA5PjLUjfaVQEYynZ3LwCg1V+h tAb1jcEaAov6Ajy8g01KJ8w= =ZGqF -----END PGP SIGNATURE----- --=-ELzI+85ovfhs2blmrMEj-- From owner-linux-xfs Sun Aug 22 07:57:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Aug 2004 07:57:15 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7MEvDY3008976 for ; Sun, 22 Aug 2004 07:57:13 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7MEvCPL008975 for linux-xfs@oss.sgi.com; Sun, 22 Aug 2004 07:57:12 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7MEvBId008961 for ; Sun, 22 Aug 2004 07:57:11 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7MEgCfU008822; Sun, 22 Aug 2004 07:42:12 -0700 Date: Sun, 22 Aug 2004 07:42:12 -0700 Message-Id: <200408221442.i7MEgCfU008822@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3957 X-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: 379 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-22-08 07:42 PDT ------- Linux 2.6.8.1-mm2 correctly replayed the log and mounted the filesystem. I will try with vanilla 2.4.x next. Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Aug 22 08:52:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Aug 2004 08:52:19 -0700 (PDT) Received: from lists.vasoftware.com (mail@internalmx2.vasoftware.com [12.152.184.150]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7MFqHGX015111 for ; Sun, 22 Aug 2004 08:52:17 -0700 Received: from adsl-67-122-115-120.dsl.sntc01.pacbell.net ([67.122.115.120]:64550 helo=[10.0.0.1]) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1Byudd-0004cV-W9 by VAauthid with fixed_plain; Sun, 22 Aug 2004 08:52:10 -0700 Message-ID: <4128C12A.80108@linux-sxs.org> Date: Sun, 22 Aug 2004 08:52:10 -0700 From: "Net Llama!" Organization: HAL V User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040818 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Smith CC: linux-xfs@oss.sgi.com Subject: Re: XFS and FC3t1 2.6.7-1.517smp References: <1093161923.7205.22.camel@kennedy> In-Reply-To: <1093161923.7205.22.camel@kennedy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1Byudd-0004cV-W9 1c2373920ceb18dcadb4b9a499c0dc69 X-archive-position: 3958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 961 Lines: 30 On 08/22/2004 01:05 AM, Stewart Smith wrote: > Hi Nathan, > as described in my mail to you a few days ago, with and updated FC3t1 > kernel, XFS / fails to mount. Below is relevant output while booting. > > Red hat nash version 4.0.4 starting > ... > Loading xfs.ko module > SGI XFS with ACLs, security attributes, large block numbers, no debug > enabled > SGI XFS Quota Management subsystem > Creating block devices > Creating root device > Mounting root filesystem > mount: error 6 mounting xfs > Switching to new root > switchroot: mount failed: 22 > Kernel panic: Attempted to kill init! > > error 6 is interesting... any ideas? put /boot on its own partition and make it non-XFS. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 08:40:00 up 62 days, 19:27, 1 user, load average: 1.60, 0.68, 0.32 From owner-linux-xfs Sun Aug 22 18:43:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Aug 2004 18:43:26 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7N1hHah002965 for ; Sun, 22 Aug 2004 18:43:23 -0700 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 LAA06767; Mon, 23 Aug 2004 11:43:04 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7N1h2ln3438272; Mon, 23 Aug 2004 11:43:02 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7N2cVd2001581; Mon, 23 Aug 2004 12:38:32 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7N2cUIQ001579; Mon, 23 Aug 2004 12:38:30 +1000 Date: Mon, 23 Aug 2004 12:38:30 +1000 From: Nathan Scott To: Stewart Smith Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and FC3t1 2.6.7-1.517smp Message-ID: <20040823023830.GA1548@frodo> References: <1093161923.7205.22.camel@kennedy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093161923.7205.22.camel@kennedy> User-Agent: Mutt/1.5.3i X-archive-position: 3959 X-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: 678 Lines: 24 On Sun, Aug 22, 2004 at 06:05:23PM +1000, Stewart Smith wrote: > Hi Nathan, > as described in my mail to you a few days ago, with and updated FC3t1 > kernel, XFS / fails to mount. Below is relevant output while booting. > ... > Creating block devices > Creating root device > Mounting root filesystem > mount: error 6 mounting xfs > ... > error 6 is interesting... any ideas? Hmm - well if 6 maps to an errno, that'd be ENXIO; we don't return that anywhere from XFS. There would usually also be a console message when XFS fails a mount with additional info. So, not sure what it might be unfortunately, not even clear if its an XFS related problem. :( cheers. -- Nathan From owner-linux-xfs Sun Aug 22 23:53:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Aug 2004 23:53:52 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7N6rmAE014609 for ; Sun, 22 Aug 2004 23:53:49 -0700 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 QAA11997; Mon, 23 Aug 2004 16:53:33 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7N6rVln3473843; Mon, 23 Aug 2004 16:53:32 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7N7n0d2002380; Mon, 23 Aug 2004 17:49:00 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7N7mw0U002378; Mon, 23 Aug 2004 17:48:58 +1000 Date: Mon, 23 Aug 2004 17:48:58 +1000 From: Nathan Scott To: Jason Howard Cc: linux-xfs@oss.sgi.com Subject: Re: Slow read performance Message-ID: <20040823074858.GE1548@frodo> References: <200408201342.53409.jason@spectsoft.com> <20040821072805.C3393262@wobbly.melbourne.sgi.com> <200408201558.52290.jason@spectsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408201558.52290.jason@spectsoft.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i7N6roAE014610 X-archive-position: 3960 X-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: 1123 Lines: 31 On Fri, Aug 20, 2004 at 03:58:52PM -0700, Jason Howard wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > They are. On the SCSI setup we are using 2K SCSI transfers, so the data and > log sectorsizes are set to 2K (or 4K). > ... > I tested Ext3 and JFS on the array we have here (the SCSI) and, while I'm not > seeing as good write speeds as XFS, the read speeds are much better than the > 67MB/s I was getting with XFS. JFS gives me about 150 MB/s on both the read > and write. Ext3 give me slightly less. It should be much closer than that - are you comparing XFS with a 2K blocksize to the others with a 4K blocksize filesystem maybe? The blocksize used makes a fairly large difference to the generic IO path IIRC. If you haven't done so already, you may want to also investigate if the atime updates are having any affect (see "noatime" mount option) on your numbers. From my performance testing we are fairly close to the other fs's on read performance, but slightly under. I haven't got to the bottom of that yet, I don't know of any reason that we should be slower there. cheers. -- Nathan From owner-linux-xfs Mon Aug 23 11:57:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Aug 2004 11:57:21 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7NIvITd018717 for ; Mon, 23 Aug 2004 11:57:18 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7NIvIWR018716 for linux-xfs@oss.sgi.com; Mon, 23 Aug 2004 11:57:18 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7NIvGgf018702 for ; Mon, 23 Aug 2004 11:57:16 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7NIDD4K017732; Mon, 23 Aug 2004 11:13:13 -0700 Date: Mon, 23 Aug 2004 11:13:13 -0700 Message-Id: <200408231813.i7NIDD4K017732@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3961 X-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: 370 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-23-08 11:13 PDT ------- Linux 2.4.27 succeeds replaying the log and mounting the filesystem. Linux 2.4.21-15.EL.sgi3 fails. Peter ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Aug 23 21:28:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Aug 2004 21:28:23 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7O4SGsc024509 for ; Mon, 23 Aug 2004 21:28:17 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i7O4Rrm13071; Tue, 24 Aug 2004 14:27:53 +1000 Date: Tue, 24 Aug 2004 14:27:53 +1000 From: Nathan Scott Message-Id: <200408240427.i7O4Rrm13071@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 918975 - default quota X-archive-position: 3964 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 543 Lines: 20 Support for default quota limits via the zero dquot (ala grace times). Merged over from IRIX XFS. Date: Mon Aug 23 21:25:29 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes@sgi.com,ivanr@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:177627a xfs_log_recover.c - 1.289 quota/xfs_trans_dquot.c - 1.7 quota/xfs_qm_syscalls.c - 1.12 quota/xfs_dquot.h - 1.5 quota/xfs_dquot.c - 1.11 quota/xfs_qm.h - 1.5 quota/xfs_qm.c - 1.16 From owner-linux-xfs Mon Aug 23 22:07:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Aug 2004 22:07:59 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7O57qMD025658 for ; Mon, 23 Aug 2004 22:07:56 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i7O57dd17942 for linux-xfs@oss.sgi.com; Tue, 24 Aug 2004 15:07:39 +1000 Date: Tue, 24 Aug 2004 15:07:39 +1000 From: Nathan Scott Message-Id: <200408240507.i7O57dd17942@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 914196 - upgrade kdb X-archive-position: 3965 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 708 Lines: 28 Upgrade to KDB 4.4 for 2.6 tree. Date: Mon Aug 23 22:02:19 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:177629a Makefile - 1.22 drivers/char/sn_serial.c - 1.17 mm/swapfile.c - 1.8 Documentation/kdb/kdb.mm - 1.8 Documentation/kdb/kdb_bp.man - 1.8 Documentation/kdb/kdb_md.man - 1.8 kdb/kdbmain.c - 1.9 kdb/modules/kdbm_task.c - 1.8 kdb/modules/Makefile - 1.8 kdb/ChangeLog - 1.11 kdb/kdbsupport.c - 1.9 kdb/kdb_bp.c - 1.8 arch/i386/kdb/ChangeLog - 1.11 split-patches/kdb-common - 1.7 split-patches/kdb-i386 - 1.6 drivers/serial/sn_console.c - 1.2 From owner-linux-xfs Tue Aug 24 03:38:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 03:38:48 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7OAceVA012892 for ; Tue, 24 Aug 2004 03:38:43 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7OAcP95015698 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Aug 2004 12:38:25 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i7OAcOnt015696; Tue, 24 Aug 2004 12:38:24 +0200 Date: Tue, 24 Aug 2004 12:38:24 +0200 From: Christoph Hellwig To: Bob Gilligan Cc: linux-iscsi-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [linux-iscsi-devel] Crash running XFS over iSCSI volume Message-ID: <20040824103824.GB15616@lst.de> Mail-Followup-To: Christoph Hellwig , Bob Gilligan , linux-iscsi-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <412A40D6.3070408@intransa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412A40D6.3070408@intransa.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 3966 X-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@lst.de Precedence: bulk X-list: linux-xfs Content-Length: 717 Lines: 13 On Mon, Aug 23, 2004 at 12:09:10PM -0700, Bob Gilligan wrote: > Hi Folks -- I'm running Linux kernel 2.6.8.1 and version 4.0.1.8 of the > Linux initiator. I mounted an XFS filesystem over a 900 GB iSCSI > volume, then ran "bonnie" with the args "-v 5 -o_direct". Within about > 30 seconds, the kernel started spewing printks from bad_page(). The > first few were: Kown issues. XFS uses slab pages (as you noticed below), networking code doesn't like that. DRBD has been tripping the same issue. We need to come up with a consensus about what type of pages can be used in block I/O requests. The drbd folks promised to get this discussed on lkml but I haven't seen a discussion yet - so let's do it now. From owner-linux-xfs Tue Aug 24 09:20:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 09:20:22 -0700 (PDT) Received: from commie.imr-net.com (mail.imr-net.com [65.182.241.242]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7OGKEQq008975 for ; Tue, 24 Aug 2004 09:20:17 -0700 Received: from commie.imr-net.com (localhost [127.0.0.1]) by commie.imr-net.com (Postfix) with ESMTP id 639A82C07F937 for ; Tue, 24 Aug 2004 09:20:07 -0700 (PDT) Received: from [10.11.11.174] (bubbles.imr-net.com [10.11.11.174]) by commie.imr-net.com (Postfix) with ESMTP id 3E47D2C080803 for ; Tue, 24 Aug 2004 09:20:07 -0700 (PDT) Message-ID: <412B6AB6.6060803@pacrimopen.com> Date: Tue, 24 Aug 2004 09:20:06 -0700 From: Joshua Schmidlkofer User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Write Barriers in 2.6.? X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3967 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kernel@pacrimopen.com Precedence: bulk X-list: linux-xfs Content-Length: 156 Lines: 7 I have not seen any traffic about it, but I am wondering about write barrier support in 2.6.x. Has XFS been adjusted to use it yet? thanks, Joshua From owner-linux-xfs Tue Aug 24 09:34:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 09:34:13 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7OGY1hn009824 for ; Tue, 24 Aug 2004 09:34:02 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BzeF6-0007wl-MU; Tue, 24 Aug 2004 17:33:52 +0100 Date: Tue, 24 Aug 2004 17:33:52 +0100 From: Christoph Hellwig To: Joshua Schmidlkofer Cc: linux-xfs@oss.sgi.com Subject: Re: Write Barriers in 2.6.? Message-ID: <20040824173352.A30547@infradead.org> References: <412B6AB6.6060803@pacrimopen.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: <412B6AB6.6060803@pacrimopen.com>; from kernel@pacrimopen.com on Tue, Aug 24, 2004 at 09:20:06AM -0700 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 3968 X-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: 315 Lines: 7 On Tue, Aug 24, 2004 at 09:20:06AM -0700, Joshua Schmidlkofer wrote: > I have not seen any traffic about it, but I am wondering about write > barrier support in 2.6.x. Has XFS been adjusted to use it yet? Not yet. But we have support for patched 2.4 kernels so it will be added in the not too distant future. From owner-linux-xfs Tue Aug 24 12:10:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 12:10:42 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7OJAexj019350 for ; Tue, 24 Aug 2004 12:10:40 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7OKFXuj028348 for ; Tue, 24 Aug 2004 13:15:33 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7OJAVOV45770954; Tue, 24 Aug 2004 14:10:32 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Bzggh-00076D-00; Tue, 24 Aug 2004 14:10:31 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 915187 - Fix warnings in xfs_bmap.c Message-Id: From: Christoph Hellwig Date: Tue, 24 Aug 2004 14:10:31 -0500 X-archive-position: 3969 X-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: 325 Lines: 14 Date: Tue Aug 24 12:10:03 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans,tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:177663a fs/xfs/xfs_bmap.c - 1.322 - very long constants need a LL postfix From owner-linux-xfs Tue Aug 24 21:00:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 21:00:24 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7P40JXW016995 for ; Tue, 24 Aug 2004 21:00:20 -0700 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i7P406E29870 for ; Wed, 25 Aug 2004 13:00:06 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i7P405g23590 for linux-xfs@oss.sgi.com; Wed, 25 Aug 2004 13:00:05 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id i7P405D24051 for ; Wed, 25 Aug 2004 13:00:05 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20040825.130429.28101864 for ; Wed, 25 Aug 2004 13:04:29 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Wed Aug 25 13:04:28 2004 +0900 Received: from localhost (localhost.localdomain [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 7EAE275530 for ; Wed, 25 Aug 2004 12:59:49 +0900 (JST) Date: Wed, 25 Aug 2004 12:59:49 +0900 (JST) Message-Id: <20040825.125949.424242868.masano@tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Subject: force shutdown at xfs_growfs From: ASANO Masahiro X-Mailer: Mew version 3.3 on XEmacs 21.4.11 (Native Windows TTY Support) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Aug_25_12:59:49_2004_912)--" Content-Transfer-Encoding: 7bit X-archive-position: 3970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 2954 Lines: 94 ----Next_Part(Wed_Aug_25_12:59:49_2004_912)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi SGI guys, I'm afraid that it is dangerous to grow filesystem by xfs_growfs under a situation of heavy file allocation. Because mp->m_maxagi is updated before formatting new AGs, and other processes can touch them. This causes filesystem shutting down. Here is a patch for Linux-2.4.27. This patch delays the update of m_maxagi. Thank you. -- masano ----Next_Part(Wed_Aug_25_12:59:49_2004_912)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="maxagi.patch" --- linux-2.4.27/fs/xfs/xfs_fsops.c.orig 2004-08-24 16:44:58.000000000 +0900 +++ linux-2.4.27/fs/xfs/xfs_fsops.c 2004-08-24 16:51:31.000000000 +0900 @@ -149,6 +149,7 @@ xfs_growfs_data_private( int pct; xfs_sb_t *sbp; xfs_trans_t *tp; + int index = 0; nb = in->newblocks; pct = in->imaxpct; @@ -183,7 +184,7 @@ xfs_growfs_data_private( memset(&mp->m_perag[oagcount], 0, (nagcount - oagcount) * sizeof(xfs_perag_t)); mp->m_flags |= XFS_MOUNT_32BITINODES; - xfs_initialize_perag(mp, nagcount); + index = xfs_initialize_perag(mp, nagcount); up_write(&mp->m_peraglock); } tp = xfs_trans_alloc(mp, XFS_TRANS_GROWFS); @@ -372,6 +373,9 @@ xfs_growfs_data_private( if (error) { return error; } + /* initialize completed, update maxagi */ + if (index) + mp->m_maxagi = index; if (mp->m_sb.sb_imax_pct) { __uint64_t icount = mp->m_sb.sb_dblocks * mp->m_sb.sb_imax_pct; do_div(icount, 100); --- linux-2.4.27/fs/xfs/xfs_mount.c.orig 2004-08-24 16:48:43.000000000 +0900 +++ linux-2.4.27/fs/xfs/xfs_mount.c 2004-08-24 17:30:31.000000000 +0900 @@ -318,7 +318,7 @@ xfs_mount_validate_sb( return 0; } -void +int xfs_initialize_perag(xfs_mount_t *mp, int agcount) { int index, max_metadata; @@ -377,7 +377,7 @@ xfs_initialize_perag(xfs_mount_t *mp, in pag->pagi_inodeok = 1; } } - mp->m_maxagi = index; + return index; } /* @@ -952,7 +952,7 @@ xfs_mountfs( mp->m_perag = kmem_zalloc(sbp->sb_agcount * sizeof(xfs_perag_t), KM_SLEEP); - xfs_initialize_perag(mp, sbp->sb_agcount); + mp->m_maxagi = xfs_initialize_perag(mp, sbp->sb_agcount); /* * log's mount-time initialization. Perform 1st part recovery if needed --- linux-2.4.27/fs/xfs/xfs_mount.h.orig 2004-08-24 16:53:20.000000000 +0900 +++ linux-2.4.27/fs/xfs/xfs_mount.h 2004-08-24 16:53:58.000000000 +0900 @@ -555,7 +555,7 @@ extern int xfs_readsb(xfs_mount_t *mp); extern void xfs_freesb(xfs_mount_t *); extern void xfs_do_force_shutdown(bhv_desc_t *, int, char *, int); extern int xfs_syncsub(xfs_mount_t *, int, int, int *); -extern void xfs_initialize_perag(xfs_mount_t *, int); +extern int xfs_initialize_perag(xfs_mount_t *, int); extern void xfs_xlatesb(void *, struct xfs_sb *, int, xfs_arch_t, __int64_t); ----Next_Part(Wed_Aug_25_12:59:49_2004_912)---- From owner-linux-xfs Tue Aug 24 21:35:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 21:35:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7P4ZZIL018243 for ; Tue, 24 Aug 2004 21:35:36 -0700 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 OAA07587; Wed, 25 Aug 2004 14:35:18 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7P4ZGln3526917; Wed, 25 Aug 2004 14:35:17 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7P5Uad2009950; Wed, 25 Aug 2004 15:30:37 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7P5UZfA009948; Wed, 25 Aug 2004 15:30:35 +1000 Date: Wed, 25 Aug 2004 15:30:35 +1000 From: Nathan Scott To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com Subject: Re: force shutdown at xfs_growfs Message-ID: <20040825053035.GB9823@frodo> References: <20040825.125949.424242868.masano@tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040825.125949.424242868.masano@tnes.nec.co.jp> User-Agent: Mutt/1.5.3i X-archive-position: 3971 X-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: 560 Lines: 25 On Wed, Aug 25, 2004 at 12:59:49PM +0900, ASANO Masahiro wrote: > Hi SGI guys, Hi there, > I'm afraid that it is dangerous to grow filesystem by xfs_growfs > under a situation of heavy file allocation. Because mp->m_maxagi is > updated before formatting new AGs, and other processes can touch > them. This causes filesystem shutting down. Yep, good catch! > Here is a patch for Linux-2.4.27. > This patch delays the update of m_maxagi. > > Thank you. Thank you; your fix looks simple & is clearly correct, I'll check it in shortly. cheers. -- Nathan From owner-linux-xfs Tue Aug 24 21:57:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 21:57:27 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7P4vP4t019142 for ; Tue, 24 Aug 2004 21:57:25 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7P4vOA4019141 for linux-xfs@oss.sgi.com; Tue, 24 Aug 2004 21:57:24 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7P4vNmG019127 for ; Tue, 24 Aug 2004 21:57:23 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7P4BwKw017699; Tue, 24 Aug 2004 21:11:58 -0700 Date: Tue, 24 Aug 2004 21:11:58 -0700 Message-Id: <200408250411.i7P4BwKw017699@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 355] unreplayable log after crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3972 X-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: 886 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=355 tes@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From tes@sgi.com 2004-24-08 21:11 PDT ------- Hi Peter, This is likely to be attributed to the incident: sgi_pv#913531 - recovery of v2 logs of log record size of 256K will fail on Linux The fix for this was checked in on June 15 2004. There was a problem with a memory allocation function which had an artificial limit of 128K. (I had an obvious hole in my v2 log qa tests up until that time ;-( --Tim ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 24 22:05:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Aug 2004 22:05:28 -0700 (PDT) Received: from tyo206.gate.nec.co.jp (TYO206.gate.nec.co.jp [202.32.8.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7P55O22019628 for ; Tue, 24 Aug 2004 22:05:25 -0700 Received: from mailgate3.nec.co.jp ([10.7.69.162]) by tyo206.gate.nec.co.jp (8.11.7/3.7W02122014) with ESMTP id i7P55Dt08800 for ; Wed, 25 Aug 2004 14:05:13 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i7P55BF08901 for linux-xfs@oss.sgi.com; Wed, 25 Aug 2004 14:05:11 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id i7P55AD26114 for ; Wed, 25 Aug 2004 14:05:10 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20040825.140934.62502132 for ; Wed, 25 Aug 2004 14:09:34 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Wed Aug 25 14:09:33 2004 +0900 Received: from localhost (localhost.localdomain [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 3799375531; Wed, 25 Aug 2004 14:04:54 +0900 (JST) Date: Wed, 25 Aug 2004 14:04:54 +0900 (JST) Message-Id: <20040825.140454.1025204076.masano@tnes.nec.co.jp> To: nathans@sgi.com Cc: linux-xfs@oss.sgi.com Subject: a deadlock at xfs_growfs From: ASANO Masahiro In-Reply-To: <20040825053035.GB9823@frodo> References: <20040825.125949.424242868.masano@tnes.nec.co.jp> <20040825053035.GB9823@frodo> X-Mailer: Mew version 3.3 on XEmacs 21.4.11 (Native Windows TTY Support) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 3717 Lines: 76 Hi Nathan, From: Nathan Scott Subject: Re: force shutdown at xfs_growfs Date: Wed, 25 Aug 2004 15:30:35 +1000 > Thank you; your fix looks simple & is clearly correct, I'll check > it in shortly. Thank you for your quick response. But I have another problem report for xfs_growfs. :-p Growing a filesystem in heavy dinode allocate/deallocate situation may cause a deadlock. It looks that (a)a process which hold m_peraglock as reading is waiting for a pagebuf(AGI), and (b)another process which hold the pagebuf(AGI) is waiting for down_read m_peraglock, while (c)xfs_growfs is waiting for down_write m_peraglock. The following is a kernel backtrace. Its kernel version was 2.4.25, but I guess that the recent kernel also has the same problem. What do you think of it? (a) PID = 3879 (tar) c76efa7c c01176f9 schedule+2b9 () [c76efabc] c0105ff2 __down+82 (c1f23594,c1f235c8,0) [c76efae0] c010618c __down_failed+8 () [c76efaf0] c0240bc0 [.text.lock.xfs_buf+8a] [c76efaf0] c023ee04 pagebuf_lock+24 (c1f23594ds,2ee00400,0,cbf7cac0) [c76efafc] c023e6e3 _pagebuf_find+1b3 (c97ca67c,177002,0,200) [c76efb30] c023e7f7 pagebuf_get+77 (c97ca67c,177002,0,1) [c76efb60] c0227df4 xfs_trans_read_buf+184 (c38a1400,cbc495b4,c97ca67c,177002) [c76efb88] c0208c7e xfs_ialloc_read_agi+8e (c38a1400,cbc495b4,6,c76efbf0) [c76efbc8] c0207434 xfs_ialloc_ag_select+244 (cbc495b4,3007d7,0,81a4) [c76efc04] c020802f xfs_dialloc+b4f (cbc495b4,3007d7,0,81a4) [c76efcb4] c020ee74 xfs_ialloc+64 (cbc495b4,c239cbc4,81a4,1) [c76efcf8] c022928b xfs_dir_ialloc+8b (c76efdc8,c239cbc4,81a4,1) [c76efd5c] c022efe7 xfs_create+3b7 (c239cbe4,cb746824,c76efe88,c76efe14) [c76efdfc] c0239821 linvfs_mknod+181 (cb312634,cb746824,81a4,0) [c76eff08] c02398a7 linvfs_create+27 (cb312634,cb746824,81a4,c76ee000) [c76eff1c] c014e62d vfs_create+10d (cb312634,cb746824,1a4,c76eff8c) [c76eff40] c014ed45 open_namei+645 (c6ba2000,80c2,1a4,c76eff84) [c76eff70] c0140623 filp_open+43 (c6ba2000,80c1,1a4,c76ee000) [c76effa8] c0140a23 sys_open+53 (8072190,80c1,1a4,80c1) [c76effc0] c010761f system_call+33 () (b) PID = 3946 (rm) c3d91d8c c01176f9 schedule+2b9 () [c3d91dcc] c039082c rwsem_down_failed_common+5c (c38a15d4,c3d91df0,fffeffff,c5c71e0c) [c3d91de0] c0390679 rwsem_down_read_failed+29 (c38a1400,c38a1400) [c3d91e04] c0208fb1 .text.lock.xfs_ialloc+d7 (?c6173d50,a4,a7) [c3d91e14] c0208169 xfs_difree+129 () [c3d91e90] c021057e xfs_ifree+5e (c008ef38,c81e2964,c3d91ee8,0) [c3d91ec0] c022e8a6 xfs_inactive+276 (c81e2984,0,c2a78e1c,0) [c3d91f08] c023dab1 vn_rele+b1 (c2a78e1c,c2a78e3c,c015a4b2,c2a78e3c) [c3d91f20] c023c088 linvfs_clear_inode+18 (c2a78e3c,c2a78e3c,c015af78,c2a78e3c) [c3d91f2c] c015a4b2 clear_inode+102 (c2a78e3c,c04c1300,c5229750,c6a26898) [c3d91f38] c015af78 iput+b8 (c2a78e3c,0,0,c5229750) [c3d91f54] c0158bd2 d_delete+a2 (c6a26898,c6a26898,c689a000,c6a26898) [c3d91f68] c014faf5 vfs_unlink+185 (c5229750,c6a26898,c5c858ec,cbff9214) [c3d91f84] c014fd69 sys_unlink+119 (805313b,2,bffffac0,8053128) [c3d91fc0] c010761f system_call+33 () (c) PID = 3947 (xfs_growfs) c33f9d90 c01176f9 schedule+2b9 () [c33f9dd0] c039082c rwsem_down_failed_common+5c (c38a15d4,c33f9df4,ffffffff,c1225978) [c33f9de4] c03906b9 rwsem_down_write_failed+29 (c272c704) [c33f9e08] c0206a4c .text.lock.xfs_fsops+6 (?0,c057d118,c1232cc4,44) [c33f9e08] c0206306 xfs_growfs_data_private+7 () [c33f9eb0] c02064c0 xfs_growfs_data+50 (c38a1400,c33f9f14,c,c767278c) [c33f9ec4] c02383c1 xfs_ioctl+261 (c1718c84,c7e31200,c3b88cb4,0) [c33f9f74] c023706b linvfs_ioctl+3b (c7e31200,c3b88cb4,400c586e,bffff8b0) [c33f9f94] c0152b75 sys_ioctl+f5 (3,400c586e,bffff8b0,7e6000) [c33f9fc0] c010761f system_call+33 () From owner-linux-xfs Wed Aug 25 00:31:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 00:31:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7P7V68R030200 for ; Wed, 25 Aug 2004 00:31:08 -0700 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 RAA11117; Wed, 25 Aug 2004 17:30:48 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7P7Ukln3536711; Wed, 25 Aug 2004 17:30:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7P7Ugdj3498217; Wed, 25 Aug 2004 17:30:42 +1000 (EST) Date: Wed, 25 Aug 2004 17:30:42 +1000 From: Nathan Scott To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com Subject: Re: a deadlock at xfs_growfs Message-ID: <20040825173042.A3534270@wobbly.melbourne.sgi.com> References: <20040825.125949.424242868.masano@tnes.nec.co.jp> <20040825053035.GB9823@frodo> <20040825.140454.1025204076.masano@tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040825.140454.1025204076.masano@tnes.nec.co.jp>; from masano@tnes.nec.co.jp on Wed, Aug 25, 2004 at 02:04:54PM +0900 X-archive-position: 3974 X-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: 4394 Lines: 89 On Wed, Aug 25, 2004 at 02:04:54PM +0900, ASANO Masahiro wrote: > Hi Nathan, > > Thank you for your quick response. > But I have another problem report for xfs_growfs. :-p > > Growing a filesystem in heavy dinode allocate/deallocate situation may > cause a deadlock. > It looks that (a)a process which hold m_peraglock as reading is > waiting for a pagebuf(AGI), and (b)another process which hold the > pagebuf(AGI) is waiting for down_read m_peraglock, while (c)xfs_growfs > is waiting for down_write m_peraglock. Hmm, I don't see the code path where (b) - the rm process - can be holding the AGI buffer locked while trying to down m_peraglock? That would seem to be an ABBA deadlock, with (a) - the tar - (but the growfs process wouldn't even be involved?). Where is it that the xfs_ifree/xfs_difree takes the AGI buffer lock before trying to grab the peraglock? The correct order would be first m_peraglock, then the AGI buffer, and I can't see anything that violates that in the code paths where you're deadlocked processes are. Odd. > The following is a kernel backtrace. Its kernel version was 2.4.25, > but I guess that the recent kernel also has the same problem. What do > you think of it? I would expect this deadlock still exists, I don't remember fixing it or seeing anyone else fix it - do you have a reproducible test case? thanks. > (a) PID = 3879 (tar) > c76efa7c c01176f9 schedule+2b9 () > [c76efabc] c0105ff2 __down+82 (c1f23594,c1f235c8,0) > [c76efae0] c010618c __down_failed+8 () > [c76efaf0] c0240bc0 [.text.lock.xfs_buf+8a] > [c76efaf0] c023ee04 pagebuf_lock+24 (c1f23594ds,2ee00400,0,cbf7cac0) > [c76efafc] c023e6e3 _pagebuf_find+1b3 (c97ca67c,177002,0,200) > [c76efb30] c023e7f7 pagebuf_get+77 (c97ca67c,177002,0,1) > [c76efb60] c0227df4 xfs_trans_read_buf+184 (c38a1400,cbc495b4,c97ca67c,177002) > [c76efb88] c0208c7e xfs_ialloc_read_agi+8e (c38a1400,cbc495b4,6,c76efbf0) > [c76efbc8] c0207434 xfs_ialloc_ag_select+244 (cbc495b4,3007d7,0,81a4) > [c76efc04] c020802f xfs_dialloc+b4f (cbc495b4,3007d7,0,81a4) > [c76efcb4] c020ee74 xfs_ialloc+64 (cbc495b4,c239cbc4,81a4,1) > [c76efcf8] c022928b xfs_dir_ialloc+8b (c76efdc8,c239cbc4,81a4,1) > [c76efd5c] c022efe7 xfs_create+3b7 (c239cbe4,cb746824,c76efe88,c76efe14) > [c76efdfc] c0239821 linvfs_mknod+181 (cb312634,cb746824,81a4,0) > [c76eff08] c02398a7 linvfs_create+27 (cb312634,cb746824,81a4,c76ee000) > [c76eff1c] c014e62d vfs_create+10d (cb312634,cb746824,1a4,c76eff8c) > [c76eff40] c014ed45 open_namei+645 (c6ba2000,80c2,1a4,c76eff84) > [c76eff70] c0140623 filp_open+43 (c6ba2000,80c1,1a4,c76ee000) > [c76effa8] c0140a23 sys_open+53 (8072190,80c1,1a4,80c1) > [c76effc0] c010761f system_call+33 () > > (b) PID = 3946 (rm) > c3d91d8c c01176f9 schedule+2b9 () > [c3d91dcc] c039082c rwsem_down_failed_common+5c (c38a15d4,c3d91df0,fffeffff,c5c71e0c) > [c3d91de0] c0390679 rwsem_down_read_failed+29 (c38a1400,c38a1400) > [c3d91e04] c0208fb1 .text.lock.xfs_ialloc+d7 (?c6173d50,a4,a7) > [c3d91e14] c0208169 xfs_difree+129 () > [c3d91e90] c021057e xfs_ifree+5e (c008ef38,c81e2964,c3d91ee8,0) > [c3d91ec0] c022e8a6 xfs_inactive+276 (c81e2984,0,c2a78e1c,0) > [c3d91f08] c023dab1 vn_rele+b1 (c2a78e1c,c2a78e3c,c015a4b2,c2a78e3c) > [c3d91f20] c023c088 linvfs_clear_inode+18 (c2a78e3c,c2a78e3c,c015af78,c2a78e3c) > [c3d91f2c] c015a4b2 clear_inode+102 (c2a78e3c,c04c1300,c5229750,c6a26898) > [c3d91f38] c015af78 iput+b8 (c2a78e3c,0,0,c5229750) > [c3d91f54] c0158bd2 d_delete+a2 (c6a26898,c6a26898,c689a000,c6a26898) > [c3d91f68] c014faf5 vfs_unlink+185 (c5229750,c6a26898,c5c858ec,cbff9214) > [c3d91f84] c014fd69 sys_unlink+119 (805313b,2,bffffac0,8053128) > [c3d91fc0] c010761f system_call+33 () > > (c) PID = 3947 (xfs_growfs) > c33f9d90 c01176f9 schedule+2b9 () > [c33f9dd0] c039082c rwsem_down_failed_common+5c (c38a15d4,c33f9df4,ffffffff,c1225978) > [c33f9de4] c03906b9 rwsem_down_write_failed+29 (c272c704) > [c33f9e08] c0206a4c .text.lock.xfs_fsops+6 (?0,c057d118,c1232cc4,44) > [c33f9e08] c0206306 xfs_growfs_data_private+7 () > [c33f9eb0] c02064c0 xfs_growfs_data+50 (c38a1400,c33f9f14,c,c767278c) > [c33f9ec4] c02383c1 xfs_ioctl+261 (c1718c84,c7e31200,c3b88cb4,0) > [c33f9f74] c023706b linvfs_ioctl+3b (c7e31200,c3b88cb4,400c586e,bffff8b0) > [c33f9f94] c0152b75 sys_ioctl+f5 (3,400c586e,bffff8b0,7e6000) > [c33f9fc0] c010761f system_call+33 () -- Nathan From owner-linux-xfs Wed Aug 25 02:22:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 02:22:04 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7P9M08h001038 for ; Wed, 25 Aug 2004 02:22:01 -0700 Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i7P9LmE18136 for ; Wed, 25 Aug 2004 18:21:48 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i7P9LmO29681 for linux-xfs@oss.sgi.com; Wed, 25 Aug 2004 18:21:48 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id i7P9Lkm05418 for ; Wed, 25 Aug 2004 18:21:46 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20040825.182611.25003836 for ; Wed, 25 Aug 2004 18:26:11 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Wed Aug 25 18:26:10 2004 +0900 Received: from localhost (localhost.localdomain [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 2916975531; Wed, 25 Aug 2004 18:21:31 +0900 (JST) Date: Wed, 25 Aug 2004 18:21:31 +0900 (JST) Message-Id: <20040825.182131.466644752.masano@tnes.nec.co.jp> To: nathans@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: a deadlock at xfs_growfs From: ASANO Masahiro In-Reply-To: <20040825173042.A3534270@wobbly.melbourne.sgi.com> References: <20040825053035.GB9823@frodo> <20040825.140454.1025204076.masano@tnes.nec.co.jp> <20040825173042.A3534270@wobbly.melbourne.sgi.com> X-Mailer: Mew version 3.3 on XEmacs 21.4.11 (Native Windows TTY Support) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 2113 Lines: 62 From: Nathan Scott Subject: Re: a deadlock at xfs_growfs Date: Wed, 25 Aug 2004 17:30:42 +1000 > On Wed, Aug 25, 2004 at 02:04:54PM +0900, ASANO Masahiro wrote: > > Hi Nathan, > > > > Thank you for your quick response. > > But I have another problem report for xfs_growfs. :-p > > > > Growing a filesystem in heavy dinode allocate/deallocate situation may > > cause a deadlock. > > It looks that (a)a process which hold m_peraglock as reading is > > waiting for a pagebuf(AGI), and (b)another process which hold the > > pagebuf(AGI) is waiting for down_read m_peraglock, while (c)xfs_growfs > > is waiting for down_write m_peraglock. > > Hmm, I don't see the code path where (b) - the rm process - can > be holding the AGI buffer locked while trying to down m_peraglock? > That would seem to be an ABBA deadlock, with (a) - the tar - (but > the growfs process wouldn't even be involved?). Where is it that > the xfs_ifree/xfs_difree takes the AGI buffer lock before trying to > grab the peraglock? Possibly (b) was a victim. There were some other hang processes. kupdated also hanged. I'll check it again more closely. Anyway, the pagebuf was linked from XFS_TRANS_INACTIVE transaction then. BTW, how about xfs_dialloc(). It seems ABA order. xfs_dialloc() { ... down_read(&mp->m_peraglock); xfs_ialloc_read_agi(); up_read(&mp->m_peraglock); ... down_read(&mp->m_peraglock); mp->m_perag[tagno].pagi_freecount--; up_read(&mp->m_peraglock); ... } > The correct order would be first m_peraglock, then the AGI buffer, > and I can't see anything that violates that in the code paths where > you're deadlocked processes are. Odd. I see. > > The following is a kernel backtrace. Its kernel version was 2.4.25, > > but I guess that the recent kernel also has the same problem. What do > > you think of it? > > I would expect this deadlock still exists, I don't remember fixing > it or seeing anyone else fix it - do you have a reproducible test > case? I'll do it later. -- masano From owner-linux-xfs Wed Aug 25 03:13:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 03:13:39 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PADSAR004504 for ; Wed, 25 Aug 2004 03:13:29 -0700 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 i7PAD57X19666216; Wed, 25 Aug 2004 20:13:06 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7PAD4jZ19147980; Wed, 25 Aug 2004 20:13:04 +1000 (EST) Date: Wed, 25 Aug 2004 20:13:04 +1000 (EST) From: Nathan Scott Message-Id: <200408251013.i7PAD4jZ19147980@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 920243 - growfs X-archive-position: 3976 X-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: 450 Lines: 16 Ensure maxagi not updated early during growfs, conflicts with concurrent inode allocations. Fix from ASANO Masahiro. Date: Wed Aug 25 03:12:20 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: tes@sgi.com,masano@tnes.nec.co.jp The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:177699a xfs_mount.h - 1.189 xfs_mount.c - 1.349 xfs_fsops.c - 1.100 From owner-linux-xfs Wed Aug 25 06:10:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 06:10:40 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PDAXIg014033 for ; Wed, 25 Aug 2004 06:10:34 -0700 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BzxXl-0005ls-00 for ; Wed, 25 Aug 2004 15:10:25 +0200 Received: from pd9e93849.dip.t-dialin.net ([217.233.56.73]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Aug 2004 15:10:25 +0200 Received: from claus by pd9e93849.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Aug 2004 15:10:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) Subject: Re: Does XFS Support UNICODE ????? Date: 24 Aug 2004 18:34:00 +0200 Message-ID: <9FVp60NJcDD@gmane.3247.org> References: <412492AC.3030605@eva.mpg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9e93849.dip.t-dialin.net User-Agent: OpenXP/3.9.8-cvs (Win32; Delphi) X-archive-position: 3977 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: claus@faerber.muc.de Precedence: bulk X-list: linux-xfs Content-Length: 304 Lines: 11 Michael Gasch schrieb/wrote: > samba is setup to store files in utf-8 format > is xfs able to store files in utf-8 unicode ???? UTF-8, formerly known as UTF-FSS ("file system safe"), has been desinged to work with all UNIX/POSIX file systems. Claus -- http://www.faerber.muc.de From owner-linux-xfs Wed Aug 25 10:09:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 10:09:05 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PH93rZ011579 for ; Wed, 25 Aug 2004 10:09:04 -0700 Received: from smtp.themccords.com (pcp09719561pcs.plsntv01.nj.comcast.net[68.44.45.39]) by comcast.net (sccrmhc11) with ESMTP id <2004082517085001100brskqe>; Wed, 25 Aug 2004 17:08:51 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.themccords.com (Postfix) with ESMTP id C1CFF274DE for ; Wed, 25 Aug 2004 13:08:50 -0400 (EDT) Received: from smtp.themccords.com ([127.0.0.1]) by localhost (smtp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11268-05 for ; Wed, 25 Aug 2004 13:08:41 -0400 (EDT) Received: from [10.0.16.1] (mail.ac-coin.com [64.152.189.74]) by smtp.themccords.com (Postfix) with ESMTP id 22903274DA for ; Wed, 25 Aug 2004 13:08:39 -0400 (EDT) Message-ID: <412CC78E.4040505@themccords.com> Date: Wed, 25 Aug 2004 13:08:30 -0400 From: Ken McCord User-Agent: Mozilla Thunderbird 0.5 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Stability of XFS in Linux Kernel 2.4.27 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at themccords.com X-archive-position: 3978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ken@themccords.com Precedence: bulk X-list: linux-xfs Content-Length: 310 Lines: 10 After running on XFS 1.1 for the past two years without a single problem, we need to upgrade to the latest Linux kernel to get driver support for an upgraded BIOS on a ServeRAID adapter. Are there any 'gotchas' I need to be aware of in moving to the latest release (XFS, not Linux)? Thanks, Ken McCord From owner-linux-xfs Wed Aug 25 10:35:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 10:35:07 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [207.218.156.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PHZ2vA012815 for ; Wed, 25 Aug 2004 10:35:03 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i7PHPOuw016609; Wed, 25 Aug 2004 12:25:25 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i7PHPIft016606; Wed, 25 Aug 2004 12:25:24 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Wed, 25 Aug 2004 12:25:18 -0500 (EST) From: Net Llama! To: Ken McCord cc: linux-xfs@oss.sgi.com Subject: Re: Stability of XFS in Linux Kernel 2.4.27 In-Reply-To: <412CC78E.4040505@themccords.com> Message-ID: References: <412CC78E.4040505@themccords.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.60.818 (localhost [127.0.0.1]); Wed, 25 Aug 2004 12:25:25 -0500 X-archive-position: 3979 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 696 Lines: 22 I'd say that kinda depends a lot more heavily on which kernel version you were runnning than the XFS version. On Wed, 25 Aug 2004, Ken McCord wrote: > After running on XFS 1.1 for the past two years without a single > problem, we need to upgrade to the latest Linux kernel to get driver > support for an upgraded BIOS on a ServeRAID adapter. Are there any > 'gotchas' I need to be aware of in moving to the latest release (XFS, > not Linux)? > > Thanks, > > Ken McCord > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Wed Aug 25 12:36:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 12:36:12 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PJa8m2024602 for ; Wed, 25 Aug 2004 12:36:09 -0700 Received: by mproxy.gmail.com with SMTP id 73so106706rnk for ; Wed, 25 Aug 2004 12:35:56 -0700 (PDT) Received: by 10.38.72.60 with SMTP id u60mr936490rna; Wed, 25 Aug 2004 12:35:56 -0700 (PDT) Received: by 10.38.24.46 with HTTP; Wed, 25 Aug 2004 12:35:55 -0700 (PDT) Message-ID: <208fc95204082512352ea7b9b9@mail.gmail.com> Date: Wed, 25 Aug 2004 12:35:55 -0700 From: Wenzel Jakob Reply-To: Wenzel Jakob To: linux-xfs@oss.sgi.com Subject: XFS corruption on vanilla kernel. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3980 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wazlaf@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1097 Lines: 27 Hello, I am experiencing XFS file system corruption on a vanilla kernel.org kernel 2.6.7 (the only additional module is the nvidia driver which really shouldn't be the cause of the problems). The problem is that, all of a sudden, files have the content of an entirely different file. For example one second I am editing a .cpp file, the next moment I open it up again, it is a jpeg file from a directory containing my digital camera pictures. The original .cpp file was lost, so the files were not exchanged. This has happened to me before with previous kernels from 2.6 - what I usually did is run knoppix and fsck the filesystem which seemed to stop it for a while. I cannot reproduce this behavior, it seems completely random and only happens every couple of weeks. Also, I have only noticed this with files on which I am actively working - who knows, maybe many more files have some wrong content by now. I am very certain that this is not a virus or an intrusion and is caused by the filesystem. If anyone has some advice, I am open to every suggestion. Thanks in advance, Wenzel Jakob From owner-linux-xfs Wed Aug 25 14:19:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 14:19:52 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [207.218.156.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PLJmgI028879 for ; Wed, 25 Aug 2004 14:19:49 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i7PLA8i6018593; Wed, 25 Aug 2004 16:10:08 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-5) with ESMTP id i7PLA7RI018590; Wed, 25 Aug 2004 16:10:07 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Wed, 25 Aug 2004 16:10:07 -0500 (EST) From: Net Llama! To: Wenzel Jakob cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on vanilla kernel. In-Reply-To: <208fc95204082512352ea7b9b9@mail.gmail.com> Message-ID: References: <208fc95204082512352ea7b9b9@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.60.818 (localhost [127.0.0.1]); Wed, 25 Aug 2004 16:10:08 -0500 X-archive-position: 3981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1779 Lines: 42 On Wed, 25 Aug 2004, Wenzel Jakob wrote: > Hello, > I am experiencing XFS file system corruption on a vanilla kernel.org > kernel 2.6.7 (the only additional module is the nvidia driver which > really shouldn't be the cause of the problems). Actually, that is historically the cause of this problem. Check the list arvhives and you'll find alot of reports of people seeing wacky problems when using the nvidia X driver. > The problem is that, all of a sudden, files have the content of an > entirely different file. For example one second I am editing a .cpp > file, the next moment I open it up again, it is a jpeg file from a > directory containing my digital camera pictures. The original .cpp > file was lost, so the files were not exchanged. Sounds like bad hardware to me. > > This has happened to me before with previous kernels from 2.6 - what I > usually did is run knoppix and fsck the filesystem which seemed to > stop it for a while. There is no fsck for XFS. What exactly were you running? > I cannot reproduce this behavior, it seems completely random and only > happens every couple of weeks. Also, I have only noticed this with > files on which I am actively working - who knows, maybe many more > files have some wrong content by now. > > I am very certain that this is not a virus or an intrusion and is > caused by the filesystem. If anyone has some advice, I am open to > every suggestion. Have you checked your logs (particularly messages) for errors? This sounds like a hardware problem, or the nvidia driver is eating you disk. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Wed Aug 25 14:36:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 14:36:34 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (heretic.physik.fu-berlin.de [160.45.32.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PLaSjY029430 for ; Wed, 25 Aug 2004 14:36:29 -0700 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i7PLZw3E018588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2004 23:36:08 +0200 Received: (from thimm@localhost) by neu.physik.fu-berlin.de (8.12.11/8.12.11/Submit) id i7PLZnCL026714; Wed, 25 Aug 2004 23:35:49 +0200 Date: Wed, 25 Aug 2004 23:35:49 +0200 From: Axel Thimm To: Wenzel Jakob Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on vanilla kernel. Message-ID: <20040825213549.GE24014@neu.physik.fu-berlin.de> References: <208fc95204082512352ea7b9b9@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF" Content-Disposition: inline In-Reply-To: <208fc95204082512352ea7b9b9@mail.gmail.com> User-Agent: Mutt/1.4.2i X-archive-position: 3982 X-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@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 1887 Lines: 51 --FN+gV9K+162wdwwF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 25, 2004 at 12:35:55PM -0700, Wenzel Jakob wrote: > Hello, > I am experiencing XFS file system corruption on a vanilla kernel.org > kernel 2.6.7 (the only additional module is the nvidia driver which > really shouldn't be the cause of the problems). >=20 > The problem is that, all of a sudden, files have the content of an > entirely different file. For example one second I am editing a .cpp > file, the next moment I open it up again, it is a jpeg file from a > directory containing my digital camera pictures. The original .cpp > file was lost, so the files were not exchanged. >=20 > This has happened to me before with previous kernels from 2.6 - what I > usually did is run knoppix and fsck the filesystem which seemed to > stop it for a while. >=20 > I cannot reproduce this behavior, it seems completely random and only > happens every couple of weeks. Also, I have only noticed this with > files on which I am actively working - who knows, maybe many more > files have some wrong content by now. >=20 > I am very certain that this is not a virus or an intrusion and is > caused by the filesystem. If anyone has some advice, I am open to > every suggestion. umount the file system (if it's your root then move the harddisk to another system for forensics or use a live CD with xfs utilities) and use xfs_check(8) and xfs_repair(8). If any output/diagnostics looks suspicious ask again on the list. --=20 Axel.Thimm at ATrpms.net --FN+gV9K+162wdwwF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBLQY1QBVS1GOamfERAhTIAJ4ixgIyOUM2VyD1ygs0Z3yJmK6K5QCeLLPu ivIilPC55BXLeRn/avEvWBI= =tK51 -----END PGP SIGNATURE----- --FN+gV9K+162wdwwF-- From owner-linux-xfs Wed Aug 25 14:36:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 14:36:43 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PLafrc029490 for ; Wed, 25 Aug 2004 14:36:42 -0700 Received: from taniwha.stupidest.org (adsl-63-202-174-89.dsl.snfc21.pacbell.net [63.202.174.89]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7PLaEhh199074; Wed, 25 Aug 2004 17:36:14 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 4E9F1115C86F; Wed, 25 Aug 2004 14:36:13 -0700 (PDT) Date: Wed, 25 Aug 2004 14:36:13 -0700 From: Chris Wedgwood To: Wenzel Jakob , Net Llama! Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on vanilla kernel. Message-ID: <20040825213613.GA32082@taniwha.stupidest.org> References: <208fc95204082512352ea7b9b9@mail.gmail.com> <208fc95204082512352ea7b9b9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <208fc95204082512352ea7b9b9@mail.gmail.com> X-archive-position: 3983 X-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: 1915 Lines: 48 On Wed, Aug 25, 2004 at 12:35:55PM -0700, Wenzel Jakob wrote: > I am experiencing XFS file system corruption on a vanilla kernel.org > kernel 2.6.7 (the only additional module is the nvidia driver which > really shouldn't be the cause of the problems). Ick, as pointed out the nvidia driver *might* (not necessarily is, but *might* be causing problems --- we just can't tell). How repeatable are the problems and can you make them occur w/o the nvidia driver having been loaded? > The problem is that, all of a sudden, files have the content of an > entirely different file. For example one second I am editing a .cpp > file, the next moment I open it up again, it is a jpeg file from a > directory containing my digital camera pictures. The original .cpp > file was lost, so the files were not exchanged. That's really weird. If you reboot and check the files again do you see the wrong content? It would be good to know if this is on-disk or in-memory (page-cache corruption). Also, for the files involved, do you know *which* two files got messed up? I'm wondering if they have a similar location on disk, similiar inode numbers or something that a bit-flip would explain. > This has happened to me before with previous kernels from 2.6 - what > I usually did is run knoppix and fsck the filesystem which seemed to > stop it for a while. Did it find any errors? What output do you typically get here? On Wed, Aug 25, 2004 at 04:10:07PM -0500, Net Llama! wrote: > There is no fsck for XFS. What exactly were you running? xfs_repair I'm guessing. It *is* fsck for XFS really. fsck.xfs isn't a NOP to make init-scripts work. > Have you checked your logs (particularly messages) for errors? This > sounds like a hardware problem, or the nvidia driver is eating you > disk. It sounds more like in-core corruption to me (which could get flushed out so persist on disk at a later stage). --cw From owner-linux-xfs Wed Aug 25 15:01:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 15:01:21 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PM1JkM030539 for ; Wed, 25 Aug 2004 15:01:19 -0700 Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1C05pP-00088b-OM; Wed, 25 Aug 2004 23:01:11 +0100 To: torvalds@osdl.org Subject: [PATCH] xfs long constants Cc: linux-xfs@oss.sgi.com Message-Id: From: viro@www.linux.org.uk Date: Wed, 25 Aug 2004 23:01:11 +0100 X-archive-position: 3985 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: viro@www.linux.org.uk Precedence: bulk X-list: linux-xfs Content-Length: 730 Lines: 20 diff -urN RC9-rc1-bk1-xfs-sendfile/fs/xfs/xfs_bmap.c RC9-rc1-bk1-xfs-constants/fs/xfs/xfs_bmap.c --- RC9-rc1-bk1-xfs-sendfile/fs/xfs/xfs_bmap.c Tue Aug 24 10:38:11 2004 +++ RC9-rc1-bk1-xfs-constants/fs/xfs/xfs_bmap.c Wed Aug 25 17:39:47 2004 @@ -3431,12 +3431,12 @@ * uninitialized br_startblock field. */ - got.br_startoff = 0xffa5a5a5a5a5a5a5; - got.br_blockcount = 0xa55a5a5a5a5a5a5a; + got.br_startoff = 0xffa5a5a5a5a5a5a5ULL; + got.br_blockcount = 0xa55a5a5a5a5a5a5aULL; got.br_state = XFS_EXT_INVALID; #if XFS_BIG_BLKNOS - got.br_startblock = 0xffffa5a5a5a5a5a5; + got.br_startblock = 0xffffa5a5a5a5a5a5ULL; #else got.br_startblock = 0xffffa5a5; #endif From owner-linux-xfs Wed Aug 25 15:01:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 15:01:12 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PM19t4030480 for ; Wed, 25 Aug 2004 15:01:10 -0700 Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1C05pF-00087r-NN; Wed, 25 Aug 2004 23:01:01 +0100 To: torvalds@osdl.org Subject: [PATCH] annotation of xfs sendfile Cc: linux-xfs@oss.sgi.com Message-Id: From: viro@www.linux.org.uk Date: Wed, 25 Aug 2004 23:01:01 +0100 X-archive-position: 3984 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: viro@www.linux.org.uk Precedence: bulk X-list: linux-xfs Content-Length: 2157 Lines: 51 ->sendfile() takes kernel pointer, not userland one. diff -urN RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_file.c RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_file.c --- RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_file.c Tue Aug 24 10:38:11 2004 +++ RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_file.c Wed Aug 25 17:39:05 2004 @@ -259,7 +259,7 @@ loff_t *ppos, size_t count, read_actor_t actor, - void __user *target) + void *target) { vnode_t *vp = LINVFS_GET_VP(filp->f_dentry->d_inode); ssize_t rval; diff -urN RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_lrw.c RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_lrw.c --- RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_lrw.c Tue Aug 24 10:38:11 2004 +++ RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_lrw.c Wed Aug 25 17:39:15 2004 @@ -366,7 +366,7 @@ int ioflags, size_t count, read_actor_t actor, - void __user *target, + void *target, cred_t *credp) { ssize_t ret; diff -urN RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_lrw.h RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_lrw.h --- RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_lrw.h Tue Aug 24 10:38:11 2004 +++ RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_lrw.h Wed Aug 25 17:39:23 2004 @@ -104,7 +104,7 @@ loff_t *, int, struct cred *); extern ssize_t xfs_sendfile(struct bhv_desc *, struct file *, loff_t *, int, size_t, read_actor_t, - void __user *, struct cred *); + void *, struct cred *); extern int xfs_dev_is_read_only(struct xfs_mount *, char *); diff -urN RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_vnode.h RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_vnode.h --- RC9-rc1-bk1-aio/fs/xfs/linux-2.6/xfs_vnode.h Tue Aug 24 10:38:11 2004 +++ RC9-rc1-bk1-xfs-sendfile/fs/xfs/linux-2.6/xfs_vnode.h Wed Aug 25 17:39:31 2004 @@ -192,7 +192,7 @@ loff_t *, int, struct cred *); typedef ssize_t (*vop_sendfile_t)(bhv_desc_t *, struct file *, loff_t *, int, size_t, read_actor_t, - void __user *, struct cred *); + void *, struct cred *); typedef int (*vop_ioctl_t)(bhv_desc_t *, struct inode *, struct file *, int, unsigned int, void __user *); typedef int (*vop_getattr_t)(bhv_desc_t *, struct vattr *, int, From owner-linux-xfs Wed Aug 25 15:02:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 15:02:53 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PM2or6031072 for ; Wed, 25 Aug 2004 15:02:51 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1C05qp-0003H0-H2; Wed, 25 Aug 2004 23:02:39 +0100 Date: Wed, 25 Aug 2004 23:02:39 +0100 From: Christoph Hellwig To: viro@www.linux.org.uk Cc: torvalds@osdl.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs long constants Message-ID: <20040825230239.A12583@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from viro@www.linux.org.uk on Wed, Aug 25, 2004 at 11:01:11PM +0100 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 3986 X-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: 136 Lines: 3 A fix for this that also kills the horrible indendation is on it's way to Linus as part of an XFS merge. Please don't apply this one. From owner-linux-xfs Wed Aug 25 15:04:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 15:04:58 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PM4t9k031416 for ; Wed, 25 Aug 2004 15:04:56 -0700 Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1C05su-0008MN-Bo; Wed, 25 Aug 2004 23:04:48 +0100 Date: Wed, 25 Aug 2004 23:04:48 +0100 From: viro@parcelfarce.linux.theplanet.co.uk To: Christoph Hellwig Cc: viro@www.linux.org.uk, torvalds@osdl.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs long constants Message-ID: <20040825220448.GL21964@parcelfarce.linux.theplanet.co.uk> References: <20040825230239.A12583@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040825230239.A12583@infradead.org> User-Agent: Mutt/1.4.1i X-archive-position: 3987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: viro@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 271 Lines: 6 On Wed, Aug 25, 2004 at 11:02:39PM +0100, Christoph Hellwig wrote: > A fix for this that also kills the horrible indendation is on it's way to > Linus as part of an XFS merge. Please don't apply this one. Fine by me (the rest of patchset doesn't depend on that one). From owner-linux-xfs Wed Aug 25 15:08:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 15:08:28 -0700 (PDT) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PM8PkP031831 for ; Wed, 25 Aug 2004 15:08:25 -0700 Received: from mailav1.fnal.gov (mailav1.fnal.gov [131.225.111.18]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with SMTP id <0I3000MSHW4AYF@mailgw2.fnal.gov> for linux-xfs@oss.sgi.com; Wed, 25 Aug 2004 17:08:15 -0500 (CDT) Received: from mailgw2.fnal.gov ([131.225.111.12]) by mailav1.fnal.gov (SAVSMTP 3.1.0.29) with SMTP id M2004082517081400764 for ; Wed, 25 Aug 2004 17:08:14 -0500 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0I3000201W4LJZ@mailgw2.fnal.gov> (original mail from greenc@fnal.gov) for linux-xfs@oss.sgi.com; Wed, 25 Aug 2004 17:08:14 -0500 (CDT) Received: from ashland.fnal.gov (ashland.fnal.gov [131.225.53.49]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0I3000MOGW5QXI@mailgw2.fnal.gov>; Wed, 25 Aug 2004 17:08:14 -0500 (CDT) Date: Wed, 25 Aug 2004 17:08:14 -0500 (CDT) From: Chris Green Subject: Re: XFS corruption on vanilla kernel. In-reply-to: <20040825213613.GA32082@taniwha.stupidest.org> To: Wenzel Jakob Cc: Chris Wedgwood , Net Llama! , linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <208fc95204082512352ea7b9b9@mail.gmail.com> <208fc95204082512352ea7b9b9@mail.gmail.com> <20040825213613.GA32082@taniwha.stupidest.org> X-archive-position: 3988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greenc@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 403 Lines: 14 Hi, Just an off-the wall comment from an habitual lurker on linux-xfs: make sure it's not something really nasty, like an interaction between an IDE chipset and your hard drive. A Serverworks OSB4 chipset and a Seagate hard drive are a particularly nice combination in this respect. Cheers, Chris. -- Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov Tel: (630) 840-2167. Fax: (630) 840-3867 From owner-linux-xfs Wed Aug 25 16:03:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 16:03:46 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7PN3fOL001209 for ; Wed, 25 Aug 2004 16:03:42 -0700 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 JAA28361; Thu, 26 Aug 2004 09:03:23 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7PN3Lln3556258; Thu, 26 Aug 2004 09:03:21 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7PN3J6N3555798; Thu, 26 Aug 2004 09:03:19 +1000 (EST) Date: Thu, 26 Aug 2004 09:03:19 +1000 From: Nathan Scott To: viro@www.linux.org.uk Cc: torvalds@osdl.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] annotation of xfs sendfile Message-ID: <20040826090318.A3531841@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from viro@www.linux.org.uk on Wed, Aug 25, 2004 at 11:01:01PM +0100 X-archive-position: 3989 X-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: 246 Lines: 11 On Wed, Aug 25, 2004 at 11:01:01PM +0100, viro@www.linux.org.uk wrote: > ->sendfile() takes kernel pointer, not userland one. Thanks Al, patch looks good to me. I'll send it on shortly if Linus hasn't picked it up already. cheers. -- Nathan From owner-linux-xfs Wed Aug 25 16:25:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 16:25:20 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7PNPEH7005966 for ; Wed, 25 Aug 2004 16:25:16 -0700 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 i7PNP07X19947301 for ; Thu, 26 Aug 2004 09:25:01 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7PNP0Xp16746009 for linux-xfs@oss.sgi.com; Thu, 26 Aug 2004 09:25:00 +1000 (EST) Date: Thu, 26 Aug 2004 09:25:00 +1000 (EST) From: Nathan Scott Message-Id: <200408252325.i7PNP0Xp16746009@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 915844 - sendfile vs sparse X-archive-position: 3990 X-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: 464 Lines: 17 Fix incorrect sparse annotation for sendfile operation. Fix from Al Viro. Date: Wed Aug 25 16:24:33 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: viro@parcelfarce.linux.theplanet.co.uk The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:177758a linux-2.6/xfs_lrw.h - 1.47 linux-2.6/xfs_lrw.c - 1.215 linux-2.6/xfs_file.c - 1.106 linux-2.6/xfs_vnode.h - 1.96 From owner-linux-xfs Wed Aug 25 17:16:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 17:16:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7Q0GrwY009945 for ; Wed, 25 Aug 2004 17:16:54 -0700 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 KAA29981; Thu, 26 Aug 2004 10:16:34 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7Q0GWln3557283; Thu, 26 Aug 2004 10:16:32 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7Q0GUU63557017; Thu, 26 Aug 2004 10:16:30 +1000 (EST) Date: Thu, 26 Aug 2004 10:16:29 +1000 From: Nathan Scott To: Ken McCord Cc: linux-xfs@oss.sgi.com Subject: Re: Stability of XFS in Linux Kernel 2.4.27 Message-ID: <20040826101629.C3531841@wobbly.melbourne.sgi.com> References: <412CC78E.4040505@themccords.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <412CC78E.4040505@themccords.com>; from ken@themccords.com on Wed, Aug 25, 2004 at 01:08:30PM -0400 X-archive-position: 3991 X-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: 423 Lines: 14 On Wed, Aug 25, 2004 at 01:08:30PM -0400, Ken McCord wrote: > After running on XFS 1.1 for the past two years without a single > problem, we need to upgrade to the latest Linux kernel to get driver > support for an upgraded BIOS on a ServeRAID adapter. Are there any > 'gotchas' I need to be aware of in moving to the latest release (XFS, > not Linux)? No gotchas, it should all Just Work (TM). cheers. -- Nathan From owner-linux-xfs Wed Aug 25 17:50:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Aug 2004 17:50:30 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7Q0oPNF011154 for ; Wed, 25 Aug 2004 17:50:27 -0700 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 i7Q0oB7X19918613; Thu, 26 Aug 2004 10:50:11 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7Q0o9rG20133490; Thu, 26 Aug 2004 10:50:09 +1000 (EST) Date: Thu, 26 Aug 2004 10:50:09 +1000 (EST) From: Nathan Scott Message-Id: <200408260050.i7Q0o9rG20133490@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE 907752 - acl X-archive-position: 3992 X-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: 21 ACL updates from Andreas. Date: Wed Aug 25 17:49:27 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:177765a acl/test/setfacl-X.test - 1.1 acl/VERSION - 1.65 acl/doc/CHANGES - 1.72 acl/debian/changelog - 1.58 acl/setfacl/setfacl.c - 1.13 acl/setfacl/sequence.h - 1.3 acl/setfacl/parse.h - 1.3 acl/setfacl/parse.c - 1.6 acl/setfacl/do_set.c - 1.12 From owner-linux-xfs Thu Aug 26 01:41:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Aug 2004 01:41:21 -0700 (PDT) Received: from a.mx.lerrahn.de (lerrahn.de [81.169.180.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7Q8fIgd004479 for ; Thu, 26 Aug 2004 01:41:18 -0700 Received: (qmail 28774 invoked by uid 210); 26 Aug 2004 08:41:03 +0000 Received: from johannes@jottbee.org by h6873 by uid 201 with qmail-scanner-1.20 (clamscan: 0.73. spamassassin: 2.63. Clear:RC:1(80.131.92.120):. Processed in 0.030175 secs); 26 Aug 2004 08:41:03 -0000 Received: from p50835c78.dip0.t-ipconnect.de (HELO jottbee.dyndns.org) (80.131.92.120) by lerrahn.de with AES256-SHA encrypted SMTP; 26 Aug 2004 08:41:03 +0000 Received: (qmail 27347 invoked by uid 210); 26 Aug 2004 10:41:11 +0200 Received: from johannes@jottbee.org by lahme-kiste by uid 201 with qmail-scanner-1.20 (clamscan: 0.75.1. Clear:RC:1(192.168.70.77):. Processed in 0.073132 secs); 26 Aug 2004 08:41:11 -0000 Received: from trickkiste.jottbee.daheim (192.168.70.77) by lahme-kiste.jottbee.daheim with AES256-SHA encrypted SMTP; 26 Aug 2004 10:41:10 +0200 Received: (qmail 6536 invoked by uid 1001); 26 Aug 2004 10:41:04 +0200 Date: Thu, 26 Aug 2004 10:41:04 +0200 From: Johannes =?iso-8859-15?Q?Br=FCgmann?= To: Linux XFS List Subject: Re: XFS corruption on vanilla kernel. Message-ID: <20040826084104.GA6509@trickkiste.jottbee.daheim> References: <208fc95204082512352ea7b9b9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <208fc95204082512352ea7b9b9@mail.gmail.com> User-Agent: Mutt/1.5.6i X-archive-position: 3993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johannes@jottbee.org Precedence: bulk X-list: linux-xfs Content-Length: 2365 Lines: 59 Hello XFS-list, Wenzel Jakob wrote: > Hello, > I am experiencing XFS file system corruption on a vanilla kernel.org > kernel 2.6.7 (the only additional module is the nvidia driver which > really shouldn't be the cause of the problems). I used the nvidia card with the Xorg driver. > The problem is that, all of a sudden, files have the content of an > entirely different file. For example one second I am editing a .cpp > file, the next moment I open it up again, it is a jpeg file from a > directory containing my digital camera pictures. The original .cpp > file was lost, so the files were not exchanged. I experienced exactly the same problem -- the main reason why I use ?fs now. I didn't have the heart to write this problem to this list (though I'm reading this list for more than half a year now) because I thought that very likely I did something wrong. First time I encountered this problem was -- I guess -- due to broken memory. Weeks later came the kernel freezes. So from this point on I knew it was the memory. I removed the broken memory -- but the problem went back. Usually after an 'emerge sync' there were missing files in the /usr/portage (my distribution sync tree) directory and syncing failed due to freshly created but lost files. This time I was experimenting with CFLAGS so I thought maybe I was too aggressive in optimizing and probably the compiler doesn't work. The confusing thing was, that the whole system and all applications worked very well and were build with the same CFLAGS. *Only* syncing failed and some files were gone. Due to the fact that syncing failed I bought a new disk, took ?fs and builded a partially new system on the new disk (the old one exists still with the old system). > This has happened to me before with previous kernels from 2.6 - what I > usually did is run knoppix and fsck the filesystem which seemed to > stop it for a while. Same with me: I used the gentoo livecd xfs_check, xfs_repair. Tons of inode messages and the lost+found directory was filled with about swap-size (with the broken memory). With a good memory it was not that much but still some files. I had kernel versions 2.6.1 - 2.6.7 and various rcs. Don't know if this is useful. Regards, Johannes -- Herr, all mein Verlangen liegt offen vor dir, und mein Seufzen ist dir nicht verborgen. Psalm 38,10 From owner-linux-xfs Thu Aug 26 02:02:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Aug 2004 02:02:23 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7Q92J4V005341 for ; Thu, 26 Aug 2004 02:02:20 -0700 Received: from localhost (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id CC56888A679 for ; Thu, 26 Aug 2004 17:02:11 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gusi.leathercollection.ph (Postfix) with ESMTP id AABA288A678 for ; Thu, 26 Aug 2004 17:02:05 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 4FBA9A54F1B6; Thu, 26 Aug 2004 17:27:02 +0800 (PHT) Date: Thu, 26 Aug 2004 17:27:02 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Software RAID 1, LVM1 and XFS Message-ID: <20040826092702.GI31521@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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.6+20040523i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at leathercollection.ph X-archive-position: 3994 X-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: 689 Lines: 18 Hi everyone, I'd just like to find out if anyone has a working, stable system with a Linux 2.4.x kernel, software RAID1, LVM1 and XFS. I remember reading some bits on the mailing list about incompatibility with Software RAID5, LVM and XFS, but I don't know about software RAID1. The reason I'm interested in this is I plan to set up a server using software RAID1, but don't want to create N arrays (where N is the number of partitions I want to have), and of course, I'll be using XFS. Thank you very much for the help. :) --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs Thu Aug 26 08:27:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Aug 2004 08:27:40 -0700 (PDT) Received: from marpa.dotforge.ch (marpa.dotforge.ch [212.147.103.250]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7QFRZHf001611 for ; Thu, 26 Aug 2004 08:27:37 -0700 Received: from smtp.nofida.ch (62-2-181-77.business.cablecom.ch [62.2.181.77]) by marpa.dotforge.ch (Postfix) with ESMTP id 41DD31B697; Thu, 26 Aug 2004 17:27:26 +0200 (CEST) Received: by smtp.nofida.ch (Postfix, from userid 101) id C5EFD11AB0; Thu, 26 Aug 2004 17:27:22 +0200 (CEST) Received: from [192.168.74.20] (galadriel.nofida.ch [192.168.74.20]) by smtp.nofida.ch (Postfix) with ESMTP id AC80E11AAE; Thu, 26 Aug 2004 17:27:14 +0200 (CEST) Subject: Re: Software RAID 1, LVM1 and XFS From: Marcel de Riedmatten To: Federico Sevilla III Cc: Linux-XFS Mailing List In-Reply-To: <20040826092702.GI31521@leathercollection.ph> References: <20040826092702.GI31521@leathercollection.ph> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QiyJpmZzhd24xfu06wVs" Message-Id: <1093534034.26367.90.camel@galadriel.nofida.ch> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 26 Aug 2004 17:27:14 +0200 X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 3995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mdr@dotforge.ch Precedence: bulk X-list: linux-xfs Content-Length: 1335 Lines: 44 --=-QiyJpmZzhd24xfu06wVs Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Le jeu 26/08/2004 =E0 11:27, Federico Sevilla III a =E9crit : > Hi everyone, >=20 > I'd just like to find out if anyone has a working, stable system with a > Linux 2.4.x kernel, software RAID1, LVM1 and XFS. I remember reading > some bits on the mailing list about incompatibility with Software RAID5, > LVM and XFS, but I don't know about software RAID1. The reason I'm > interested in this is I plan to set up a server using software RAID1, > but don't want to create N arrays (where N is the number of partitions I > want to have), and of course, I'll be using XFS. works fine for me for 6 months: - 1 GB root partition, /dev/md0, ext3 - 1 partition for the rest /dev/md1 in a lvm1 vg with ext3 and xfs volume - 2.4.26 pretty vanilla=20 - smp box with 1 GB ram --=20 Marcel de Riedmatten --=-QiyJpmZzhd24xfu06wVs Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBBLgFSwEgIdc/nA8oRAkKSAJwIxd4ymND4AzL45puecp44ELSmiQCfZNb+ pw4+xX0heKh37zu8+70qsjc= =Mh9h -----END PGP SIGNATURE----- --=-QiyJpmZzhd24xfu06wVs-- From owner-linux-xfs Thu Aug 26 14:34:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Aug 2004 14:34:32 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7QLYSxC025764 for ; Thu, 26 Aug 2004 14:34:29 -0700 Received: by mproxy.gmail.com with SMTP id 75so154698rnl for ; Thu, 26 Aug 2004 14:34:21 -0700 (PDT) Received: by 10.38.92.30 with SMTP id p30mr2701022rnb; Thu, 26 Aug 2004 14:34:21 -0700 (PDT) Received: by 10.38.24.46 with HTTP; Thu, 26 Aug 2004 14:34:21 -0700 (PDT) Message-ID: <208fc95204082614344e3ff85c@mail.gmail.com> Date: Thu, 26 Aug 2004 23:34:21 +0200 From: Wenzel Jakob Reply-To: Wenzel Jakob To: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on vanilla kernel. In-Reply-To: <20040825213613.GA32082@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <208fc95204082512352ea7b9b9@mail.gmail.com> <208fc95204082512352ea7b9b9@mail.gmail.com> <20040825213613.GA32082@taniwha.stupidest.org> X-archive-position: 3996 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wazlaf@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 406 Lines: 10 Actually, I was running xfs_check and xfs_repair, I just called them fsck because that's what they do. Unfortunately, since I very much depend on the OpenGL performance, I cannot go without the NVidia drivers. The damage definitely stays after a reboot, it is nothing cache-related. If it is of any help, I have uploaded the output of xfs_check and xfs_repair to http://www.wazlaf.org/xfs Thanks, Wenzel From owner-linux-xfs Thu Aug 26 16:09:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Aug 2004 16:09:27 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7QN9NKT029181 for ; Thu, 26 Aug 2004 16:09:24 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7QN9F0f010785 for ; Thu, 26 Aug 2004 18:09:16 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7QN9EZO19381320; Thu, 26 Aug 2004 18:09:14 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1C0TMn-0006U5-00; Thu, 26 Aug 2004 18:09:13 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 920390 - generic_file_direct_write split Message-Id: From: Christoph Hellwig Date: Thu, 26 Aug 2004 18:09:13 -0500 X-archive-position: 3997 X-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: 463 Lines: 16 Date: Thu Aug 26 16:08:53 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: akpm@osdl.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:177836a include/linux/fs.h - 1.10 - add prototypes for generic_file_direct_write and generic_file_buffered_write mm/filemap.c - 1.12 - split generic_file_aio_write_nolock apart into buffered and direct I/O parts From owner-linux-xfs Fri Aug 27 00:24:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Aug 2004 00:24:31 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7R7OKi3020716 for ; Fri, 27 Aug 2004 00:24:21 -0700 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 i7R7Nw7X20975316; Fri, 27 Aug 2004 17:23:58 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7R7Nvld21140552; Fri, 27 Aug 2004 17:23:57 +1000 (EST) Date: Fri, 27 Aug 2004 17:23:57 +1000 (EST) From: Nathan Scott Message-Id: <200408270723.i7R7Nvld21140552@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 919705 - fix compiler warning X-archive-position: 3998 X-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: 339 Lines: 13 Fix compiler warning on IA64 builds in ioctl compat code. Date: Fri Aug 27 00:23:31 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: kaos@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:177850a linux-2.6/xfs_ioctl32.c - 1.2 From owner-linux-xfs Fri Aug 27 04:33:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Aug 2004 04:33:59 -0700 (PDT) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7RBXwjG003302 for ; Fri, 27 Aug 2004 04:33:58 -0700 Received: (qmail 24699 invoked by alias); 27 Aug 2004 11:33:50 -0000 Received: from unknown (HELO dellszerver.localdomain) (195.228.226.66) by 0 with SMTP; 27 Aug 2004 11:33:50 -0000 Subject: 64 bit linux xfs block size 16k From: Gabor Forgacs To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1093606760.2913.315.camel@dellszerver> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 Aug 2004 13:39:20 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 3999 X-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: 174 Lines: 8 Hi All, Is there a chance that the current 4k block size limitation can be avoided by using 16k pagesize on the 64 bit linux? Will it work on a cxfs san ? regards,gabor From owner-linux-xfs Fri Aug 27 10:25:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Aug 2004 10:25:42 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7RHPcmT005454 for ; Fri, 27 Aug 2004 10:25:40 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i7RIUvxQ022748 for ; Fri, 27 Aug 2004 11:30:57 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i7RHPTOV45977546; Fri, 27 Aug 2004 12:25:29 -0500 (CDT) Message-ID: <412F6E89.2040602@sgi.com> Date: Fri, 27 Aug 2004 12:25:29 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gabor Forgacs CC: linux-xfs@oss.sgi.com Subject: Re: 64 bit linux xfs block size 16k References: <1093606760.2913.315.camel@dellszerver> In-Reply-To: <1093606760.2913.315.camel@dellszerver> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4000 X-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: 566 Lines: 20 The filesytem block size limitation is that the block size must be <= page size. So, if you have a Linux box that supports 16k pages, then you can use up to 16k filesystem blocks on that machine. IA64 boxes do support 16k pages. Opteron machines don't. Regarding cxfs, you probably need to talk to your cxfs support folks about that. :) -Eric Gabor Forgacs wrote: > Hi All, > > Is there a chance that the current 4k block size > limitation can be avoided by using 16k pagesize > on the 64 bit linux? Will it work on a cxfs san ? > > regards,gabor > From owner-linux-xfs Sat Aug 28 11:37:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Aug 2004 11:37:41 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7SIbb4Z012047 for ; Sat, 28 Aug 2004 11:37:38 -0700 Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id i7SIbMHg006262 for ; Sat, 28 Aug 2004 20:37:23 +0200 (MEST) Received: by apps.cwi.nl id i7SIbM405948; Sat, 28 Aug 2004 20:37:22 +0200 (MEST) Date: Sat, 28 Aug 2004 20:37:22 +0200 (MEST) From: Message-Id: To: linux-xfs@oss.sgi.com Subject: setfattr comments X-archive-position: 4001 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Andries.Brouwer@cwi.nl Precedence: bulk X-list: linux-xfs Content-Length: 1276 Lines: 42 Three remarks: (i) # setfattr -x user.gat -v 12 /mnt/aa Usage: setfattr {-n name|-x name} [-v value] [-h] file... Try `setfattr --help' for more information. # setfattr -x user.gat /mnt/aa # The Usage: message is too complicated, and moreover wrong. Maybe make it Usage: setfattr -n name [-v value] [-h] file... or: setfattr -x name [-h] file... (ii) # getfattr -d /mnt/aa getfattr: Removing leading '/' from absolute path names # file: mnt/aa user.gut="abc" # It is unclear to me why getfattr has to tell me that it is going to print the name given without a slash. It seems silly - the working directory is nowhere near / or /mnt so this leading / is not at all superfluous, and mnt/aa denotes an entirely different file. (And it is not the name relative to the mountpoint either.) Probably this is a leftover from ancient times that should be removed. (Or is it an attempt to mimic tar?) (iii) The manpage tells me to send remarks to a.gruenbacher@computer.org or linux-xfs@oss.sgi.com, but the first address bounces. Andries By the way - is there improvement is the copyright situation? Last I asked I was still not permitted to distribute the section 2-7 manpages in the manpages package. [Requirement: page and modified versions can be distributed freely.] From owner-linux-xfs Sat Aug 28 22:52:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Aug 2004 22:53:01 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7T5qvij002419 for ; Sat, 28 Aug 2004 22:52:58 -0700 Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1C1IcT-00080j-F2; Sun, 29 Aug 2004 06:52:49 +0100 To: torvalds@osdl.org Subject: [PATCH] XFS #if abuses Cc: linux-xfs@oss.sgi.com Message-Id: From: viro@www.linux.org.uk Date: Sun, 29 Aug 2004 06:52:49 +0100 X-archive-position: 4002 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: viro@www.linux.org.uk Precedence: bulk X-list: linux-xfs Content-Length: 3163 Lines: 94 Signed-off-by: Al Viro ---- diff -urN RC9-rc1-bk4-pcm/fs/xfs/xfs_arch.h RC9-rc1-bk4-xfs/fs/xfs/xfs_arch.h --- RC9-rc1-bk4-pcm/fs/xfs/xfs_arch.h Sat Aug 14 03:46:32 2004 +++ RC9-rc1-bk4-xfs/fs/xfs/xfs_arch.h Sat Aug 28 23:21:33 2004 @@ -52,7 +52,7 @@ /* do we need conversion? */ #define ARCH_NOCONVERT 1 -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN # define ARCH_CONVERT 0 #else # define ARCH_CONVERT ARCH_NOCONVERT @@ -123,7 +123,7 @@ * now pick the right ones for our MACHINE ARCHITECTURE */ -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN #define INT_GET_UNALIGNED_16(pointer) INT_GET_UNALIGNED_16_LE(pointer) #define INT_SET_UNALIGNED_16(pointer,value) INT_SET_UNALIGNED_16_LE(pointer,value) #define INT_GET_UNALIGNED_32(pointer) INT_GET_UNALIGNED_32_LE(pointer) @@ -251,7 +251,7 @@ ) #else /* MACHINE ARCHITECTURE dependent */ -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN #define DIRINO_GET_ARCH(pointer,arch) \ DIRINO4_GET_ARCH((((__u8*)pointer)+4),arch) #else diff -urN RC9-rc1-bk4-pcm/fs/xfs/xfs_bmap_btree.h RC9-rc1-bk4-xfs/fs/xfs/xfs_bmap_btree.h --- RC9-rc1-bk4-pcm/fs/xfs/xfs_bmap_btree.h Tue Aug 24 10:38:11 2004 +++ RC9-rc1-bk4-xfs/fs/xfs/xfs_bmap_btree.h Sat Aug 28 23:21:38 2004 @@ -62,7 +62,7 @@ * l1:0-20 are blockcount. */ -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN #define BMBT_TOTAL_BITLEN 128 /* 128 bits, 16 bytes */ #define BMBT_EXNTFLAG_BITOFF 0 diff -urN RC9-rc1-bk4-pcm/fs/xfs/xfs_dir_leaf.h RC9-rc1-bk4-xfs/fs/xfs/xfs_dir_leaf.h --- RC9-rc1-bk4-pcm/fs/xfs/xfs_dir_leaf.h Mon May 5 03:28:10 2003 +++ RC9-rc1-bk4-xfs/fs/xfs/xfs_dir_leaf.h Sat Aug 28 23:21:44 2004 @@ -127,7 +127,7 @@ * Watch the order here (endian-ness dependent). */ struct { -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN xfs_dahash_t h; /* hash value */ __uint32_t be; /* block and entry */ #else /* __BYTE_ORDER == __BIG_ENDIAN */ diff -urN RC9-rc1-bk4-pcm/fs/xfs/xfs_log.h RC9-rc1-bk4-xfs/fs/xfs/xfs_log.h --- RC9-rc1-bk4-pcm/fs/xfs/xfs_log.h Wed Feb 4 05:23:21 2004 +++ RC9-rc1-bk4-xfs/fs/xfs/xfs_log.h Sat Aug 28 23:21:51 2004 @@ -32,7 +32,7 @@ #ifndef __XFS_LOG_H__ #define __XFS_LOG_H__ -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN #define LSN_FIELD_CYCLE(arch) (((arch)==ARCH_NOCONVERT)?1:0) #define LSN_FIELD_BLOCK(arch) (((arch)==ARCH_NOCONVERT)?0:1) #else diff -urN RC9-rc1-bk4-pcm/fs/xfs/xfs_log_priv.h RC9-rc1-bk4-xfs/fs/xfs/xfs_log_priv.h --- RC9-rc1-bk4-pcm/fs/xfs/xfs_log_priv.h Tue Aug 24 10:38:11 2004 +++ RC9-rc1-bk4-xfs/fs/xfs/xfs_log_priv.h Sat Aug 28 23:21:55 2004 @@ -112,7 +112,7 @@ * this has endian issues, of course. */ -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN #define GET_CLIENT_ID(i,arch) \ ((i) & 0xff) #else @@ -366,10 +366,10 @@ #define XLOG_FMT_IRIX_BE 3 /* our fmt */ -#if __BYTE_ORDER == __LITTLE_ENDIAN +#ifdef __LITTLE_ENDIAN #define XLOG_FMT XLOG_FMT_LINUX_LE #else -#if __BYTE_ORDER == __BIG_ENDIAN +#ifdef __BIG_ENDIAN #define XLOG_FMT XLOG_FMT_LINUX_BE #else #error unknown byte order From owner-linux-xfs Sun Aug 29 12:55:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 12:55:45 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7TJtgPC005846 for ; Sun, 29 Aug 2004 12:55:43 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1C1Vlz-0000od-3I; Sun, 29 Aug 2004 20:55:31 +0100 Date: Sun, 29 Aug 2004 20:55:30 +0100 From: Christoph Hellwig To: viro@www.linux.org.uk Cc: torvalds@osdl.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] XFS #if abuses Message-ID: <20040829205530.A3131@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from viro@www.linux.org.uk on Sun, Aug 29, 2004 at 06:52:49AM +0100 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4003 X-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: 19 Lines: 2 Looks fine to me. From owner-linux-xfs Sun Aug 29 13:24:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 13:24:32 -0700 (PDT) Received: from mail.mikehost.net ([69.9.160.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7TKOUdf007257 for ; Sun, 29 Aug 2004 13:24:30 -0700 Received: by mail.mikehost.net (Postfix, from userid 1001) id D3B537000F56B; Sun, 29 Aug 2004 13:24:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mikehost.net (Postfix) with ESMTP id D33919000F9CD for ; Sun, 29 Aug 2004 13:24:22 -0700 (PDT) Date: Sun, 29 Aug 2004 13:24:22 -0700 (PDT) From: mike X-X-Sender: mike@raid01.mikehost.net To: linux-xfs@oss.sgi.com Subject: Linux/XFS equivalents of defrag, chkdsk? Message-ID: mike: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 4004 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mike@mike2k.com Precedence: bulk X-list: linux-xfs Content-Length: 753 Lines: 21 I want to ensure that my filesystems are always optimized as well as be able to detect any possible filesystem-level issues ahead of time. I looked around the command line switches and manpages for the XFS and fsck commands, and could not find anything relevant. So I bring it to this mailing list: Are there Linux equivalents for the XFS filesystem for chkdsk (fsck -n seemed like the only possibility and it does not work) or defrag? Perhaps the way XFS runs, defrag is useless/not required. But it would be nice to be able to check filesystem consistency (while it's mounted, so it'd be read-only checking obviously) before something happens or while it's not in the process of booting the machine. Any help is appreciated. Thanks, mike From owner-linux-xfs Sun Aug 29 13:44:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 13:44:49 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7TKij7w009363 for ; Sun, 29 Aug 2004 13:44:47 -0700 Received: from taniwha.stupidest.org (adsl-63-202-174-89.dsl.snfc21.pacbell.net [63.202.174.89]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7TKiVK6084734; Sun, 29 Aug 2004 16:44:31 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id DCC3D115C874; Sun, 29 Aug 2004 13:44:30 -0700 (PDT) Date: Sun, 29 Aug 2004 13:44:30 -0700 From: Chris Wedgwood To: mike Cc: linux-xfs@oss.sgi.com Subject: Re: Linux/XFS equivalents of defrag, chkdsk? Message-ID: <20040829204430.GA11930@taniwha.stupidest.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 4005 X-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: 1182 Lines: 37 On Sun, Aug 29, 2004 at 01:24:22PM -0700, mike wrote: > Are there Linux equivalents for the XFS filesystem for chkdsk (fsck > -n seemed like the only possibility and it does not work) or defrag? yes and no xfs_repair can detect and repair damage for file-systems which are *not* in use xfs_fsr tries to reduce the fragmention of files there are not really the sane and windows chkdsk or defrag though > Perhaps the way XFS runs, defrag is useless/not required. file fragmentation shouldn't be a big issue with the exception of a a few applications / usage patterns (p2p applications are actually make this hard but that's true for all filesystems pretty much) > But it would be nice to be able to check filesystem consistency > (while it's mounted, so it'd be read-only checking obviously) can't really be done reliably, i guess you could snapshot, clone and check the clone, but it's really a hack > before something happens or while it's not in the process of booting > the machine. most people don't need to check the fs whilst it's mounted, file-system problems shouldn't occur that often if they are, something is wrong and it should be fixed --cw From owner-linux-xfs Sun Aug 29 13:45:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 13:46:02 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7TKjxRv009664 for ; Sun, 29 Aug 2004 13:45:59 -0700 Received: from [10.1.2.77] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id 47666252E1; Sun, 29 Aug 2004 14:45:40 -0600 (MDT) Date: Sun, 29 Aug 2004 14:45:59 -0600 From: Michael Loftis To: mike , linux-xfs@oss.sgi.com Subject: Re: Linux/XFS equivalents of defrag, chkdsk? Message-ID: <644FC18B61604F2740978BD3@[10.1.2.77]> In-Reply-To: References: X-Mailer: Mulberry/3.1.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-MailScanner-From: mloftis@wgops.com X-archive-position: 4006 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1981 Lines: 54 --On Sunday, August 29, 2004 13:24 -0700 mike wrote: > I want to ensure that my filesystems are always optimized as well as be > able to detect any possible filesystem-level issues ahead of time. > > I looked around the command line switches and manpages for the XFS and > fsck commands, and could not find anything relevant. > > So I bring it to this mailing list: > > Are there Linux equivalents for the XFS filesystem for chkdsk (fsck -n > seemed like the only possibility and it does not work) or defrag? > > Perhaps the way XFS runs, defrag is useless/not required. But it would be > nice to be able to check filesystem consistency (while it's mounted, so > it'd be read-only checking obviously) before something happens or while > it's not in the process of booting the machine. defrag was only really ever necessary on FAT and FAT32 systems. it can help NTFS some though. There arent' any defrag utils for most nix filesystems because they do a good job of keeping the fragmentation down below the 5% mark without any help. as far as chkdsk, again, unix this isn't necessary nor beneficial to run manually. XFS even less so. whent he system boots it takes a quick look at the state of the filesystems. if any need repairing it will do it on it's own, presuming they're listed in /etc/fstab. if not you can call the correct fsck for the filesytem you're using if you really want to, but it's not necessary. XFS journal's all transactions, so the only time you need to fsck it is when you have a bug, or a hardware error. besides that unix/linux filesystems, even the worst of them, are almost all universally more stable, and faster, than Windows and DOS variants. > > Any help is appreciated. > > Thanks, > mike > > > -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs Sun Aug 29 13:47:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 13:47:25 -0700 (PDT) Received: from mail.mikehost.net ([69.9.160.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7TKlNKO010019 for ; Sun, 29 Aug 2004 13:47:24 -0700 Received: by mail.mikehost.net (Postfix, from userid 1001) id BFF667000F56B; Sun, 29 Aug 2004 13:47:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mikehost.net (Postfix) with ESMTP id BF7A99000F9CD; Sun, 29 Aug 2004 13:47:15 -0700 (PDT) Date: Sun, 29 Aug 2004 13:47:15 -0700 (PDT) From: mike X-X-Sender: mike@raid01.mikehost.net To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Linux/XFS equivalents of defrag, chkdsk? In-Reply-To: <20040829204430.GA11930@taniwha.stupidest.org> Message-ID: References: <20040829204430.GA11930@taniwha.stupidest.org> mike: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 4007 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mike@mike2k.com Precedence: bulk X-list: linux-xfs Content-Length: 1625 Lines: 54 first off, thanks for the reply. On Sun, 29 Aug 2004, Chris Wedgwood wrote: > On Sun, Aug 29, 2004 at 01:24:22PM -0700, mike wrote: > >> Are there Linux equivalents for the XFS filesystem for chkdsk (fsck >> -n seemed like the only possibility and it does not work) or defrag? > > yes and no > > xfs_repair can detect and repair damage for file-systems which are > *not* in use > > xfs_fsr tries to reduce the fragmention of files > > there are not really the sane and windows chkdsk or defrag though > >> Perhaps the way XFS runs, defrag is useless/not required. > > file fragmentation shouldn't be a big issue with the exception of a a > few applications / usage patterns (p2p applications are actually make > this hard but that's true for all filesystems pretty much) > >> But it would be nice to be able to check filesystem consistency >> (while it's mounted, so it'd be read-only checking obviously) > > can't really be done reliably, i guess you could snapshot, clone and > check the clone, but it's really a hack > >> before something happens or while it's not in the process of booting >> the machine. > > most people don't need to check the fs whilst it's mounted, > file-system problems shouldn't occur that often > > if they are, something is wrong and it should be fixed > that's what i'm hoping to find BEFORE something bad happens. how come windows can check it's filesystems and/or defrag while it's in use, but linux can't? i don't get that. in summary, you're saying that if it's mounted, i'm SOL for doing any sort of filesystem optimizations or maintenance...? thanks - mike > > --cw > From owner-linux-xfs Sun Aug 29 14:24:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 14:25:02 -0700 (PDT) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7TLOwLs013432 for ; Sun, 29 Aug 2004 14:24:58 -0700 Received: from erbenson.alaska.net (66-230-89-58-dial-as3.nwc.acsalaska.net [66.230.89.58]) by iris.acsalaska.net (8.12.11/8.12.11) with ESMTP id i7TLOmCU074708 for ; Sun, 29 Aug 2004 13:24:49 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 04F5439B0 for ; Sun, 29 Aug 2004 13:24:47 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id E2DC540FF35; Sun, 29 Aug 2004 13:24:47 -0800 (AKDT) Date: Sun, 29 Aug 2004 13:24:47 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Linux/XFS equivalents of defrag, chkdsk? Message-ID: <20040829212447.GM951@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040829204430.GA11930@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zROEGoKAXsG5UqGB" Content-Disposition: inline In-Reply-To: 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-ACS-Scanned-By: MD 2.44; SA 2.64; spamdefang 1.108 X-archive-position: 4008 X-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: 1307 Lines: 48 --zROEGoKAXsG5UqGB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 01:47:15PM -0700, mike wrote: >=20 > that's what i'm hoping to find BEFORE something bad happens. XFS does much more internal checking then other filesystems. > how come windows can check it's filesystems and/or defrag while it's in= =20 > use, but linux can't? i don't get that. xfs_fsr runs on mounted filesystems, but its rarly necessary. as for checking, windows can't check a filesystem which is in use either, it tells you it will just mark it to be checked on next reboot. the reason is the checkers can only look at the on disk structures, which will not necessarily be correct at all times since the system is using it. > in summary, you're saying that if it's mounted, i'm SOL for doing any sor= t=20 > of filesystem optimizations or maintenance...? you don't need to. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --zROEGoKAXsG5UqGB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkEySZ8ACgkQJKx7GixEevxqMwCgoOBiwmor6UPpaVJbJrvmVT0J 24MAn2+G5EQepPkjgOb/ogPKJ0KT/PkR =fEvo -----END PGP SIGNATURE----- --zROEGoKAXsG5UqGB-- From owner-linux-xfs Sun Aug 29 14:49:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 14:49:39 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7TLnZnB014466 for ; Sun, 29 Aug 2004 14:49:35 -0700 Received: from taniwha.stupidest.org (adsl-63-202-174-89.dsl.snfc21.pacbell.net [63.202.174.89]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i7TLnGH9006320; Sun, 29 Aug 2004 17:49:16 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 536A1115C869; Sun, 29 Aug 2004 14:49:15 -0700 (PDT) Date: Sun, 29 Aug 2004 14:49:15 -0700 From: Chris Wedgwood To: mike Cc: linux-xfs@oss.sgi.com Subject: Re: Linux/XFS equivalents of defrag, chkdsk? Message-ID: <20040829214915.GA2229@taniwha.stupidest.org> References: <20040829204430.GA11930@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 4009 X-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: 1284 Lines: 37 On Sun, Aug 29, 2004 at 01:47:15PM -0700, mike wrote: > that's what i'm hoping to find BEFORE something bad happens. how can you find something BEFORE it happens? if it's BEFORE then nothing has gone wrong yet > how come windows can check it's filesystems and/or defrag while it's > in use, but linux can't? windows can't do a 100% check on a live fs last i checked, in suck cases it actually will do the check on boot this might have changed. the is also true for defrag. and as for this checking (and defrag), it requires various hooks that allow the application to lock parts of the device/filesystem down during the check --- and it only works for some filesystems not all in theory you could add similar things to linux but since it's not a 100% solution im not sure if it's really worth it btw, XFS *can* defrag a line filesystem > in summary, you're saying that if it's mounted, i'm SOL for doing > any sort of filesystem optimizations or maintenance...? no, i never said that you can defrag[1] XFS as mentioned previously and above and as for checking for errors, there are hacky ways to do this on a live filesystem im just not sure it's worth the effort in practise though since it's a lot of effort and work to deal with problems most people don't see --cw From owner-linux-xfs Sun Aug 29 17:34:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 17:34:12 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7U0Y7b3022121 for ; Sun, 29 Aug 2004 17:34:08 -0700 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 KAA05993; Mon, 30 Aug 2004 10:33:44 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7U0XXln3685736; Mon, 30 Aug 2004 10:33:37 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7U1ScCw001024; Mon, 30 Aug 2004 11:28:38 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7U1SS5s001022; Mon, 30 Aug 2004 11:28:28 +1000 Date: Mon, 30 Aug 2004 11:28:28 +1000 From: Nathan Scott To: agruen@suse.de, Andries.Brouwer@cwi.nl Cc: linux-xfs@oss.sgi.com Subject: Re: setfattr comments Message-ID: <20040830012828.GB883@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: 4010 X-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: 1632 Lines: 57 Hi Andries, I guess Andreas is the best one to answer these questions, as the original author of these tools and the man pages in question (current contact address above). cheers. On Sat, Aug 28, 2004 at 08:37:22PM +0200, Andries.Brouwer@cwi.nl wrote: > Three remarks: > > (i) > # setfattr -x user.gat -v 12 /mnt/aa > Usage: setfattr {-n name|-x name} [-v value] [-h] file... > Try `setfattr --help' for more information. > # setfattr -x user.gat /mnt/aa > # > > The Usage: message is too complicated, and moreover wrong. Maybe make it > Usage: setfattr -n name [-v value] [-h] file... > or: setfattr -x name [-h] file... > > (ii) > # getfattr -d /mnt/aa > getfattr: Removing leading '/' from absolute path names > # file: mnt/aa > user.gut="abc" > > # > > It is unclear to me why getfattr has to tell me that it > is going to print the name given without a slash. > It seems silly - the working directory is nowhere near > / or /mnt so this leading / is not at all superfluous, > and mnt/aa denotes an entirely different file. > (And it is not the name relative to the mountpoint either.) > > Probably this is a leftover from ancient times that should be removed. > (Or is it an attempt to mimic tar?) > > (iii) > The manpage tells me to send remarks to a.gruenbacher@computer.org > or linux-xfs@oss.sgi.com, but the first address bounces. > > Andries > > By the way - is there improvement is the copyright situation? > Last I asked I was still not permitted to distribute the section 2-7 > manpages in the manpages package. > [Requirement: page and modified versions can be distributed freely.] > > -- Nathan From owner-linux-xfs Sun Aug 29 21:52:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 21:52:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7U4q9jd031432 for ; Sun, 29 Aug 2004 21:52:10 -0700 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 OAA10407; Mon, 30 Aug 2004 14:51:52 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7U4pnln3689139; Mon, 30 Aug 2004 14:51:50 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7U5l0Cw001649; Mon, 30 Aug 2004 15:47:00 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7U5kvIO001647; Mon, 30 Aug 2004 15:46:58 +1000 Date: Mon, 30 Aug 2004 15:46:57 +1000 From: Nathan Scott To: viro@www.linux.org.uk, hch@lst.de Cc: torvalds@osdl.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] XFS #if abuses Message-ID: <20040830054657.GC883@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: 4011 X-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: 597 Lines: 19 On Sun, Aug 29, 2004 at 06:52:49AM +0100, viro@www.linux.org.uk wrote: > Signed-off-by: Al Viro This seems like unnecessary code churn to me. These macros are used in this way so that some XFS kernel headers are the same as the userspace equivalents, so that we don't end up maintaining diverged duplicate headers. The patch could go further and remove __BYTE_ORDER, not sure why that wasn't done. But, whatever, I'd prefer it isn't applied unless there's a compelling reason here that I've overlooked (eg, it actually fixes something?). thanks. -- Nathan From owner-linux-xfs Sun Aug 29 22:00:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 22:00:47 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7U50iJv032130 for ; Sun, 29 Aug 2004 22:00:45 -0700 Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1C1eHU-0005Ob-BG; Mon, 30 Aug 2004 06:00:36 +0100 Date: Mon, 30 Aug 2004 06:00:36 +0100 From: viro@parcelfarce.linux.theplanet.co.uk To: Nathan Scott Cc: viro@www.linux.org.uk, hch@lst.de, torvalds@osdl.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] XFS #if abuses Message-ID: <20040830050036.GH16297@parcelfarce.linux.theplanet.co.uk> References: <20040830054657.GC883@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830054657.GC883@frodo> User-Agent: Mutt/1.4.1i X-archive-position: 4012 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: viro@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 1181 Lines: 28 On Mon, Aug 30, 2004 at 03:46:57PM +1000, Nathan Scott wrote: > On Sun, Aug 29, 2004 at 06:52:49AM +0100, viro@www.linux.org.uk wrote: > > Signed-off-by: Al Viro > > This seems like unnecessary code churn to me. > > These macros are used in this way so that some XFS kernel > headers are the same as the userspace equivalents, so that > we don't end up maintaining diverged duplicate headers. > > The patch could go further and remove __BYTE_ORDER, not > sure why that wasn't done. But, whatever, I'd prefer it > isn't applied unless there's a compelling reason here > that I've overlooked (eg, it actually fixes something?). Ehh... a) #if where #ifdef would be enough b) use of (legitimate, but *ugly*) semantics of undefined identifiers in #if (they are replaced with 0, all right, but more often than not it's *not* the intended behaviour - same story as with assignment in conditional, etc.) I can kill __BYTE_ORDER and its users - gladly. But that's a separate series of patches (already have some done). Anyway, NAK is NAK. Linus, the rest of series is independent from this one, so just drop this patch - it won't affect others. From owner-linux-xfs Sun Aug 29 22:40:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Aug 2004 22:40:59 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7U5esuA000997 for ; Sun, 29 Aug 2004 22:40:56 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11268 for ; Mon, 30 Aug 2004 15:40:41 +1000 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i7U5Vndg002806 for ; Mon, 30 Aug 2004 15:31:49 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i7U5Vncx002805 for linux-xfs@oss.sgi.com; Mon, 30 Aug 2004 15:31:49 +1000 Date: Mon, 30 Aug 2004 15:31:49 +1000 From: FSG QA Message-Id: <200408300531.i7U5Vncx002805@bruce.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests X-archive-position: 4013 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 349 Lines: 14 Fix test 022 when used with -bsize=1024 and -isize=512; filtering problem. Date: Sun Aug 29 22:40:10 PDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:177939a xfstests/common.dump - 1.52 From owner-linux-xfs Mon Aug 30 00:34:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Aug 2004 00:34:42 -0700 (PDT) Received: from web53202.mail.yahoo.com (web53202.mail.yahoo.com [206.190.39.218]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7U7YauQ008251 for ; Mon, 30 Aug 2004 00:34:36 -0700 Message-ID: <20040830073422.28472.qmail@web53202.mail.yahoo.com> Received: from [203.199.164.2] by web53202.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 00:34:22 PDT Date: Mon, 30 Aug 2004 00:34:22 -0700 (PDT) From: Ash Subject: XFS recovery issues To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1605874743-1093851262=:25296" X-archive-position: 4014 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: my_qa2004@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 8066 Lines: 237 --0-1605874743-1093851262=:25296 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Hi I am using XFS with Linux 2.6.7 kernel on Redhat 8.0. xfsprogs version is 2.6.13. I was running a kind of crash test on an XFS filesystem to check recovery/corruptions from unclean shutdowns. The XFS filesystem sits on 18G partition. The test worked in the following manner: 20 dirs were created under the FS root directory. A sample program which repeatedly does a number of different operations like create,delete,link,read,write,rename etc was used to generate FS load. 20 threads of this program were spawned each working on one of the above 20 directories to generate heavy FS load. After about 5 minutes from the time the threads were spawned to build up the load a bit, the machine was crashed with a direct power-off. This cycle was repeated for about 200 times. After about 164 cycles, the filesystem usage reached 100% and further writes failed as expected. I had logged the dmesg outputs for each reboot cycle and all of them showed that XFS recovery did not face any problems. The message seen in each dmesg log was Starting XFS recovery on filesystem: cciss/c0d0p8 (dev: cciss/c0d0p8) Ending XFS recovery on filesystem: cciss/c0d0p8 (dev: cciss/c0d0p8 Upto this point, everything was fine with XFS recovering properly after each crash even after the filesystem was 100% full. Next, I deleted 10 of the 20 top level directories to free up some space. Here, in the "rm -rf" command for one of the directories, I noticed a hang. After sometime of inactivity, I rebooted the system (a clean reboot) and noticed that XFS recovery failed. The relevant sections of the boot messages are attached in xfs_bootup_failure.txt Next, I tried xfs_check. It basically printed a lot of "block 12/232064 type unknown not expected" messages and stopped responding too. I noticed a defunct xfs_db process on the system at this point. [root@mirahp1 root]# ps -aef | grep 1433 root 1433 1377 0 11:39 pts/1 00:00:00 /bin/sh -f /usr/sbin/xfs_check /dev/cciss/c0d0p8 root 1434 1433 0 11:39 pts/1 00:00:01 [xfs_db] After this, I tried xfs_repair. Following is the session trace [root@mirahp1 root]# xfs_repair /dev/cciss/c0d0p8 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. [root@mirahp1 root]# mount -t xfs /dev/cciss/c0d0p8 /xfs Segmentation fault xfs_repair with -L also results in a hang after this point. Any ideas whats going wrong ? Basically, its looking like my filesystem is inaccessible now. I am unable to mount it or run any repair on it. Any help will be appreciated. Thanks, Ash __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1605874743-1093851262=:25296 Content-Type: text/plain; name="xfs_bootup_failure.txt" Content-Description: xfs_bootup_failure.txt Content-Disposition: inline; filename="xfs_bootup_failure.txt" XFS mounting filesystem cciss/c0d0p8 Starting XFS recovery on filesystem: cciss/c0d0p8 (dev: cciss/c0d0p8) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4355 of file fs/xfs/xfs_bmap.c. Caller 0xc024aeaf [] xfs_bmap_read_extents+0x37d/0x520 [] xfs_iread_extents+0x9f/0x1a0 [] xfs_iread_extents+0x9f/0x1a0 [] __wake_up_locked+0x2a/0x30 [] xfs_bunmapi+0xf05/0xfa0 [] default_wake_function+0x0/0x20 [] __down_failed+0x8/0xc [] .text.lock.xfs_buf+0x37/0x49 [] pagebuf_iostart+0x6f/0xb0 [] xlog_grant_log_space+0x189/0x350 [] find_lock_page+0x2c/0xb0 [] xfs_trans_log_inode+0x2d/0x60 [] xfs_itruncate_finish+0x1e5/0x440 [] xfs_inactive+0x50a/0x570 [] xfs_itobp+0xfc/0x280 [] vn_rele+0x95/0xa0 [] linvfs_clear_inode+0x18/0x30 [] clear_inode+0xc6/0xe0 [] generic_delete_inode+0xe8/0x120 [] pagebuf_free+0x8a/0x110 [] iput+0x55/0x80 [] xlog_recover_process_iunlinks+0x320/0x3c0 [] xlog_recover_finish+0xa9/0xe0 [] xfs_log_mount_finish+0x2c/0x30 [] xfs_mountfs+0xa63/0xff0 [] xfs_setsize_buftarg+0x3c/0x80 [] xfs_ioinit+0x22/0x40 [] xfs_mount+0x2dd/0x400 [] vfs_mount+0x43/0x50 [] linvfs_fill_super+0x97/0x240 [] snprintf+0x27/0x30 [] disk_name+0x66/0xc0 [] sb_set_blocksize+0x25/0x60 [] get_sb_bdev+0x126/0x160 [] alloc_vfsmnt+0x85/0xc0 [] linvfs_get_sb+0x2f/0x40 [] linvfs_fill_super+0x0/0x240 [] do_kern_mount+0x5f/0xe0 [] do_add_mount+0x95/0x1a0 [] do_mount+0x170/0x1c0 [] copy_mount_options+0x78/0xc0 [] sys_mount+0xb1/0xe0 [] syscall_call+0x7/0xb Unable to handle kernel NULL pointer dereference at virtual address 000002f2 printing eip: c026447f *pde = 00000000 Oops: 0000 [#1] Modules linked in: usbcore CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010282 (2.6.7-mirahp1compiled30jul) EIP is at xfs_trans_brelse+0x1f/0x100 eax: 00000246 ebx: f4345504 ecx: c03e2af0 edx: 000023b7 esi: 00000000 edi: 00000246 ebp: f7fc7b38 esp: f36819c8 ds: 007b es: 007b ss: 0068 Process mount (pid: 517, threadinfo=f3680000 task=f77e9930) Stack: 0000000d c01061ec 00000000 00000000 f4345504 c02210f1 f4345504 00000246 00000000 c039c53c 00001103 c024aeaf f7fec340 eb89b36c f7fec338 f7d1102c 00000000 00000000 eb89b36c f77e9930 00000286 f3681a30 0000000d f7792c00 Call Trace: [] dump_stack+0x1c/0x20 [] xfs_bmap_read_extents+0x391/0x520 [] xfs_iread_extents+0x9f/0x1a0 [] xfs_iread_extents+0x9f/0x1a0 [] __wake_up_locked+0x2a/0x30 [] xfs_bunmapi+0xf05/0xfa0 [] default_wake_function+0x0/0x20 [] __down_failed+0x8/0xc [] .text.lock.xfs_buf+0x37/0x49 [] pagebuf_iostart+0x6f/0xb0 [] xlog_grant_log_space+0x189/0x350 [] find_lock_page+0x2c/0xb0 [] xfs_trans_log_inode+0x2d/0x60 [] xfs_itruncate_finish+0x1e5/0x440 [] xfs_inactive+0x50a/0x570 [] xfs_itobp+0xfc/0x280 [] vn_rele+0x95/0xa0 [] linvfs_clear_inode+0x18/0x30 [] clear_inode+0xc6/0xe0 [] generic_delete_inode+0xe8/0x120 [] pagebuf_free+0x8a/0x110 [] iput+0x55/0x80 [] xlog_recover_process_iunlinks+0x320/0x3c0 [] xlog_recover_finish+0xa9/0xe0 [] xfs_log_mount_finish+0x2c/0x30 [] xfs_mountfs+0xa63/0xff0 [] xfs_setsize_buftarg+0x3c/0x80 [] xfs_ioinit+0x22/0x40 [] xfs_mount+0x2dd/0x400 [] vfs_mount+0x43/0x50 [] linvfs_fill_super+0x97/0x240 [] snprintf+0x27/0x30 [] disk_name+0x66/0xc0 [] disk_name+0x66/0xc0 [] sb_set_blocksize+0x25/0x60 [] get_sb_bdev+0x126/0x160 [] alloc_vfsmnt+0x85/0xc0 [] linvfs_get_sb+0x2f/0x40 [] linvfs_fill_super+0x0/0x240 [] do_kern_mount+0x5f/0xe0 [] do_add_mount+0x95/0x1a0 [] do_mount+0x170/0x1c0 [] copy_mount_options+0x78/0xc0 [] sys_mount+0xb1/0xe0 [] syscall_call+0x7/0xb Code: 8b b7 ac 00 00 00 89 1c 24 89 74 24 04 e8 cf 0a 00 00 89 c2 --0-1605874743-1093851262=:25296-- From owner-linux-xfs Mon Aug 30 00:55:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Aug 2004 00:55:33 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7U7tTEb010399 for ; Mon, 30 Aug 2004 00:55:30 -0700 Received: from [10.1.2.77] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id 148792546E; Mon, 30 Aug 2004 01:55:01 -0600 (MDT) Date: Mon, 30 Aug 2004 01:55:28 -0600 From: Michael Loftis To: Ash , linux-xfs@oss.sgi.com Subject: Re: XFS recovery issues Message-ID: In-Reply-To: <20040830073422.28472.qmail@web53202.mail.yahoo.com> References: <20040830073422.28472.qmail@web53202.mail.yahoo.com> X-Mailer: Mulberry/3.1.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-MailScanner-From: mloftis@wgops.com X-archive-position: 4015 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 3840 Lines: 124 Uhm, what do you expect, you tried to break it and suceeded. Any box treated like that in production will need to be seriously rethought as to what/how it should be implemented. --On Monday, August 30, 2004 00:34 -0700 Ash wrote: > Hi > > I am using XFS with Linux 2.6.7 kernel on Redhat 8.0. > xfsprogs version is 2.6.13. > > I was running a kind of crash test on an XFS > filesystem to check recovery/corruptions from unclean > shutdowns. > > The XFS filesystem sits on 18G partition. The test > worked in the following manner: > 20 dirs were created under the FS root directory. A > sample program which repeatedly does a number of > different operations like > create,delete,link,read,write,rename etc was used to > generate FS load. 20 threads of this program were > spawned each working on one of the above 20 > directories to generate heavy FS load. > After about 5 minutes from the time the threads were > spawned to build up the load a bit, the machine was > crashed with a direct power-off. > This cycle was repeated for about 200 times. > > After about 164 cycles, the filesystem usage reached > 100% and further writes failed as expected. I had > logged the dmesg outputs for each reboot cycle > and all of them showed that XFS recovery did not face > any problems. The message seen in each dmesg log was > > > > Starting XFS recovery on filesystem: cciss/c0d0p8 > (dev: cciss/c0d0p8) > Ending XFS recovery on filesystem: cciss/c0d0p8 (dev: > cciss/c0d0p8 > > > > Upto this point, everything was fine with XFS > recovering properly after each crash even after the > filesystem was 100% full. > > Next, I deleted 10 of the 20 top level directories to > free up some space. > Here, in the "rm -rf" command for one of the > directories, I noticed a hang. > After sometime of inactivity, I rebooted the system (a > clean reboot) and noticed > that XFS recovery failed. The relevant sections of the > boot messages are attached in xfs_bootup_failure.txt > > Next, I tried xfs_check. It basically printed a lot of > "block 12/232064 type unknown not expected" messages > and stopped responding too. I noticed a defunct xfs_db > process on the system at this point. > > > [root@mirahp1 root]# ps -aef | grep 1433 > root 1433 1377 0 11:39 pts/1 00:00:00 > /bin/sh -f /usr/sbin/xfs_check /dev/cciss/c0d0p8 > root 1434 1433 0 11:39 pts/1 00:00:01 > [xfs_db] > > > > After this, I tried xfs_repair. Following is the > session trace > > > > [root@mirahp1 root]# xfs_repair /dev/cciss/c0d0p8 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > ERROR: The filesystem has valuable metadata changes in > a log which needs to > be replayed. Mount the filesystem to replay the log, > and unmount it before > re-running xfs_repair. If you are unable to mount the > filesystem, then use > the -L option to destroy the log and attempt a repair. > Note that destroying the log may cause corruption -- > please attempt a mount > of the filesystem before doing this. > > [root@mirahp1 root]# mount -t xfs /dev/cciss/c0d0p8 > /xfs > Segmentation fault > > > > xfs_repair with -L also results in a hang after this > point. > > Any ideas whats going wrong ? > Basically, its looking like my filesystem is > inaccessible now. > I am unable to mount it or run any repair on it. > > Any help will be appreciated. > > Thanks, > Ash > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs Mon Aug 30 02:31:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Aug 2004 02:32:02 -0700 (PDT) Received: from zero.aec.at (M_P_Nopput@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7U9VvI3014754 for ; Mon, 30 Aug 2004 02:31:58 -0700 Received: from averell.firstfloor.org.muc.de (Bootle_P_Gish@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i7U9Vgg14886; Mon, 30 Aug 2004 11:31:47 +0200 To: Ash cc: linux-xfs@oss.sgi.com Subject: Re: XFS recovery issues References: <20040830073422.28472.qmail@web53202.mail.yahoo.com> From: Andi Kleen Date: Mon, 30 Aug 2004 11:31:35 +0200 In-Reply-To: <20040830073422.28472.qmail@web53202.mail.yahoo.com> (my_qa2004@yahoo.com's message of "Mon, 30 Aug 2004 00:34:22 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4016 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 490 Lines: 19 Ash writes: > After about 5 minutes from the time the threads were > spawned to build up the load a bit, the machine was > crashed with a direct power-off. > This cycle was repeated for about 200 times. [...] Did you explicitely turn off the write caches in your hard disks? Without that it is unlikely that any fs will survive such a test for long, because it cannot trust the write ordering. However the fs arguably should error out later, not hang. -Andi From owner-linux-xfs Mon Aug 30 05:31:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Aug 2004 05:31:53 -0700 (PDT) Received: from web53206.mail.yahoo.com (web53206.mail.yahoo.com [206.190.39.222]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7UCVnfE024909 for ; Mon, 30 Aug 2004 05:31:50 -0700 Message-ID: <20040830123133.92258.qmail@web53206.mail.yahoo.com> Received: from [203.199.164.2] by web53206.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 05:31:33 PDT Date: Mon, 30 Aug 2004 05:31:33 -0700 (PDT) From: Ash Subject: Re: XFS recovery issues To: Michael Loftis , linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4017 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: my_qa2004@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 624 Lines: 27 > Uhm, what do you expect, you tried to break it and > suceeded. Any box > treated like that in production will need to be > seriously rethought as to > what/how it should be implemented. > Agreed. Although my concern is not in the number of cycles the test was run. What bothers me is that this could have very well happened in the first couple of crashes as well. I just wanted to make sure that there wasn't some obvious problem lurking here and hence the post. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-linux-xfs Mon Aug 30 17:34:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Aug 2004 17:34:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7V0YV5r030728 for ; Mon, 30 Aug 2004 17:34:32 -0700 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 KAA01363; Tue, 31 Aug 2004 10:34:16 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i7V0YEln3713976; Tue, 31 Aug 2004 10:34:15 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i7V1TNCw004719; Tue, 31 Aug 2004 11:29:23 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i7V1TMFq004717; Tue, 31 Aug 2004 11:29:22 +1000 Date: Tue, 31 Aug 2004 11:29:22 +1000 From: Nathan Scott To: Ash Cc: linux-xfs@oss.sgi.com Subject: Re: XFS recovery issues Message-ID: <20040831012922.GD1942@frodo> References: <20040830073422.28472.qmail@web53202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830073422.28472.qmail@web53202.mail.yahoo.com> User-Agent: Mutt/1.5.3i X-archive-position: 4018 X-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: 2321 Lines: 77 On Mon, Aug 30, 2004 at 12:34:22AM -0700, Ash wrote: > Hi > > I was running a kind of crash test on an XFS > filesystem to check recovery/corruptions from unclean > shutdowns. > ... > logged the dmesg outputs for each reboot cycle > and all of them showed that XFS recovery did not face > any problems. The message seen in each dmesg log was > > Starting XFS recovery on filesystem: cciss/c0d0p8 > (dev: cciss/c0d0p8) > Ending XFS recovery on filesystem: cciss/c0d0p8 (dev: > cciss/c0d0p8 Hmm, we should fix that dup'd device name (looks like you're running a debug version of XFS here...?) > Here, in the "rm -rf" command for one of the > directories, I noticed a hang. A kdb backtrace at this point would have been useful (in case you see it again). > After sometime of inactivity, I rebooted the system (a > clean reboot) and noticed > that XFS recovery failed. The relevant sections of the > boot messages are attached in xfs_bootup_failure.txt > > Next, I tried xfs_check. It basically printed a lot of > "block 12/232064 type unknown not expected" messages > and stopped responding too. I noticed a defunct xfs_db > process on the system at this point. That would be due to not yet running log recovery. More recent versions of xfs_check now act like repair, and wont run on a filesystem with a dirty log. > xfs_repair with -L also results in a hang after this > point. > > Any ideas whats going wrong ? > Basically, its looking like my filesystem is > inaccessible now. > I am unable to mount it or run any repair on it. If you can't even repair, looks like the device has got into a funny state (repair talks directly to the device). I'd reboot to try clear that up, then run repair with -L again see if that resolves it. If repair still hangs, kdb will be of use - get a backtrace on the hung repair process. > Unable to handle kernel NULL pointer dereference at virtual address 000002f2 > printing eip: > c026447f > *pde = 00000000 > Oops: 0000 [#1] > Modules linked in: usbcore > CPU: 0 > EIP: 0060:[] Not tainted > EFLAGS: 00010282 (2.6.7-mirahp1compiled30jul) > EIP is at xfs_trans_brelse+0x1f/0x100 There's a couple of known use-after-free bugs related to forced filesystem shutdown, I suspect thats what you're hitting here where it oops'd. HTH. cheers. -- Nathan From owner-linux-xfs Mon Aug 30 17:57:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Aug 2004 17:57:54 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7V0vp0K031967 for ; Mon, 30 Aug 2004 17:57:51 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7V0vpmX031966 for linux-xfs@oss.sgi.com; Mon, 30 Aug 2004 17:57:51 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7V0vnil031952 for ; Mon, 30 Aug 2004 17:57:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7V0RTg1030606; Mon, 30 Aug 2004 17:27:29 -0700 Date: Mon, 30 Aug 2004 17:27:29 -0700 Message-Id: <200408310027.i7V0RTg1030606@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 358] New: XFS 1.3 and 1.3.1 leave FS corrupted after crash/reboot X-Bugzilla-Reason: AssignedTo X-archive-position: 4019 X-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: 2863 Lines: 66 http://oss.sgi.com/bugzilla/show_bug.cgi?id=358 Summary: XFS 1.3 and 1.3.1 leave FS corrupted after crash/reboot Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: mbellon@mvista.com I've got a problem that occurs on what, even after a lot of testing, appears to be a single platform, an ATI 22[56] (MIPS with EIDE), which makes me uneasy that this is a platform bug. However much analysis and test has been thrown at the platform and we cannot find anything wrong with the processor, memory, DMA, EIDE or disk drives. XFS is running on MV PRO 3.1 (2.4.20++). Make a default file system (mkfs.xfs 2.5.11). Mount it and run a file system stress program (reads and writes files, creates and deletes directories) - we can provide it. Reset machine in the middle of the program running and reboot. Mount the file system; log replays and file system is corrupted 100% of the time (hundreds of tests so far). What we see is one of the test directories is corrupt - it has no "." or ".." but you can cd into it and "cd .." out of it. Attempt to create a file via touch and: root@192.168.1.60:/mnt/test6# touch foo xfs_da_do_buf: bno 8388608 dir: inode 50331776 Filesystem "ide0(3,1)": XFS internal error xfs_da_do_buf(1) at line 2187 of file xfs_da_btree.c. Caller 0x801b1404 This architecture does not implement dump_stack() xfs_da_do_buf: bno 8388608 dir: inode 50331776 Filesystem "ide0(3,1)": XFS internal error xfs_da_do_buf(1) at line 2187 of file xfs_da_btree.c. Caller 0x801b1404 This architecture does not implement dump_stack() touch: creating `foo': Unknown error 990 No XFS parameters appear to affect the problem. Neither does the size of the file system (10 GB, 40 GB and 160 GB). Problem does not show running same kernel source on X86, PPC and other MIPS platforms. Every block device test passes on all platforms including the ATI 22[56] - buffer layer seems OK. EXT3 passes this test 100% of the time on all platforms. Use xfs_repair and have it forget the log (-L) and the file system is OK, the corrupted directory is gone and there are a few files in lost+found. The test program deletes a great many files and then the directory quite often. Since no problem is too trivial I report this hoping that there may be something that can be shared or remembered. Is there a program to dump a log from user space directly from a disk partition? Any debugging ideas? sorry to bother you but I'm running out of things to try and learning XFS internals is taking a lot of time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Aug 30 18:57:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Aug 2004 18:57:53 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7V1vper002065 for ; Mon, 30 Aug 2004 18:57:51 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7V1vpiB002064 for linux-xfs@oss.sgi.com; Mon, 30 Aug 2004 18:57:51 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7V1vopI002048 for ; Mon, 30 Aug 2004 18:57:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i7V1AdTr032666; Mon, 30 Aug 2004 18:10:39 -0700 Date: Mon, 30 Aug 2004 18:10:39 -0700 Message-Id: <200408310110.i7V1AdTr032666@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 358] XFS 1.3 and 1.3.1 leave FS corrupted after crash/reboot X-Bugzilla-Reason: AssignedTo X-archive-position: 4020 X-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: 680 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=358 ------- Additional Comments From nathans@sgi.com 2004-30-08 18:10 PDT ------- | which makes me uneasy that this is a platform bug. Yes, my #1 thought is "compiler bug"; have you tried different versions of gcc to try and rule that out? XFS does alot of 64 bit number manipulation and compilers have been the cause of several problems in the past. > Is there a program to dump a log from user > space directly from a disk partition? Recent versions of xfs_logprint have that capability, yes. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 31 04:22:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 04:23:02 -0700 (PDT) Received: from web53208.mail.yahoo.com (web53208.mail.yahoo.com [206.190.39.224]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i7VBMwbn012521 for ; Tue, 31 Aug 2004 04:22:58 -0700 Message-ID: <20040831111039.43539.qmail@web53208.mail.yahoo.com> Received: from [203.199.164.2] by web53208.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 04:10:39 PDT Date: Tue, 31 Aug 2004 04:10:39 -0700 (PDT) From: Ash Subject: Re: XFS recovery issues To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040831012922.GD1942@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4021 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: my_qa2004@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1229 Lines: 52 > If you can't even repair, looks like the device has > got > into a funny state (repair talks directly to the > device). > I'd reboot to try clear that up, then run repair > with -L > again see if that resolves it. Yes it did. After a clean reboot, xfs_check and xfs_repair -L worked fine. I was able to repair and mount my filesystem and broadly my data seemed to look ok. > > Unable to handle kernel NULL pointer dereference > at virtual address 000002f2 > > printing eip: > > c026447f > > *pde = 00000000 > > Oops: 0000 [#1] > > Modules linked in: usbcore > > CPU: 0 > > EIP: 0060:[] Not tainted > > EFLAGS: 00010282 (2.6.7-mirahp1compiled30jul) > > EIP is at xfs_trans_brelse+0x1f/0x100 > > There's a couple of known use-after-free bugs > related to forced > filesystem shutdown, I suspect thats what you're > hitting here > where it oops'd. > I didn't quite get this. Are you suggesting that this is a known issue with the 2.6 kernel or with XFS ? Are there any known bugs already logged against similar issues ? Thanks for all your help. Ash _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-linux-xfs Tue Aug 31 06:16:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 06:16:49 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i7VDGjx9018308 for ; Tue, 31 Aug 2004 06:16:46 -0700 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 i7VDGRxu194349; Tue, 31 Aug 2004 23:16:27 +1000 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i7VDGQ72194121; Tue, 31 Aug 2004 23:16:26 +1000 (EST) Date: Tue, 31 Aug 2004 23:16:26 +1000 (EST) From: Timothy Shimmin Message-Id: <200408311316.i7VDGQ72194121@snort.melbourne.sgi.com> To: sgi.bugs.kudzu@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 920426 - xlog recovery failure on pre-v2-log xfs X-archive-position: 4023 X-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: 538 Lines: 18 Fix problem for case where v1 log is created on a recent xfs kernel (from Feb 27, 2004 onwards) and its a dirty log (not a clean unmount) and now trying to replay this log on an old xfs kernel (prior to Dec 2, 2002 when v2 logs went in). fix up h_len for v1 logs Date: Tue Aug 31 06:08:52 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-linux Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:178055a xfs_log.c - 1.300 From owner-linux-xfs Tue Aug 31 17:03:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 17:03:17 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8103Dsv017692 for ; Tue, 31 Aug 2004 17:03:14 -0700 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 KAA28336; Wed, 1 Sep 2004 10:02:56 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i8102sln3741977; Wed, 1 Sep 2004 10:02:55 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i8102rOW3741668; Wed, 1 Sep 2004 10:02:53 +1000 (EST) Date: Wed, 1 Sep 2004 10:02:53 +1000 From: Nathan Scott To: Ash Cc: linux-xfs@oss.sgi.com Subject: Re: XFS recovery issues Message-ID: <20040901100253.H3083077@wobbly.melbourne.sgi.com> References: <20040831012922.GD1942@frodo> <20040831111039.43539.qmail@web53208.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040831111039.43539.qmail@web53208.mail.yahoo.com>; from my_qa2004@yahoo.com on Tue, Aug 31, 2004 at 04:10:39AM -0700 X-archive-position: 4024 X-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: 393 Lines: 19 On Tue, Aug 31, 2004 at 04:10:39AM -0700, Ash wrote: > > > There's a couple of known use-after-free bugs > > related to forced > > filesystem shutdown, I suspect thats what you're > > hitting here > > where it oops'd. > > > > I didn't quite get this. Are you suggesting that this > is a known issue with the 2.6 kernel or with XFS ? This one would be an XFS problem. cheers. -- Nathan From owner-linux-xfs Tue Aug 31 19:57:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 19:57:58 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i812vuDt023002 for ; Tue, 31 Aug 2004 19:57:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i812vuwD022999 for linux-xfs@oss.sgi.com; Tue, 31 Aug 2004 19:57:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i812vtdM022972 for ; Tue, 31 Aug 2004 19:57:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i812pnBC022838; Tue, 31 Aug 2004 19:51:49 -0700 Date: Tue, 31 Aug 2004 19:51:49 -0700 Message-Id: <200409010251.i812pnBC022838@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 326] xfs_repair failing to repair corrupted dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 4025 X-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: 808 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=326 bernd@zeimetz.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |critical ------- Additional Comments From bernd@zeimetz.de 2004-31-08 19:49 PDT ------- Created an attachment (id=135) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=135&action=view) log of xfs_repair, version from CVS ------- Additional Comments From bernd@zeimetz.de 2004-31-08 19:50 PDT ------- Created an attachment (id=136) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=136&action=view) log of xfs_check ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 31 19:57:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 19:58:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i812vuJ4023001 for ; Tue, 31 Aug 2004 19:57:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i812vuY5023000 for linux-xfs@oss.sgi.com; Tue, 31 Aug 2004 19:57:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i812vtdQ022972 for ; Tue, 31 Aug 2004 19:57:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i812m0H5022755; Tue, 31 Aug 2004 19:48:00 -0700 Date: Tue, 31 Aug 2004 19:48:00 -0700 Message-Id: <200409010248.i812m0H5022755@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 326] xfs_repair failing to repair corrupted dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 4026 X-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: 955 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=326 bernd@zeimetz.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Priority|Medium |High Version|unspecified |Current ------- Additional Comments From bernd@zeimetz.de 2004-31-08 19:47 PDT ------- same problem with the latest xfs_repair from CVS, just gives a little bit different error. Tried it after xfs_repair 2.6.20 produced the same error as mentioned before. Kernel 2.6.9-rc1 is able to mount the filesystem (i didn't want to try writing...), reading works well. I'll attach the output of xfs_check and xfs_reapir. If you need some more info, just ask. Bernd ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 31 20:57:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 20:58:00 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i813vuar027915 for ; Tue, 31 Aug 2004 20:57:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i813vusl027914 for linux-xfs@oss.sgi.com; Tue, 31 Aug 2004 20:57:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i813vt9t027894 for ; Tue, 31 Aug 2004 20:57:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i81361wP023783; Tue, 31 Aug 2004 20:06:01 -0700 Date: Tue, 31 Aug 2004 20:06:01 -0700 Message-Id: <200409010306.i81361wP023783@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 326] xfs_repair failing to repair corrupted dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 4027 X-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: 1264 Lines: 34 http://oss.sgi.com/bugzilla/show_bug.cgi?id=326 bernd@zeimetz.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernd@zeimetz.de ------- Additional Comments From bernd@zeimetz.de 2004-31-08 20:06 PDT ------- btw.: i can't reproduce how the damage to the filesystem could happen, it was cleanly unmounted, after mounting it again there were some not really existing files, they were found but it was not possible to get any data from them. But xfs_repair corrected that allready. meta-data=/mnt/maxtor/xfs isize=256 agcount=16, agsize=2947425 blks = sectsz=512 data = bsize=4096 blocks=47158800, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=23026, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Aug 31 21:06:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 21:06:57 -0700 (PDT) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8146s4F028436 for ; Tue, 31 Aug 2004 21:06:55 -0700 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Tue, 31 Aug 2004 23:06:43 -0500 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 23:06:40 -0500 Message-ID: From: Joe Eiler To: "'linux-xfs@oss.sgi.com'" Date: Tue, 31 Aug 2004 23:06:37 -0500 Subject: Oops when running xfs_fsr MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 4028 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeiler@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 2627 Lines: 68 I am getting an Oops when running xfs_fsr. The only way I can get it to disappear is to turn on debugging in the kernel ;-) From my limited stack tracing abilities it doesn't look like and xfs problem but I can't reproduce it anyother way than with xfs_fsr. I have reliably reproduced the problem on 3 different machines running 2.6.7, 2.6.8.1 (from kernel.org) Most of the rest of the system is fedora core2 rpms. I already tried the latest xfs-cmds from cvs. (xfs is latest from cvs also) When I get the Oops, the system is locked up and nothing gets saved to the logs.(So I am taking the Oops off the screen by hand ;-( Oh, kernel is tainted due to imq module but I tried it once without imq loaded. Some config info. local ide harddrive is formatted with reiserfs my data volume is on a 12drive 3ware controller(lvm on two 6 drive raid 10s) and is formated with xfs with an external log. #xfs_fsr /base/d0 /base/d0 start inode = 0 Unable to handle kernel NULL pointer dereference at virtual address 00000005 printing eip: c01c0eab *pde = 00000000 Oops: 0002 [#1] SMP Modules linked in: xfs_quota xfs nfsd exportfs lockd raw imq sg sunrpc e1000 uhci_hcd usbcore thermal processor fan button dm_mod 3w_xxxx sd_mod scsi_mod CPU: 0 EIP: 0060[] Tainted: P EFLAGS: 00010282 (2.6.8.1) EIP is at reiserfs_add_ordered_list+0x4b/0xd0 eax: f41b9088 ebx: f41b9080 ecx: f41b908c edx: 00000001 esi: e7a19590 edi: f8b4b000 ebp: f7fe7e00 esp: f49ffdb4 ds: 007b es: 007b ss: 0068 Process hydra (pid:1242, threadinfo=f499e000 task=f51a8bf0) Stack: 00000001 e7a19590 00001000 c01aa96c f35a8750 e7a19590 00000000 00000001 00000000 00000000 e7a19590 00001000 00000000 f77c7590 0000001f f6a27660 00000036 00000000 00000014 00000000 00000000 00000115 00000115 00000000 Call Trace: reiserfs_commit_page+0x18c/0x260 reiserfs_submit_file_region_for_write+0x7b/0x320 reiserfs_file_write+0x54b/0x7a0 do_no_page+0x6c/0x280 __vma_link+0x44/0x80 do_page_fault+0x18b/0x593 do_mmap_pgoff+0x3fa/0x710 vfs_write+0xb8/0x140 sys_write+0x51/0x80 sysenter_past_esp+0x52/0x71 code 89 4a 04 89 11 89 40 04 89 43 08 8b 87 b4 00 00 00 8d 53 08 The process will change frequently (this one is my custom app, but I have seen it do with sed, sdt, kswapd, etc.) It looks like more of the times the apps are trying to write to the local disk(duh!) The Call trace always takes one of two paths, the one in the above oops and the other through reiserfs_get_block Tomorrow, I'll try to move the console to a serial port so I can catch the Oops directly. If you got this far through my message, thanks for hanging in there, Joe From owner-linux-xfs Tue Aug 31 21:28:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Aug 2004 21:28:27 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i814SO8G029450 for ; Tue, 31 Aug 2004 21:28:25 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA03573 for ; Wed, 1 Sep 2004 14:28:09 +1000 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i814FQbJ006146 for ; Wed, 1 Sep 2004 14:15:27 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i814FQq4006145 for linux-xfs@oss.sgi.com; Wed, 1 Sep 2004 14:15:26 +1000 Date: Wed, 1 Sep 2004 14:15:26 +1000 From: FSG QA Message-Id: <200409010415.i814FQq4006145@bruce.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests X-archive-position: 4029 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 424 Lines: 15 Add a test program which just dumps out device size as mkfs would see it. Makes finger-pointing at buggy drivers easier. Date: Tue Aug 31 21:27:46 PDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:178146a xfstests/src/getdevicesize.c - 1.1 xfstests/src/Makefile - 1.30