From owner-linux-xfs Wed Dec 1 08:04:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Dec 2004 08:04:41 -0800 (PST) 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 iB1G4XFk013532 for ; Wed, 1 Dec 2004 08:04:38 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iB1HNsL3002175 for ; Wed, 1 Dec 2004 09:23:55 -0800 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 iB1G41am3242462; Wed, 1 Dec 2004 10:04:01 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CZWxV-0006AW-00; Wed, 01 Dec 2004 10:04:01 -0600 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 923968 - Message-Id: From: Christoph Hellwig Date: Wed, 01 Dec 2004 10:04:01 -0600 X-archive-position: 4571 X-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 Avoid inode generation 0, it's used as wildcard by NFSD Date: Wed Dec 1 08:03:30 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: tes,nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:183616a fs/xfs/xfs_ialloc.c - 1.176 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.176&r2=text&tr2=1.175&f=h - start with di_gen = 1 for newly allocated inode clusters fs/xfs/xfs_inode.c - 1.407 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.407&r2=text&tr2=1.406&f=h - make sure we skip inode generation 0 in both xfs_ifree (wraparound) and xfs_iread (old inodes on disk) From owner-linux-xfs Wed Dec 1 12:12:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Dec 2004 12:12:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1KC0hF028317 for ; Wed, 1 Dec 2004 12:12:00 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB1KC0cu028315 for linux-xfs@oss.sgi.com; Wed, 1 Dec 2004 12:12:00 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1KBwi9028288 for ; Wed, 1 Dec 2004 12:11:58 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB1K0Tc8024961; Wed, 1 Dec 2004 12:00:29 -0800 Date: Wed, 1 Dec 2004 12:00:29 -0800 Message-Id: <200412012000.iB1K0Tc8024961@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 391] New: unable to copy a 25GB-file from xfs X-Bugzilla-Reason: AssignedTo X-archive-position: 4573 X-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: 1585 Lines: 46 http://oss.sgi.com/bugzilla/show_bug.cgi?id=391 Summary: unable to copy a 25GB-file from xfs Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: Henning.Rohde@uni-bayreuth.de trying to backup the filesystem that is dedicated to vmware, i'm unable to get a funktionable copy of the vmware-diskimage: vmware dislikes the copy, md5sums differ between source and destination there's no difference how the disk-image was copied: - "xfs_copy /dev/$sourcepart /dev/$destpart" - "xfsdump $source-mountpoint | xfsrestore $dest-mountpoint" - "cp -a /path/to/$sourcefile /path/to/$destfile" - "cat /path/to/$sourcefile > /path/to/$destfile"" - "tar -cf - ./$sourcefile | (cd $dest-mountpoint ; tar -xf - )" xfs_check and xfs_repair are unable to find any problem on the source-partition, the same on the dest-partition in the case the partition was backup'ed with xfs_copy or "xfsdump|xfsrestore". a binary copy with "/bin/dd if=/dev/$sourcepart of=/dev/$destpart bs=1024" results in an usable copy on the dest-partition the source-filesystem was created at installing SuSEv9.1 with fix from http://portal.suse.com/sdb/en/2004/04/91_xfsfix.html, for further details see BugID 391 thanks for help in advance, Henning Rohde ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Dec 1 12:12:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Dec 2004 12:12:05 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1KC0wb028318 for ; Wed, 1 Dec 2004 12:12:00 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB1KC07B028316 for linux-xfs@oss.sgi.com; Wed, 1 Dec 2004 12:12:00 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1KBwiD028288 for ; Wed, 1 Dec 2004 12:11:59 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB1JcmYC024070; Wed, 1 Dec 2004 11:38:48 -0800 Date: Wed, 1 Dec 2004 11:38:48 -0800 Message-Id: <200412011938.iB1JcmYC024070@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 390] New: xfs_copy produces corrupt copy X-Bugzilla-Reason: AssignedTo X-archive-position: 4574 X-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: 2002 Lines: 60 http://oss.sgi.com/bugzilla/show_bug.cgi?id=390 Summary: xfs_copy produces corrupt copy Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: Henning.Rohde@uni-bayreuth.de making a backup of my 17GB-/home-filesystem with xfs_copy to another partition results in a corrupt filesystem on the second hd. Source-filesystems were created on installing SuSEv9.1 with fix from http://portal.suse.com/sdb/en/2004/04/91_xfsfix.html Problem is reproducable (using this one source-partition) with following Distros / tools: SuSEv9.1: - kernel-default-2.6.5-7.111.i586 - xfsprogs-2.6.3-29.i586 Debian-SID: - kernel-source-2.6.8_2.6.8-8 - xfsprogs_2.6.20-1_i386 gzipped log of xfs_check on dest-part of /home: http://www.linux-bayreuth.de/~henning/xfs_check_hdc8.gz gzipped log of "xfs_repair -n" on dest-part of /home: http://www.linux-bayreuth.de/~henning/xfs_repair_-n_hdc8.log.gz (sorry for having to anonymize the file-names!) further information: - the dest-partition has definitely no bad sectors (tested with "/sbin/badblocks -w") - source- and dest-partition have the same size according to "/sbin/blockdev --getsize". - a binary copy with /bin/dd results in the same md5-sums on the partitions. - there's no problem in accessing any files on the source-filesystem with tar, afterwards there is, according to "/usr/bin/diff -q", no difference between any of the files on source- and destination-filesystem. - source-partition was clean before doing the copy according to xfs_check: e.g. http://www.linux-bayreuth.de/~henning/xfs_check_hda8 , same with xfs_repair Further information will be provided happily once requested, Henning Rohde ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Dec 1 13:12:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Dec 2004 13:12:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1LC0J1001192 for ; Wed, 1 Dec 2004 13:12:00 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB1LC0lf001191 for linux-xfs@oss.sgi.com; Wed, 1 Dec 2004 13:12:00 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1LBwRF001177 for ; Wed, 1 Dec 2004 13:11:59 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB1KOIll032606; Wed, 1 Dec 2004 12:24:18 -0800 Date: Wed, 1 Dec 2004 12:24:18 -0800 Message-Id: <200412012024.iB1KOIll032606@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 391] unable to copy a 25GB-file from xfs X-Bugzilla-Reason: AssignedTo X-archive-position: 4575 X-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: 350 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=391 ------- Additional Comments From Henning.Rohde@uni-bayreuth.de 2004-01-12 12:24 PDT ------- sorry, I meant of course BugID390: http://oss.sgi.com/bugzilla/show_bug.cgi?id=390 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Dec 2 14:52:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Dec 2004 14:52:40 -0800 (PST) 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 iB2MqXK5016459 for ; Thu, 2 Dec 2004 14:52:33 -0800 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id iB2Mpo905046; Thu, 2 Dec 2004 14:51:51 -0800 Date: Thu, 2 Dec 2004 14:56:10 -0800 From: Andrew Morton To: Stefan Schmidt Cc: xhejtman@mail.muni.cz, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-Id: <20041202145610.49e27b49.akpm@osdl.org> In-Reply-To: <20041202223146.GA31508@zaphods.net> References: <20041111214435.GB29112@mail.muni.cz> <4194A7F9.5080503@cyberone.com.au> <20041113144743.GL20754@zaphods.net> <20041116093311.GD11482@logos.cnet> <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4577 X-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 Content-Length: 1671 Lines: 35 Stefan Schmidt wrote: > > On Thu, Dec 02, 2004 at 10:03:48PM +0100, Lukas Hejtmanek wrote: > > > > I found out that 2.6.6-bk4 kernel is OK. > > > That kernel didn't have the TSO thing. Pretty much all of these reports > > > have been against e1000_alloc_rx_buffers() since the TSO changes went in. > > > Did you try disabling TSO, btw? > > I did it. Allocation failure is still there :( > I had no luck with/without TSO either but on tg3. > I disabled the on-disk-caching component of the application and it now runs > without page allocation errors. Currently it is running smoothly at ~500mbit/s > and ~80kpps in each direction at ~44k interrupts/s, so the problematic > combination seems to be many open files, high i/o transaction rate or > troughput and heavy networking load. (tso currently on) > Caching on ext2-fs in general seemed to generate less page allocation errors > than on xfs and none of the traces i looked over so far showed involvement > of the filesystem i.e. were all triggered by alloc_skb. hm, OK, interesting. It's quite possible that XFS is performing rather too many GFP_ATOMIC allocations and is depleting the page reserves. Although increasing /proc/sys/vm/min_free_kbytes should help there. Nathan, it would be a worthwhile exercise to consider replacing GFP_ATOMIC with (GFP_ATOMIC & ~ __GFP_HIGH) where appropriate. This is because GFP_ATOMIC does two distinct things: a) Don't sleep, so we can call it from within-spinlock and interrupt contexts. b) Dip further into the page reserves. If there are places in XFS where it only needs one of these two behaviours, it would be good to select just that one. From owner-linux-xfs Thu Dec 2 15:53:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Dec 2004 15:53:40 -0800 (PST) Received: from hell.sks3.muni.cz (hell.sks3.muni.cz [147.251.210.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2NrZQK021621 for ; Thu, 2 Dec 2004 15:53:36 -0800 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1Ca0EY-0003NA-00; Fri, 03 Dec 2004 00:19:34 +0100 Date: Fri, 3 Dec 2004 00:18:37 +0100 From: Lukas Hejtmanek To: Andrew Morton Cc: Stefan Schmidt , marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041202231837.GB15185@mail.muni.cz> References: <20041113144743.GL20754@zaphods.net> <20041116093311.GD11482@logos.cnet> <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041202145610.49e27b49.akpm@osdl.org> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 591 Lines: 16 On Thu, Dec 02, 2004 at 02:56:10PM -0800, Andrew Morton wrote: > It's quite possible that XFS is performing rather too many GFP_ATOMIC > allocations and is depleting the page reserves. Although increasing > /proc/sys/vm/min_free_kbytes should help there. Btw, how the min_free_kbytes works? I have up to 1MB TCP windows. If I'm running out of memory then kswapd should try to free some memory (or bdflush). But on GE I can receive data faster then disk is able to swap or flush buffers. So I should keep min_free big enough to give time to disk to flush/swap data? -- Lukáš Hejtmánek From owner-linux-xfs Thu Dec 2 16:19:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Dec 2004 16:19:58 -0800 (PST) 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 iB30Jpew026044 for ; Thu, 2 Dec 2004 16:19:52 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id iB30J2921192; Thu, 2 Dec 2004 16:19:02 -0800 Date: Thu, 2 Dec 2004 16:18:39 -0800 From: Andrew Morton To: Lukas Hejtmanek Cc: zaphodb@zaphods.net, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-Id: <20041202161839.736352c2.akpm@osdl.org> In-Reply-To: <20041202231837.GB15185@mail.muni.cz> References: <20041113144743.GL20754@zaphods.net> <20041116093311.GD11482@logos.cnet> <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041202231837.GB15185@mail.muni.cz> 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: 4579 X-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 Content-Length: 1126 Lines: 28 Lukas Hejtmanek wrote: > > On Thu, Dec 02, 2004 at 02:56:10PM -0800, Andrew Morton wrote: > > It's quite possible that XFS is performing rather too many GFP_ATOMIC > > allocations and is depleting the page reserves. Although increasing > > /proc/sys/vm/min_free_kbytes should help there. > > Btw, how the min_free_kbytes works? The page reclaim code and the page allocator will aim to keep that amount of memory free for emergency, IRQ and atomic allocations. > I have up to 1MB TCP windows. If I'm running out of memory then kswapd should > try to free some memory (or bdflush). yes, there's some latency involved. Especially on uniprocessor - if the CPU is stuck in an interrupt handler refilling a huge network Rx ring then waking kswapd won't do anything and you will run out of memory. > But on GE I can receive data faster then > disk is able to swap or flush buffers. So I should keep min_free big enough to > give time to disk to flush/swap data? All I can say is "experiment with it". It might be useful to renice kswapd so that userspace processes do not increase its latency. From owner-linux-xfs Thu Dec 2 22:21:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Dec 2004 22:21:46 -0800 (PST) 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 iB36LbET007042 for ; Thu, 2 Dec 2004 22:21:38 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02176; Fri, 3 Dec 2004 17:21:04 +1100 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 iB36L0XE128595; Fri, 3 Dec 2004 17:21:00 +1100 (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 iB36Igma002256; Fri, 3 Dec 2004 17:18:43 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iB36IZF7002254; Fri, 3 Dec 2004 17:18:35 +1100 Date: Fri, 3 Dec 2004 17:18:35 +1100 From: Nathan Scott To: Stefan Schmidt , Andrew Morton Cc: xhejtman@mail.muni.cz, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041203061835.GF1228@frodo> References: <20041113144743.GL20754@zaphods.net> <20041116093311.GD11482@logos.cnet> <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041202145610.49e27b49.akpm@osdl.org> User-Agent: Mutt/1.5.3i X-archive-position: 4580 X-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: 2025 Lines: 56 Hi there, On Thu, Dec 02, 2004 at 02:56:10PM -0800, Andrew Morton wrote: > Stefan Schmidt wrote: > > > > and ~80kpps in each direction at ~44k interrupts/s, so the problematic > > combination seems to be many open files, high i/o transaction rate or > > troughput and heavy networking load. (tso currently on) > > Caching on ext2-fs in general seemed to generate less page allocation errors > > than on xfs and none of the traces i looked over so far showed involvement > > of the filesystem i.e. were all triggered by alloc_skb. > > hm, OK, interesting. > > It's quite possible that XFS is performing rather too many GFP_ATOMIC > allocations and is depleting the page reserves. Although increasing > /proc/sys/vm/min_free_kbytes should help there. > > Nathan, it would be a worthwhile exercise to consider replacing GFP_ATOMIC > with (GFP_ATOMIC & ~ __GFP_HIGH) where appropriate. > ... (i.e. zero? so future-proofing for if GFP_ATOMIC != __GFP_HIGH?) > If there are places in XFS where it only needs one of these two behaviours, > it would be good to select just that one. OK, I took a quick look through - there's two places where we use GFP_ATOMIC at the moment. One is a log debug/tracing chunk of code, wont be coming into play here, I'll go back and rework that later. The second is in the metadata buffering code, and is in a spot where we can cope with a failure (don't need to dip into emergency pools at all) but looks like we're avoiding sleeping there. Does this patch improve things for your workload, Stefan? cheers. -- Nathan Index: xfs-linux-2.6/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- xfs-linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c +++ xfs-linux-2.6/fs/xfs/linux-2.6/xfs_buf.c @@ -183,7 +183,7 @@ { a_list_t *aentry; - aentry = kmalloc(sizeof(a_list_t), GFP_ATOMIC); + aentry = kmalloc(sizeof(a_list_t), (GFP_ATOMIC & ~__GFP_HIGH)); if (aentry) { spin_lock(&as_lock); aentry->next = as_free_head; From owner-linux-xfs Thu Dec 2 23:07:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Dec 2004 23:07:27 -0800 (PST) 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 iB377O1H008590 for ; Thu, 2 Dec 2004 23:07:25 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id iB376g911405; Thu, 2 Dec 2004 23:06:42 -0800 Date: Thu, 2 Dec 2004 23:06:20 -0800 From: Andrew Morton To: Nathan Scott Cc: zaphodb@zaphods.net, xhejtman@mail.muni.cz, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-Id: <20041202230620.4de4ec82.akpm@osdl.org> In-Reply-To: <20041203061835.GF1228@frodo> References: <20041113144743.GL20754@zaphods.net> <20041116093311.GD11482@logos.cnet> <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041203061835.GF1228@frodo> 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: 4581 X-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 Content-Length: 1025 Lines: 24 Nathan Scott wrote: > > > Nathan, it would be a worthwhile exercise to consider replacing GFP_ATOMIC > > with (GFP_ATOMIC & ~ __GFP_HIGH) where appropriate. > > ... > > (i.e. zero? so future-proofing for if GFP_ATOMIC != __GFP_HIGH?) yup. (GFP_ATOMIC & ~ __GFP_HIGH) would mean "allocate atomically, but if this means use emergency pools, then don't bother with that". > > If there are places in XFS where it only needs one of these two behaviours, > > it would be good to select just that one. > > OK, I took a quick look through - there's two places where we use > GFP_ATOMIC at the moment. One is a log debug/tracing chunk of code, > wont be coming into play here, I'll go back and rework that later. > The second is in the metadata buffering code, and is in a spot where > we can cope with a failure (don't need to dip into emergency pools > at all) but looks like we're avoiding sleeping there. Just two callsites? That's less that I imagined. Looks like my theory comes unstuck. From owner-linux-xfs Fri Dec 3 02:36:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Dec 2004 02:36:27 -0800 (PST) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB3AaObA016652 for ; Fri, 3 Dec 2004 02:36:24 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.42 #1 (Red Hat Linux)) id 1CaAmv-0002qA-Gp; Fri, 03 Dec 2004 10:35:45 +0000 Date: Fri, 3 Dec 2004 10:35:45 +0000 From: Christoph Hellwig To: Andrew Morton Cc: Stefan Schmidt , xhejtman@mail.muni.cz, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041203103545.GC10799@infradead.org> Mail-Followup-To: Christoph Hellwig , Andrew Morton , Stefan Schmidt , xhejtman@mail.muni.cz, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20041113144743.GL20754@zaphods.net> <20041116093311.GD11482@logos.cnet> <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041202145610.49e27b49.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4582 X-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: 385 Lines: 10 On Thu, Dec 02, 2004 at 02:56:10PM -0800, Andrew Morton wrote: > hm, OK, interesting. > > It's quite possible that XFS is performing rather too many GFP_ATOMIC > allocations and is depleting the page reserves. Although increasing > /proc/sys/vm/min_free_kbytes should help there. There's only a single place in XFS (and a second one for debug builds) doing GFP_ATOMIC allocations. From owner-linux-xfs Fri Dec 3 04:12:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Dec 2004 04:12:41 -0800 (PST) Received: from hell.sks3.muni.cz (hell.sks3.muni.cz [147.251.210.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB3CCSir021455 for ; Fri, 3 Dec 2004 04:12:29 -0800 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1CaCHa-0007TY-00; Fri, 03 Dec 2004 13:11:30 +0100 Date: Fri, 3 Dec 2004 13:11:30 +0100 From: Lukas Hejtmanek To: Andrew Morton Cc: Lukas Hejtmanek , zaphodb@zaphods.net, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041203121129.GC27716@mail.muni.cz> References: <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041202231837.GB15185@mail.muni.cz> <20041202161839.736352c2.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041202161839.736352c2.akpm@osdl.org> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 432 Lines: 13 On Thu, Dec 02, 2004 at 04:18:39PM -0800, Andrew Morton wrote: > All I can say is "experiment with it". > > It might be useful to renice kswapd so that userspace processes do not > increase its latency. Hmm, increasing the min free kb to 64MB and renicing kswapd to -8 seems to solve the issue. However, for me it seems as not so good solution mainly because 2.6.6-bk4 kernel is just ok without any tweeks. -- Lukáš Hejtmánek From owner-linux-xfs Fri Dec 3 04:18:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Dec 2004 04:18:21 -0800 (PST) Received: from hell.sks3.muni.cz (hell.sks3.muni.cz [147.251.210.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB3CIIRX021834 for ; Fri, 3 Dec 2004 04:18:19 -0800 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1CaCNk-0007Tq-00; Fri, 03 Dec 2004 13:17:52 +0100 Date: Fri, 3 Dec 2004 13:17:52 +0100 From: Lukas Hejtmanek To: linux-xfs@oss.sgi.com Cc: Andrew Morton , zaphodb@zaphods.net, marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041203121752.GD27716@mail.muni.cz> References: <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041202231837.GB15185@mail.muni.cz> <20041202161839.736352c2.akpm@osdl.org> <20041203121129.GC27716@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041203121129.GC27716@mail.muni.cz> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 613 Lines: 17 On Fri, Dec 03, 2004 at 01:11:30PM +0100, Lukas Hejtmanek wrote: > On Thu, Dec 02, 2004 at 04:18:39PM -0800, Andrew Morton wrote: > > All I can say is "experiment with it". > > > > It might be useful to renice kswapd so that userspace processes do not > > increase its latency. > > Hmm, increasing the min free kb to 64MB and renicing kswapd to -8 seems to > solve the issue. However, for me it seems as not so good solution mainly because > 2.6.6-bk4 kernel is just ok without any tweeks. Forgot one more think. Renicing kswapd resulted in xfsbufd oops at reboot. (Regarding preeption) -- Lukáš Hejtmánek From owner-linux-xfs Fri Dec 3 13:46:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Dec 2004 13:46:09 -0800 (PST) Received: from snark.thyrsus.com (dsl092-053-140.phl1.dsl.speakeasy.net [66.92.53.140]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB3LjpIq008444 for ; Fri, 3 Dec 2004 13:45:56 -0800 Received: from snark.thyrsus.com (localhost [127.0.0.1]) by snark.thyrsus.com (8.13.1/8.13.1) with ESMTP id iB3LeGRU002727 for ; Fri, 3 Dec 2004 16:40:17 -0500 Date: Fri, 3 Dec 2004 16:40:16 -0500 From: esr@thyrsus.com Message-Id: <200412032140.iB3LeGRU002727@snark.thyrsus.com> To: linux-xfs@oss.sgi.com Subject: problems in xfs_bmap.8, xfs_check.8 X-archive-position: 4585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: esr@thyrsus.com Precedence: bulk X-list: linux-xfs Content-Length: 4304 Lines: 141 This is automatically generated email about problems in a man page for which you appear to be responsible. If you are not the right person or list, tell me and I will attempt to correct my database. In the last mailing (20 Nov 2004) of these reminders, a bug in my script suppressed the sending of second and subsequent patches associated with a maintainer. This resend is going only to maintainers with multiple patches; the first one may be one you have already processed. I apologize for any inconvenience this may cause. See http://catb.org/~esr/doclifter/problems.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the mod date of any manual page. You may wish to do that by hand. Problems with xfs_bmap.8: 1. Unknown or invalid macro. That is, one that does not fit in the macro set that the man page seems to be using. This is a serious error; it often means part of your text is being lost or rendered incorrectly. --- xfs_bmap.8-orig 2004-07-09 06:59:14.210997800 -0400 +++ xfs_bmap.8 2004-07-09 06:59:59.299143360 -0400 @@ -12,10 +12,12 @@ in the file that do not have any corresponding blocks (\f2hole\f1s). Each line of the listings takes the following form: -.Ex -\f2extent\f1\f7: [\f1\f2startoffset\f1\f7..\f1\f2endoffset\f1\f7]: \c -\f1\f2startblock\f1\f7..\f1\f2endblock\f1 -.Ee +.nf +.ft CW + \f2extent\f1\f7: [\f1\f2startoffset\f1\f7..\f1\f2endoffset\f1\f7]: \c + \f1\f2startblock\f1\f7..\f1\f2endblock\f1 +.ft +.fi Holes are marked by replacing the \f2startblock..endblock\f1 with \f2hole\fP. All the file offsets and disk blocks are in units of 512-byte blocks, @@ -29,9 +31,11 @@ .PP If the \f3-l\f1 option is used, then -.Ex -\f1\f2\f1\f7 \f1\f2blocks\f1\f7 -.Ee +.nf +.ft CW + \f1\f2\f1\f7 \f1\f2blocks\f1\f7 +.ft +.fi will be appended to each line. \f1\f2Nblocks\f1\f7 is the length of the extent described on the line in units of 512-byte blocks. ----------------------------- Problems with xfs_bmap.8: 1. Unknown or invalid macro. That is, one that does not fit in the macro set that the man page seems to be using. This is a serious error; it often means part of your text is being lost or rendered incorrectly. --- xfs_bmap.8-orig 2004-07-09 06:59:14.210997800 -0400 +++ xfs_bmap.8 2004-07-09 06:59:59.299143360 -0400 @@ -12,10 +12,12 @@ in the file that do not have any corresponding blocks (\f2hole\f1s). Each line of the listings takes the following form: -.Ex -\f2extent\f1\f7: [\f1\f2startoffset\f1\f7..\f1\f2endoffset\f1\f7]: \c -\f1\f2startblock\f1\f7..\f1\f2endblock\f1 -.Ee +.nf +.ft CW + \f2extent\f1\f7: [\f1\f2startoffset\f1\f7..\f1\f2endoffset\f1\f7]: \c + \f1\f2startblock\f1\f7..\f1\f2endblock\f1 +.ft +.fi Holes are marked by replacing the \f2startblock..endblock\f1 with \f2hole\fP. All the file offsets and disk blocks are in units of 512-byte blocks, @@ -29,9 +31,11 @@ .PP If the \f3-l\f1 option is used, then -.Ex -\f1\f2\f1\f7 \f1\f2blocks\f1\f7 -.Ee +.nf +.ft CW + \f1\f2\f1\f7 \f1\f2blocks\f1\f7 +.ft +.fi will be appended to each line. \f1\f2Nblocks\f1\f7 is the length of the extent described on the line in units of 512-byte blocks. ----------------------------- Problems with xfs_check.8: 1. Unknown or invalid macro. That is, one that does not fit in the macro set that the man page seems to be using. This is a serious error; it often means part of your text is being lost or rendered incorrectly. --- xfs_check.8-orig 2004-07-09 07:01:51.627066920 -0400 +++ xfs_check.8 2004-07-09 07:03:06.440693520 -0400 @@ -90,17 +90,21 @@ rather than produce useful output. If the filesystem is completely corrupt, a core dump might be produced instead of the message -.Ex -\f2xxx\f1\f7 is not a valid filesystem\f1 -.Ee +.nf +.ft CW + \f2xxx\f1\f7 is not a valid filesystem\f1 +.ft +.fi .PP If the filesystem is very large (has many files) then .I xfs_check might run out of memory. In this case the message -.Ex -out of memory -.Ee +.nf +.ft CW + out of memory +.ft +.fi is printed. .PP The following is a description of the most likely problems and the associated ----------------------------- -- Eric S. Raymond From owner-linux-xfs Sat Dec 4 10:10:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Dec 2004 10:10:50 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB4IAkAq026743 for ; Sat, 4 Dec 2004 10:10:47 -0800 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CaeMT-0005kL-00 for linux-xfs@oss.sgi.com; Sat, 04 Dec 2004 19:10:25 +0100 Received: from [80.171.132.204] (helo=tric) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-SHA:128) (Exim 3.35 #1) id 1CaeMS-0007Ox-00 for linux-xfs@oss.sgi.com; Sat, 04 Dec 2004 19:10:25 +0100 Received: from tric by tric with local (Exim 4.34) id 1CaeMS-0003As-63 for linux-xfs@oss.sgi.com; Sat, 04 Dec 2004 19:10:24 +0100 Date: Sat, 4 Dec 2004 19:10:24 +0100 From: Volker Gropp To: linux-xfs@oss.sgi.com Subject: xfs_repair: fatal error -- couldn't map inode 5980339, err = 990 Message-ID: <20041204181024.GC5116@kiste> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Priority: normal User-Agent: Mutt/1.5.6+20040907i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:12fcccdf158e54581356c471c4ea6e5a X-archive-position: 4586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vgropp@pefra.de Precedence: bulk X-list: linux-xfs Content-Length: 1500 Lines: 42 Hi, after a system hang due to XFree86 and alot windows my xfs filesystem contains some errors. A xfs_repair doesnt finish and my research on the www didnt showup any working solutions. kernel is a vanilla 2.6.9 with acpi and swsusp2 patches on a debian sid. xfs_repair version 2.6.20 (debian version) and xfs_repair version 2.6.25 (todays cvs) both fail, but with different errors. I am still able to mount the Fs but some files are broken. For testing the repair im using a copy made using dd and using the loop module. You can find the xfs_repair -v logs at http://www.gropp.org/xfs_repair-2.6.20.log and http://www.gropp.org/xfs_repair-2.6.25.log output of: xfs_db -c 'inode 5980339' -c p /dev/loop0 http://www.gropp.org/xfs_db-after-2.6.20-repair.log and http://www.gropp.org/xfs_db-after-2.6.25-repair.log xfs_info /dev/loop0 meta-data=/mnt isize=256 agcount=8, agsize=156161 blks = sectsz=512 data = bsize=4096 blocks=1249288, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 i already tried a xfs_db -x -c 'inode 5980339' -c 'write core.nblocks 840' /dev/loop0 but with no luck. thanks in advance for any help Volker Gropp From owner-linux-xfs Sun Dec 5 07:39:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Dec 2004 07:39:19 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB5FdFeO019094 for ; Sun, 5 Dec 2004 07:39:16 -0800 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CayTN-0005Lm-00 for linux-xfs@oss.sgi.com; Sun, 05 Dec 2004 16:38:53 +0100 Received: from [80.171.88.169] (helo=tric) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-SHA:128) (Exim 3.35 #1) id 1CayTM-0004fe-00 for linux-xfs@oss.sgi.com; Sun, 05 Dec 2004 16:38:52 +0100 Received: from tric by tric with local (Exim 4.34) id 1CayTI-0005bl-1K for linux-xfs@oss.sgi.com; Sun, 05 Dec 2004 16:38:48 +0100 Date: Sun, 5 Dec 2004 16:38:48 +0100 From: Volker Gropp To: linux-xfs@oss.sgi.com Subject: Re: xfs_repair: fatal error -- couldn't map inode 5980339, err = 990 Message-ID: <20041205153847.GE5116@kiste> References: <20041204181024.GC5116@kiste> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041204181024.GC5116@kiste> Priority: normal User-Agent: Mutt/1.5.6+20040907i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:12fcccdf158e54581356c471c4ea6e5a X-archive-position: 4587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vgropp@pefra.de Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 14 Hi, one addition to my yesterdays error report. I had the loop mounted over night, and updatedb (locate) hang, with some kernel errors in syslog. It is a 2.4.26 vanilla smp kernel with xfs debug enabled. You can find the log entries at http://www.gropp.org/xfs_error_kernel_log any advice how to repair this? thx Volker Gropp From owner-linux-xfs Sun Dec 5 18:24:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Dec 2004 18:24:59 -0800 (PST) Received: from ygw07.jvc-victor.co.jp (ygw07.jvc-victor.co.jp [61.209.242.186]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB62Ou1Z020214 for ; Sun, 5 Dec 2004 18:24:57 -0800 Received: from unknown (HELO ycm06.jvc-victor.co.jp) (136.198.180.101) by ygw07.jvc-victor.co.jp with ESMTP; 06 Dec 2004 11:24:35 +0900 Received: (from root@localhost) by ycm06.jvc-victor.co.jp (8.11.6/8.11.6) id iB62OZV24452 for linux-xfs@oss.sgi.com; Mon, 6 Dec 2004 11:24:35 +0900 Received: from ycf02.jvc-victor.co.jp [136.198.212.103] by ycm06.jvc-victor.co.jp with ESMTP id MAA24451; Mon, 6 Dec 2004 11:24:35 +0900 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: linux-xfs@oss.sgi.com From: Sakai Yasutoshi Subject: Process stuck in R state at extent = 2049 Date: Mon, 6 Dec 2004 11:24:34 +0900 X-Mailer: Apple Mail (2.619) X-archive-position: 4588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sakai-yasutoshi@jvc-victor.jp Precedence: bulk X-list: linux-xfs Content-Length: 426 Lines: 19 Hi. We are running linux 2.4.26 on IBM PPC405GP. Sometimes our process stuck in 'R' state when number of extent reaches 2049. And disk cache is freed at same time, so we have 40Mbyte of free memory, but we get kernel message "kernel: __alloc_pages: 4-order allocation failed (gfp=0xf0/0)". Process reverts to normal state after 5 seconds to 20 minutes once in a while. is this XFS problem? Regards, Yasutoshi Sakai From owner-linux-xfs Mon Dec 6 10:13:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Dec 2004 10:13:13 -0800 (PST) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB6IDAms027264 for ; Mon, 6 Dec 2004 10:13:10 -0800 Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 9136BA33F2 for ; Mon, 6 Dec 2004 10:12:43 -0800 (PST) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Mon, 6 Dec 2004 10:12:37 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id iB6ICbpT010805 for ; Mon, 6 Dec 2004 10:12:37 -0800 (PST) (envelope-from zaphodb@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id iB6ICbON010798 for linux-xfs@oss.sgi.com; Mon, 6 Dec 2004 10:12:37 -0800 (PST) Message-Id: <200412061812.iB6ICbON010798@mailserver2.hushmail.com> Date: Mon, 6 Dec 2004 10:12:31 -0800 To: linux-xfs@oss.sgi.com Cc: Subject: XFS_VERSION_STRING not autoversioning? From: X-archive-position: 4589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zaphodb@hush.com Precedence: bulk X-list: linux-xfs Content-Length: 755 Lines: 28 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems that XFS_VERSION_STRING in the Linux-2.4/Linux 2.6 CVS code is stuck at 2004-10-22. Is this by design? Cheers. -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.4 wkYEARECAAYFAkG0oQUACgkQDD16SQywcr55iQCeMEFjkeEHO0UYPGOCLWPnP2ykg6cA njoql3N49akwedym03L1DYSZgEr6 =6lYq -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 From owner-linux-xfs Mon Dec 6 15:00:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Dec 2004 15:00:30 -0800 (PST) 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 iB6N0PsB012557 for ; Mon, 6 Dec 2004 15:00:26 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA19170; Tue, 7 Dec 2004 09:59:50 +1100 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 iB6MxkXE238326; Tue, 7 Dec 2004 09:59:47 +1100 (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 iB6MvSaK001004; Tue, 7 Dec 2004 09:57:28 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iB6MvQp1001002; Tue, 7 Dec 2004 09:57:26 +1100 Date: Tue, 7 Dec 2004 09:57:26 +1100 From: Nathan Scott To: zaphodb@hush.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS_VERSION_STRING not autoversioning? Message-ID: <20041206225726.GA993@frodo> References: <200412061812.iB6ICbON010798@mailserver2.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412061812.iB6ICbON010798@mailserver2.hushmail.com> User-Agent: Mutt/1.5.3i X-archive-position: 4590 X-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: 302 Lines: 14 On Mon, Dec 06, 2004 at 10:12:31AM -0800, zaphodb@hush.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It seems that XFS_VERSION_STRING in the Linux-2.4/Linux 2.6 CVS > code is stuck at 2004-10-22. Is this by design? No, not by design; Russells fixed it now. cheers. -- Nathan From owner-linux-xfs Mon Dec 6 16:16:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Dec 2004 16:16:17 -0800 (PST) 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 iB70GEq4016713 for ; Mon, 6 Dec 2004 16:16:15 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20702; Tue, 7 Dec 2004 11:15:43 +1100 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 iB70FeXE240130; Tue, 7 Dec 2004 11:15:41 +1100 (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 iB70DLaK001207; Tue, 7 Dec 2004 11:13:21 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iB70DJIt001205; Tue, 7 Dec 2004 11:13:19 +1100 Date: Tue, 7 Dec 2004 11:13:19 +1100 From: Nathan Scott To: Sakai Yasutoshi Cc: linux-xfs@oss.sgi.com Subject: Re: Process stuck in R state at extent = 2049 Message-ID: <20041207001319.GB993@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: 4591 X-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: 918 Lines: 29 On Mon, Dec 06, 2004 at 11:24:34AM +0900, Sakai Yasutoshi wrote: > Hi. > > We are running linux 2.4.26 on IBM PPC405GP. > > Sometimes our process stuck in 'R' state when number of extent reaches > 2049. > And disk cache is freed at same time, so we have 40Mbyte of free memory, > but we get kernel message "kernel: __alloc_pages: 4-order allocation > failed (gfp=0xf0/0)". > > Process reverts to normal state after 5 seconds to 20 minutes once in a > while. > > is this XFS problem? Sort of; XFS has a tendency of asking for contiguous pages, and the VM has a tendency of not being able to satisfy such requests -- you might have more luck with a CVS 2.4 kernel, in particular the split-patches/cache_defs patch there adds a mechanism for 2.4 kernels to be able to do memory shaking which the XFS code can plug into. 2.6 provides a mechanism like that, without need for patching (fwiw). cheers. -- Nathan From owner-linux-xfs Mon Dec 6 18:39:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Dec 2004 18:39:05 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB72d27c001054 for ; Mon, 6 Dec 2004 18:39:02 -0800 Received: by wproxy.gmail.com with SMTP id 68so38992wri for ; Mon, 06 Dec 2004 18:38:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=md4BSWA5YoTW7CMM0FV3lZe0zOziWnkTEbMuKX/JT6Cu4DntR6XxM7xUDWo/cMxUfKFDM5r3wHMV7Tow79IgiERxsmYL5paF1iwOtA29H8nllvbii5cXey8IjSk7/Uni2cHA+WS7cUxBnTsShQVOVnBcipeuCwAGvB/3MiwgoNA= Received: by 10.54.23.71 with SMTP id 71mr834158wrw; Mon, 06 Dec 2004 18:37:15 -0800 (PST) Received: by 10.54.15.10 with HTTP; Mon, 6 Dec 2004 18:37:14 -0800 (PST) Message-ID: <4339a3ea041206183777e5f123@mail.gmail.com> Date: Mon, 6 Dec 2004 20:37:14 -0600 From: shuhua S Reply-To: shuhua S To: linux-xfs@oss.sgi.com Subject: On disk data structure of XFS Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shuhua.s@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 320 Lines: 11 Hi, Where can I find any document that talks about the detailed on-disk data structure of XFS? I've a project to write a pseudo disk driver to monitor some XFS operations. I am wondering if I can find such a document so that I can get a quick start without the tedious work of reading the source code :( Thanks, John From owner-linux-xfs Tue Dec 7 03:18:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 03:18:54 -0800 (PST) Received: from hell.sks3.muni.cz (hell.sks3.muni.cz [147.251.210.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB7BInK0002513 for ; Tue, 7 Dec 2004 03:18:50 -0800 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1CbdLc-0002qA-00; Tue, 07 Dec 2004 12:17:36 +0100 Date: Tue, 7 Dec 2004 12:17:36 +0100 From: Lukas Hejtmanek To: Nathan Scott Cc: Stefan Schmidt , Andrew Morton , marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041207111736.GA10872@mail.muni.cz> References: <20041116093311.GD11482@logos.cnet> <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041203061835.GF1228@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041203061835.GF1228@frodo> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 1731 Lines: 45 On Fri, Dec 03, 2004 at 05:18:35PM +1100, Nathan Scott wrote: > OK, I took a quick look through - there's two places where we use > GFP_ATOMIC at the moment. One is a log debug/tracing chunk of code, > wont be coming into play here, I'll go back and rework that later. > The second is in the metadata buffering code, and is in a spot where > we can cope with a failure (don't need to dip into emergency pools > at all) but looks like we're avoiding sleeping there. > > Does this patch improve things for your workload, Stefan? This change leads to: Filesystem "sda1": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/x fs/xfs_da_btree.c. Caller 0xc0200641 [] xfs_da_do_buf+0x72a/0x8df [] xfs_da_read_buf+0x57/0x5b [] kmem_zone_alloc+0x50/0x96 [] xfs_da_node_lookup_int+0x80/0x369 [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leafn_lookup_int+0x381/0x551 [] xfs_dir2_leafn_lookup_int+0x381/0x551 [] xfs_da_node_lookup_int+0x20a/0x369 [] xfs_dir2_node_lookup+0x3f/0xb9 [] xfs_dir2_lookup+0x13e/0x14e [] update_atime+0xd0/0xd5 [] do_generic_mapping_read+0x2bc/0x53f [] xfs_dir_lookup_int+0x4c/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x58/0x96 [] real_lookup+0xcd/0xf0 [] do_lookup+0x96/0xa1 [] link_path_walk+0x693/0xd13 [] path_lookup+0x93/0x155 [] open_namei+0x85/0x60c [] filp_open+0x3e/0x64 [] vfs_read+0xc9/0x119 [] get_unused_fd+0x7b/0xcf [] sys_open+0x49/0x89 [] syscall_call+0x7/0xb xfs_da_do_buf: bno 96 -- Lukáš Hejtmánek From owner-linux-xfs Tue Dec 7 08:23:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 08:23:35 -0800 (PST) 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 iB7GNUwb023973 for ; Tue, 7 Dec 2004 08:23:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iB7HhiwD021560 for ; Tue, 7 Dec 2004 09:43:44 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iB7GLwp75372343; Tue, 7 Dec 2004 10:21:58 -0600 (CST) Message-ID: <41B5D8A5.904@sgi.com> Date: Tue, 07 Dec 2004 10:21:57 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: shuhua S CC: linux-xfs@oss.sgi.com Subject: Re: On disk data structure of XFS References: <4339a3ea041206183777e5f123@mail.gmail.com> In-Reply-To: <4339a3ea041206183777e5f123@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4595 X-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: 617 Lines: 22 shuhua S wrote: > Hi, > > Where can I find any document that talks about the detailed on-disk > data structure of XFS? I've a project to write a pseudo disk driver to > monitor some XFS operations. I am wondering if I can find such a > document so that I can get a quick start without the tedious work of > reading the source code :( > > Thanks, > John > take a look at the "publications" link on the xfs homepage - http://oss.sgi.com/projects/xfs/publications.html the original whitepapers might be useful - until we fix up the .htaccess you can also find them at http://oss.sgi.com:/~sandeen/design -Eric From owner-linux-xfs Tue Dec 7 11:36:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 11:36:09 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iB7Ja4nS001646 for ; Tue, 7 Dec 2004 11:36:05 -0800 Received: (qmail 13880 invoked from network); 7 Dec 2004 19:35:36 -0000 Received: from r063115.stusta.swh.mhn.de (HELO r063144.stusta.swh.mhn.de) (10.150.63.115) by mailout.stusta.mhn.de with SMTP; 7 Dec 2004 19:35:36 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 327A8BBDBF; Tue, 7 Dec 2004 20:35:33 +0100 (CET) Date: Tue, 7 Dec 2004 20:35:33 +0100 From: Adrian Bunk To: Andrew Morton Cc: nathans@sgi.com, linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] some XFS cleanups (fwd) Message-ID: <20041207193533.GG7250@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4596 X-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@stusta.de Precedence: bulk X-list: linux-xfs Content-Length: 9085 Lines: 265 The patch forwarded below still applies and compiles against 2.6.10-rc2-mm4. Please apply. ----- Forwarded message from Adrian Bunk ----- Date: Sat, 30 Oct 2004 20:13:07 +0200 From: Adrian Bunk To: nathans@sgi.com Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] some XFS cleanups The patch below makes the following cleanups in the XFS code: - remove the unused global function vfs_dmapiops - remove some unused #define's - make several functions static diffstat output: fs/xfs/linux-2.6/xfs_aops.c | 17 ++++++++++++++++- fs/xfs/linux-2.6/xfs_buf.c | 4 ++-- fs/xfs/linux-2.6/xfs_iops.h | 1 - fs/xfs/linux-2.6/xfs_linux.h | 14 -------------- fs/xfs/linux-2.6/xfs_super.c | 2 +- fs/xfs/linux-2.6/xfs_super.h | 12 ------------ fs/xfs/linux-2.6/xfs_vfs.c | 29 ++++++++++++++--------------- fs/xfs/linux-2.6/xfs_vfs.h | 5 ----- 8 files changed, 33 insertions(+), 51 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_linux.h.old 2004-10-30 15:33:15.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_linux.h 2004-10-30 16:54:04.000000000 +0200 @@ -115,20 +115,6 @@ #undef HAVE_REFCACHE /* reference cache not needed for NFS in 2.6 */ #define HAVE_SENDFILE /* sendfile(2) exists in 2.6, but not in 2.4 */ -/* - * State flag for unwritten extent buffers. - * - * We need to be able to distinguish between these and delayed - * allocate buffers within XFS. The generic IO path code does - * not need to distinguish - we use the BH_Delay flag for both - * delalloc and these ondisk-uninitialised buffers. - */ -BUFFER_FNS(PrivateStart, unwritten); -static inline void set_buffer_unwritten_io(struct buffer_head *bh) -{ - bh->b_end_io = linvfs_unwritten_done; -} - #define restricted_chown xfs_params.restrict_chown.val #define irix_sgid_inherit xfs_params.sgid_inherit.val #define irix_symlink_mode xfs_params.symlink_mode.val --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_iops.h.old 2004-10-30 15:30:36.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_iops.h 2004-10-30 15:32:26.000000000 +0200 @@ -43,7 +43,6 @@ extern struct address_space_operations linvfs_aops; extern int linvfs_get_block(struct inode *, sector_t, struct buffer_head *, int); -extern void linvfs_unwritten_done(struct buffer_head *, int); extern int xfs_ioctl(struct bhv_desc *, struct inode *, struct file *, int, unsigned int, void __user *); --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_aops.c.old 2004-10-30 15:26:37.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_aops.c 2004-10-30 16:56:46.000000000 +0200 @@ -55,10 +55,25 @@ #include #include +STATIC void linvfs_unwritten_done(struct buffer_head *, int); STATIC void xfs_count_page_state(struct page *, int *, int *, int *); STATIC void xfs_convert_page(struct inode *, struct page *, xfs_iomap_t *, struct writeback_control *wbc, void *, int, int); +/* + * State flag for unwritten extent buffers. + * + * We need to be able to distinguish between these and delayed + * allocate buffers within XFS. The generic IO path code does + * not need to distinguish - we use the BH_Delay flag for both + * delalloc and these ondisk-uninitialised buffers. + */ +BUFFER_FNS(PrivateStart, unwritten); +static inline void set_buffer_unwritten_io(struct buffer_head *bh) +{ + bh->b_end_io = linvfs_unwritten_done; +} + #if defined(XFS_RW_TRACE) void xfs_page_trace( @@ -104,7 +119,7 @@ #define xfs_page_trace(tag, inode, page, mask) #endif -void +STATIC void linvfs_unwritten_done( struct buffer_head *bh, int uptodate) --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_buf.c.old 2004-10-30 15:33:58.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_buf.c 2004-10-30 15:40:03.000000000 +0200 @@ -1084,7 +1084,7 @@ * done with respect to that I/O. The pb_iodone routine, if * present, will be called as a side-effect. */ -void +static void pagebuf_iodone_work( void *v) { @@ -1263,7 +1263,7 @@ return 0; } -void +static void _pagebuf_ioapply( xfs_buf_t *pb) { --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.h.old 2004-10-30 17:00:13.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.h 2004-10-30 17:00:30.000000000 +0200 @@ -32,24 +32,12 @@ #ifndef __XFS_SUPER_H__ #define __XFS_SUPER_H__ -#ifdef CONFIG_XFS_DMAPI -# define vfs_insertdmapi(vfs) vfs_insertops(vfsp, &xfs_dmops) -# define vfs_initdmapi() dmapi_init() -# define vfs_exitdmapi() dmapi_uninit() -#else -# define vfs_insertdmapi(vfs) do { } while (0) -# define vfs_initdmapi() do { } while (0) -# define vfs_exitdmapi() do { } while (0) -#endif - #ifdef CONFIG_XFS_QUOTA -# define vfs_insertquota(vfs) vfs_insertops(vfsp, &xfs_qmops) extern void xfs_qm_init(void); extern void xfs_qm_exit(void); # define vfs_initquota() xfs_qm_init() # define vfs_exitquota() xfs_qm_exit() #else -# define vfs_insertquota(vfs) do { } while (0) # define vfs_initquota() do { } while (0) # define vfs_exitquota() do { } while (0) #endif --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.c.old 2004-10-30 16:58:45.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.c 2004-10-30 16:59:50.000000000 +0200 @@ -284,7 +284,7 @@ kmem_cache_free(linvfs_inode_zone, LINVFS_GET_VP(inode)); } -int +STATIC int xfs_inode_shake( int priority, unsigned int gfp_mask) --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.h.old 2004-10-30 17:08:34.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.h 2004-10-30 17:01:57.000000000 +0200 @@ -158,7 +158,6 @@ #define VFS_STATVFS(v, sp,vp, rv) ((rv) = vfs_statvfs(VHEAD(v), sp,vp)) #define VFS_SYNC(v, flag,cr, rv) ((rv) = vfs_sync(VHEAD(v), flag,cr)) #define VFS_VGET(v, vpp,fidp, rv) ((rv) = vfs_vget(VHEAD(v), vpp,fidp)) -#define VFS_DMAPIOPS(v, p, rv) ((rv) = vfs_dmapiops(VHEAD(v), p)) #define VFS_QUOTACTL(v, c,id,p, rv) ((rv) = vfs_quotactl(VHEAD(v), c,id,p)) #define VFS_INIT_VNODE(v, vp,b,ul) ( vfs_init_vnode(VHEAD(v), vp,b,ul) ) #define VFS_FORCE_SHUTDOWN(v, fl,f,l) ( vfs_force_shutdown(VHEAD(v), fl,f,l) ) @@ -176,7 +175,6 @@ #define PVFS_STATVFS(b, sp,vp, rv) ((rv) = vfs_statvfs(b, sp,vp)) #define PVFS_SYNC(b, flag,cr, rv) ((rv) = vfs_sync(b, flag,cr)) #define PVFS_VGET(b, vpp,fidp, rv) ((rv) = vfs_vget(b, vpp,fidp)) -#define PVFS_DMAPIOPS(b, p, rv) ((rv) = vfs_dmapiops(b, p)) #define PVFS_QUOTACTL(b, c,id,p, rv) ((rv) = vfs_quotactl(b, c,id,p)) #define PVFS_INIT_VNODE(b, vp,b2,ul) ( vfs_init_vnode(b, vp,b2,ul) ) #define PVFS_FORCE_SHUTDOWN(b, fl,f,l) ( vfs_force_shutdown(b, fl,f,l) ) @@ -191,7 +189,6 @@ extern int vfs_statvfs(bhv_desc_t *, xfs_statfs_t *, struct vnode *); extern int vfs_sync(bhv_desc_t *, int, struct cred *); extern int vfs_vget(bhv_desc_t *, struct vnode **, struct fid *); -extern int vfs_dmapiops(bhv_desc_t *, caddr_t); extern int vfs_quotactl(bhv_desc_t *, int, int, caddr_t); extern void vfs_init_vnode(bhv_desc_t *, struct vnode *, bhv_desc_t *, int); extern void vfs_force_shutdown(bhv_desc_t *, int, char *, int); @@ -209,8 +206,6 @@ extern vfs_t *vfs_allocate(void); extern void vfs_deallocate(vfs_t *); -extern void vfs_insertops(vfs_t *, bhv_vfsops_t *); -extern void vfs_insertbhv(vfs_t *, bhv_desc_t *, vfsops_t *, void *); extern void bhv_insert_all_vfsops(struct vfs *); extern void bhv_remove_all_vfsops(struct vfs *, int); --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.c.old 2004-10-30 17:08:29.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.c 2004-10-30 17:05:54.000000000 +0200 @@ -47,6 +47,18 @@ #include "xfs_mount.h" #include "xfs_quota.h" +#ifdef CONFIG_XFS_DMAPI +# define vfs_insertdmapi(vfs) vfs_insertops(vfsp, &xfs_dmops) +#else +# define vfs_insertdmapi(vfs) do { } while (0) +#endif + +#ifdef CONFIG_XFS_QUOTA +# define vfs_insertquota(vfs) vfs_insertops(vfsp, &xfs_qmops) +#else +# define vfs_insertquota(vfs) do { } while (0) +#endif + int vfs_mount( struct bhv_desc *bdp, @@ -173,19 +185,6 @@ } int -vfs_dmapiops( - struct bhv_desc *bdp, - caddr_t addr) -{ - struct bhv_desc *next = bdp; - - ASSERT(next); - while (! (bhvtovfsops(next))->vfs_dmapiops) - next = BHV_NEXT(next); - return ((*bhvtovfsops(next)->vfs_dmapiops)(next, addr)); -} - -int vfs_quotactl( struct bhv_desc *bdp, int cmd, @@ -264,7 +263,7 @@ kmem_free(vfsp, sizeof(vfs_t)); } -void +static void vfs_insertops( struct vfs *vfsp, struct bhv_vfsops *vfsops) @@ -276,7 +275,7 @@ bhv_insert(&vfsp->vfs_bh, bdp); } -void +static void vfs_insertbhv( struct vfs *vfsp, struct bhv_desc *bdp, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ----- End forwarded message ----- From owner-linux-xfs Tue Dec 7 11:47:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 11:47:40 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB7JlbdU002181 for ; Tue, 7 Dec 2004 11:47:38 -0800 Received: from mkexu (mkexu.corp.yahoo.com [207.126.231.140]) by mrout3.yahoo.com (8.13.1/8.13.1/y.out) with ESMTP id iB7Jkpd7058006; Tue, 7 Dec 2004 11:46:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole:importance; b=oR1IbF6UFQDvDkJrDKMSRz29FXxq3XXvVSWJO+x9709wAjWFo0V4yJvIDgOvV8wb From: "Mike Xu" To: Cc: Subject: Large file support in Linux Date: Tue, 7 Dec 2004 11:46:18 -0800 Message-ID: <001601c4dc95$6b764f50$8ce77ecf@mkexu> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 4597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mkexu@yahoo-inc.com Precedence: bulk X-list: linux-xfs Content-Length: 580 Lines: 45 Hello, I am testing the patch for the large file support (> 2TB) on Linux. After I executed the command mkfs.xfs to create a file system of more than 2 TB, I did a mount, but I got the following error: XFS: File system is too large to be mounted on this system. I checked the source, the error is from the file xfs_mount.c #if !XFS_BIG_BLKNOS xxxxx("XFS: File system is too large to be mounted on this system."); #endif Should I define XFS_BIG_BLKNOS in the header file xfs_types.h? Thanks, Mike [[HTML alternate version deleted]] From owner-linux-xfs Tue Dec 7 14:53:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 14:53:18 -0800 (PST) Received: from mail.iinet.net.au (mail-03.iinet.net.au [203.59.3.35]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iB7MrEMX012651 for ; Tue, 7 Dec 2004 14:53:15 -0800 Received: (qmail 27519 invoked from network); 7 Dec 2004 22:52:45 -0000 Received: from unknown (HELO chimp.local.net) (203.173.5.119) by mail.iinet.net.au with SMTP; 7 Dec 2004 22:52:45 -0000 Received: from didi.local.net ([192.168.0.1]) by chimp.local.net with esmtp (Exim 4.34) id 1CboCI-0000pd-L0; Wed, 08 Dec 2004 09:52:42 +1100 Message-ID: <41B6343A.9060601@cyberone.com.au> Date: Wed, 08 Dec 2004 09:52:42 +1100 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: Lukas Hejtmanek CC: Andrew Morton , zaphodb@zaphods.net, marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures References: <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041202231837.GB15185@mail.muni.cz> <20041202161839.736352c2.akpm@osdl.org> <20041203121129.GC27716@mail.muni.cz> In-Reply-To: <20041203121129.GC27716@mail.muni.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: piggin@cyberone.com.au Precedence: bulk X-list: linux-xfs Content-Length: 519 Lines: 20 Lukas Hejtmanek wrote: >On Thu, Dec 02, 2004 at 04:18:39PM -0800, Andrew Morton wrote: > >>All I can say is "experiment with it". >> >>It might be useful to renice kswapd so that userspace processes do not >>increase its latency. >> > >Hmm, increasing the min free kb to 64MB and renicing kswapd to -8 seems to >solve the issue. However, for me it seems as not so good solution mainly because >2.6.6-bk4 kernel is just ok without any tweeks. > > You're using 2.6.9, right? 2.6.10 should be better in this regard. From owner-linux-xfs Tue Dec 7 16:00:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 16:00:16 -0800 (PST) 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 iB800DwO014481 for ; Tue, 7 Dec 2004 16:00:14 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16491; Wed, 8 Dec 2004 10:59:42 +1100 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 iB7NxeXE267864; Wed, 8 Dec 2004 10:59:41 +1100 (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 iB7NvKEr001815; Wed, 8 Dec 2004 10:57:20 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iB7NvIcL001813; Wed, 8 Dec 2004 10:57:18 +1100 Date: Wed, 8 Dec 2004 10:57:18 +1100 From: Nathan Scott To: Mike Xu Cc: linux-xfs@oss.sgi.com Subject: Re: Large file support in Linux Message-ID: <20041207235718.GA1611@frodo> References: <001601c4dc95$6b764f50$8ce77ecf@mkexu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001601c4dc95$6b764f50$8ce77ecf@mkexu> User-Agent: Mutt/1.5.3i X-archive-position: 4599 X-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: 914 Lines: 34 On Tue, Dec 07, 2004 at 11:46:18AM -0800, Mike Xu wrote: > Hello, > > I am testing the patch for the large file support (> 2TB) on Linux. After I Do you mean the Large Block Device (LBD) patch? Which kernel version are you using? > executed the command mkfs.xfs to create a file system of more than 2 TB, I > did a mount, but I got the following error: > > XFS: File system is too large to be mounted on this system. > > I checked the source, the error is from the file xfs_mount.c > > #if !XFS_BIG_BLKNOS > > xxxxx("XFS: File system is too large to be mounted on this > system."); > > #endif > > Should I define XFS_BIG_BLKNOS in the header file xfs_types.h? No, when the LBD patch is enabled XFS_BIG_BLKNOS is automatically enabled (for 2.6 kernels, where LBD is merged). For 2.4 kernels, you will want to use XFS from CVS (i.e. not mainline) along with the LBD patch. cheers. -- Nathan From owner-linux-xfs Tue Dec 7 16:18:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 16:18:29 -0800 (PST) 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 iB80IPJQ015174 for ; Tue, 7 Dec 2004 16:18:26 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16969; Wed, 8 Dec 2004 11:17:51 +1100 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 iB80HkXE267986; Wed, 8 Dec 2004 11:17:47 +1100 (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 iB80FNEr001886; Wed, 8 Dec 2004 11:15:24 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iB80FI4N001884; Wed, 8 Dec 2004 11:15:18 +1100 Date: Wed, 8 Dec 2004 11:15:18 +1100 From: Nathan Scott To: Lukas Hejtmanek Cc: Stefan Schmidt , Andrew Morton , marcelo.tosatti@cyclades.com, piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041208001518.GB1611@frodo> References: <20041116170527.GA3525@mail.muni.cz> <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041203061835.GF1228@frodo> <20041207111736.GA10872@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207111736.GA10872@mail.muni.cz> User-Agent: Mutt/1.5.3i X-archive-position: 4600 X-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: 664 Lines: 20 On Tue, Dec 07, 2004 at 12:17:36PM +0100, Lukas Hejtmanek wrote: > On Fri, Dec 03, 2004 at 05:18:35PM +1100, Nathan Scott wrote: > > Does this patch improve things for your workload, Stefan? > > This change leads to: > > Filesystem "sda1": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/x > fs/xfs_da_btree.c. Caller 0xc0200641 > [] xfs_da_do_buf+0x72a/0x8df Hmmm, thats not healthy -- the patch might be making some other lurking problem more likely to hit; what workload are you using to hit this? (is it reproducible?) I haven't come across this in the testing I've done so far, so I'm keen to try your case. thanks. -- Nathan From owner-linux-xfs Tue Dec 7 16:37:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 16:37:27 -0800 (PST) Received: from hell.sks3.muni.cz (hell.sks3.muni.cz [147.251.210.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB80bM0q019074 for ; Tue, 7 Dec 2004 16:37:23 -0800 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1Cbpp5-0003M3-00; Wed, 08 Dec 2004 01:36:51 +0100 Date: Wed, 8 Dec 2004 01:36:51 +0100 From: Lukas Hejtmanek To: Nathan Scott Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures Message-ID: <20041208003650.GA12775@mail.muni.cz> References: <20041121014350.GJ4999@zaphods.net> <20041121024226.GK4999@zaphods.net> <20041202195422.GA20771@mail.muni.cz> <20041202122546.59ff814f.akpm@osdl.org> <20041202210348.GD20771@mail.muni.cz> <20041202223146.GA31508@zaphods.net> <20041202145610.49e27b49.akpm@osdl.org> <20041203061835.GF1228@frodo> <20041207111736.GA10872@mail.muni.cz> <20041208001518.GB1611@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041208001518.GB1611@frodo> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4601 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 591 Lines: 17 On Wed, Dec 08, 2004 at 11:15:18AM +1100, Nathan Scott wrote: > Hmmm, thats not healthy -- the patch might be making some other > lurking problem more likely to hit; what workload are you using > to hit this? (is it reproducible?) I haven't come across this > in the testing I've done so far, so I'm keen to try your case. IBP server tried to recover disk allocations. That means 1 thread is reading many files. One by one. It did only once as I did not want to loose data I rather switched to previous version of the kernel immediatelly. [removed unnecessary cc] -- Lukáš Hejtmánek From owner-linux-xfs Tue Dec 7 21:06:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Dec 2004 21:06:55 -0800 (PST) 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 iB856o5X030407 for ; Tue, 7 Dec 2004 21:06:51 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA22637; Wed, 8 Dec 2004 16:06:16 +1100 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 iB856DXE273898; Wed, 8 Dec 2004 16:06:14 +1100 (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 iB853oEr002680; Wed, 8 Dec 2004 16:03:51 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iB853mFg002678; Wed, 8 Dec 2004 16:03:48 +1100 Date: Wed, 8 Dec 2004 16:03:48 +1100 From: Nathan Scott To: Adrian Bunk Cc: Andrew Morton , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] some XFS cleanups (fwd) Message-ID: <20041208050348.GI1611@frodo> References: <20041207193533.GG7250@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207193533.GG7250@stusta.de> User-Agent: Mutt/1.5.3i X-archive-position: 4602 X-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: 956 Lines: 34 On Tue, Dec 07, 2004 at 08:35:33PM +0100, Adrian Bunk wrote: > The patch forwarded below still applies and compiles against > 2.6.10-rc2-mm4. > > Please apply. Needs a bit of tweaking yet... (apologies for not replying earlier, there's just been more pressing things to work on). > ----- Forwarded message from Adrian Bunk ----- > > Date: Sat, 30 Oct 2004 20:13:07 +0200 > From: Adrian Bunk > To: nathans@sgi.com > Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org > Subject: [2.6 patch] some XFS cleanups > > The patch below makes the following cleanups in the XFS code: > - remove the unused global function vfs_dmapiops > - remove some unused #define's These first changes aren't really useful; they make the DMAPI code more difficult to integrate and manage in our trees, for not-enough gain. > - make several functions static These are more useful - I'll merge these in, thanks. cheers. -- Nathan From owner-linux-xfs Wed Dec 8 02:46:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 02:46:47 -0800 (PST) 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 iB8AkgN2022140 for ; Wed, 8 Dec 2004 02:46:43 -0800 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 0F60C18D72B; Wed, 8 Dec 2004 11:46:20 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id A626C18D70C for ; Wed, 8 Dec 2004 11:46:19 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.13.1/8.13.1) with ESMTP id iB8AkJta005414 for ; Wed, 8 Dec 2004 11:46:19 +0100 Subject: is rename atomic in XFS, also some sync question? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 Date: Wed, 08 Dec 2004 11:46:18 +0100 Message-Id: <1102502778.3970.9.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4603 X-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: 707 Lines: 31 Hi, I want to atomically change file content. Will the scenario work?: 1. cp config.oryg config.change 2. do some changes on config.change 3. sync 4. mv config.change config.oryg 5. sync I would like to be sure that: 1. after point 3 in case of system crash the file config.change will be visible on disk and have correct data 2. after point 4 in case of system crash in config.oryg I have correct config.change or correct config.oryg data (depends when metadata are flushed) 3. after point 5 in case of system crash in config.oryg I have data from config.change Of course I assume that config.oryg and config.change are on the same filesystem. Regards, Olaf -- Olaf Frączyk From owner-linux-xfs Wed Dec 8 02:52:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 02:52:26 -0800 (PST) Received: from artinet.artcom-gmbh.de (ns1.artcom-gmbh.de [62.145.22.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB8AqNZM023170 for ; Wed, 8 Dec 2004 02:52:23 -0800 Received: from artcom10.artcom-gmbh.de (artcom10 [196.0.0.41]) by artinet.artcom-gmbh.de (8.12.10+/8.12.10) with SMTP id iB8Aq0hs008935 for ; Wed, 8 Dec 2004 11:52:00 +0100 (MET) Received: from blau.artcom-gmbh.de by artcom10.artcom-gmbh.de with esmtp (Smail3.2 #1) id m1CbzQO-016OtHC; Wed, 8 Dec 2004 11:52:00 +0100 (CET) Received: by blau.artcom-gmbh.de (Postfix, from userid 530) id 5EC6E140D8919; Wed, 8 Dec 2004 11:52:00 +0100 (CET) Date: Wed, 8 Dec 2004 11:52:00 +0100 From: Martin =?iso-8859-1?Q?Schr=F6der?= To: linux-xfs@oss.sgi.com Subject: Re: is rename atomic in XFS, also some sync question? Message-ID: <20041208105200.GQ5103@blau.artcom-gmbh.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1102502778.3970.9.camel@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1102502778.3970.9.camel@venus.local.navi.pl> User-Agent: Mutt/1.4.2.1i Organization: ArtCom GmbH, Lise-Meitner-Strasse 5, 28359 Bremen, Germany X-Disclaimer: The views expressed are my own and not necessarily that of my employers. X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iB8AqOZM023173 X-archive-position: 4604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ms@artcom-gmbh.de Precedence: bulk X-list: linux-xfs Content-Length: 460 Lines: 14 On 2004-12-08 11:46:18 +0100, Olaf Fr?czyk wrote: > 1. after point 3 in case of system crash the file config.change will be > visible on disk and have correct data Only if you disable the write cache of the disc. Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de From owner-linux-xfs Wed Dec 8 04:34:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 04:34:31 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB8CYQJ6010821 for ; Wed, 8 Dec 2004 04:34:27 -0800 Received: from traveler.cistron-office.nl ([62.216.29.67] helo=traveler) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1Cc111-0004LU-00; Wed, 08 Dec 2004 13:33:55 +0100 Date: Wed, 08 Dec 2004 12:33:51 +0000 From: Miquel van Smoorenburg Subject: Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c To: Nathan Scott Cc: Miquel van Smoorenburg , linux-xfs@oss.sgi.com References: <20041115103130.GA7971@cistron.nl> <20041117232247.GA9834@frodo> <1101386106l.15668l.0l@traveler> <20041126041132.GA1426@frodo> <1101486186l.15668l.4l@traveler> In-Reply-To: <1101486186l.15668l.4l@traveler> (from miquels@cistron.net on Fri Nov 26 17:23:06 2004) X-Mailer: Balsa 2.2.4 Message-Id: <1102509231l.23125l.0l@traveler> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; Format=Flowed Content-Disposition: inline X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iB8CYRJ6010824 X-archive-position: 4605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.net Precedence: bulk X-list: linux-xfs Content-Length: 1149 Lines: 32 On 2004.11.26 17:23, Miquel van Smoorenburg wrote: > On 2004.11.26 05:11, Nathan Scott wrote: > > I tweaked a couple of things, esp. keeping the uses of GFP flags > > together in kmem.h and xfs_buf.c and dropped the timeout. How > > does the following patch fare for you? (could you also send me > > a Signed-off-by: line for when the final patch is merged in?) > > Applied, compiled, module reloaded - looking good so far (half a day). > > > Index: xfs-linux/linux-2.6/xfs_buf.c > > =================================================================== > > --- xfs-linux.orig/linux-2.6/xfs_buf.c > > +++ xfs-linux/linux-2.6/xfs_buf.c > > The patch is reasonably trivial and you changed most lines, but feel > free to add my Signed-off-by: line to it: > > Signed-off-by: Miquel van Smoorenburg Hi Nathan, not to rush you or anything, but I was just curious as to how a patch like this gets into the actual kernel. I assume it's XFS CVS -> testing -> -mm kernel -> linus kernel ? I don't see anything in XFS CVS at http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/linux-2.6/ yet, am I looking in the right place ? Thanks, Mike. From owner-linux-xfs Wed Dec 8 05:15:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 05:16:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB8DFx9n021773 for ; Wed, 8 Dec 2004 05:15:59 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB8DFwGc021771 for linux-xfs@oss.sgi.com; Wed, 8 Dec 2004 05:15:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB8DFtd3021734 for ; Wed, 8 Dec 2004 05:15:57 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB8CuMoo019380; Wed, 8 Dec 2004 04:56:22 -0800 Date: Wed, 8 Dec 2004 04:56:22 -0800 Message-Id: <200412081256.iB8CuMoo019380@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4606 X-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: 389 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 v@gropp.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |v@gropp.org ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Dec 8 06:15:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 06:16:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB8EFwjk025134 for ; Wed, 8 Dec 2004 06:15:58 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB8EFveZ025132 for linux-xfs@oss.sgi.com; Wed, 8 Dec 2004 06:15:57 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB8EFtRX025094 for ; Wed, 8 Dec 2004 06:15:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iB8DS2s7022855; Wed, 8 Dec 2004 05:28:02 -0800 Date: Wed, 8 Dec 2004 05:28:02 -0800 Message-Id: <200412081328.iB8DS2s7022855@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-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4607 X-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: 389 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=326 v@gropp.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |v@gropp.org ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Dec 8 14:01:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 14:01:51 -0800 (PST) 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 iB8M1jmi024716 for ; Wed, 8 Dec 2004 14:01:47 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10179; Thu, 9 Dec 2004 09:01:09 +1100 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 iB8M16XE293852; Thu, 9 Dec 2004 09:01:07 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iB8M13AL293615; Thu, 9 Dec 2004 09:01:03 +1100 (EST) Date: Thu, 9 Dec 2004 09:01:03 +1100 From: Nathan Scott To: Miquel van Smoorenburg Cc: linux-xfs@oss.sgi.com Subject: Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c Message-ID: <20041209090103.C292523@wobbly.melbourne.sgi.com> References: <20041115103130.GA7971@cistron.nl> <20041117232247.GA9834@frodo> <1101386106l.15668l.0l@traveler> <20041126041132.GA1426@frodo> <1101486186l.15668l.4l@traveler> <1102509231l.23125l.0l@traveler> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1102509231l.23125l.0l@traveler>; from miquels@cistron.net on Wed, Dec 08, 2004 at 12:33:51PM +0000 X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4608 X-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: 1079 Lines: 40 Hi Mike, On Wed, Dec 08, 2004 at 12:33:51PM +0000, Miquel van Smoorenburg wrote: > On 2004.11.26 17:23, Miquel van Smoorenburg wrote: > > Hi Nathan, not to rush you or anything, but I was just curious as > to how a patch like this gets into the actual kernel. > > I assume it's XFS CVS -> testing -> -mm kernel -> linus kernel ? Its actually like this, for an XFS-only change (differs a bit if there's a core kernel change, that adds in a -mm step near the end): Testing (my machines, several days/weeks depending on the change), including nightly regression test runs. | v Internal review by other XFS developers. | v CVS on oss.sgi.com (via our internal ptools tree). | v Linus' kernel. > I don't see anything in XFS CVS at > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/linux-2.6/ > yet, am I looking in the right place ? That's the right place; the first two steps are done, I expect to push it into CVS sometime today, and I plan to merge it and several other fixes into Linus' tree later this week or early next week. cheers. -- Nathan From owner-linux-xfs Wed Dec 8 16:27:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 16:27:51 -0800 (PST) Received: from web14006.mail.yahoo.com (web14006.mail.yahoo.com [216.136.175.122]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iB90Rk5g004094 for ; Wed, 8 Dec 2004 16:27:46 -0800 Received: (qmail 40686 invoked by uid 60001); 9 Dec 2004 00:27:24 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=hC3AvY154pF9wckkhSVi0Jr58YKkltVI+vefZxCu2geRvrFtwwsdStuRbBNyeNvvWHvDJz8YUUXeGji22jtORDluzjEchAUfNB+OZ1WTGkFjg2I55iH8R2oCS41gd69z1J1j6VyjhXiEjwe2kT56Kb2EoYEaRnnDzWTtEnMzxHo= ; Message-ID: <20041209002724.40684.qmail@web14006.mail.yahoo.com> Received: from [67.122.123.121] by web14006.mail.yahoo.com via HTTP; Wed, 08 Dec 2004 16:27:24 PST Date: Wed, 8 Dec 2004 16:27:24 -0800 (PST) From: Rod Tolosa Subject: insmod xfs To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rodtolosa@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 466 Lines: 23 Hello, When kernel-2.4.18-SGI_XFS_1.1.i686.rpm is installed, ~23MB is installed in the /lib/modules/2.4.18-SGI_XFS_1.1 directory. How do I install the XFS module at this point. It's not apparent what the xfs module .o file is. I didnt't see any README file explaining what to do next. Please help. Thanks, ~Rod __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From owner-linux-xfs Wed Dec 8 17:13:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 17:13:19 -0800 (PST) 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 iB91DBPv006767 for ; Wed, 8 Dec 2004 17:13:13 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iB91CiD11676 for linux-xfs@oss.sgi.com; Thu, 9 Dec 2004 12:12:44 +1100 Date: Thu, 9 Dec 2004 12:12:44 +1100 From: Nathan Scott Message-Id: <200412090112.iB91CiD11676@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 914873 - low memory allocation improvements X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4610 X-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: 845 Lines: 23 Low memory allocation improvements (quietness and blk congestion checks). Signed-off-by: Miquel van Smoorenburg Date: Thu Dec 9 12:11:41 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20564a linux-2.6/xfs_buf.c - 1.181 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.181&r2=text&tr2=1.180&f=h linux-2.6/kmem.h - 1.27 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h linux-2.6/kmem.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - Low memory allocation improvements. From owner-linux-xfs Wed Dec 8 17:16:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Dec 2004 17:16:58 -0800 (PST) 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 iB91Gtg4007348 for ; Wed, 8 Dec 2004 17:16:56 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iB91GSG11786 for linux-xfs@oss.sgi.com; Thu, 9 Dec 2004 12:16:28 +1100 Date: Thu, 9 Dec 2004 12:16:28 +1100 From: Nathan Scott Message-Id: <200412090116.iB91GSG11786@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - trivial cleanups X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4611 X-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: 689 Lines: 21 Mark several functions as being static. Signed-off-by: Adrian Bunk Date: Thu Dec 9 12:15:43 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: nathans@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20565a linux-2.6/xfs_super.c - 1.321 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.321&r2=text&tr2=1.320&f=h linux-2.6/xfs_buf.c - 1.182 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.182&r2=text&tr2=1.181&f=h - Mark several functions as being static. From owner-linux-xfs Thu Dec 9 07:19:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Dec 2004 07:19:39 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iB9FJZbi003033 for ; Thu, 9 Dec 2004 07:19:36 -0800 Received: (qmail 16570 invoked by uid 65534); 9 Dec 2004 15:19:07 -0000 Received: from G1f91.g.pppool.de (EHLO [192.168.10.11]) (80.185.31.145) by mail.gmx.net (mp006) with SMTP; 09 Dec 2004 16:19:07 +0100 X-Authenticated: #2986359 Message-ID: <41B86CE4.5010609@gmx.net> Date: Thu, 09 Dec 2004 16:19:00 +0100 From: Christian User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Rod Tolosa Subject: Re: insmod xfs References: <20041209002724.40684.qmail@web14006.mail.yahoo.com> In-Reply-To: <20041209002724.40684.qmail@web14006.mail.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4612 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 14 Rod Tolosa schrieb: > Hello, > > When kernel-2.4.18-SGI_XFS_1.1.i686.rpm is installed, > ~23MB is installed > in the /lib/modules/2.4.18-SGI_XFS_1.1 directory. > > How do I install the XFS module at this point. AFAICS, XFS is statically compiled into the kernel. no need for insmod, no need for xfs.o being present. Christian. From owner-linux-xfs Thu Dec 9 15:15:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Dec 2004 15:15:35 -0800 (PST) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB9NFW3S004810 for ; Thu, 9 Dec 2004 15:15:33 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.42 #1 (Red Hat Linux)) id 1CcXV8-0005u5-4l; Thu, 09 Dec 2004 23:15:10 +0000 Date: Thu, 9 Dec 2004 23:15:10 +0000 From: Christoph Hellwig To: Nathan Scott Cc: linux-xfs@oss.sgi.com, agruen@suse.de Subject: Re: TAKE 907752 - acl/attr Message-ID: <20041209231510.GA22618@infradead.org> References: <200411300535.iAU5ZD1H1131214@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411300535.iAU5ZD1H1131214@snort.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4613 X-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: 266 Lines: 6 On Tue, Nov 30, 2004 at 04:35:13PM +1100, Nathan Scott wrote: > License and email address updates from Andreas. Hmm, any reason COPYING is the LGPL 2.1 but the individual sources files say LGPL 2 or later? Also the empty LICENSE files should probably be removed. From owner-linux-xfs Thu Dec 9 15:28:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Dec 2004 15:28:28 -0800 (PST) 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 iB9NSOKd006312 for ; Thu, 9 Dec 2004 15:28:25 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08635; Fri, 10 Dec 2004 10:27:50 +1100 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 iB9NRjXE322382; Fri, 10 Dec 2004 10:27:45 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iB9NReGW323110; Fri, 10 Dec 2004 10:27:40 +1100 (EST) Date: Fri, 10 Dec 2004 10:27:40 +1100 From: Nathan Scott To: Christoph Hellwig , agruen@suse.de, cattelan@xfs.org Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 907752 - acl/attr Message-ID: <20041210102739.A322537@wobbly.melbourne.sgi.com> References: <200411300535.iAU5ZD1H1131214@snort.melbourne.sgi.com> <20041209231510.GA22618@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20041209231510.GA22618@infradead.org>; from hch@infradead.org on Thu, Dec 09, 2004 at 11:15:10PM +0000 X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4614 X-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: 545 Lines: 16 On Thu, Dec 09, 2004 at 11:15:10PM +0000, Christoph Hellwig wrote: > On Tue, Nov 30, 2004 at 04:35:13PM +1100, Nathan Scott wrote: > > License and email address updates from Andreas. > > Hmm, any reason COPYING is the LGPL 2.1 but the individual sources files > say LGPL 2 or later? Also the empty LICENSE files should probably be removed. It (COPYING) was copied over from attr - which version do you want to use, Andreas? The LICENSE file is gone from our tree, so I think shouldn't still be there in CVS -- Russell? cheers. -- Nathan From owner-linux-xfs Thu Dec 9 23:09:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Dec 2004 23:09:39 -0800 (PST) Received: from ygw07.jvc-victor.co.jp (ygw07.jvc-victor.co.jp [61.209.242.186]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBA79Zrh003191 for ; Thu, 9 Dec 2004 23:09:36 -0800 Received: from unknown (HELO ycm05.jvc-victor.co.jp) (136.198.180.101) by ygw07.jvc-victor.co.jp with ESMTP; 10 Dec 2004 16:09:13 +0900 Received: (from root@localhost) by ycm05.jvc-victor.co.jp (8.11.6/8.11.6) id iBA79CB10732; Fri, 10 Dec 2004 16:09:12 +0900 Received: from ycf02.jvc-victor.co.jp [136.198.212.103] by ycm05.jvc-victor.co.jp with ESMTP id SAA10731; Fri, 10 Dec 2004 16:09:12 +0900 In-Reply-To: <20041207001319.GB993@frodo> References: <20041207001319.GB993@frodo> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6461348A-4A7A-11D9-A8C7-003065E619BC@jvc-victor.jp> Content-Transfer-Encoding: 7bit Cc: linux-xfs@oss.sgi.com From: Sakai Yasutoshi Subject: Re: Process stuck in R state at extent = 2049 Date: Fri, 10 Dec 2004 16:09:11 +0900 To: Nathan Scott X-Mailer: Apple Mail (2.619) X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sakai-yasutoshi@jvc-victor.jp Precedence: bulk X-list: linux-xfs Content-Length: 1121 Lines: 40 On 2004/12/07, at 9:13, Nathan Scott wrote: > On Mon, Dec 06, 2004 at 11:24:34AM +0900, Sakai Yasutoshi wrote: >> Hi. >> >> We are running linux 2.4.26 on IBM PPC405GP. >> >> Sometimes our process stuck in 'R' state when number of extent reaches >> 2049. >> And disk cache is freed at same time, so we have 40Mbyte of free >> memory, >> but we get kernel message "kernel: __alloc_pages: 4-order allocation >> failed (gfp=0xf0/0)". >> >> Process reverts to normal state after 5 seconds to 20 minutes once in >> a >> while. >> >> is this XFS problem? > > Sort of; XFS has a tendency of asking for contiguous pages, > and the VM has a tendency of not being able to satisfy such > requests -- you might have more luck with a CVS 2.4 kernel, > in particular the split-patches/cache_defs patch there adds > a mechanism for 2.4 kernels to be able to do memory shaking > which the XFS code can plug into. 2.6 provides a mechanism > like that, without need for patching (fwiw). > It seems this patch fixes our problem. Does XFS need more contiguous pages especially when extents reachs 2049? Thanks. -- Yasutoshi Sakai From owner-linux-xfs Thu Dec 9 23:50:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Dec 2004 23:50:39 -0800 (PST) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBA7oW9a005206 for ; Thu, 9 Dec 2004 23:50:33 -0800 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id D4B6411F43EF; Fri, 10 Dec 2004 08:49:56 +0100 (CET) From: Andreas Gruenbacher To: Nathan Scott Subject: Re: TAKE 907752 - acl/attr Date: Fri, 10 Dec 2004 08:50:39 +0100 User-Agent: KMail/1.7.1 Cc: Christoph Hellwig , cattelan@xfs.org, linux-xfs@oss.sgi.com References: <200411300535.iAU5ZD1H1131214@snort.melbourne.sgi.com> <20041209231510.GA22618@infradead.org> <20041210102739.A322537@wobbly.melbourne.sgi.com> In-Reply-To: <20041210102739.A322537@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412100850.40031.agruen@suse.de> X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 634 Lines: 19 On Friday 10 December 2004 00:27, Nathan Scott wrote: > On Thu, Dec 09, 2004 at 11:15:10PM +0000, Christoph Hellwig wrote: > > On Tue, Nov 30, 2004 at 04:35:13PM +1100, Nathan Scott wrote: > > > License and email address updates from Andreas. > > > > Hmm, any reason COPYING is the LGPL 2.1 but the individual sources files > > say LGPL 2 or later? Also the empty LICENSE files should probably be > > removed. > > It (COPYING) was copied over from attr - which version do you > want to use, Andreas? It should be the GNU Lesser General Public License 2.1. Cheers, -- Andreas Gruenbacher SUSE Labs, SUSE LINUX AG From owner-linux-xfs Fri Dec 10 03:13:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Dec 2004 03:14:00 -0800 (PST) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBABDqtT018933 for ; Fri, 10 Dec 2004 03:13:55 -0800 Received: from barclay.balt.net (evaldas@barclay.balt.net [195.14.162.78]) by barclay.balt.net (8.13.1/8.13.1/Debian-15) with ESMTP id iBAB9Zxr027833 for ; Fri, 10 Dec 2004 13:09:35 +0200 Date: Fri, 10 Dec 2004 13:09:35 +0200 (EET) From: Evaldas Darcianovas To: linux-xfs@oss.sgi.com Subject: kernel 2.6.9 oops in XFS Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="247680674-978388123-1102676975=:27530" X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4617 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evaldas@balt.net Precedence: bulk X-list: linux-xfs Content-Length: 36233 Lines: 586 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --247680674-978388123-1102676975=:27530 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi This FTP server running vanilla 2.6.9, XFS on 1TB 3ware RAID array. For the third time it happens under heavy disk i/o load. Earlier I was using JFS for the same hardware/software configuration and experienced no problems so I guess this is not hardware related. Kernel config is attached below. Dec 9 20:48:29 ll kernel: Unable to handle kernel paging request at virtual address 00017fa3 Dec 9 20:48:29 ll kernel: printing eip: Dec 9 20:48:29 ll kernel: f8a08bd3 Dec 9 20:48:29 ll kernel: *pde = 00000000 Dec 9 20:48:29 ll kernel: Oops: 0000 [#1] Dec 9 20:48:29 ll kernel: Modules linked in: nfsd exportfs nfs lockd sunrpc e100 mii sk98lin unix xfs Dec 9 20:48:29 ll kernel: CPU: 0 Dec 9 20:48:29 ll kernel: EIP: 0060:[pg0+946793427/1070482432] Not tainted VLI Dec 9 20:48:29 ll kernel: EFLAGS: 00010283 (2.6.9) Dec 9 20:48:29 ll kernel: EIP is at _pagebuf_map_pages+0x1d/0x8f [xfs] Dec 9 20:48:29 ll kernel: eax: 0000fe0b ebx: ed634d80 ecx: c1243677 edx: 00018001 Dec 9 20:48:29 ll kernel: esi: ed634d80 edi: 00018001 ebp: 00000000 esp: c1b477ec Dec 9 20:48:29 ll kernel: ds: 007b es: 007b ss: 0068 Dec 9 20:48:29 ll kernel: Process pdflush (pid: 7, threadinfo=c1b47000 task=c1b46aa0) Dec 9 20:48:29 ll kernel: Stack: c012d95d 00000001 f8a08f1f 00000200 00018001 ed634d80 7a441001 00000000 Dec 9 20:48:29 ll kernel: 00018001 00000000 7a441001 f89fc4d7 00000001 00018001 00000200 f7d31b80 Dec 9 20:48:29 ll kernel: c738fcf4 f7dfc400 7a441001 00000000 f7dfc400 0000001c f89b185d 7a441001 Dec 9 20:48:29 ll kernel: Call Trace: Dec 9 20:48:29 ll kernel: [mark_page_accessed+40/46] mark_page_accessed+0x28/0x2e Dec 9 20:48:29 ll kernel: [pg0+946794271/1070482432] pagebuf_get+0x100/0x144 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946742487/1070482432] xfs_trans_read_buf+0x152/0x2e1 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946436189/1070482432] xfs_alloc_read_agf+0x95/0x1a6 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946435289/1070482432] xfs_alloc_fix_freelist+0x37f/0x401 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946743296/1070482432] xfs_trans_log_buf+0x5f/0x91 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946435744/1070482432] xfs_alloc_log_agf+0x47/0x53 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946437082/1070482432] xfs_alloc_vextent+0x26c/0x464 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946493964/1070482432] xfs_bmap_alloc+0x96c/0x172d [xfs] Dec 9 20:48:29 ll kernel: [buffered_rmqueue+198/337] buffered_rmqueue+0xc6/0x151 Dec 9 20:48:29 ll kernel: [pg0+946537158/1070482432] xfs_bmbt_get_state+0x12/0x28 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946509705/1070482432] xfs_bmapi+0x585/0x1606 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946688165/1070482432] xlog_grant_push_ail+0x45/0x15d [xfs] Dec 9 20:48:29 ll kernel: [pg0+946506753/1070482432] xfs_bmap_last_offset+0x26/0xf8 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946674217/1070482432] xfs_iomap_write_allocate+0x255/0x4ac [xfs] Dec 9 20:48:29 ll kernel: [mempool_alloc+99/257] mempool_alloc+0x63/0x101 Dec 9 20:48:29 ll kernel: [pg0+946669781/1070482432] xfs_iomap+0x38b/0x4a0 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946786319/1070482432] xfs_map_blocks+0x45/0x68 [xfs] Dec 9 20:48:29 ll kernel: [pg0+946789834/1070482432] xfs_page_state_convert+0x439/0x542 [xfs] Dec 9 20:48:29 ll kernel: [__generic_unplug_device+45/47] __generic_unplug_device+0x2d/0x2f Dec 9 20:48:29 ll kernel: [radix_tree_gang_lookup_tag+73/97] radix_tree_gang_lookup_tag+0x49/0x61 Dec 9 20:48:29 ll kernel: [pg0+946791531/1070482432] linvfs_writepage+0x5b/0xd8 [xfs] Dec 9 20:48:29 ll kernel: [mpage_writepages+584/881] mpage_writepages+0x248/0x371 Dec 9 20:48:29 ll kernel: [pg0+946791440/1070482432] linvfs_writepage+0x0/0xd8 [xfs] Dec 9 20:48:29 ll kernel: [__sync_single_inode+78/452] __sync_single_inode+0x4e/0x1c4 Dec 9 20:48:29 ll kernel: [sync_sb_inodes+384/587] sync_sb_inodes+0x180/0x24b Dec 9 20:48:29 ll kernel: [pdflush+0/30] pdflush+0x0/0x1e Dec 9 20:48:29 ll kernel: [writeback_inodes+127/129] writeback_inodes+0x7f/0x81 Dec 9 20:48:29 ll kernel: [wb_kupdate+130/237] wb_kupdate+0x82/0xed Dec 9 20:48:29 ll kernel: [__pdflush+150/327] __pdflush+0x96/0x147 Dec 9 20:48:29 ll kernel: [pdflush+26/30] pdflush+0x1a/0x1e Dec 9 20:48:29 ll kernel: [wb_kupdate+0/237] wb_kupdate+0x0/0xed Dec 9 20:48:29 ll kernel: [pdflush+0/30] pdflush+0x0/0x1e Dec 9 20:48:29 ll kernel: [kthread+144/149] kthread+0x90/0x95 Dec 9 20:48:29 ll kernel: [kthread+0/149] kthread+0x0/0x95 Dec 9 20:48:29 ll kernel: [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb Dec 9 20:48:29 ll kernel: Code: 54 24 22 66 3b 96 ba 3f 00 00 72 d9 eb cd 83 ec 08 89 5c 24 04 89 c3 0f b7 80 ba 00 00 00 66 3f f8 01 74 61 80 e2 04 3f 44 83 3d 57 a2 f8 40 7f 45 8b 0d 38 f9 26 c0 0f b7 d0 8b 83 c0 00 3f --247680674-978388123-1102676975=:27530 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=pilkas_config Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=pilkas_config Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBtYWtlIGNvbmZpZzogZG9u J3QgZWRpdA0KIyBMaW51eCBrZXJuZWwgdmVyc2lvbjogMi42LjkNCiMgV2Vk IERlYyAgOCAxMTowNzowNCAyMDA0DQojDQpDT05GSUdfWDg2PXkNCkNPTkZJ R19NTVU9eQ0KQ09ORklHX1VJRDE2PXkNCkNPTkZJR19HRU5FUklDX0lTQV9E TUE9eQ0KQ09ORklHX0dFTkVSSUNfSU9NQVA9eQ0KDQojDQojIENvZGUgbWF0 dXJpdHkgbGV2ZWwgb3B0aW9ucw0KIw0KQ09ORklHX0VYUEVSSU1FTlRBTD15 DQpDT05GSUdfQ0xFQU5fQ09NUElMRT15DQpDT05GSUdfQlJPS0VOX09OX1NN UD15DQoNCiMNCiMgR2VuZXJhbCBzZXR1cA0KIw0KQ09ORklHX0xPQ0FMVkVS U0lPTj0iIg0KQ09ORklHX1NXQVA9eQ0KQ09ORklHX1NZU1ZJUEM9eQ0KIyBD T05GSUdfUE9TSVhfTVFVRVVFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JTRF9Q Uk9DRVNTX0FDQ1QgaXMgbm90IHNldA0KQ09ORklHX1NZU0NUTD15DQojIENP TkZJR19BVURJVCBpcyBub3Qgc2V0DQpDT05GSUdfTE9HX0JVRl9TSElGVD0x NA0KIyBDT05GSUdfSE9UUExVRyBpcyBub3Qgc2V0DQpDT05GSUdfSUtDT05G SUc9eQ0KQ09ORklHX0lLQ09ORklHX1BST0M9eQ0KIyBDT05GSUdfRU1CRURE RUQgaXMgbm90IHNldA0KQ09ORklHX0tBTExTWU1TPXkNCiMgQ09ORklHX0tB TExTWU1TX0VYVFJBX1BBU1MgaXMgbm90IHNldA0KQ09ORklHX0ZVVEVYPXkN CkNPTkZJR19FUE9MTD15DQpDT05GSUdfSU9TQ0hFRF9OT09QPXkNCkNPTkZJ R19JT1NDSEVEX0FTPXkNCkNPTkZJR19JT1NDSEVEX0RFQURMSU5FPXkNCkNP TkZJR19JT1NDSEVEX0NGUT15DQojIENPTkZJR19DQ19PUFRJTUlaRV9GT1Jf U0laRSBpcyBub3Qgc2V0DQpDT05GSUdfU0hNRU09eQ0KIyBDT05GSUdfVElO WV9TSE1FTSBpcyBub3Qgc2V0DQoNCiMNCiMgTG9hZGFibGUgbW9kdWxlIHN1 cHBvcnQNCiMNCkNPTkZJR19NT0RVTEVTPXkNCkNPTkZJR19NT0RVTEVfVU5M T0FEPXkNCiMgQ09ORklHX01PRFVMRV9GT1JDRV9VTkxPQUQgaXMgbm90IHNl dA0KQ09ORklHX09CU09MRVRFX01PRFBBUk09eQ0KQ09ORklHX01PRFZFUlNJ T05TPXkNCiMgQ09ORklHX0tNT0QgaXMgbm90IHNldA0KDQojDQojIFByb2Nl c3NvciB0eXBlIGFuZCBmZWF0dXJlcw0KIw0KQ09ORklHX1g4Nl9QQz15DQoj IENPTkZJR19YODZfRUxBTiBpcyBub3Qgc2V0DQojIENPTkZJR19YODZfVk9Z QUdFUiBpcyBub3Qgc2V0DQojIENPTkZJR19YODZfTlVNQVEgaXMgbm90IHNl dA0KIyBDT05GSUdfWDg2X1NVTU1JVCBpcyBub3Qgc2V0DQojIENPTkZJR19Y ODZfQklHU01QIGlzIG5vdCBzZXQNCiMgQ09ORklHX1g4Nl9WSVNXUyBpcyBu b3Qgc2V0DQojIENPTkZJR19YODZfR0VORVJJQ0FSQ0ggaXMgbm90IHNldA0K IyBDT05GSUdfWDg2X0VTNzAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19NMzg2 IGlzIG5vdCBzZXQNCiMgQ09ORklHX000ODYgaXMgbm90IHNldA0KIyBDT05G SUdfTTU4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2VFNDIGlzIG5vdCBz ZXQNCiMgQ09ORklHX001ODZNTVggaXMgbm90IHNldA0KIyBDT05GSUdfTTY4 NiBpcyBub3Qgc2V0DQojIENPTkZJR19NUEVOVElVTUlJIGlzIG5vdCBzZXQN CiMgQ09ORklHX01QRU5USVVNSUlJIGlzIG5vdCBzZXQNCiMgQ09ORklHX01Q RU5USVVNTSBpcyBub3Qgc2V0DQpDT05GSUdfTVBFTlRJVU00PXkNCiMgQ09O RklHX01LNiBpcyBub3Qgc2V0DQojIENPTkZJR19NSzcgaXMgbm90IHNldA0K IyBDT05GSUdfTUs4IGlzIG5vdCBzZXQNCiMgQ09ORklHX01DUlVTT0UgaXMg bm90IHNldA0KIyBDT05GSUdfTVdJTkNISVBDNiBpcyBub3Qgc2V0DQojIENP TkZJR19NV0lOQ0hJUDIgaXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNISVAz RCBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1lSSVhJSUkgaXMgbm90IHNldA0K IyBDT05GSUdfTVZJQUMzXzIgaXMgbm90IHNldA0KQ09ORklHX1g4Nl9HRU5F UklDPXkNCkNPTkZJR19YODZfQ01QWENIRz15DQpDT05GSUdfWDg2X1hBREQ9 eQ0KQ09ORklHX1g4Nl9MMV9DQUNIRV9TSElGVD03DQpDT05GSUdfUldTRU1f WENIR0FERF9BTEdPUklUSE09eQ0KQ09ORklHX1g4Nl9XUF9XT1JLU19PSz15 DQpDT05GSUdfWDg2X0lOVkxQRz15DQpDT05GSUdfWDg2X0JTV0FQPXkNCkNP TkZJR19YODZfUE9QQURfT0s9eQ0KQ09ORklHX1g4Nl9HT09EX0FQSUM9eQ0K Q09ORklHX1g4Nl9JTlRFTF9VU0VSQ09QWT15DQpDT05GSUdfWDg2X1VTRV9Q UFJPX0NIRUNLU1VNPXkNCiMgQ09ORklHX0hQRVRfVElNRVIgaXMgbm90IHNl dA0KIyBDT05GSUdfU01QIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BSRUVNUFQg aXMgbm90IHNldA0KIyBDT05GSUdfWDg2X1VQX0FQSUMgaXMgbm90IHNldA0K Q09ORklHX1g4Nl9UU0M9eQ0KQ09ORklHX1g4Nl9NQ0U9eQ0KIyBDT05GSUdf WDg2X01DRV9OT05GQVRBTCBpcyBub3Qgc2V0DQojIENPTkZJR19UT1NISUJB IGlzIG5vdCBzZXQNCiMgQ09ORklHX0k4SyBpcyBub3Qgc2V0DQojIENPTkZJ R19NSUNST0NPREUgaXMgbm90IHNldA0KIyBDT05GSUdfWDg2X01TUiBpcyBu b3Qgc2V0DQojIENPTkZJR19YODZfQ1BVSUQgaXMgbm90IHNldA0KDQojDQoj IEZpcm13YXJlIERyaXZlcnMNCiMNCiMgQ09ORklHX0VERCBpcyBub3Qgc2V0 DQojIENPTkZJR19OT0hJR0hNRU0gaXMgbm90IHNldA0KQ09ORklHX0hJR0hN RU00Rz15DQojIENPTkZJR19ISUdITUVNNjRHIGlzIG5vdCBzZXQNCkNPTkZJ R19ISUdITUVNPXkNCiMgQ09ORklHX0hJR0hQVEUgaXMgbm90IHNldA0KIyBD T05GSUdfTUFUSF9FTVVMQVRJT04gaXMgbm90IHNldA0KQ09ORklHX01UUlI9 eQ0KQ09ORklHX1JFR1BBUk09eQ0KDQojDQojIFBvd2VyIG1hbmFnZW1lbnQg b3B0aW9ucyAoQUNQSSwgQVBNKQ0KIw0KIyBDT05GSUdfUE0gaXMgbm90IHNl dA0KIyBDT05GSUdfUE1fREVCVUcgaXMgbm90IHNldA0KDQojDQojIEFDUEkg KEFkdmFuY2VkIENvbmZpZ3VyYXRpb24gYW5kIFBvd2VyIEludGVyZmFjZSkg U3VwcG9ydA0KIw0KIyBDT05GSUdfQUNQSSBpcyBub3Qgc2V0DQpDT05GSUdf QUNQSV9CTEFDS0xJU1RfWUVBUj0wDQoNCiMNCiMgQ1BVIEZyZXF1ZW5jeSBz Y2FsaW5nDQojDQojIENPTkZJR19DUFVfRlJFUSBpcyBub3Qgc2V0DQoNCiMN CiMgQnVzIG9wdGlvbnMgKFBDSSwgUENNQ0lBLCBFSVNBLCBNQ0EsIElTQSkN CiMNCkNPTkZJR19QQ0k9eQ0KIyBDT05GSUdfUENJX0dPQklPUyBpcyBub3Qg c2V0DQojIENPTkZJR19QQ0lfR09NTUNPTkZJRyBpcyBub3Qgc2V0DQojIENP TkZJR19QQ0lfR09ESVJFQ1QgaXMgbm90IHNldA0KQ09ORklHX1BDSV9HT0FO WT15DQpDT05GSUdfUENJX0JJT1M9eQ0KQ09ORklHX1BDSV9ESVJFQ1Q9eQ0K IyBDT05GSUdfUENJX0xFR0FDWV9QUk9DIGlzIG5vdCBzZXQNCkNPTkZJR19Q Q0lfTkFNRVM9eQ0KIyBDT05GSUdfSVNBIGlzIG5vdCBzZXQNCiMgQ09ORklH X01DQSBpcyBub3Qgc2V0DQojIENPTkZJR19TQ3gyMDAgaXMgbm90IHNldA0K DQojDQojIEV4ZWN1dGFibGUgZmlsZSBmb3JtYXRzDQojDQpDT05GSUdfQklO Rk1UX0VMRj15DQojIENPTkZJR19CSU5GTVRfQU9VVCBpcyBub3Qgc2V0DQpD T05GSUdfQklORk1UX01JU0M9bQ0KDQojDQojIERldmljZSBEcml2ZXJzDQoj DQoNCiMNCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucw0KIw0KQ09ORklHX1NU QU5EQUxPTkU9eQ0KQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJTEQ9eQ0K DQojDQojIE1lbW9yeSBUZWNobm9sb2d5IERldmljZXMgKE1URCkNCiMNCiMg Q09ORklHX01URCBpcyBub3Qgc2V0DQoNCiMNCiMgUGFyYWxsZWwgcG9ydCBz dXBwb3J0DQojDQojIENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQNCg0KIw0K IyBQbHVnIGFuZCBQbGF5IHN1cHBvcnQNCiMNCg0KIw0KIyBCbG9jayBkZXZp Y2VzDQojDQpDT05GSUdfQkxLX0RFVl9GRD1tDQojIENPTkZJR19CTEtfQ1BR X0RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBu b3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0RBQzk2MCBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX1VNRU0gaXMgbm90IHNldA0KQ09ORklHX0JMS19E RVZfTE9PUD1tDQpDT05GSUdfQkxLX0RFVl9DUllQVE9MT09QPW0NCkNPTkZJ R19CTEtfREVWX05CRD1tDQojIENPTkZJR19CTEtfREVWX1NYOCBpcyBub3Qg c2V0DQpDT05GSUdfQkxLX0RFVl9SQU09bQ0KQ09ORklHX0JMS19ERVZfUkFN X1NJWkU9ODE5Mg0KQ09ORklHX0xCRD15DQoNCiMNCiMgQVRBL0FUQVBJL01G TS9STEwgc3VwcG9ydA0KIw0KQ09ORklHX0lERT15DQpDT05GSUdfQkxLX0RF Vl9JREU9eQ0KDQojDQojIFBsZWFzZSBzZWUgRG9jdW1lbnRhdGlvbi9pZGUu dHh0IGZvciBoZWxwL2luZm8gb24gSURFIGRyaXZlcw0KIw0KIyBDT05GSUdf QkxLX0RFVl9JREVfU0FUQSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X0hEX0lERSBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9JREVESVNLPXkN CiMgQ09ORklHX0lERURJU0tfTVVMVElfTU9ERSBpcyBub3Qgc2V0DQpDT05G SUdfQkxLX0RFVl9JREVDRD1tDQojIENPTkZJR19CTEtfREVWX0lERVRBUEUg aXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVGTE9QUFkgaXMgbm90 IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVTQ1NJIGlzIG5vdCBzZXQNCiMg Q09ORklHX0lERV9UQVNLX0lPQ1RMIGlzIG5vdCBzZXQNCkNPTkZJR19JREVf VEFTS0ZJTEVfSU89eQ0KDQojDQojIElERSBjaGlwc2V0IHN1cHBvcnQvYnVn Zml4ZXMNCiMNCkNPTkZJR19JREVfR0VORVJJQz15DQojIENPTkZJR19CTEtf REVWX0NNRDY0MCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9JREVQQ0k9 eQ0KQ09ORklHX0lERVBDSV9TSEFSRV9JUlE9eQ0KIyBDT05GSUdfQkxLX0RF Vl9PRkZCT0FSRCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9HRU5FUklD PXkNCiMgQ09ORklHX0JMS19ERVZfT1BUSTYyMSBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX1JaMTAwMCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RF Vl9JREVETUFfUENJPXkNCiMgQ09ORklHX0JMS19ERVZfSURFRE1BX0ZPUkNF RCBpcyBub3Qgc2V0DQpDT05GSUdfSURFRE1BX1BDSV9BVVRPPXkNCiMgQ09O RklHX0lERURNQV9PTkxZRElTSyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0FFQzYyWFggaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9BTEkx NVgzIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQU1ENzRYWCBpcyBu b3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0FUSUlYUCBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX0NNRDY0WCBpcyBub3Qgc2V0DQojIENPTkZJR19C TEtfREVWX1RSSUZMRVggaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9D WTgyQzY5MyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NTNTUyMCBp cyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NTNTUzMCBpcyBub3Qgc2V0 DQojIENPTkZJR19CTEtfREVWX0hQVDM0WCBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0hQVDM2NiBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X1NDMTIwMCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9QSUlYPXkNCiMg Q09ORklHX0JMS19ERVZfTlM4NzQxNSBpcyBub3Qgc2V0DQojIENPTkZJR19C TEtfREVWX1BEQzIwMlhYX09MRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX1BEQzIwMlhYX05FVyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X1NWV0tTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU0lJTUFHRSBp cyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1NJUzU1MTMgaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9TTEM5MEU2NiBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX1RSTTI5MCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX1ZJQTgyQ1hYWCBpcyBub3Qgc2V0DQojIENPTkZJR19JREVfQVJNIGlz IG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERURNQT15DQojIENPTkZJR19J REVETUFfSVZCIGlzIG5vdCBzZXQNCkNPTkZJR19JREVETUFfQVVUTz15DQoj IENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQNCg0KIw0KIyBTQ1NJIGRl dmljZSBzdXBwb3J0DQojDQpDT05GSUdfU0NTST15DQpDT05GSUdfU0NTSV9Q Uk9DX0ZTPXkNCg0KIw0KIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFw ZSwgQ0QtUk9NKQ0KIw0KQ09ORklHX0JMS19ERVZfU0Q9eQ0KIyBDT05GSUdf Q0hSX0RFVl9TVCBpcyBub3Qgc2V0DQojIENPTkZJR19DSFJfREVWX09TU1Qg aXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9TUiBpcyBub3Qgc2V0DQoj IENPTkZJR19DSFJfREVWX1NHIGlzIG5vdCBzZXQNCg0KIw0KIyBTb21lIFND U0kgZGV2aWNlcyAoZS5nLiBDRCBqdWtlYm94KSBzdXBwb3J0IG11bHRpcGxl IExVTnMNCiMNCkNPTkZJR19TQ1NJX01VTFRJX0xVTj15DQpDT05GSUdfU0NT SV9DT05TVEFOVFM9eQ0KQ09ORklHX1NDU0lfTE9HR0lORz15DQoNCiMNCiMg U0NTSSBUcmFuc3BvcnQgQXR0cmlidXRlcw0KIw0KIyBDT05GSUdfU0NTSV9T UElfQVRUUlMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9GQ19BVFRSUyBp cyBub3Qgc2V0DQoNCiMNCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycw0KIw0K Q09ORklHX0JMS19ERVZfM1dfWFhYWF9SQUlEPXkNCiMgQ09ORklHX1NDU0lf M1dfOVhYWCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FDQVJEIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfQUFDUkFJRCBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJX0FJQzdYWFggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9B SUM3WFhYX09MRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FJQzc5WFgg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9EUFRfSTJPIGlzIG5vdCBzZXQN CiMgQ09ORklHX01FR0FSQUlEX05FV0dFTiBpcyBub3Qgc2V0DQojIENPTkZJ R19NRUdBUkFJRF9MRUdBQ1kgaXMgbm90IHNldA0KQ09ORklHX1NDU0lfU0FU QT15DQojIENPTkZJR19TQ1NJX1NBVEFfU1ZXIGlzIG5vdCBzZXQNCkNPTkZJ R19TQ1NJX0FUQV9QSUlYPW0NCiMgQ09ORklHX1NDU0lfU0FUQV9OViBpcyBu b3Qgc2V0DQojIENPTkZJR19TQ1NJX1NBVEFfUFJPTUlTRSBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX1NBVEFfU1g0IGlzIG5vdCBzZXQNCiMgQ09ORklH X1NDU0lfU0FUQV9TSUwgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9TQVRB X1NJUyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1NBVEFfVklBIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfU0FUQV9WSVRFU1NFIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfQlVTTE9HSUMgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9ETVgzMTkxRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0VBVEEg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9FQVRBX1BJTyBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9HRFRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSVBT IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSU5JQTEwMCBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX1NZTTUzQzhYWF8yIGlzIG5vdCBzZXQNCiMgQ09O RklHX1NDU0lfSVBSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxPR0lD X0lTUCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMT0dJQ19GQyBpcyBu b3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMT0dJQ18xMjgwIGlzIG5vdCBzZXQN CkNPTkZJR19TQ1NJX1FMQTJYWFg9eQ0KIyBDT05GSUdfU0NTSV9RTEEyMVhY IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxBMjJYWCBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX1FMQTIzMDAgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9RTEEyMzIyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxBNjMx MiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMQTYzMjIgaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9EQzM5NXggaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9EQzM5MFQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9OU1AzMiBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0RFQlVHIGlzIG5vdCBzZXQNCg0K Iw0KIyBNdWx0aS1kZXZpY2Ugc3VwcG9ydCAoUkFJRCBhbmQgTFZNKQ0KIw0K IyBDT05GSUdfTUQgaXMgbm90IHNldA0KDQojDQojIEZ1c2lvbiBNUFQgZGV2 aWNlIHN1cHBvcnQNCiMNCiMgQ09ORklHX0ZVU0lPTiBpcyBub3Qgc2V0DQoN CiMNCiMgSUVFRSAxMzk0IChGaXJlV2lyZSkgc3VwcG9ydA0KIw0KIyBDT05G SUdfSUVFRTEzOTQgaXMgbm90IHNldA0KDQojDQojIEkyTyBkZXZpY2Ugc3Vw cG9ydA0KIw0KIyBDT05GSUdfSTJPIGlzIG5vdCBzZXQNCg0KIw0KIyBOZXR3 b3JraW5nIHN1cHBvcnQNCiMNCkNPTkZJR19ORVQ9eQ0KDQojDQojIE5ldHdv cmtpbmcgb3B0aW9ucw0KIw0KQ09ORklHX1BBQ0tFVD1tDQpDT05GSUdfUEFD S0VUX01NQVA9eQ0KIyBDT05GSUdfTkVUTElOS19ERVYgaXMgbm90IHNldA0K Q09ORklHX1VOSVg9bQ0KQ09ORklHX05FVF9LRVk9bQ0KQ09ORklHX0lORVQ9 eQ0KQ09ORklHX0lQX01VTFRJQ0FTVD15DQojIENPTkZJR19JUF9BRFZBTkNF RF9ST1VURVIgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfUE5QIGlzIG5vdCBz ZXQNCkNPTkZJR19ORVRfSVBJUD1tDQojIENPTkZJR19ORVRfSVBHUkUgaXMg bm90IHNldA0KIyBDT05GSUdfSVBfTVJPVVRFIGlzIG5vdCBzZXQNCiMgQ09O RklHX0FSUEQgaXMgbm90IHNldA0KQ09ORklHX1NZTl9DT09LSUVTPXkNCiMg Q09ORklHX0lORVRfQUggaXMgbm90IHNldA0KIyBDT05GSUdfSU5FVF9FU1Ag aXMgbm90IHNldA0KIyBDT05GSUdfSU5FVF9JUENPTVAgaXMgbm90IHNldA0K Q09ORklHX0lORVRfVFVOTkVMPW0NCg0KIw0KIyBJUDogVmlydHVhbCBTZXJ2 ZXIgQ29uZmlndXJhdGlvbg0KIw0KIyBDT05GSUdfSVBfVlMgaXMgbm90IHNl dA0KQ09ORklHX0lQVjY9bQ0KQ09ORklHX0lQVjZfUFJJVkFDWT15DQojIENP TkZJR19JTkVUNl9BSCBpcyBub3Qgc2V0DQojIENPTkZJR19JTkVUNl9FU1Ag aXMgbm90IHNldA0KIyBDT05GSUdfSU5FVDZfSVBDT01QIGlzIG5vdCBzZXQN CkNPTkZJR19JTkVUNl9UVU5ORUw9bQ0KQ09ORklHX0lQVjZfVFVOTkVMPW0N CkNPTkZJR19ORVRGSUxURVI9eQ0KIyBDT05GSUdfTkVURklMVEVSX0RFQlVH IGlzIG5vdCBzZXQNCg0KIw0KIyBJUDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRp b24NCiMNCiMgQ09ORklHX0lQX05GX0NPTk5UUkFDSyBpcyBub3Qgc2V0DQpD T05GSUdfSVBfTkZfUVVFVUU9bQ0KQ09ORklHX0lQX05GX0lQVEFCTEVTPW0N CkNPTkZJR19JUF9ORl9NQVRDSF9MSU1JVD1tDQojIENPTkZJR19JUF9ORl9N QVRDSF9JUFJBTkdFIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9ORl9NQVRDSF9N QUM9bQ0KQ09ORklHX0lQX05GX01BVENIX1BLVFRZUEU9bQ0KQ09ORklHX0lQ X05GX01BVENIX01BUks9bQ0KQ09ORklHX0lQX05GX01BVENIX01VTFRJUE9S VD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfVE9TPW0NCkNPTkZJR19JUF9ORl9N QVRDSF9SRUNFTlQ9bQ0KQ09ORklHX0lQX05GX01BVENIX0VDTj1tDQpDT05G SUdfSVBfTkZfTUFUQ0hfRFNDUD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfQUhf RVNQPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9MRU5HVEg9bQ0KQ09ORklHX0lQ X05GX01BVENIX1RUTD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfVENQTVNTPW0N CkNPTkZJR19JUF9ORl9NQVRDSF9PV05FUj1tDQpDT05GSUdfSVBfTkZfTUFU Q0hfQUREUlRZUEU9bQ0KQ09ORklHX0lQX05GX01BVENIX1JFQUxNPW0NCiMg Q09ORklHX0lQX05GX01BVENIX1NDVFAgaXMgbm90IHNldA0KIyBDT05GSUdf SVBfTkZfTUFUQ0hfQ09NTUVOVCBpcyBub3Qgc2V0DQpDT05GSUdfSVBfTkZf RklMVEVSPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRfUkVKRUNUPW0NCkNPTkZJ R19JUF9ORl9UQVJHRVRfTE9HPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRfVUxP Rz1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX1RDUE1TUz1tDQpDT05GSUdfSVBf TkZfTUFOR0xFPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRfVE9TPW0NCkNPTkZJ R19JUF9ORl9UQVJHRVRfRUNOPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRfRFND UD1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX01BUks9bQ0KIyBDT05GSUdfSVBf TkZfVEFSR0VUX0NMQVNTSUZZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05G X1JBVyBpcyBub3Qgc2V0DQpDT05GSUdfSVBfTkZfQVJQVEFCTEVTPW0NCkNP TkZJR19JUF9ORl9BUlBGSUxURVI9bQ0KQ09ORklHX0lQX05GX0FSUF9NQU5H TEU9bQ0KIyBDT05GSUdfSVBfTkZfQ09NUEFUX0lQQ0hBSU5TIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0lQX05GX0NPTVBBVF9JUEZXQURNIGlzIG5vdCBzZXQN Cg0KIw0KIyBJUHY2OiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbg0KIw0KQ09O RklHX0lQNl9ORl9RVUVVRT1tDQpDT05GSUdfSVA2X05GX0lQVEFCTEVTPW0N CkNPTkZJR19JUDZfTkZfTUFUQ0hfTElNSVQ9bQ0KQ09ORklHX0lQNl9ORl9N QVRDSF9NQUM9bQ0KQ09ORklHX0lQNl9ORl9NQVRDSF9SVD1tDQpDT05GSUdf SVA2X05GX01BVENIX09QVFM9bQ0KQ09ORklHX0lQNl9ORl9NQVRDSF9GUkFH PW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfSEw9bQ0KQ09ORklHX0lQNl9ORl9N QVRDSF9NVUxUSVBPUlQ9bQ0KQ09ORklHX0lQNl9ORl9NQVRDSF9PV05FUj1t DQpDT05GSUdfSVA2X05GX01BVENIX01BUks9bQ0KQ09ORklHX0lQNl9ORl9N QVRDSF9JUFY2SEVBREVSPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfQUhFU1A9 bQ0KQ09ORklHX0lQNl9ORl9NQVRDSF9MRU5HVEg9bQ0KQ09ORklHX0lQNl9O Rl9NQVRDSF9FVUk2ND1tDQpDT05GSUdfSVA2X05GX0ZJTFRFUj1tDQpDT05G SUdfSVA2X05GX1RBUkdFVF9MT0c9bQ0KQ09ORklHX0lQNl9ORl9NQU5HTEU9 bQ0KQ09ORklHX0lQNl9ORl9UQVJHRVRfTUFSSz1tDQojIENPTkZJR19JUDZf TkZfUkFXIGlzIG5vdCBzZXQNCkNPTkZJR19YRlJNPXkNCiMgQ09ORklHX1hG Uk1fVVNFUiBpcyBub3Qgc2V0DQoNCiMNCiMgU0NUUCBDb25maWd1cmF0aW9u IChFWFBFUklNRU5UQUwpDQojDQojIENPTkZJR19JUF9TQ1RQIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0FUTSBpcyBub3Qgc2V0DQojIENPTkZJR19CUklER0Ug aXMgbm90IHNldA0KQ09ORklHX1ZMQU5fODAyMVE9bQ0KIyBDT05GSUdfREVD TkVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xMQzIgaXMgbm90IHNldA0KIyBD T05GSUdfSVBYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUQUxLIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0DQojIENPTkZJR19MQVBCIGlz IG5vdCBzZXQNCiMgQ09ORklHX05FVF9ESVZFUlQgaXMgbm90IHNldA0KIyBD T05GSUdfRUNPTkVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dBTl9ST1VURVIg aXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MIGlzIG5v dCBzZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZhaXIgcXVldWVpbmcNCiMNCiMg Q09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX0NMU19S T1VURT15DQoNCiMNCiMgTmV0d29yayB0ZXN0aW5nDQojDQojIENPTkZJR19O RVRfUEtUR0VOIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVFBPTEwgaXMgbm90 IHNldA0KIyBDT05GSUdfTkVUX1BPTExfQ09OVFJPTExFUiBpcyBub3Qgc2V0 DQojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0DQojIENPTkZJR19JUkRB IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JUIGlzIG5vdCBzZXQNCkNPTkZJR19O RVRERVZJQ0VTPXkNCiMgQ09ORklHX0RVTU1ZIGlzIG5vdCBzZXQNCiMgQ09O RklHX0JPTkRJTkcgaXMgbm90IHNldA0KQ09ORklHX0VRVUFMSVpFUj1tDQpD T05GSUdfVFVOPW0NCg0KIw0KIyBBUkNuZXQgZGV2aWNlcw0KIw0KIyBDT05G SUdfQVJDTkVUIGlzIG5vdCBzZXQNCg0KIw0KIyBFdGhlcm5ldCAoMTAgb3Ig MTAwTWJpdCkNCiMNCkNPTkZJR19ORVRfRVRIRVJORVQ9eQ0KQ09ORklHX01J ST1tDQojIENPTkZJR19IQVBQWU1FQUwgaXMgbm90IHNldA0KIyBDT05GSUdf U1VOR0VNIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfVkVORE9SXzNDT009eQ0K Q09ORklHX1ZPUlRFWD1tDQojIENPTkZJR19UWVBIT09OIGlzIG5vdCBzZXQN Cg0KIw0KIyBUdWxpcCBmYW1pbHkgbmV0d29yayBkZXZpY2Ugc3VwcG9ydA0K Iw0KIyBDT05GSUdfTkVUX1RVTElQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hQ MTAwIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfUENJPXkNCiMgQ09ORklHX1BD TkVUMzIgaXMgbm90IHNldA0KIyBDT05GSUdfQU1EODExMV9FVEggaXMgbm90 IHNldA0KIyBDT05GSUdfQURBUFRFQ19TVEFSRklSRSBpcyBub3Qgc2V0DQoj IENPTkZJR19CNDQgaXMgbm90IHNldA0KIyBDT05GSUdfRk9SQ0VERVRIIGlz IG5vdCBzZXQNCiMgQ09ORklHX0RHUlMgaXMgbm90IHNldA0KQ09ORklHX0VF UFJPMTAwPW0NCiMgQ09ORklHX0VFUFJPMTAwX1BJTyBpcyBub3Qgc2V0DQpD T05GSUdfRTEwMD1tDQpDT05GSUdfRTEwMF9OQVBJPXkNCiMgQ09ORklHX0ZF QUxOWCBpcyBub3Qgc2V0DQojIENPTkZJR19OQVRTRU1JIGlzIG5vdCBzZXQN CiMgQ09ORklHX05FMktfUENJIGlzIG5vdCBzZXQNCkNPTkZJR184MTM5Q1A9 bQ0KQ09ORklHXzgxMzlUT089bQ0KIyBDT05GSUdfODEzOVRPT19QSU8gaXMg bm90IHNldA0KIyBDT05GSUdfODEzOVRPT19UVU5FX1RXSVNURVIgaXMgbm90 IHNldA0KIyBDT05GSUdfODEzOVRPT184MTI5IGlzIG5vdCBzZXQNCiMgQ09O RklHXzgxMzlfT0xEX1JYX1JFU0VUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NJ UzkwMCBpcyBub3Qgc2V0DQojIENPTkZJR19FUElDMTAwIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NVTkRBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RMQU4g aXMgbm90IHNldA0KIyBDT05GSUdfVklBX1JISU5FIGlzIG5vdCBzZXQNCiMg Q09ORklHX1ZJQV9WRUxPQ0lUWSBpcyBub3Qgc2V0DQoNCiMNCiMgRXRoZXJu ZXQgKDEwMDAgTWJpdCkNCiMNCkNPTkZJR19BQ0VOSUM9bQ0KQ09ORklHX0FD RU5JQ19PTUlUX1RJR09OX0k9eQ0KQ09ORklHX0RMMks9bQ0KQ09ORklHX0Ux MDAwPW0NCkNPTkZJR19FMTAwMF9OQVBJPXkNCiMgQ09ORklHX05TODM4MjAg aXMgbm90IHNldA0KIyBDT05GSUdfSEFNQUNISSBpcyBub3Qgc2V0DQojIENP TkZJR19ZRUxMT1dGSU4gaXMgbm90IHNldA0KQ09ORklHX1I4MTY5PW0NCiMg Q09ORklHX1I4MTY5X05BUEkgaXMgbm90IHNldA0KQ09ORklHX1NLOThMSU49 bQ0KIyBDT05GSUdfVElHT04zIGlzIG5vdCBzZXQNCg0KIw0KIyBFdGhlcm5l dCAoMTAwMDAgTWJpdCkNCiMNCiMgQ09ORklHX0lYR0IgaXMgbm90IHNldA0K IyBDT05GSUdfUzJJTyBpcyBub3Qgc2V0DQoNCiMNCiMgVG9rZW4gUmluZyBk ZXZpY2VzDQojDQojIENPTkZJR19UUiBpcyBub3Qgc2V0DQoNCiMNCiMgV2ly ZWxlc3MgTEFOIChub24taGFtcmFkaW8pDQojDQojIENPTkZJR19ORVRfUkFE SU8gaXMgbm90IHNldA0KDQojDQojIFdhbiBpbnRlcmZhY2VzDQojDQojIENP TkZJR19XQU4gaXMgbm90IHNldA0KIyBDT05GSUdfRkRESSBpcyBub3Qgc2V0 DQojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0DQojIENPTkZJR19QUFAgaXMg bm90IHNldA0KIyBDT05GSUdfU0xJUCBpcyBub3Qgc2V0DQojIENPTkZJR19O RVRfRkMgaXMgbm90IHNldA0KIyBDT05GSUdfU0hBUEVSIGlzIG5vdCBzZXQN CiMgQ09ORklHX05FVENPTlNPTEUgaXMgbm90IHNldA0KDQojDQojIElTRE4g c3Vic3lzdGVtDQojDQojIENPTkZJR19JU0ROIGlzIG5vdCBzZXQNCg0KIw0K IyBUZWxlcGhvbnkgU3VwcG9ydA0KIw0KIyBDT05GSUdfUEhPTkUgaXMgbm90 IHNldA0KDQojDQojIElucHV0IGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdf SU5QVVQ9eQ0KDQojDQojIFVzZXJsYW5kIGludGVyZmFjZXMNCiMNCkNPTkZJ R19JTlBVVF9NT1VTRURFVj15DQojIENPTkZJR19JTlBVVF9NT1VTRURFVl9Q U0FVWCBpcyBub3Qgc2V0DQpDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVO X1g9MTAyNA0KQ09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9ZPTc2OA0K IyBDT05GSUdfSU5QVVRfSk9ZREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lO UFVUX1RTREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0VWREVWIGlz IG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0VWQlVHIGlzIG5vdCBzZXQNCg0K Iw0KIyBJbnB1dCBJL08gZHJpdmVycw0KIw0KIyBDT05GSUdfR0FNRVBPUlQg aXMgbm90IHNldA0KQ09ORklHX1NPVU5EX0dBTUVQT1JUPXkNCkNPTkZJR19T RVJJTz15DQpDT05GSUdfU0VSSU9fSTgwNDI9eQ0KIyBDT05GSUdfU0VSSU9f U0VSUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19TRVJJT19DVDgyQzcxMCBp cyBub3Qgc2V0DQojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldA0K IyBDT05GSUdfU0VSSU9fUkFXIGlzIG5vdCBzZXQNCg0KIw0KIyBJbnB1dCBE ZXZpY2UgRHJpdmVycw0KIw0KQ09ORklHX0lOUFVUX0tFWUJPQVJEPXkNCkNP TkZJR19LRVlCT0FSRF9BVEtCRD15DQojIENPTkZJR19LRVlCT0FSRF9TVU5L QkQgaXMgbm90IHNldA0KIyBDT05GSUdfS0VZQk9BUkRfTEtLQkQgaXMgbm90 IHNldA0KIyBDT05GSUdfS0VZQk9BUkRfWFRLQkQgaXMgbm90IHNldA0KIyBD T05GSUdfS0VZQk9BUkRfTkVXVE9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lO UFVUX01PVVNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0pPWVNUSUNL IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX1RPVUNIU0NSRUVOIGlzIG5v dCBzZXQNCiMgQ09ORklHX0lOUFVUX01JU0MgaXMgbm90IHNldA0KDQojDQoj IENoYXJhY3RlciBkZXZpY2VzDQojDQpDT05GSUdfVlQ9eQ0KQ09ORklHX1ZU X0NPTlNPTEU9eQ0KQ09ORklHX0hXX0NPTlNPTEU9eQ0KIyBDT05GSUdfU0VS SUFMX05PTlNUQU5EQVJEIGlzIG5vdCBzZXQNCg0KIw0KIyBTZXJpYWwgZHJp dmVycw0KIw0KIyBDT05GSUdfU0VSSUFMXzgyNTAgaXMgbm90IHNldA0KDQoj DQojIE5vbi04MjUwIHNlcmlhbCBwb3J0IHN1cHBvcnQNCiMNCkNPTkZJR19V TklYOThfUFRZUz15DQojIENPTkZJR19MRUdBQ1lfUFRZUyBpcyBub3Qgc2V0 DQoNCiMNCiMgSVBNSQ0KIw0KIyBDT05GSUdfSVBNSV9IQU5ETEVSIGlzIG5v dCBzZXQNCg0KIw0KIyBXYXRjaGRvZyBDYXJkcw0KIw0KIyBDT05GSUdfV0FU Q0hET0cgaXMgbm90IHNldA0KIyBDT05GSUdfSFdfUkFORE9NIGlzIG5vdCBz ZXQNCiMgQ09ORklHX05WUkFNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQyBp cyBub3Qgc2V0DQojIENPTkZJR19HRU5fUlRDIGlzIG5vdCBzZXQNCiMgQ09O RklHX0RUTEsgaXMgbm90IHNldA0KIyBDT05GSUdfUjM5NjQgaXMgbm90IHNl dA0KIyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldA0KIyBDT05GSUdfU09O WVBJIGlzIG5vdCBzZXQNCg0KIw0KIyBGdGFwZSwgdGhlIGZsb3BweSB0YXBl IGRldmljZSBkcml2ZXINCiMNCiMgQ09ORklHX0ZUQVBFIGlzIG5vdCBzZXQN CiMgQ09ORklHX0FHUCBpcyBub3Qgc2V0DQojIENPTkZJR19EUk0gaXMgbm90 IHNldA0KIyBDT05GSUdfTVdBVkUgaXMgbm90IHNldA0KIyBDT05GSUdfUkFX X0RSSVZFUiBpcyBub3Qgc2V0DQojIENPTkZJR19IQU5HQ0hFQ0tfVElNRVIg aXMgbm90IHNldA0KDQojDQojIEkyQyBzdXBwb3J0DQojDQpDT05GSUdfSTJD PW0NCkNPTkZJR19JMkNfQ0hBUkRFVj1tDQoNCiMNCiMgSTJDIEFsZ29yaXRo bXMNCiMNCkNPTkZJR19JMkNfQUxHT0JJVD1tDQpDT05GSUdfSTJDX0FMR09Q Q0Y9bQ0KIyBDT05GSUdfSTJDX0FMR09QQ0EgaXMgbm90IHNldA0KDQojDQoj IEkyQyBIYXJkd2FyZSBCdXMgc3VwcG9ydA0KIw0KQ09ORklHX0kyQ19BTEkx NTM1PW0NCkNPTkZJR19JMkNfQUxJMTU2Mz1tDQpDT05GSUdfSTJDX0FMSTE1 WDM9bQ0KQ09ORklHX0kyQ19BTUQ3NTY9bQ0KQ09ORklHX0kyQ19BTUQ4MTEx PW0NCkNPTkZJR19JMkNfSTgwMT1tDQpDT05GSUdfSTJDX0k4MTA9bQ0KQ09O RklHX0kyQ19JU0E9bQ0KQ09ORklHX0kyQ19ORk9SQ0UyPW0NCkNPTkZJR19J MkNfUEFSUE9SVF9MSUdIVD1tDQpDT05GSUdfSTJDX1BJSVg0PW0NCkNPTkZJ R19JMkNfUFJPU0FWQUdFPW0NCkNPTkZJR19JMkNfU0FWQUdFND1tDQpDT05G SUdfU0N4MjAwX0FDQj1tDQpDT05GSUdfSTJDX1NJUzU1OTU9bQ0KQ09ORklH X0kyQ19TSVM2MzA9bQ0KQ09ORklHX0kyQ19TSVM5Nlg9bQ0KQ09ORklHX0ky Q19WSUE9bQ0KQ09ORklHX0kyQ19WSUFQUk89bQ0KQ09ORklHX0kyQ19WT09E T08zPW0NCiMgQ09ORklHX0kyQ19QQ0FfSVNBIGlzIG5vdCBzZXQNCg0KIw0K IyBIYXJkd2FyZSBTZW5zb3JzIENoaXAgc3VwcG9ydA0KIw0KQ09ORklHX0ky Q19TRU5TT1I9bQ0KQ09ORklHX1NFTlNPUlNfQURNMTAyMT1tDQpDT05GSUdf U0VOU09SU19BRE0xMDI1PW0NCkNPTkZJR19TRU5TT1JTX0FETTEwMzE9bQ0K Q09ORklHX1NFTlNPUlNfQVNCMTAwPW0NCkNPTkZJR19TRU5TT1JTX0RTMTYy MT1tDQpDT05GSUdfU0VOU09SU19GU0NIRVI9bQ0KQ09ORklHX1NFTlNPUlNf R0w1MThTTT1tDQpDT05GSUdfU0VOU09SU19JVDg3PW0NCkNPTkZJR19TRU5T T1JTX0xNNzU9bQ0KQ09ORklHX1NFTlNPUlNfTE03Nz1tDQpDT05GSUdfU0VO U09SU19MTTc4PW0NCkNPTkZJR19TRU5TT1JTX0xNODA9bQ0KQ09ORklHX1NF TlNPUlNfTE04Mz1tDQpDT05GSUdfU0VOU09SU19MTTg1PW0NCkNPTkZJR19T RU5TT1JTX0xNOTA9bQ0KQ09ORklHX1NFTlNPUlNfTUFYMTYxOT1tDQojIENP TkZJR19TRU5TT1JTX1NNU0M0N00xIGlzIG5vdCBzZXQNCkNPTkZJR19TRU5T T1JTX1ZJQTY4NkE9bQ0KQ09ORklHX1NFTlNPUlNfVzgzNzgxRD1tDQpDT05G SUdfU0VOU09SU19XODNMNzg1VFM9bQ0KQ09ORklHX1NFTlNPUlNfVzgzNjI3 SEY9bQ0KDQojDQojIE90aGVyIEkyQyBDaGlwIHN1cHBvcnQNCiMNCiMgQ09O RklHX1NFTlNPUlNfRUVQUk9NIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFTlNP UlNfUENGODU3NCBpcyBub3Qgc2V0DQojIENPTkZJR19TRU5TT1JTX1BDRjg1 OTEgaXMgbm90IHNldA0KIyBDT05GSUdfU0VOU09SU19SVEM4NTY0IGlzIG5v dCBzZXQNCiMgQ09ORklHX0kyQ19ERUJVR19DT1JFIGlzIG5vdCBzZXQNCiMg Q09ORklHX0kyQ19ERUJVR19BTEdPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ky Q19ERUJVR19CVVMgaXMgbm90IHNldA0KIyBDT05GSUdfSTJDX0RFQlVHX0NI SVAgaXMgbm90IHNldA0KDQojDQojIERhbGxhcydzIDEtd2lyZSBidXMNCiMN CiMgQ09ORklHX1cxIGlzIG5vdCBzZXQNCg0KIw0KIyBNaXNjIGRldmljZXMN CiMNCiMgQ09ORklHX0lCTV9BU00gaXMgbm90IHNldA0KDQojDQojIE11bHRp bWVkaWEgZGV2aWNlcw0KIw0KIyBDT05GSUdfVklERU9fREVWIGlzIG5vdCBz ZXQNCg0KIw0KIyBEaWdpdGFsIFZpZGVvIEJyb2FkY2FzdGluZyBEZXZpY2Vz DQojDQojIENPTkZJR19EVkIgaXMgbm90IHNldA0KDQojDQojIEdyYXBoaWNz IHN1cHBvcnQNCiMNCiMgQ09ORklHX0ZCIGlzIG5vdCBzZXQNCiMgQ09ORklH X1ZJREVPX1NFTEVDVCBpcyBub3Qgc2V0DQoNCiMNCiMgQ29uc29sZSBkaXNw bGF5IGRyaXZlciBzdXBwb3J0DQojDQpDT05GSUdfVkdBX0NPTlNPTEU9eQ0K Q09ORklHX0RVTU1ZX0NPTlNPTEU9eQ0KDQojDQojIFNvdW5kDQojDQojIENP TkZJR19TT1VORCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIHN1cHBvcnQNCiMN CiMgQ09ORklHX1VTQiBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIEdhZGdldCBT dXBwb3J0DQojDQojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQNCg0K Iw0KIyBGaWxlIHN5c3RlbXMNCiMNCkNPTkZJR19FWFQyX0ZTPW0NCiMgQ09O RklHX0VYVDJfRlNfWEFUVFIgaXMgbm90IHNldA0KQ09ORklHX0VYVDNfRlM9 bQ0KIyBDT05GSUdfRVhUM19GU19YQVRUUiBpcyBub3Qgc2V0DQpDT05GSUdf SkJEPW0NCiMgQ09ORklHX0pCRF9ERUJVRyBpcyBub3Qgc2V0DQpDT05GSUdf UkVJU0VSRlNfRlM9eQ0KIyBDT05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMgbm90 IHNldA0KIyBDT05GSUdfUkVJU0VSRlNfUFJPQ19JTkZPIGlzIG5vdCBzZXQN CiMgQ09ORklHX1JFSVNFUkZTX0ZTX1hBVFRSIGlzIG5vdCBzZXQNCkNPTkZJ R19KRlNfRlM9bQ0KIyBDT05GSUdfSkZTX1BPU0lYX0FDTCBpcyBub3Qgc2V0 DQojIENPTkZJR19KRlNfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfSkZT X1NUQVRJU1RJQ1MgaXMgbm90IHNldA0KQ09ORklHX0ZTX1BPU0lYX0FDTD15 DQpDT05GSUdfWEZTX0ZTPW0NCiMgQ09ORklHX1hGU19SVCBpcyBub3Qgc2V0 DQojIENPTkZJR19YRlNfUVVPVEEgaXMgbm90IHNldA0KIyBDT05GSUdfWEZT X1NFQ1VSSVRZIGlzIG5vdCBzZXQNCiMgQ09ORklHX1hGU19QT1NJWF9BQ0wg aXMgbm90IHNldA0KIyBDT05GSUdfTUlOSVhfRlMgaXMgbm90IHNldA0KIyBD T05GSUdfUk9NRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfUVVPVEEgaXMg bm90IHNldA0KIyBDT05GSUdfQVVUT0ZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09O RklHX0FVVE9GUzRfRlMgaXMgbm90IHNldA0KDQojDQojIENELVJPTS9EVkQg RmlsZXN5c3RlbXMNCiMNCkNPTkZJR19JU085NjYwX0ZTPW0NCkNPTkZJR19K T0xJRVQ9eQ0KQ09ORklHX1pJU09GUz15DQpDT05GSUdfWklTT0ZTX0ZTPW0N CkNPTkZJR19VREZfRlM9bQ0KQ09ORklHX1VERl9OTFM9eQ0KDQojDQojIERP Uy9GQVQvTlQgRmlsZXN5c3RlbXMNCiMNCkNPTkZJR19GQVRfRlM9bQ0KQ09O RklHX01TRE9TX0ZTPW0NCkNPTkZJR19WRkFUX0ZTPW0NCkNPTkZJR19GQVRf REVGQVVMVF9DT0RFUEFHRT00MzcNCkNPTkZJR19GQVRfREVGQVVMVF9JT0NI QVJTRVQ9Imlzbzg4NTktMSINCkNPTkZJR19OVEZTX0ZTPW0NCiMgQ09ORklH X05URlNfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfTlRGU19SVyBpcyBu b3Qgc2V0DQoNCiMNCiMgUHNldWRvIGZpbGVzeXN0ZW1zDQojDQpDT05GSUdf UFJPQ19GUz15DQpDT05GSUdfUFJPQ19LQ09SRT15DQpDT05GSUdfU1lTRlM9 eQ0KIyBDT05GSUdfREVWRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfREVW UFRTX0ZTX1hBVFRSIGlzIG5vdCBzZXQNCkNPTkZJR19UTVBGUz15DQojIENP TkZJR19IVUdFVExCRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSFVHRVRMQl9Q QUdFIGlzIG5vdCBzZXQNCkNPTkZJR19SQU1GUz15DQoNCiMNCiMgTWlzY2Vs bGFuZW91cyBmaWxlc3lzdGVtcw0KIw0KIyBDT05GSUdfQURGU19GUyBpcyBu b3Qgc2V0DQojIENPTkZJR19BRkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH X0hGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19IRlNQTFVTX0ZTIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JFRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf QkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0 DQojIENPTkZJR19DUkFNRlMgaXMgbm90IHNldA0KIyBDT05GSUdfVlhGU19G UyBpcyBub3Qgc2V0DQojIENPTkZJR19IUEZTX0ZTIGlzIG5vdCBzZXQNCiMg Q09ORklHX1FOWDRGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19TWVNWX0ZT IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GUyBpcyBub3Qgc2V0DQoNCiMN CiMgTmV0d29yayBGaWxlIFN5c3RlbXMNCiMNCkNPTkZJR19ORlNfRlM9bQ0K Q09ORklHX05GU19WMz15DQpDT05GSUdfTkZTX1Y0PXkNCiMgQ09ORklHX05G U19ESVJFQ1RJTyBpcyBub3Qgc2V0DQpDT05GSUdfTkZTRD1tDQpDT05GSUdf TkZTRF9WMz15DQpDT05GSUdfTkZTRF9WND15DQpDT05GSUdfTkZTRF9UQ1A9 eQ0KQ09ORklHX0xPQ0tEPW0NCkNPTkZJR19MT0NLRF9WND15DQpDT05GSUdf RVhQT1JURlM9bQ0KQ09ORklHX1NVTlJQQz1tDQpDT05GSUdfU1VOUlBDX0dT Uz1tDQpDT05GSUdfUlBDU0VDX0dTU19LUkI1PW0NCiMgQ09ORklHX1JQQ1NF Q19HU1NfU1BLTTMgaXMgbm90IHNldA0KIyBDT05GSUdfU01CX0ZTIGlzIG5v dCBzZXQNCiMgQ09ORklHX0NJRlMgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQ X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NPREFfRlMgaXMgbm90IHNldA0K IyBDT05GSUdfQUZTX0ZTIGlzIG5vdCBzZXQNCg0KIw0KIyBQYXJ0aXRpb24g VHlwZXMNCiMNCiMgQ09ORklHX1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qg c2V0DQpDT05GSUdfTVNET1NfUEFSVElUSU9OPXkNCg0KIw0KIyBOYXRpdmUg TGFuZ3VhZ2UgU3VwcG9ydA0KIw0KQ09ORklHX05MUz1tDQpDT05GSUdfTkxT X0RFRkFVTFQ9ImNwNDM3Ig0KQ09ORklHX05MU19DT0RFUEFHRV80Mzc9bQ0K IyBDT05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBub3Qgc2V0DQojIENPTkZJ R19OTFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19D T0RFUEFHRV84NTAgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdF Xzg1MiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODU1IGlz IG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NTcgaXMgbm90IHNl dA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MCBpcyBub3Qgc2V0DQojIENP TkZJR19OTFNfQ09ERVBBR0VfODYxIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M U19DT0RFUEFHRV84NjIgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg2MyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY0 IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjUgaXMgbm90 IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NiBpcyBub3Qgc2V0DQoj IENPTkZJR19OTFNfQ09ERVBBR0VfODY5IGlzIG5vdCBzZXQNCiMgQ09ORklH X05MU19DT0RFUEFHRV85MzYgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NP REVQQUdFXzk1MCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0Vf OTMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV85NDkgaXMg bm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg3NCBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfSVNPODg1OV84IGlzIG5vdCBzZXQNCiMgQ09ORklH X05MU19DT0RFUEFHRV8xMjUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19D T0RFUEFHRV8xMjUxIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19BU0NJSSBp cyBub3Qgc2V0DQpDT05GSUdfTkxTX0lTTzg4NTlfMT1tDQojIENPTkZJR19O TFNfSVNPODg1OV8yIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5 XzMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNCBpcyBub3Qg c2V0DQojIENPTkZJR19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQNCiMgQ09O RklHX05MU19JU084ODU5XzYgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lT Tzg4NTlfNyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV85IGlz IG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzEzIGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19JU084ODU5XzE0IGlzIG5vdCBzZXQNCiMgQ09ORklH X05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19LT0k4 X1IgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0tPSThfVSBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfVVRGOCBpcyBub3Qgc2V0DQoNCiMNCiMgUHJvZmls aW5nIHN1cHBvcnQNCiMNCiMgQ09ORklHX1BST0ZJTElORyBpcyBub3Qgc2V0 DQoNCiMNCiMgS2VybmVsIGhhY2tpbmcNCiMNCiMgQ09ORklHX0RFQlVHX0tF Uk5FTCBpcyBub3Qgc2V0DQojIENPTkZJR19GUkFNRV9QT0lOVEVSIGlzIG5v dCBzZXQNCkNPTkZJR19FQVJMWV9QUklOVEs9eQ0KQ09ORklHXzRLU1RBQ0tT PXkNCg0KIw0KIyBTZWN1cml0eSBvcHRpb25zDQojDQojIENPTkZJR19TRUNV UklUWSBpcyBub3Qgc2V0DQoNCiMNCiMgQ3J5cHRvZ3JhcGhpYyBvcHRpb25z DQojDQpDT05GSUdfQ1JZUFRPPXkNCkNPTkZJR19DUllQVE9fSE1BQz15DQpD T05GSUdfQ1JZUFRPX05VTEw9bQ0KQ09ORklHX0NSWVBUT19NRDQ9bQ0KQ09O RklHX0NSWVBUT19NRDU9bQ0KQ09ORklHX0NSWVBUT19TSEExPW0NCkNPTkZJ R19DUllQVE9fU0hBMjU2PW0NCkNPTkZJR19DUllQVE9fU0hBNTEyPW0NCiMg Q09ORklHX0NSWVBUT19XUDUxMiBpcyBub3Qgc2V0DQpDT05GSUdfQ1JZUFRP X0RFUz1tDQpDT05GSUdfQ1JZUFRPX0JMT1dGSVNIPW0NCkNPTkZJR19DUllQ VE9fVFdPRklTSD1tDQpDT05GSUdfQ1JZUFRPX1NFUlBFTlQ9bQ0KQ09ORklH X0NSWVBUT19BRVNfNTg2PW0NCkNPTkZJR19DUllQVE9fQ0FTVDU9bQ0KQ09O RklHX0NSWVBUT19DQVNUNj1tDQpDT05GSUdfQ1JZUFRPX1RFQT1tDQpDT05G SUdfQ1JZUFRPX0FSQzQ9bQ0KQ09ORklHX0NSWVBUT19LSEFaQUQ9bQ0KQ09O RklHX0NSWVBUT19ERUZMQVRFPW0NCiMgQ09ORklHX0NSWVBUT19NSUNIQUVM X01JQyBpcyBub3Qgc2V0DQojIENPTkZJR19DUllQVE9fQ1JDMzJDIGlzIG5v dCBzZXQNCkNPTkZJR19DUllQVE9fVEVTVD1tDQoNCiMNCiMgTGlicmFyeSBy b3V0aW5lcw0KIw0KIyBDT05GSUdfQ1JDX0NDSVRUIGlzIG5vdCBzZXQNCkNP TkZJR19DUkMzMj1tDQojIENPTkZJR19MSUJDUkMzMkMgaXMgbm90IHNldA0K Q09ORklHX1pMSUJfSU5GTEFURT1tDQpDT05GSUdfWkxJQl9ERUZMQVRFPW0N CkNPTkZJR19YODZfQklPU19SRUJPT1Q9eQ0KQ09ORklHX1BDPXkNCg== --247680674-978388123-1102676975=:27530-- From owner-linux-xfs Fri Dec 10 05:26:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Dec 2004 05:26:29 -0800 (PST) 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 iBADQQh4010054 for ; Fri, 10 Dec 2004 05:26:27 -0800 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 iBADQ4xT026984 for ; Fri, 10 Dec 2004 07:26:04 -0600 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iBADQ2ad6566735; Fri, 10 Dec 2004 05:26:02 -0800 (PST) Message-ID: <41B9A3E9.4080003@sgi.com> Date: Fri, 10 Dec 2004 07:26:01 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Evaldas Darcianovas CC: linux-xfs@oss.sgi.com Subject: Re: kernel 2.6.9 oops in XFS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 18:09:44 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4618 X-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: 394 Lines: 13 Evaldas Darcianovas wrote: > Hi > > This FTP server running vanilla 2.6.9, XFS on 1TB 3ware RAID array. For > the third time it happens under heavy disk i/o load. > Earlier I was using JFS for the same hardware/software configuration and > experienced no problems so I guess this is not hardware related. > Kernel config is attached below. Can you duplicate without CONFIG_4KSTACKS? -Eric From owner-linux-xfs Mon Dec 13 05:58:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 05:59:02 -0800 (PST) Received: from mail45.messagelabs.com (mail45.messagelabs.com [140.174.2.179]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iBDDwW22008680 for ; Mon, 13 Dec 2004 05:58:52 -0800 X-VirusChecked: Checked X-Env-Sender: justin.piszcz@mitretek.org X-Msg-Ref: server-10.tower-45.messagelabs.com!1102946282!8347482!1 X-StarScan-Version: 5.4.2; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 4416 invoked from network); 13 Dec 2004 13:58:02 -0000 Received: from mtk-news1.mitretek.org (66.10.26.57) by server-10.tower-45.messagelabs.com with SMTP; 13 Dec 2004 13:58:02 -0000 Received: from email1.mitretek.org (localhost [127.0.0.1]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id iBDDw0TP021951 for ; Mon, 13 Dec 2004 08:58:00 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Unknown Issue. X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 13 Dec 2004 08:57:59 -0500 Message-ID: <2E314DE03538984BA5634F12115B3A4E01BC4175@email1.mitretek.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unknown Issue. Thread-Index: AcTgkJ/dRlq7soY5R9KEgCqtJn8YywAiXCUg From: "Piszcz, Justin Michael" To: "Patrick" , , Cc: "Andrew Morton" , "Kristofer T. Karas" , "Jeff Garzik" , "Linus Torvalds" X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iBDDwq22008694 X-archive-position: 4619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: justin.piszcz@mitretek.org Precedence: bulk X-list: linux-xfs Content-Length: 3077 Lines: 87 Patrick, I had the same problem on two machines with XFS. Both slackware-current machines. The kernel on the Dell GX1 was built with GCC-3.4.2 and on my main box was GCC-3.4.3. There seems to be a bug in XFS with some configurations of 2.6.9 and 2.6.10-rc series. After re-installing Slackware-10.0 and upgrading to -current, I have installed 2.6.10-rc3 and so far, I have not been able to reproduce the problem. Some questions for you: 1] What kernel are you running? 2] What did you last change before you started getting these errors? As far as severity goes, I ran XFS' fsck from a KNOPPIX CD and as a result, I had about 500-600mb of files in my /lost+found directory when it was finished. Files were missing from all parts of the file system. I had to restore from backup. I would say stick with your previous 2.6.9 configuration (if you were running it) or go back to 2.6.8.1, some 2.6.9 configurations and 2.6.10-rc1 and/or 2.6.10-rc2 definitely cause file corruption with XFS. So far, however, I have not been able to reproduce the error with 2.6.10-rc3. Justin. -----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Patrick Sent: Sunday, December 12, 2004 4:15 PM To: linux-kernel@vger.kernel.org Subject: Unknown Issue. Hi, I've got a computer running gentoo, on a clean install where i've got an odd problem : after a while, the computer refuses to spawn processes anymore : -/bin/bash: /bin/ps: Input/output error -/bin/bash: /usr/bin/w: Input/output error -/bin/bash: /bin/df: Input/output error -/bin/bash: /bin/mount: Input/output error It happen's randomly, i've tried everything from changing the computer from running software raid ( scsi ) to running a hardware solution and reinstalling, I've run the memory through memtest as well as i've remounted the drives and i've tested the ram to make sure it was properly mounted. The only thing running on this box is mysql, which runs perfectly at 7500 q/s ( running super smack ) now, i'm not sure if this is a linux kernel thing, or a gentoo thing, or a hardware thing. I've checked and i'm not running out of file descriptors ( by looking in /proc/sys/fs/file-nr ) and i've increased the ammount in ( /proc/sys/fs/file-max ( if i member correctly ) ) by adding a 0 after the end of the value thus increasing it alot. It's running XFS on the root partition with a single partition, dual xeon 2.66 with hyperthreading enabled, dual intel gbe and a adaptec 2120S AACraid card. Dual 36gb 10krpm scsi drives in raid1. Does anyone have any ideas on what i can do, what i can test, if it's hardware ? software ? guys ? P -- ------ In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-xfs Mon Dec 13 09:05:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:05:08 -0800 (PST) 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 iBDH4dHS032029 for ; Mon, 13 Dec 2004 09:05:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iBDIPk2c010230 for ; Mon, 13 Dec 2004 10:25:46 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iBDH4Fpq5809100; Mon, 13 Dec 2004 11:04:16 -0600 (CST) Message-ID: <41BDCB8F.5080902@sgi.com> Date: Mon, 13 Dec 2004 11:04:15 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Piszcz, Justin Michael" CC: Patrick , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton , "Kristofer T. Karas" , Jeff Garzik , Linus Torvalds Subject: Re: Unknown Issue. References: <2E314DE03538984BA5634F12115B3A4E01BC4175@email1.mitretek.org> In-Reply-To: <2E314DE03538984BA5634F12115B3A4E01BC4175@email1.mitretek.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4620 X-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: 2265 Lines: 64 My first thought is that perhaps the filesystem has shut down due to some error (memory corruption, bad disk, xfs bug...); did you check your log messages? Justin, when you mentioned that you used xfs' fsck, I guess you used xfs_repair. Was the log clean when you ran it, or did you force repair to zero out the log? That could explain the large lost+found/ when you were done... Patrick, can you reproduce on a non-gentoo kernel? That'd be the first step for this audience. -Eric Piszcz, Justin Michael wrote: > Patrick, > > I had the same problem on two machines with XFS. Both slackware-current > machines. The kernel on the Dell GX1 was built with GCC-3.4.2 and on my > main box was GCC-3.4.3. > > There seems to be a bug in XFS with some configurations of 2.6.9 and > 2.6.10-rc series. > > After re-installing Slackware-10.0 and upgrading to -current, I have > installed 2.6.10-rc3 and so far, I have not been able to reproduce the > problem. > > Some questions for you: > > 1] What kernel are you running? > 2] What did you last change before you started getting these errors? > > As far as severity goes, I ran XFS' fsck from a KNOPPIX CD and as a > result, I had about 500-600mb of files in my /lost+found directory when > it was finished. Files were missing from all parts of the file system. > I had to restore from backup. I would say stick with your previous > 2.6.9 configuration (if you were running it) or go back to 2.6.8.1, some > 2.6.9 configurations and 2.6.10-rc1 and/or 2.6.10-rc2 definitely cause > file corruption with XFS. So far, however, I have not been able to > reproduce the error with 2.6.10-rc3. > > Justin. > > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Patrick > Sent: Sunday, December 12, 2004 4:15 PM > To: linux-kernel@vger.kernel.org > Subject: Unknown Issue. > > Hi, > > I've got a computer running gentoo, on a clean install where i've got > an odd problem : > > after a while, the computer refuses to spawn processes anymore : > > -/bin/bash: /bin/ps: Input/output error > -/bin/bash: /usr/bin/w: Input/output error > -/bin/bash: /bin/df: Input/output error > -/bin/bash: /bin/mount: Input/output error > From owner-linux-xfs Mon Dec 13 09:14:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:14:48 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBDHEMot000313 for ; Mon, 13 Dec 2004 09:14:43 -0800 Received: by wproxy.gmail.com with SMTP id 37so1447932wra for ; Mon, 13 Dec 2004 09:13:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CWHSx6+u/Rr291cPoxiBACOy0+teckqis6RV8Gf4/DJ2D/RNq/4Fw16OJf1MoLM11bs++YfNE2sf+IH77BBYVhqEZg9BI8gvIy8tN+g2j0o2JidppNZj/aPiDZpJneWzuOhM30GrLE9Tk9zjciJeTLXSZmBfPeW0JB/RQDPRkxE= Received: by 10.54.42.25 with SMTP id p25mr2202382wrp; Mon, 13 Dec 2004 09:13:55 -0800 (PST) Received: by 10.54.54.30 with HTTP; Mon, 13 Dec 2004 09:13:54 -0800 (PST) Message-ID: <3fff1a7104121309131df25f97@mail.gmail.com> Date: Mon, 13 Dec 2004 19:13:54 +0200 From: Patrick Reply-To: Patrick To: Eric Sandeen Subject: Re: Unknown Issue. Cc: "Piszcz, Justin Michael" , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton , "Kristofer T. Karas" , Jeff Garzik , Linus Torvalds In-Reply-To: <41BDCB8F.5080902@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2E314DE03538984BA5634F12115B3A4E01BC4175@email1.mitretek.org> <41BDCB8F.5080902@sgi.com> X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4621 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nawtyness@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 716 Lines: 20 Hi, > Patrick, can you reproduce on a non-gentoo kernel? That'd be the first > step for this audience. I've not tried to reproduce it on a non-gentoo kernel as the original one that i had the problem was a vanilla kernel ;) ( as i know your fondness of gentoo's patch-o-lotic ) I've been abusing the box the entire day with FreeBSD, the same mysql config and version of the mysqld as well as the same operations ( and some more ... serious ones ( e.g. forkbomb, iozone, etc. ) and no problem's. There were no messages in the log, and nothing in kmesg. Anything else i could try ? Also, as far as i know i was running kernel 2.6.10_rc3 and i'd reinstalled the box twice with new XFS filesystems both times. P From owner-linux-xfs Mon Dec 13 09:15:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:15:10 -0800 (PST) Received: from mail45.messagelabs.com (mail45.messagelabs.com [140.174.2.179]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iBDHEhtr000325 for ; Mon, 13 Dec 2004 09:15:04 -0800 X-VirusChecked: Checked X-Env-Sender: justin.piszcz@mitretek.org X-Msg-Ref: server-17.tower-45.messagelabs.com!1102958054!2358580!1 X-StarScan-Version: 5.4.2; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 21679 invoked from network); 13 Dec 2004 17:14:15 -0000 Received: from mtk-news1.mitretek.org (66.10.26.57) by server-17.tower-45.messagelabs.com with SMTP; 13 Dec 2004 17:14:15 -0000 Received: from email1.mitretek.org (localhost [127.0.0.1]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id iBDHECTP014896 for ; Mon, 13 Dec 2004 12:14:12 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Unknown Issue. Date: Mon, 13 Dec 2004 12:14:11 -0500 Message-ID: <2E314DE03538984BA5634F12115B3A4E01BC4179@email1.mitretek.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unknown Issue. Thread-Index: AcThNc0bdoCvAbnPSxGvklqu2rt0nAAAFLcA From: "Piszcz, Justin Michael" To: "Eric Sandeen" Cc: "Patrick" , , , "Andrew Morton" , "Kristofer T. Karas" , "Jeff Garzik" , "Linus Torvalds" X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iBDHF4tr000457 X-archive-position: 4622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: justin.piszcz@mitretek.org Precedence: bulk X-list: linux-xfs Content-Length: 6885 Lines: 182 > My first thought is that perhaps the filesystem has shut down due to > some error (memory corruption, bad disk, xfs bug...); did you check your > log messages? Yes, there was nothing relevant on either machine. > Justin, when you mentioned that you used xfs' fsck, I guess you used > xfs_repair. Was the log clean when you ran it, or did you force repair > to zero out the log? That could explain the large lost+found/ when you > were done... Ah, good question, yes I used xfs_repair, at this point I knew I had to restore from backup and answered "y" to all questions. I am not sure but I do not recall the log being dirty. In the logs on my main machine, it showed the following when it attempted to mount the two filesystems (root and boot, /dev/hde4 and /dev/hde1 respectively). As far as bad disk/memory, I have tested both systems with memtest86 and the result was 0 errors, as far as the disks go, I have not experienced any problems with either of them until I moved to 2.6.9/2.6.10-rc{1,2}. Justin. Dec 5 08:23:53 jpiszcz kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xc021de57 Dec 5 08:23:53 jpiszcz kernel: [xfs_free_ag_extent+1237/2065] xfs_free_ag_extent+0x4d5/0x811 Dec 5 08:23:53 jpiszcz kernel: [xfs_free_extent+207/242] xfs_free_extent+0xcf/0xf2 Dec 5 08:23:53 jpiszcz kernel: [xlog_grant_push_ail+279/400] xlog_grant_push_ail+0x117/0x190 Dec 5 08:23:53 jpiszcz kernel: [xfs_free_extent+207/242] xfs_free_extent+0xcf/0xf2 Dec 5 08:23:53 jpiszcz kernel: [xfs_trans_get_efd+56/70] xfs_trans_get_efd+0x38/0x46 Dec 5 08:23:53 jpiszcz kernel: [xlog_recover_process_efi+402/508] xlog_recover_process_efi+0x192/0x1fc Dec 5 08:23:53 jpiszcz kernel: [xlog_recover_process_efis+77/129] xlog_recover_process_efis+0x4d/0x81 Dec 5 08:23:53 jpiszcz kernel: [xlog_recover_finish+26/194] xlog_recover_finish+0x1a/0xc2 Dec 5 08:23:53 jpiszcz kernel: [xfs_rtmount_inodes+193/230] xfs_rtmount_inodes+0xc1/0xe6 Dec 5 08:23:53 jpiszcz kernel: [xfs_log_mount_finish+44/48] xfs_log_mount_finish+0x2c/0x30 Dec 5 08:23:53 jpiszcz kernel: [xfs_mountfs+2459/3995] xfs_mountfs+0x99b/0xf9b Dec 5 08:23:53 jpiszcz kernel: [pagebuf_iostart+143/159] pagebuf_iostart+0x8f/0x9f Dec 5 08:23:53 jpiszcz kernel: [atomic_dec_and_lock+39/68] atomic_dec_and_lock+0x27/0x44 Dec 5 08:23:53 jpiszcz kernel: [xfs_readsb+417/559] xfs_readsb+0x1a1/0x22f Dec 5 08:23:53 jpiszcz kernel: [xfs_ioinit+27/46] xfs_ioinit+0x1b/0x2e Dec 5 08:23:53 jpiszcz kernel: [xfs_mount+934/1646] xfs_mount+0x3a6/0x66e Dec 5 08:23:53 jpiszcz kernel: [linvfs_fill_super+155/486] linvfs_fill_super+0x9b/0x1e6 Dec 5 08:23:53 jpiszcz kernel: [snprintf+39/43] snprintf+0x27/0x2b Dec 5 08:23:53 jpiszcz kernel: [disk_name+98/191] disk_name+0x62/0xbf Dec 5 08:23:53 jpiszcz kernel: [sb_set_blocksize+46/94] sb_set_blocksize+0x2e/0x5e Dec 5 08:23:53 jpiszcz kernel: [get_sb_bdev+258/342] get_sb_bdev+0x102/0x156 Dec 5 08:23:53 jpiszcz kernel: [alloc_vfsmnt+156/215] alloc_vfsmnt+0x9c/0xd7 Dec 5 08:23:53 jpiszcz kernel: [linvfs_get_sb+47/51] linvfs_get_sb+0x2f/0x33 Dec 5 08:23:53 jpiszcz kernel: [linvfs_fill_super+0/486] linvfs_fill_super+0x0/0x1e6 Dec 5 08:23:53 jpiszcz kernel: [do_kern_mount+99/235] do_kern_mount+0x63/0xeb Dec 5 08:23:53 jpiszcz kernel: [do_new_mount+158/247] do_new_mount+0x9e/0xf7 Dec 5 08:23:53 jpiszcz kernel: [do_mount+413/443] do_mount+0x19d/0x1bb Dec 5 08:23:53 jpiszcz kernel: [copy_mount_options+96/183] copy_mount_options+0x60/0xb7 Dec 5 08:23:53 jpiszcz kernel: [sys_mount+191/291] sys_mount+0xbf/0x123 Dec 5 08:23:53 jpiszcz kernel: [do_mount_root+47/158] do_mount_root+0x2f/0x9e Dec 5 08:23:53 jpiszcz kernel: [mount_block_root+96/305] mount_block_root+0x60/0x131 Dec 5 08:23:53 jpiszcz kernel: [mount_root+101/135] mount_root+0x65/0x87 Dec 5 08:23:53 jpiszcz kernel: [prepare_namespace+25/178] prepare_namespace+0x19/0xb2 Dec 5 08:23:53 jpiszcz kernel: [flush_workqueue+136/180] flush_workqueue+0x88/0xb4 Dec 5 08:23:53 jpiszcz kernel: [init+427/475] init+0x1ab/0x1db Dec 5 08:23:53 jpiszcz kernel: [init+0/475] init+0x0/0x1db Dec 5 08:23:53 jpiszcz kernel: [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb Dec 5 08:23:53 jpiszcz kernel: VFS: Mounted root (xfs filesystem) readonly. -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Monday, December 13, 2004 12:04 PM To: Piszcz, Justin Michael Cc: Patrick; linux-kernel@vger.kernel.org; linux-xfs@oss.sgi.com; Andrew Morton; Kristofer T. Karas; Jeff Garzik; Linus Torvalds Subject: Re: Unknown Issue. My first thought is that perhaps the filesystem has shut down due to some error (memory corruption, bad disk, xfs bug...); did you check your log messages? Justin, when you mentioned that you used xfs' fsck, I guess you used xfs_repair. Was the log clean when you ran it, or did you force repair to zero out the log? That could explain the large lost+found/ when you were done... Patrick, can you reproduce on a non-gentoo kernel? That'd be the first step for this audience. -Eric Piszcz, Justin Michael wrote: > Patrick, > > I had the same problem on two machines with XFS. Both slackware-current > machines. The kernel on the Dell GX1 was built with GCC-3.4.2 and on my > main box was GCC-3.4.3. > > There seems to be a bug in XFS with some configurations of 2.6.9 and > 2.6.10-rc series. > > After re-installing Slackware-10.0 and upgrading to -current, I have > installed 2.6.10-rc3 and so far, I have not been able to reproduce the > problem. > > Some questions for you: > > 1] What kernel are you running? > 2] What did you last change before you started getting these errors? > > As far as severity goes, I ran XFS' fsck from a KNOPPIX CD and as a > result, I had about 500-600mb of files in my /lost+found directory when > it was finished. Files were missing from all parts of the file system. > I had to restore from backup. I would say stick with your previous > 2.6.9 configuration (if you were running it) or go back to 2.6.8.1, some > 2.6.9 configurations and 2.6.10-rc1 and/or 2.6.10-rc2 definitely cause > file corruption with XFS. So far, however, I have not been able to > reproduce the error with 2.6.10-rc3. > > Justin. > > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Patrick > Sent: Sunday, December 12, 2004 4:15 PM > To: linux-kernel@vger.kernel.org > Subject: Unknown Issue. > > Hi, > > I've got a computer running gentoo, on a clean install where i've got > an odd problem : > > after a while, the computer refuses to spawn processes anymore : > > -/bin/bash: /bin/ps: Input/output error > -/bin/bash: /usr/bin/w: Input/output error > -/bin/bash: /bin/df: Input/output error > -/bin/bash: /bin/mount: Input/output error > From owner-linux-xfs Mon Dec 13 09:18:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:18:14 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBDHHk54001235 for ; Mon, 13 Dec 2004 09:18:07 -0800 Received: by wproxy.gmail.com with SMTP id 67so472250wri for ; Mon, 13 Dec 2004 09:17:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HNS+Z4vujkd3pq9naGoQgStx06gB5wdxzj6zwLyXU0l5TJgUTyd66VQPNSw1PlNBb4zYRQug2QkXUvq7qmX46KaN0oDGVCWTMEpuDhIK1cH+SnV6prAq88DT/HW3+dycQ19fAnO+nUapIw/6apNDlHRLR485/quWhaR8Gcc6YFM= Received: by 10.54.27.79 with SMTP id a79mr1983624wra; Mon, 13 Dec 2004 09:17:18 -0800 (PST) Received: by 10.54.54.30 with HTTP; Mon, 13 Dec 2004 09:17:18 -0800 (PST) Message-ID: <3fff1a7104121309177a52f33d@mail.gmail.com> Date: Mon, 13 Dec 2004 19:17:18 +0200 From: Patrick Reply-To: Patrick To: "Piszcz, Justin Michael" Subject: Re: Unknown Issue. Cc: Eric Sandeen , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton , "Kristofer T. Karas" , Jeff Garzik , Linus Torvalds In-Reply-To: <2E314DE03538984BA5634F12115B3A4E01BC4179@email1.mitretek.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2E314DE03538984BA5634F12115B3A4E01BC4179@email1.mitretek.org> X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4623 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nawtyness@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 3902 Lines: 90 Hi, > Yes, there was nothing relevant on either machine. Same here. > Dec 5 08:23:53 jpiszcz kernel: XFS internal error > XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller > 0xc021de57 > Dec 5 08:23:53 jpiszcz kernel: [xfs_free_ag_extent+1237/2065] > xfs_free_ag_extent+0x4d5/0x811 > Dec 5 08:23:53 jpiszcz kernel: [xfs_free_extent+207/242] > xfs_free_extent+0xcf/0xf2 > Dec 5 08:23:53 jpiszcz kernel: [xlog_grant_push_ail+279/400] > xlog_grant_push_ail+0x117/0x190 > Dec 5 08:23:53 jpiszcz kernel: [xfs_free_extent+207/242] > xfs_free_extent+0xcf/0xf2 > Dec 5 08:23:53 jpiszcz kernel: [xfs_trans_get_efd+56/70] > xfs_trans_get_efd+0x38/0x46 > Dec 5 08:23:53 jpiszcz kernel: [xlog_recover_process_efi+402/508] > xlog_recover_process_efi+0x192/0x1fc > Dec 5 08:23:53 jpiszcz kernel: [xlog_recover_process_efis+77/129] > xlog_recover_process_efis+0x4d/0x81 > Dec 5 08:23:53 jpiszcz kernel: [xlog_recover_finish+26/194] > xlog_recover_finish+0x1a/0xc2 > Dec 5 08:23:53 jpiszcz kernel: [xfs_rtmount_inodes+193/230] > xfs_rtmount_inodes+0xc1/0xe6 > Dec 5 08:23:53 jpiszcz kernel: [xfs_log_mount_finish+44/48] > xfs_log_mount_finish+0x2c/0x30 > Dec 5 08:23:53 jpiszcz kernel: [xfs_mountfs+2459/3995] > xfs_mountfs+0x99b/0xf9b > Dec 5 08:23:53 jpiszcz kernel: [pagebuf_iostart+143/159] > pagebuf_iostart+0x8f/0x9f > Dec 5 08:23:53 jpiszcz kernel: [atomic_dec_and_lock+39/68] > atomic_dec_and_lock+0x27/0x44 > Dec 5 08:23:53 jpiszcz kernel: [xfs_readsb+417/559] > xfs_readsb+0x1a1/0x22f > Dec 5 08:23:53 jpiszcz kernel: [xfs_ioinit+27/46] xfs_ioinit+0x1b/0x2e > Dec 5 08:23:53 jpiszcz kernel: [xfs_mount+934/1646] > xfs_mount+0x3a6/0x66e > Dec 5 08:23:53 jpiszcz kernel: [linvfs_fill_super+155/486] > linvfs_fill_super+0x9b/0x1e6 > Dec 5 08:23:53 jpiszcz kernel: [snprintf+39/43] snprintf+0x27/0x2b > Dec 5 08:23:53 jpiszcz kernel: [disk_name+98/191] disk_name+0x62/0xbf > Dec 5 08:23:53 jpiszcz kernel: [sb_set_blocksize+46/94] > sb_set_blocksize+0x2e/0x5e > Dec 5 08:23:53 jpiszcz kernel: [get_sb_bdev+258/342] > get_sb_bdev+0x102/0x156 > Dec 5 08:23:53 jpiszcz kernel: [alloc_vfsmnt+156/215] > alloc_vfsmnt+0x9c/0xd7 > Dec 5 08:23:53 jpiszcz kernel: [linvfs_get_sb+47/51] > linvfs_get_sb+0x2f/0x33 > Dec 5 08:23:53 jpiszcz kernel: [linvfs_fill_super+0/486] > linvfs_fill_super+0x0/0x1e6 > Dec 5 08:23:53 jpiszcz kernel: [do_kern_mount+99/235] > do_kern_mount+0x63/0xeb > Dec 5 08:23:53 jpiszcz kernel: [do_new_mount+158/247] > do_new_mount+0x9e/0xf7 > Dec 5 08:23:53 jpiszcz kernel: [do_mount+413/443] do_mount+0x19d/0x1bb > Dec 5 08:23:53 jpiszcz kernel: [copy_mount_options+96/183] > copy_mount_options+0x60/0xb7 > Dec 5 08:23:53 jpiszcz kernel: [sys_mount+191/291] > sys_mount+0xbf/0x123 > Dec 5 08:23:53 jpiszcz kernel: [do_mount_root+47/158] > do_mount_root+0x2f/0x9e > Dec 5 08:23:53 jpiszcz kernel: [mount_block_root+96/305] > mount_block_root+0x60/0x131 > Dec 5 08:23:53 jpiszcz kernel: [mount_root+101/135] > mount_root+0x65/0x87 > Dec 5 08:23:53 jpiszcz kernel: [prepare_namespace+25/178] > prepare_namespace+0x19/0xb2 > Dec 5 08:23:53 jpiszcz kernel: [flush_workqueue+136/180] > flush_workqueue+0x88/0xb4 > Dec 5 08:23:53 jpiszcz kernel: [init+427/475] init+0x1ab/0x1db > Dec 5 08:23:53 jpiszcz kernel: [init+0/475] init+0x0/0x1db > Dec 5 08:23:53 jpiszcz kernel: [kernel_thread_helper+5/11] > kernel_thread_helper+0x5/0xb > Dec 5 08:23:53 jpiszcz kernel: VFS: Mounted root (xfs filesystem) > readonly. Ok, well i couldn't pinpoint it at FS and looked like hardware to me, i suppose i could redo the box with 2.6.10 and XFS again to see if i can redo the problem, although i'm partially leaning towards hardware, but that's the easiest thing to blame :) I figure i'm going to try out another FS, maby reiser, that should either do the same, or not, if not, then we know where to start ? P From owner-linux-xfs Mon Dec 13 09:21:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:21:29 -0800 (PST) Received: from mail45.messagelabs.com (mail45.messagelabs.com [140.174.2.179]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iBDHL2Kw001775 for ; Mon, 13 Dec 2004 09:21:22 -0800 X-VirusChecked: Checked X-Env-Sender: justin.piszcz@mitretek.org X-Msg-Ref: server-5.tower-45.messagelabs.com!1102958434!8387176!1 X-StarScan-Version: 5.4.2; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 23131 invoked from network); 13 Dec 2004 17:20:34 -0000 Received: from mtk-news1.mitretek.org (66.10.26.57) by server-5.tower-45.messagelabs.com with SMTP; 13 Dec 2004 17:20:34 -0000 Received: from email1.mitretek.org (localhost [127.0.0.1]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id iBDHKVTP018043 for ; Mon, 13 Dec 2004 12:20:31 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Unknown Issue. Date: Mon, 13 Dec 2004 12:20:30 -0500 Message-ID: <2E314DE03538984BA5634F12115B3A4E01BC417A@email1.mitretek.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unknown Issue. Thread-Index: AcThNyMyyZLRMWkhR6mZ1NQoigplOgAABWew From: "Piszcz, Justin Michael" To: "Patrick" , "Eric Sandeen" Cc: , , "Andrew Morton" , "Kristofer T. Karas" , "Jeff Garzik" , "Linus Torvalds" X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iBDHLNKw001796 X-archive-position: 4624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: justin.piszcz@mitretek.org Precedence: bulk X-list: linux-xfs Content-Length: 1362 Lines: 41 So your problem was only temporary? Or? After I began having the problem, I was trying to edit some files and then I got the same errors as you, ie: /usr/bin/vi Input/Ouput error, and then I tried to run or edit different programs and files and nothing was working. Were you also forced to re-install, or does this only happen sometimes? -----Original Message----- From: Patrick [mailto:nawtyness@gmail.com] Sent: Monday, December 13, 2004 12:14 PM To: Eric Sandeen Cc: Piszcz, Justin Michael; linux-kernel@vger.kernel.org; linux-xfs@oss.sgi.com; Andrew Morton; Kristofer T. Karas; Jeff Garzik; Linus Torvalds Subject: Re: Unknown Issue. Hi, > Patrick, can you reproduce on a non-gentoo kernel? That'd be the first > step for this audience. I've not tried to reproduce it on a non-gentoo kernel as the original one that i had the problem was a vanilla kernel ;) ( as i know your fondness of gentoo's patch-o-lotic ) I've been abusing the box the entire day with FreeBSD, the same mysql config and version of the mysqld as well as the same operations ( and some more ... serious ones ( e.g. forkbomb, iozone, etc. ) and no problem's. There were no messages in the log, and nothing in kmesg. Anything else i could try ? Also, as far as i know i was running kernel 2.6.10_rc3 and i'd reinstalled the box twice with new XFS filesystems both times. P From owner-linux-xfs Mon Dec 13 09:28:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:28:15 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBDHRmMd002397 for ; Mon, 13 Dec 2004 09:28:09 -0800 Received: by wproxy.gmail.com with SMTP id 67so474561wri for ; Mon, 13 Dec 2004 09:27:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FH1u8FbkePbi147XGEDP6+pZ8gYqMtQkWIfaYFsBfBPG3u1EkXjxplg/aPvzX7kjuDVhFUHuwF1sCTB0xonUJpQr6GCPQCWalOdiWa5LWE+D0ly1a9xmyqD93qG/QIQ6H1YVTsLuuY897jxAmdn2IcOKmrzmkoOqnKoaJwltPHE= Received: by 10.54.29.47 with SMTP id c47mr2130279wrc; Mon, 13 Dec 2004 09:27:20 -0800 (PST) Received: by 10.54.54.30 with HTTP; Mon, 13 Dec 2004 09:27:20 -0800 (PST) Message-ID: <3fff1a710412130927268a445a@mail.gmail.com> Date: Mon, 13 Dec 2004 19:27:20 +0200 From: Patrick Reply-To: Patrick To: "Piszcz, Justin Michael" Subject: Re: Unknown Issue. Cc: Eric Sandeen , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton , "Kristofer T. Karas" , Jeff Garzik , Linus Torvalds In-Reply-To: <2E314DE03538984BA5634F12115B3A4E01BC417A@email1.mitretek.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2E314DE03538984BA5634F12115B3A4E01BC417A@email1.mitretek.org> X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nawtyness@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 610 Lines: 19 Hi, > So your problem was only temporary? No, it happened randomly though, and all the time. Generally within an hour. > After I began having the problem, I was trying to edit some files and > then I got the same errors as you, ie: /usr/bin/vi Input/Ouput error, > and then I tried to run or edit different programs and files and nothing > was working. > > Were you also forced to re-install, or does this only happen sometimes? I moved to freebsd as i require the box to actually work, which it seems to be doing at the moment, even after a bit-o-nailing, but that still doesn't solve the problem. P From owner-linux-xfs Mon Dec 13 09:52:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:52:05 -0800 (PST) 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 iBDHpeda003588 for ; Mon, 13 Dec 2004 09:52:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iBDJCmlV019519 for ; Mon, 13 Dec 2004 11:12:48 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iBDHoHpq5810225; Mon, 13 Dec 2004 11:50:17 -0600 (CST) Message-ID: <41BDD659.9070500@sgi.com> Date: Mon, 13 Dec 2004 11:50:17 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Piszcz, Justin Michael" CC: Patrick , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton , "Kristofer T. Karas" , Jeff Garzik , Linus Torvalds Subject: Re: Unknown Issue. References: <2E314DE03538984BA5634F12115B3A4E01BC4179@email1.mitretek.org> In-Reply-To: <2E314DE03538984BA5634F12115B3A4E01BC4179@email1.mitretek.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4626 X-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: 1124 Lines: 31 Piszcz, Justin Michael wrote: > Ah, good question, yes I used xfs_repair, at this point I knew I had to > restore from backup and answered "y" to all questions. I am not sure > but I do not recall the log being dirty. Hm, xfs_repair does not ask any questions. > In the logs on my main machine, it showed the following when it > attempted to mount the two filesystems (root and boot, /dev/hde4 and > /dev/hde1 respectively). > Dec 5 08:23:53 jpiszcz kernel: XFS internal error > XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller > 0xc021de57 (having trouble replaying the log here) Ok, so XVM has found something wrong at this point. Any chance the box had a power failure? Write caches on ide drives can wreak havoc with journaling filesystems... i.e. what happened between "the filesystem was working" and "i remounted the filesystem and got this" > > As far as bad disk/memory, I have tested both systems with memtest86 and > the result was 0 errors, as far as the disks go, I have not experienced > any problems with either of them until I moved to 2.6.9/2.6.10-rc{1,2}. ok -Eric From owner-linux-xfs Mon Dec 13 09:57:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 09:57:16 -0800 (PST) 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 iBDHupXB004447 for ; Mon, 13 Dec 2004 09:57:11 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iBDHuSxT003962 for ; Mon, 13 Dec 2004 11:56:28 -0600 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 iBDHuRCK4254206; Mon, 13 Dec 2004 11:56:27 -0600 (CST) Message-ID: <41BDD7CA.1020806@sgi.com> Date: Mon, 13 Dec 2004 11:56:26 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: "Piszcz, Justin Michael" , Patrick , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, "Kristofer T. Karas" Subject: Re: Unknown Issue. References: <2E314DE03538984BA5634F12115B3A4E01BC4179@email1.mitretek.org> <41BDD659.9070500@sgi.com> In-Reply-To: <41BDD659.9070500@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4627 X-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: 325 Lines: 14 Eric Sandeen wrote: >> Dec 5 08:23:53 jpiszcz kernel: XFS internal error >> XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller >> 0xc021de57 > > (having trouble replaying the log here) > > Ok, so XVM has found something wrong at this point. urk, make that "XFS has found..." of course :) -Eric From owner-linux-xfs Mon Dec 13 10:57:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 10:57:57 -0800 (PST) Received: from mail45.messagelabs.com (mail45.messagelabs.com [140.174.2.179]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iBDIvWiG014493 for ; Mon, 13 Dec 2004 10:57:52 -0800 X-VirusChecked: Checked X-Env-Sender: justin.piszcz@mitretek.org X-Msg-Ref: server-18.tower-45.messagelabs.com!1102964223!8378526!1 X-StarScan-Version: 5.4.2; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 24739 invoked from network); 13 Dec 2004 18:57:03 -0000 Received: from mtk-news1.mitretek.org (66.10.26.57) by server-18.tower-45.messagelabs.com with SMTP; 13 Dec 2004 18:57:03 -0000 Received: from email1.mitretek.org (localhost [127.0.0.1]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id iBDIv0TP011238 for ; Mon, 13 Dec 2004 13:57:01 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Unknown Issue. Date: Mon, 13 Dec 2004 13:57:00 -0500 Message-ID: <2E314DE03538984BA5634F12115B3A4E01BC417F@email1.mitretek.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unknown Issue. Thread-Index: AcThPF6BsUj1/TE/TTayE/VL+ERoegABKkng From: "Piszcz, Justin Michael" To: "Eric Sandeen" Cc: "Patrick" , , , "Andrew Morton" , "Kristofer T. Karas" , "Jeff Garzik" , "Linus Torvalds" X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iBDIvqiG014515 X-archive-position: 4628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: justin.piszcz@mitretek.org Precedence: bulk X-list: linux-xfs Content-Length: 2484 Lines: 65 > Ok, so XVM has found something wrong at this point. Any chance the box > had a power failure? Write caches on ide drives can wreak havoc with > journaling filesystems... i.e. what happened between "the filesystem > was working" and "i remounted the filesystem and got this" For main system: To make a long story short, I was attempting to hook up a cd burner and dvd reader to SATA via SATA<->PATA adapters and enable SATA in the kernel for the Intel ICH5 chipset and I was trying different drivers/options in an attempt to get them to work. However, please note during the entire time, the disk that suffered FS corruption was always hooked to a Ultra ATA/133 Promise Controller. I believe I had a kernel panic once and at another time during either loading SATA drivers or IDE drivers I had a lockup somewhere along the lines and I rebooted improperly. For Dell GX1 system: No, all I did was upgrade the kernel [2.6.9 -> 2.6.10-rc2] and reboot, no power outages or crashes at all. After about an hour or so, I began to experience these problems. -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Monday, December 13, 2004 12:50 PM To: Piszcz, Justin Michael Cc: Patrick; linux-kernel@vger.kernel.org; linux-xfs@oss.sgi.com; Andrew Morton; Kristofer T. Karas; Jeff Garzik; Linus Torvalds Subject: Re: Unknown Issue. Piszcz, Justin Michael wrote: > Ah, good question, yes I used xfs_repair, at this point I knew I had to > restore from backup and answered "y" to all questions. I am not sure > but I do not recall the log being dirty. Hm, xfs_repair does not ask any questions. > In the logs on my main machine, it showed the following when it > attempted to mount the two filesystems (root and boot, /dev/hde4 and > /dev/hde1 respectively). > Dec 5 08:23:53 jpiszcz kernel: XFS internal error > XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller > 0xc021de57 (having trouble replaying the log here) Ok, so XVM has found something wrong at this point. Any chance the box had a power failure? Write caches on ide drives can wreak havoc with journaling filesystems... i.e. what happened between "the filesystem was working" and "i remounted the filesystem and got this" > > As far as bad disk/memory, I have tested both systems with memtest86 and > the result was 0 errors, as far as the disks go, I have not experienced > any problems with either of them until I moved to 2.6.9/2.6.10-rc{1,2}. ok -Eric From owner-linux-xfs Mon Dec 13 16:07:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 16:07:21 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iBE06oRM000893 for ; Mon, 13 Dec 2004 16:07:14 -0800 Received: (qmail 5428 invoked from network); 14 Dec 2004 00:06:22 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 14 Dec 2004 00:06:22 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 6BCDEBB662; Tue, 14 Dec 2004 01:06:21 +0100 (CET) Date: Tue, 14 Dec 2004 01:06:21 +0100 From: Adrian Bunk To: Nathan Scott Cc: Andrew Morton , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] some XFS cleanups (fwd) Message-ID: <20041214000621.GO23151@stusta.de> References: <20041207193533.GG7250@stusta.de> <20041208050348.GI1611@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041208050348.GI1611@frodo> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.80/624/Thu Dec 9 11:01:06 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4629 X-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@stusta.de Precedence: bulk X-list: linux-xfs Content-Length: 745 Lines: 27 On Wed, Dec 08, 2004 at 04:03:48PM +1100, Nathan Scott wrote: >... > > The patch below makes the following cleanups in the XFS code: > > - remove the unused global function vfs_dmapiops > > - remove some unused #define's > > These first changes aren't really useful; they make the DMAPI > code more difficult to integrate and manage in our trees, for > not-enough gain. >... OK, then the #define's have to stay. Would it be OK to make vfs_dmapiops #ifdef on the DMAPI code? > Nathan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From owner-linux-xfs Mon Dec 13 16:45:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Dec 2004 16:45:35 -0800 (PST) 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 iBE0j87J001387 for ; Mon, 13 Dec 2004 16:45:29 -0800 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 iBE0f4xT023799 for ; Mon, 13 Dec 2004 18:41:06 -0600 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 LAA09860; Tue, 14 Dec 2004 11:39:31 +1100 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 iBE0dSXE442988; Tue, 14 Dec 2004 11:39:29 +1100 (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 iBE0awpg001259; Tue, 14 Dec 2004 11:36:59 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iBE0auRS001257; Tue, 14 Dec 2004 11:36:56 +1100 Date: Tue, 14 Dec 2004 11:36:56 +1100 From: Nathan Scott To: Adrian Bunk Cc: Andrew Morton , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] some XFS cleanups (fwd) Message-ID: <20041214003656.GA1215@frodo> References: <20041207193533.GG7250@stusta.de> <20041208050348.GI1611@frodo> <20041214000621.GO23151@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041214000621.GO23151@stusta.de> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4630 X-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: 180 Lines: 12 On Tue, Dec 14, 2004 at 01:06:21AM +0100, Adrian Bunk wrote: > > Would it be OK to make vfs_dmapiops #ifdef on the DMAPI code? > Yep, that should be fine. cheers. -- Nathan From owner-linux-xfs Tue Dec 14 02:04:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 02:04:42 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBEA4KdJ020503 for ; Tue, 14 Dec 2004 02:04:40 -0800 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id iBEA3t5k000182 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 14 Dec 2004 11:03:55 +0100 (CET) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1Ce9X9-0003Ik-00 for ; Tue, 14 Dec 2004 11:03:55 +0100 Date: Tue, 14 Dec 2004 11:01:58 +0100 From: Nicolas.Kowalski@imag.fr To: linux-xfs@oss.sgi.com Subject: xfsrestore on non-xfs filesystem ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (imag.imag.fr [129.88.30.1]); Tue, 14 Dec 2004 11:03:55 +0100 (CET) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 505 Lines: 21 Hello. Is it possible to restore files from a xfsdump backup on a non-XFS filesystem ? Here is was I get when I try to restore on an ext3 filesystem ("/restore"): gaspard:/restore# xfsrestore -i -f /dev/nst0 /restore xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: version 2.2.25 (dump format 3.0) - Running single-threaded xfsrestore: unable to construct a file system handle for /restore: Inappropriate ioctl for device xfsrestore: Restore Status: ERROR Thanks. -- Nicolas From owner-linux-xfs Tue Dec 14 02:24:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 02:24:58 -0800 (PST) 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 iBEAOZF3022668 for ; Tue, 14 Dec 2004 02:24:55 -0800 Received: from [10.1.2.77] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id D4AA0252E1 for ; Tue, 14 Dec 2004 03:24:11 -0700 (MST) Date: Tue, 14 Dec 2004 03:24:45 -0700 From: Michael Loftis To: linux-xfs@oss.sgi.com Subject: Re: xfsrestore on non-xfs filesystem ? Message-ID: <90EECEEF82ABB17F806CA672@[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-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4632 X-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: 987 Lines: 41 --On Tuesday, December 14, 2004 11:01 +0100 Nicolas.Kowalski@imag.fr wrote: > > Hello. > > Is it possible to restore files from a xfsdump backup on a non-XFS > filesystem ? No. xfsdump/restore and XFS style dumps (all dumps in general really) are filesystm specific. If you want/need a portable backup get and use GNU Tar. > > Here is was I get when I try to restore on an ext3 filesystem > ("/restore"): > > gaspard:/restore# xfsrestore -i -f /dev/nst0 /restore > xfsrestore: using scsi tape (drive_scsitape) strategy > xfsrestore: version 2.2.25 (dump format 3.0) - Running single-threaded > xfsrestore: unable to construct a file system handle for /restore: > Inappropriate ioctl for device > xfsrestore: Restore Status: ERROR > > Thanks. > > -- > Nicolas > > > -- 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 Tue Dec 14 02:40:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 02:40:24 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBEAe2QE025147 for ; Tue, 14 Dec 2004 02:40:23 -0800 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id iBEAdcSX010951 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 14 Dec 2004 11:39:38 +0100 (CET) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1CeA5h-0003mE-00 for ; Tue, 14 Dec 2004 11:39:37 +0100 Date: Tue, 14 Dec 2004 11:37:40 +0100 From: Nicolas.Kowalski@imag.fr To: linux-xfs@oss.sgi.com Subject: Re: xfsrestore on non-xfs filesystem ? In-Reply-To: <90EECEEF82ABB17F806CA672@[10.1.2.77]> Message-ID: References: <90EECEEF82ABB17F806CA672@[10.1.2.77]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (imag.imag.fr [129.88.30.1]); Tue, 14 Dec 2004 11:39:38 +0100 (CET) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 404 Lines: 16 On Tue, 14 Dec 2004, Michael Loftis wrote: > --On Tuesday, December 14, 2004 11:01 +0100 Nicolas.Kowalski@imag.fr wrote: > > > Is it possible to restore files from a xfsdump backup on a non-XFS > > filesystem ? > > No. xfsdump/restore and XFS style dumps (all dumps in general really) > are filesystm specific. If you want/need a portable backup get and > use GNU Tar. Ok, Thanks. -- Nicolas From owner-linux-xfs Tue Dec 14 08:10:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 08:10:59 -0800 (PST) Received: from ll.mit.edu (LLMAIL.LL.MIT.EDU [129.55.12.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBEGAa2t000591 for ; Tue, 14 Dec 2004 08:10:57 -0800 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id iBEGAC6d012544 for ; Tue, 14 Dec 2004 11:10:12 -0500 (EST) Received: from skippy.llan.ll.mit.edu( ), claiming to be "[155.34.135.64]" via SMTP by llpost, id smtpdAAAmsaiEx; Tue Dec 14 11:09:55 2004 Message-ID: <41BF1052.7030704@ll.mit.edu> Date: Tue, 14 Dec 2004 11:09:54 -0500 From: Joe Miazga 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: redhat question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miazga@ll.mit.edu Precedence: bulk X-list: linux-xfs Content-Length: 224 Lines: 7 We have a linux cluster running Redhat Enterprise 3. We would like to switch to XFS for our attached storage system. Can it be installed, I noticed you have rpms and patches for RH9. Thanks Joe Miazga miazga@ll.mit.edu From owner-linux-xfs Tue Dec 14 08:35:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 08:35:05 -0800 (PST) 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 iBEGYhSS007421 for ; Tue, 14 Dec 2004 08:35:03 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iBEGYKxT030301 for ; Tue, 14 Dec 2004 10:34:20 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iBEGYJpq5868036; Tue, 14 Dec 2004 10:34:20 -0600 (CST) Message-ID: <41BF160B.8000505@sgi.com> Date: Tue, 14 Dec 2004 10:34:19 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Miazga CC: linux-xfs@oss.sgi.com Subject: Re: redhat question References: <41BF1052.7030704@ll.mit.edu> In-Reply-To: <41BF1052.7030704@ll.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4635 X-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: 509 Lines: 17 see ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre3/kernels/RHEL/ I'll try to get udpates for that out at some point; the xfs code was based on an internal product that's now released, so I should get a "final" 1.3.3 out the door. -Eric Joe Miazga wrote: > We have a linux cluster running Redhat Enterprise 3. We would like to > switch to XFS for our attached storage system. Can it be installed, I > noticed you have rpms and patches for RH9. > Thanks > Joe Miazga > miazga@ll.mit.edu > From owner-linux-xfs Tue Dec 14 14:18:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 14:18:45 -0800 (PST) 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 iBEMIKU2032131 for ; Tue, 14 Dec 2004 14:18:43 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iBENdcmb026269 for ; Tue, 14 Dec 2004 15:39:38 -0800 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 iBEMHuCK4342378; Tue, 14 Dec 2004 16:17:56 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CeKzU-0003BI-00; Tue, 14 Dec 2004 16:17:56 -0600 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: REOPEN 923968 - Backout the i_generation changes again Message-Id: From: Christoph Hellwig Date: Tue, 14 Dec 2004 16:17:56 -0600 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4636 X-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: 388 Lines: 16 this was causing problems with xfsdump Date: Tue Dec 14 14:17:29 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: nathans Undoes mod: xfs-linux:xfs-kern:183616a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:184470a fs/xfs/xfs_ialloc.c - 1.177 fs/xfs/xfs_inode.c - 1.408 From owner-linux-xfs Tue Dec 14 14:32:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 14:32:21 -0800 (PST) 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 iBEMVweW000408 for ; Tue, 14 Dec 2004 14:32:19 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iBEMVaxT006784 for ; Tue, 14 Dec 2004 16:31:36 -0600 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iBEMVZCK4342514; Tue, 14 Dec 2004 16:31:35 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id C06264FC3F; Tue, 14 Dec 2004 16:31:34 -0600 (CST) To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: Re: REOPEN 923968 - Backout the i_generation changes again Date: Tue, 14 Dec 2004 16:31:34 -0600 From: Dean Roehrich Message-Id: <20041214223134.C06264FC3F@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4637 X-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: 742 Lines: 30 Christoph, The original mod that changes the generation number was just batch merged into Propack 3 SP5, so we'd better send this mod along with it. Are you comfortable with the Propack process (I haven't noticed whether you've done this before)? If not, I'll do it. Let me know. Dean >From: Christoph Hellwig >this was causing problems with xfsdump > > >Date: Tue Dec 14 14:17:29 PST 2004 >Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x >Inspected by: nathans >Undoes mod: xfs-linux:xfs-kern:183616a > >The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs > > >Modid: xfs-linux:xfs-kern:184470a >fs/xfs/xfs_ialloc.c - 1.177 >fs/xfs/xfs_inode.c - 1.408 > > From owner-linux-xfs Tue Dec 14 16:44:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 16:44:31 -0800 (PST) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBF0i6OT009652 for ; Tue, 14 Dec 2004 16:44:28 -0800 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iBF0hbVV495575; Wed, 15 Dec 2004 11:43:37 +1100 (AEDT) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iBF0hZuD495498; Wed, 15 Dec 2004 11:43:35 +1100 (AEDT) Date: Wed, 15 Dec 2004 11:43:34 +1100 From: Tim Shimmin To: Nicolas.Kowalski@imag.fr Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore on non-xfs filesystem ? Message-ID: <20041215114334.W32073@boing.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Nicolas.Kowalski@imag.fr on Tue, Dec 14, 2004 at 11:01:58AM +0100 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4638 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 999 Lines: 34 Hi Nicolas, On Tue, Dec 14, 2004 at 11:01:58AM +0100, Nicolas.Kowalski@imag.fr wrote: > > Hello. > > Is it possible to restore files from an xfsdump backup on a non-XFS > filesystem ? > It should be possible and indeed it used to be possible :) > Here is was I get when I try to restore on an ext3 filesystem > ("/restore"): > > gaspard:/restore# xfsrestore -i -f /dev/nst0 /restore > xfsrestore: using scsi tape (drive_scsitape) strategy > xfsrestore: version 2.2.25 (dump format 3.0) - Running single-threaded > xfsrestore: unable to construct a file system handle for /restore: > Inappropriate ioctl for device > xfsrestore: Restore Status: ERROR > Bummer. Looks like we've regressed in this area. In the past, if one wasn't using any EAs (and there may have been some other XFS specific things) then one could restore onto non-xfs - I remember restoring a simple fs onto ext2. I'll talk to the people that changed this handle code and try to get this going again. Cheers, Tim. From owner-linux-xfs Tue Dec 14 19:05:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 19:05:54 -0800 (PST) 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 iBF35UE2023479 for ; Tue, 14 Dec 2004 19:05:51 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iBF34wl20515; Wed, 15 Dec 2004 14:04:58 +1100 Date: Wed, 15 Dec 2004 14:04:58 +1100 From: Nathan Scott Message-Id: <200412150304.iBF34wl20515@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 923092 - reduce DMAPI BKL use X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4639 X-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: 479 Lines: 14 Drop the big kernel lock while executing DMAPI ioctls (esp. bulkstat!). Date: Wed Dec 15 14:03:46 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: linux-melb:dmapi:20764a fs/dmapi/dmapi_sysent.c - 1.32 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_sysent.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h From owner-linux-xfs Tue Dec 14 19:11:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 19:11:29 -0800 (PST) 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 iBF3B5YF023962 for ; Tue, 14 Dec 2004 19:11:26 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iBF3AZa21294; Wed, 15 Dec 2004 14:10:35 +1100 Date: Wed, 15 Dec 2004 14:10:35 +1100 From: Nathan Scott Message-Id: <200412150310.iBF3AZa21294@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 923092 - fix xfs_iget_core scaling issues X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4640 X-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: 1040 Lines: 24 Fix a performance and scaling problem in xfs_iget_core. Improved the inode hash table sizing heuristics, and allow these to be manually tweaked as well. Date: Wed Dec 15 14:08:53 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20766a xfs_vfsops.c - 1.459 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.459&r2=text&tr2=1.458&f=h xfs_iget.c - 1.200 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.200&r2=text&tr2=1.199&f=h xfs_clnt.h - 1.44 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_clnt.h.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfs_mount.h - 1.192 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.192&r2=text&tr2=1.191&f=h xfs_inode.h - 1.197 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.197&r2=text&tr2=1.196&f=h From owner-linux-xfs Tue Dec 14 23:14:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Dec 2004 23:14:21 -0800 (PST) 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 iBF7Dvug003498 for ; Tue, 14 Dec 2004 23:14:18 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iBF7DRR07620; Wed, 15 Dec 2004 18:13:27 +1100 Date: Wed, 15 Dec 2004 18:13:27 +1100 From: Nathan Scott Message-Id: <200412150713.iBF7DRR07620@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 926724 - 64KB pages X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4641 X-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: 497 Lines: 15 Prevent attempts to mount 512 byte sector filesystems with 64KB pagesizes, until fixed. Date: Wed Dec 15 18:12:44 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20780a linux-2.6/xfs_buf.c - 1.183 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.183&r2=text&tr2=1.182&f=h From owner-linux-xfs Wed Dec 15 06:32:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Dec 2004 06:32:53 -0800 (PST) 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 iBFEWUg4000468 for ; Wed, 15 Dec 2004 06:32:51 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iBFFrsiW021490 for ; Wed, 15 Dec 2004 07:53:54 -0800 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 iBFEV6CK4385243; Wed, 15 Dec 2004 08:31:06 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CeaBG-0007Vg-00; Wed, 15 Dec 2004 08:31:06 -0600 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 921072 - make sure to always reclaim inodes in xfs_finish_reclaim Message-Id: From: Christoph Hellwig Date: Wed, 15 Dec 2004 08:31:06 -0600 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4642 X-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: 444 Lines: 15 Date: Wed Dec 15 06:30:54 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:184505a fs/xfs/xfs_vnodeops.c - 1.637 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.637&r2=text&tr2=1.636&f=h - don't forget to call xfs_ireclaim for bad vnodes From owner-linux-xfs Thu Dec 16 11:11:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Dec 2004 11:11:16 -0800 (PST) Received: from imo-d21.mx.aol.com (imo-d21.mx.aol.com [205.188.144.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBGJAsWK028056 for ; Thu, 16 Dec 2004 11:11:15 -0800 Received: from AndyLiebman@aol.com by imo-d21.mx.aol.com (mail_out_v37_r3.8.) id 4.e2.8f40134 (3850) for ; Thu, 16 Dec 2004 14:10:09 -0500 (EST) From: AndyLiebman@aol.com Message-ID: Date: Thu, 16 Dec 2004 14:10:09 EST Subject: After XFS_REPAIR, then what? To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5115 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 2341 Lines: 46 Hi. I hope somebody can help us out here. We are running XFS on a Linux Hardware RAID array (2.6.6 kernel, XFS as a module, RAID contains only data -- no OS files -- RAID card is 3ware 9000). A technician of ours was trying to expand our storage with a new RAID card attached to some additional drives that he put into the empty bays on our server. During the hardware upgrade (the machine was shutdown, of course) somehow, the file system on the EXISTING RAID became very corrupted. And our OS drive also got fried. We couldn't reboot. We replaced the OS drive and imaged it with a recent backup. Then, upon booting up again, when we mounted the existing array and did an "ls" command -- no files showed up and we got an "unknown error 90 or 99" (I forget which). After studying the problem for a while and looking at various logs, we rebooted the machine, mounted the RAID, then unmounted the RAID and ran "xfs_repair -n /dev/sda" to see what actions would be taken if we really ran repair. Then we ran "xfs_repair" for real. When the process was completed, we had about 10,000 inodes listed in a lost+found directory. About 3000 were files. The rest were symbolic links to those files. We listed all the files using Midnight Commander -- and wherever we highlighted a LINK we could see in the info line at the bottom of Midnight Commander the name of the file the link used to point to (they're all dead links of course, because the files they pointed to are not where they used to be). However, when we highlighted anything that was NOT a link (i.e., real data), no information was displayed in MC other than the inode number. So, at this point, I have about 3000 inodes that still probably contain valid data, but that no longer are associated with any filenames that I can recognize or use. My question is, is there any way to get back the original filenames at this point -- or has the connection between the filenames and the data been lost? On another point, is there anything one should do on a daily/weekly basis to maintain the integrity of an xfs filesystem on Linux? From what I've read, it seems that it's not recommended to automatically run xfs_check or xfs_repair on a regular basis but rather, only when you think something is wrong. Thanks in advance for the help Andy Liebman From owner-linux-xfs Fri Dec 17 07:08:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Dec 2004 07:08:34 -0800 (PST) Received: from imo-m19.mx.aol.com (imo-m19.mx.aol.com [64.12.137.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBHF7xvC011546 for ; Fri, 17 Dec 2004 07:08:24 -0800 Received: from AndyLiebman@aol.com by imo-m19.mx.aol.com (mail_out_v37_r3.8.) id 4.13e.8bf1d3a (3850) for ; Fri, 17 Dec 2004 10:07:08 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <13e.8bf1d3a.2ef4501c@aol.com> Date: Fri, 17 Dec 2004 10:07:08 EST Subject: Partions (or lack thereof) and xfs repair To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5115 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 1719 Lines: 36 Hi, I wrote in yesterday about a serious file system corruption incident. This issue is related, but separate, so I want to create a separate post. To summarize yesterday's issue: A 1.75 TB xfs file system got corrupted. Upon running xfs_repair, I ended up with about 3000 files in a lost+found directory. They are listed by INODE number. The file names seem to have gotten lost. I don't know if this is normal or not for xfs_repair. I am wondering if my particular setup method could have contributed to a failure of xfs_repair. When I create a RAID-5 array with a 3ware 9000 SATA card, I get a 1.75 TB device -- let's call it /dev/sda. On the advice of some Linux experts who should know about these things, I DO NOT create any partitions on the device /dev/sda. I do not run fdisk on the device. When I put the xfs filesystem on it, I use: "mkfs.xfs /dev/sda" xfs doesn't complain about not being on a partition. I haven't had any issues until this one -- after many months and many machines that have been set up this way. The only thing that worries me is that if a user opens up a disk management utility such as the Mandrake "DiskDrake" program, he will get a message saying "I don't understand this device. It doesn't have any information that I can understand. Do you want to create a partition on it?" I don't use DiskDrake, so I don't really care about this message. And I have made it difficult for my users to run DiskDrake out in the field. But does the fact that I don't run fdisk on the device, and the lack of at least a single partition, in any way making the xfs file system vulnerable? I would appreciate your speedy and thoughtful comments. Regards, Andy Liebman From owner-linux-xfs Fri Dec 17 07:34:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Dec 2004 07:34:40 -0800 (PST) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBHFYH4j013984 for ; Fri, 17 Dec 2004 07:34:38 -0800 Received: from [10.0.6.17] (a194-109-165-123.adsl.xs4all.nl [194.109.165.123]) (authenticated bits=0) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id iBHFXlWF000893; Fri, 17 Dec 2004 16:33:48 +0100 (CET) (envelope-from seth.mos@xs4all.nl) Message-ID: <41C2FC59.8050604@xs4all.nl> Date: Fri, 17 Dec 2004 16:33:45 +0100 From: Seth Mos User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: AndyLiebman@aol.com CC: linux-xfs@oss.sgi.com Subject: Re: Partions (or lack thereof) and xfs repair References: <13e.8bf1d3a.2ef4501c@aol.com> In-Reply-To: <13e.8bf1d3a.2ef4501c@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Status: Clean X-archive-position: 4645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seth.mos@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1098 Lines: 31 AndyLiebman@aol.com wrote: > Hi, > But does the fact that I don't run fdisk on the device, and the lack of at > least a single partition, in any way making the xfs file system vulnerable? No, not really. However, the XFS superblock lives on sector 0 of the partition or sector 0 of the device if you don't have any. If you write a partition table, whatever sort, even empty, this will destroy the superblock and make the filesystem unmountable. xfs_repair would search out an alternate superblock and could even restore it theoretically. I don't see what advantage the "no partition" approach has except not knowing what is actually on the disk. And shooting yourself in the foot is easy, just one disk utility that asks to write a disk signature will destroy it. It was probably to circumvent 1 or 2 TB limits that broke some utility. Fdisk and most others go up to 2TB, beyond is special and requires 2.6.x This works similar to assigning raw disk devices to databases and letting a co worker thinking there is still disk space there since there is nothing on it :-( Cheers From owner-linux-xfs Fri Dec 17 07:39:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Dec 2004 07:39:25 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBHFd2h8014498 for ; Fri, 17 Dec 2004 07:39:23 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.1/8.13.1/Debian-19) with ESMTP id iBHFcLNw021071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Dec 2004 10:38:22 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.1/8.13.1/Submit) with ESMTP id iBHFcL8J021068; Fri, 17 Dec 2004 10:38:21 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Fri, 17 Dec 2004 10:38:21 -0500 (EST) From: Net Llama! To: AndyLiebman@aol.com cc: linux-xfs@oss.sgi.com Subject: Re: Partions (or lack thereof) and xfs repair In-Reply-To: <13e.8bf1d3a.2ef4501c@aol.com> Message-ID: References: <13e.8bf1d3a.2ef4501c@aol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Fri, 17 Dec 2004 10:38:22 -0500 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4646 X-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: 940 Lines: 20 On Fri, 17 Dec 2004 AndyLiebman@aol.com wrote: > I am wondering if my particular setup method could have contributed to a > failure of xfs_repair. When I create a RAID-5 array with a 3ware 9000 SATA card, I > get a 1.75 TB device -- let's call it /dev/sda. On the advice of some Linux > experts who should know about these things, I DO NOT create any partitions on > the device /dev/sda. I do not run fdisk on the device. When I put the xfs > filesystem on it, I use: > > "mkfs.xfs /dev/sda" I certainly don't consider myself to be an expert, but i've never heard of doing this before, and i'm kinda surprised that it works at all. What was the justification for formatting a block device, rather than a partition XFS? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Fri Dec 17 08:24:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Dec 2004 08:24:32 -0800 (PST) Received: from foehn.mgras.de (quickstep.mgras.net [213.146.115.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBHGO8oH021979 for ; Fri, 17 Dec 2004 08:24:29 -0800 Received: from osprey.mgras.de (osprey.mgras.de [192.168.48.3]) by foehn.mgras.de (8.13.0/8.13.0) with ESMTP id iBHGNT3D009971 for ; Fri, 17 Dec 2004 17:23:30 +0100 (CET) Received: (from news@localhost) by osprey.mgras.de (AIX5.1/8.11.6p2/8.11.0) id iBHGNTc35746 for linux-xfs@oss.sgi.com; Fri, 17 Dec 2004 17:23:29 +0100 To: linux-xfs@oss.sgi.com Path: not-for-mail From: Martin Spott Newsgroups: list.linux-xfs Subject: Re: Partions (or lack thereof) and xfs repair Date: Fri, 17 Dec 2004 16:23:28 +0000 (UTC) Organization: home Message-ID: References: <13e.8bf1d3a.2ef4501c@aol.com> NNTP-Posting-Host: foehn.mgras.de X-Trace: osprey.mgras.de 1103300608 30168 192.168.48.1 (17 Dec 2004 16:23:28 GMT) X-Complaints-To: usenet@osprey.mgras.de NNTP-Posting-Date: Fri, 17 Dec 2004 16:23:28 +0000 (UTC) User-Agent: tin/pre-1.4-19990927 ("Nine While Nine") (UNIX) (SunOS/5.8 (sun4m)) X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4647 X-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.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs Content-Length: 690 Lines: 19 Net Llama! wrote: > On Fri, 17 Dec 2004 AndyLiebman@aol.com wrote: >> "mkfs.xfs /dev/sda" > > I certainly don't consider myself to be an expert, but i've never heard of > doing this before, and i'm kinda surprised that it works at all. What was > the justification for formatting a block device, rather than a partition > XFS? Why create a partition table when you're going to use the whole device anyway ? ;-) I've done this several times with different filesystems (Ext2, Reiser, XFS) and I never got into any trouble, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs Fri Dec 17 14:48:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Dec 2004 14:48:34 -0800 (PST) Received: from mail.mailsnare.net (v187.mailsnare.net [206.246.200.187]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBHMm4Ta004808 for ; Fri, 17 Dec 2004 14:48:24 -0800 Received: from [192.168.1.2] (ip243.132.1511H-CUD12K-01.ish.de [62.143.132.243]) by mail.mailsnare.net (Postfix) with ESMTP id C26A4C099 for ; Fri, 17 Dec 2004 22:47:33 +0000 (UTC) Message-ID: <41C36205.3080406@spammotel.com> Date: Fri, 17 Dec 2004 23:47:33 +0100 From: Juergen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Partions (or lack thereof) and xfs repair References: <13e.8bf1d3a.2ef4501c@aol.com> In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by ClamAV at mailsnare.net X-Virus-Status: Clean X-archive-position: 4649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ajdvgtneapwe@spammotel.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 14 Martin Spott wrote: > Why create a partition table when you're going to use the whole device > anyway ? ;-) > I've done this several times with different filesystems (Ext2, Reiser, > XFS) and I never got into any trouble, Me too (never had any problems with it), especially when I use large drives (> 2TB). Regards, Jürgen From owner-linux-xfs Mon Dec 20 13:19:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Dec 2004 13:19:15 -0800 (PST) Received: from irpns.grc.nia.nih.gov (webmail.grc.nia.nih.gov [137.187.161.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBKLIpqK025406 for ; Mon, 20 Dec 2004 13:19:12 -0800 Received: from [137.187.162.77] ([137.187.162.77]) by irpns.grc.nia.nih.gov (8.11.6/8.11.6) with ESMTP id iBKLICY04664 for ; Mon, 20 Dec 2004 16:18:12 -0500 Subject: getfacl crashes From: Charles Weber To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1103577485.834.16.camel@weberlin.grc.nia.nih.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 20 Dec 2004 16:18:05 -0500 Content-Transfer-Encoding: 7bit X-niairp-MailScanner-Information: Please contact the ISP for more information X-niairp-MailScanner: Found to be clean X-MailScanner-From: weberc@irpmail.nia.nih.gov X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: weberc@irpmail1.grc.nia.nih.gov Precedence: bulk X-list: linux-xfs Content-Length: 1224 Lines: 35 I have some older samba with acl servers to retire. they are redhat 7.3 2.4.21-xfs kernel xfsprogs-2.5.6-0 acl-2.2.15-0 My new server is FC2 2.6.8-1.521smp x86_64 xfsprogs-2.6.25-1 acl-2.2.27-1 I have gotten good service except some the filesystems have become confused as to file size, that is a 400 GB partition may have some directories that think they contain 600 GB. The servers have been used for PC and Mac samba, so I have some funny (such as :: or " or chinese characters) names. I also have to change uid to sid samba mapping after the copy. My test strategy is to smbmount onto the new server, star the files over, getfacl -R olddir >file.lst and then replay the acl file to apply acl rights on the new file share. Then I fix all the ugly file name errors and move on. This takes care of acl and uid properly when testing on 30 GB directories. When I tried it with a 250GB samba share, I ran into the problem of getfacl not finishing the logging of acls and the not so serious problem of setfacl not finishing when it ran into some illegal file names. Comments, suggestions or xfsprog suggested versions are welcome. I am reluctant to xfsrepair the partitions as I dont want to risk losing any data. Chuck From owner-linux-xfs Mon Dec 20 14:31:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Dec 2004 14:31:33 -0800 (PST) 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 iBKMV8wF028124 for ; Mon, 20 Dec 2004 14:31:30 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29384; Tue, 21 Dec 2004 09:30:34 +1100 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 iBKMUWXE645312; Tue, 21 Dec 2004 09:30:32 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iBKMUUfE631966; Tue, 21 Dec 2004 09:30:30 +1100 (EST) Date: Tue, 21 Dec 2004 09:30:29 +1100 From: Nathan Scott To: Charles Weber Cc: linux-xfs@oss.sgi.com Subject: Re: getfacl crashes Message-ID: <20041221093029.B641816@wobbly.melbourne.sgi.com> References: <1103577485.834.16.camel@weberlin.grc.nia.nih.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1103577485.834.16.camel@weberlin.grc.nia.nih.gov>; from weberc@irpmail1.grc.nia.nih.gov on Mon, Dec 20, 2004 at 04:18:05PM -0500 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4652 X-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: 1003 Lines: 30 On Mon, Dec 20, 2004 at 04:18:05PM -0500, Charles Weber wrote: > > My test strategy is to smbmount onto the new server, star the files > over, getfacl -R olddir >file.lst and then replay the acl file to apply > acl rights on the new file share. Then I fix all the ugly file name > errors and move on. This takes care of acl and uid properly when testing > on 30 GB directories. > > When I tried it with a 250GB samba share, I ran into the problem of > getfacl not finishing the logging of acls and the not so serious problem > of setfacl not finishing when it ran into some illegal file names. Details...? Did getfacl dump core? Kernel oops? Any stacktraces? Got a reproducible test case for us to analyse? > Comments, suggestions or xfsprog suggested versions are welcome. xfsprogs version is irrelevent here, all will work fine for your needs. > I am reluctant to xfsrepair the partitions as I dont want to risk losing > any data. You do keep backups though, right? :) cheers. -- Nathan From owner-linux-xfs Tue Dec 21 03:42:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Dec 2004 03:42:34 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBLBgVM7007046 for ; Tue, 21 Dec 2004 03:42:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBLBgVtx007045 for linux-xfs@oss.sgi.com; Tue, 21 Dec 2004 03:42:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBLBgTvN007028 for ; Tue, 21 Dec 2004 03:42:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBLB02Ku005582; Tue, 21 Dec 2004 03:00:02 -0800 Date: Tue, 21 Dec 2004 03:00:02 -0800 Message-Id: <200412211100.iBLB02Ku005582@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 350] Starting XFS recovery never complete X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4653 X-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: 3321 Lines: 80 http://oss.sgi.com/bugzilla/show_bug.cgi?id=350 ------- Additional Comments From tom@odl.qmul.ac.uk 2004-21-12 03:00 PDT ------- I've just had similar problem on Debian Sarge running 2.6.7-1-686-smp and xfsprogs 2.6.20. The partition was /var and had postgres and openldap running on it. The partition was taken offline due to the error, reboot didn't fix it, though the xfs_repair did, sorry don't have the output :-( Here's the trace from dmesg after the reboot if its useful. i *think* the error msg was the same before the reboot. Filesystem "md1": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/xfs/xfs_alloc.c. Caller 0xf89a07ad [] xfs_alloc_read_agf+0x12d/0x1f0 [xfs] [] xfs_alloc_fix_freelist+0x3fd/0x490 [xfs] [] xfs_alloc_fix_freelist+0x3fd/0x490 [xfs] [] xfs_alloc_fix_freelist+0x3fd/0x490 [xfs] [] xfs_trans_log_buf+0x72/0xb0 [xfs] [] xfs_alloc_log_agf+0x5a/0x60 [xfs] [] xfs_alloc_ag_vextent+0x61/0x140 [xfs] [] xfs_alloc_vextent+0x131/0x4b0 [xfs] [] xfs_bmap_alloc+0xd08/0x1c70 [xfs] [] xfs_bmap_add_extent_delay_real+0x8cd/0x16b0 [xfs] [] ide_build_sglist+0x3d/0xb0 [ide_core] [] __ide_dma_begin+0x35/0x50 [ide_core] [] __ide_dma_write+0xc0/0xd0 [ide_core] [] ide_dma_intr+0x0/0xb0 [ide_core] [] xfs_bmap_add_extent+0x3b4/0x4f0 [xfs] [] xfs_bmapi+0x5c8/0x1640 [xfs] [] handle_IRQ_event+0x49/0x80 [] xfs_bmbt_get_state+0x2f/0x40 [xfs] [] xfs_bmap_do_search_extents+0xbc/0x420 [xfs] [] xfs_log_reserve+0xde/0xf0 [xfs] [] xfs_iomap_write_allocate+0x2ca/0x530 [xfs] [] autoremove_wake_function+0x0/0x60 [] xfs_iomap+0x3ff/0x560 [xfs] [] xfs_map_blocks+0x58/0xc0 [xfs] [] xfs_page_state_convert+0x54b/0x6d0 [xfs] [] radix_tree_gang_lookup_tag+0x63/0x80 [] find_get_pages_tag+0x4e/0xb0 [] linvfs_writepage+0x66/0x100 [xfs] [] mpage_writepages+0x211/0x350 [] linvfs_writepage+0x0/0x100 [xfs] [] xfs_inode_flush+0x21a/0x280 [xfs] [] pagebuf_rele+0x3a/0x170 [xfs] [] xfs_bdstrat_cb+0x3e/0x50 [xfs] [] xfs_trans_first_ail+0x16/0x30 [xfs] [] do_writepages+0x42/0x50 [] __sync_single_inode+0x79/0x230 [] sync_sb_inodes+0x18e/0x2f0 [] writeback_inodes+0x15d/0x190 [] wb_kupdate+0xa7/0x120 [] __pdflush+0xf8/0x230 [] pdflush+0x0/0x30 [] pdflush+0x26/0x30 [] wb_kupdate+0x0/0x120 [] pdflush+0x0/0x30 [] kthread+0xba/0xc0 [] kthread+0x0/0xc0 [] kernel_thread_helper+0x5/0x10 xfs_force_shutdown(md1,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xf8a0ee4b Filesystem "md1": Corruption of in-memory data detected. Shutting down filesystem: md1 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(md1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf8a0ee4b XFS mounting filesystem md1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Dec 23 03:12:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Dec 2004 03:12:16 -0800 (PST) Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBNBBoBW001148 for ; Thu, 23 Dec 2004 03:12:11 -0800 Received: from AndyLiebman@aol.com by imo-d22.mx.aol.com (mail_out_v37_r3.8.) id 4.d1.1eafb88f (4418) for ; Thu, 23 Dec 2004 06:13:12 -0500 (EST) From: AndyLiebman@aol.com Message-ID: Date: Thu, 23 Dec 2004 06:13:12 EST Subject: Best Maintenance Practices with XFS To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5115 X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 445 Lines: 10 I asked this question the other day at the end of long post about something related -- and nobody responded to this part: Is there anything one should do on a daily/weekly basis to maintain the integrity of an xfs filesystem on Linux? From what I have read, it seems that it is NOT recommended to automatically run xfs_check or xfs_repair on a regular basis, but rather only when you have evidence that something is wrong. Andy Liebman From owner-linux-xfs Thu Dec 23 18:49:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Dec 2004 18:49:30 -0800 (PST) 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 iBO2muEl031765 for ; Thu, 23 Dec 2004 18:49:24 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iBO2oLH15245 for linux-xfs@oss.sgi.com; Fri, 24 Dec 2004 13:50:21 +1100 Date: Fri, 24 Dec 2004 13:50:21 +1100 From: Nathan Scott Message-Id: <200412240250.iBO2oLH15245@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904192 - hash.h in 2.4 X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4656 X-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: 748 Lines: 21 Copy of the 2.6 linux/hash.h for use within XFS - performs better than our current block hash. Date: Fri Dec 24 13:45:41 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:20987a include/linux/hash.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/hash.h Modid: 2.4.x-xfs-melb:linux:20988a split-patches/hash-backport - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/hash-backport split-patches/series - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/series.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h From owner-linux-xfs Thu Dec 23 18:58:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Dec 2004 18:58:21 -0800 (PST) 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 iBO2vsjc032492 for ; Thu, 23 Dec 2004 18:58:15 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iBO2xFD15475; Fri, 24 Dec 2004 13:59:15 +1100 Date: Fri, 24 Dec 2004 13:59:15 +1100 From: Nathan Scott Message-Id: <200412240259.iBO2xFD15475@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 927536 - per-device hash tables X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4657 X-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: 1161 Lines: 25 Move to per-device hash tables (scalability), and use Bill Irwins hash (quicker). Date: Fri Dec 24 13:58:33 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20989a xfsidbg.c - 1.268 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.268&r2=text&tr2=1.267&f=h xfs_vfsops.c - 1.460 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.460&r2=text&tr2=1.459&f=h linux-2.6/xfs_buf.h - 1.102 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.102&r2=text&tr2=1.101&f=h linux-2.6/xfs_buf.c - 1.184 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.184&r2=text&tr2=1.183&f=h linux-2.4/xfs_buf.h - 1.108 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h linux-2.4/xfs_buf.c - 1.200 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.200&r2=text&tr2=1.199&f=h From owner-linux-xfs Thu Dec 23 19:09:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Dec 2004 19:09:18 -0800 (PST) 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 iBO38p7R000903 for ; Thu, 23 Dec 2004 19:09:12 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iBO3ADm15728; Fri, 24 Dec 2004 14:10:13 +1100 Date: Fri, 24 Dec 2004 14:10:13 +1100 From: Nathan Scott Message-Id: <200412240310.iBO3ADm15728@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 926724 - fix 64K pagesizes on 2.6 X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4658 X-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: 576 Lines: 16 Switch to managing uptodate state on a region within a page, rather than on a sector within a page. Fixes 64K pagesize kernels with 512 byte sectors. Date: Fri Dec 24 14:09:31 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen@sgi.com,tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20990a linux-2.6/xfs_buf.c - 1.185 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.185&r2=text&tr2=1.184&f=h From owner-linux-xfs Thu Dec 23 19:13:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Dec 2004 19:13:59 -0800 (PST) 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 iBO3DWfV001570 for ; Thu, 23 Dec 2004 19:13:53 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iBO3EsD15867; Fri, 24 Dec 2004 14:14:54 +1100 Date: Fri, 24 Dec 2004 14:14:54 +1100 From: Nathan Scott Message-Id: <200412240314.iBO3EsD15867@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 927535 - attr_multi opcount check X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4659 X-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: 636 Lines: 16 Add sanity checks before use of attr_multi opcount parameter. Date: Fri Dec 24 14:14:31 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: kaos@sgi.com,overby@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20991a linux-2.6/xfs_ioctl.c - 1.117 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h linux-2.4/xfs_ioctl.c - 1.112 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h From owner-linux-xfs Thu Dec 23 19:22:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Dec 2004 19:22:27 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBO3M0Jc002341 for ; Thu, 23 Dec 2004 19:22:22 -0800 Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id iBO3NRHn024037; Fri, 24 Dec 2004 14:23:27 +1100 Received: from jdc.local (ppp1FAC.dsl.pacific.net.au [203.100.245.172]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id iBO3NQPh023110; Fri, 24 Dec 2004 14:23:26 +1100 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.13.1/8.13.1/Debian-20) with ESMTP id iBO3Mgiv004651; Fri, 24 Dec 2004 14:22:42 +1100 Received: (from jason@localhost) by jdc.local (8.13.1/8.13.1/Submit) id iBO3MgUb004643; Fri, 24 Dec 2004 14:22:42 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16843.35714.165496.249150@jdc.local> Date: Fri, 24 Dec 2004 14:22:42 +1100 To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: Best Maintenance Practices with XFS In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.3.1 Reply-To: jasonw@ariel.its.unimelb.edu.au X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.its.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 599 Lines: 14 AndyLiebman@aol.com writes: > I asked this question the other day at the end of long post about something > related -- and nobody responded to this part: > > Is there anything one should do on a daily/weekly basis to maintain the > integrity of an xfs filesystem on Linux? No. xfs_check and xfs_repair should only be used when there is evidence of a problem, and after the file system has been unmounted. If the file system becomes highly fragmented and performance is important you might want to run xfs_fsr to improve it (this has nothing to do with "maintaining integrity", however). From owner-linux-xfs Fri Dec 24 06:28:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Dec 2004 06:28:30 -0800 (PST) Received: from imo-m24.mx.aol.com (imo-m24.mx.aol.com [64.12.137.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBOES4QP018292 for ; Fri, 24 Dec 2004 06:28:24 -0800 Received: from AndyLiebman@aol.com by imo-m24.mx.aol.com (mail_out_v37_r3.8.) id y.1a5.2d5c3eaf (3310); Fri, 24 Dec 2004 09:29:20 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <1a5.2d5c3eaf.2efd81c0@aol.com> Date: Fri, 24 Dec 2004 09:29:20 EST Subject: Re: Best Maintenance Practices with XFS To: jasonw@ariel.its.unimelb.edu.au CC: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5115 X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 1527 Lines: 42 Thanks for that reply, Jason. I just looked at the man page for xfs_fsr. It's a bit sketchy -- it doesn't really give good examples of what kinds of files it would be appropriate to use this on. For instance, I am storing thousands of fairly large video and audio files -- in general, they may be anywhere from 10s of MBs up to 2 GBs in size. After many months and cyles of creating such files and deleting such files, maybe it will be a good idea to run xfs_fsr (I imagine that the best time to run it would be when many files have just been deleted, and as few files as possible remain on a file system). Questions: 1) Does xfs_fsr reorganize "free space"? 2) How safe is xfs_fsr? Is there any risk in running it? 3) How large a benefit can be gained from running it? 4) Is there any utility to visually see how fragmented an xfs filesystem is? It was/is my understanding that xfs suffers far less from fragmentation than many other filesystems (such as NTFS). Can you explain why that is? And, once again, how can you know when fragmentation is becoming and issue (other than "guessing" that you're seeing lowered performance)? Hope to hear fro you and others soon. Happy Holidays, Andy Liebman > a message dated 12/23/2004 10:23:32 PM Eastern Standard Time, > jasonw@ariel.its.unimelb.edu.au writes: > If the file system becomes highly fragmented and performance is > important you might want to run xfs_fsr to improve it (this has > nothing to do with "maintaining integrity", however). From owner-linux-xfs Fri Dec 24 13:06:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Dec 2004 13:06:22 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBOL5vlx016570 for ; Fri, 24 Dec 2004 13:06:17 -0800 Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (rwcrmhc11) with ESMTP id <200412242107210130018r9de>; Fri, 24 Dec 2004 21:07:21 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1) with ESMTP id iBOL7NRG009161 for ; Fri, 24 Dec 2004 16:07:24 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1/Submit) id iBOL7N7o009160 for linux-xfs@oss.sgi.com; Fri, 24 Dec 2004 16:07:23 -0500 (EST) (envelope-from rodrigc) Date: Fri, 24 Dec 2004 16:07:23 -0500 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: aclocal.m4 xfsprogs fix for FreeBSD Message-ID: <20041224210723.GA9140@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: linux-xfs Content-Length: 1568 Lines: 50 Hi, I am working on getting xfsprogs to compile under FreeBSD. Here is a small aclocal.m4 patch to get a few things to compile on FreeBSD. On FreeBSD,: gzip is /usr/bin/gzip msgfmt is /usr/local/bin/msgfmt msgmerge is /usr/local/bin/msgmerge Is this patch OK to add to the Linux XFS CVS repository? Index: aclocal.m4 =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/aclocal.m4,v retrieving revision 1.13 diff -u -r1.13 aclocal.m4 --- aclocal.m4 7 Oct 2004 23:09:23 -0000 1.13 +++ aclocal.m4 24 Dec 2004 21:02:14 -0000 @@ -107,7 +107,7 @@ tar=$TAR AC_SUBST(tar) if test -z "$ZIP"; then - AC_PATH_PROG(ZIP, gzip,, /bin:/usr/local/bin:/usr/freeware/bin) + AC_PATH_PROG(ZIP, gzip,, /bin:/usr/local/bin:/usr/freeware/bin:/usr/bin) fi zip=$ZIP @@ -148,14 +148,14 @@ if test "$enable_gettext" = yes; then if test -z "$MSGFMT"; then - AC_PATH_PROG(MSGFMT, msgfmt,, /usr/bin:/usr/freeware/bin) + AC_PATH_PROG(MSGFMT, msgfmt,, /usr/bin:/usr/freeware/bin:/usr/local/bin) fi msgfmt=$MSGFMT AC_SUBST(msgfmt) AC_PACKAGE_NEED_UTILITY($1, "$msgfmt", msgfmt, gettext) if test -z "$MSGMERGE"; then - AC_PATH_PROG(MSGMERGE, msgmerge,, /usr/bin:/usr/freeware/bin) + AC_PATH_PROG(MSGMERGE, msgmerge,, /usr/bin:/usr/freeware/bin:/usr/local/bin) fi msgmerge=$MSGMERGE AC_SUBST(msgmerge) -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs Sat Dec 25 06:00:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 25 Dec 2004 06:01:03 -0800 (PST) Received: from mail4.centrum.cz (mail4.centrum.cz [213.29.7.230]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBPE0cq0006325 for ; Sat, 25 Dec 2004 06:00:59 -0800 Received: by mail4.centrum.cz id S4039955AbULYOCA (ORCPT ); Sat, 25 Dec 2004 15:02:00 +0100 Date: Sat, 25 Dec 2004 15:02:00 +0100 From: To: X-Mailer: Centrum Mail 1.0 MIME-Version: 1.0 X-Priority: 3 Subject: primary partition problem Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-Id: X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ankor@centrum.cz Precedence: bulk X-list: linux-xfs Content-Length: 610 Lines: 15 Hi, I have 1st primary partition hda116MB, 2nd primary hda2 10GB, nad logical hda5 etc. Hda1 is mounted as /boot. hda2 is free. When I try mkfs.xfs on hda1, there appears error message: agsize (4008b) is too small, need at least 4096 blocks. I thought when I enlarge hda1, then it must be OK, but is not. When I join hda1 and hda2 together (to hda1 with 10GB), there is still the same error message: agsize (4008b) is too small, need at least 4096 blocks. But when I try mkfs.xfs only on hda2 (10GB), that is OK. Can you please explain me what is going on, and how to solve this problem? thnx. Tony. From owner-linux-xfs Mon Dec 27 05:39:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Dec 2004 05:39:55 -0800 (PST) Received: from MXR-7.estpak.ee (mail.hot.ee [194.126.101.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBRDdSuJ028347 for ; Mon, 27 Dec 2004 05:39:49 -0800 Received: by portal.hot.ee (Postfix, from userid 65534) id 2656818761; Mon, 27 Dec 2004 15:40:57 +0200 (EET) To: linux-xfs@oss.sgi.com From: "Vadim" X-Mailer: Hot.ee webmail (http://portal.hot.ee) Content-Transfer-Encoding: 8bit Subject: XFS specification. Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <20041227134057.2656818761@portal.hot.ee> Date: Mon, 27 Dec 2004 15:40:57 +0200 (EET) X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee X-Virus-Status: Clean X-archive-position: 4665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vadimv@hot.ee Precedence: bulk X-list: linux-xfs Content-Length: 491 Lines: 11 Where could I find detailed XFS specification(documentation)? I got such a problem: I have to write an add-on for "sparse files support system" in XFS: if to write file that has a big area with 0, so it could interpritate it like a "hole", and don't write it onto disk. But I need detailed specification, I digged over whole internet, didnt find anything valuable. Thank you! Vadim Vohmjanin ----------------------------------------- ITV - Sinu lemmiksaated internetis! http://www.itv.ee From owner-linux-xfs Mon Dec 27 07:49:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Dec 2004 07:49:39 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [83.137.98.96]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBRFnDjJ001739 for ; Mon, 27 Dec 2004 07:49:33 -0800 Received: from localhost (localhost [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id C6141102A02 for ; Mon, 27 Dec 2004 16:50:41 +0100 (CET) Received: from nx-01.home.sapienti-sat.org (pD95D19EC.dip.t-dialin.net [217.93.25.236]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 8D8FD102756 for ; Mon, 27 Dec 2004 16:50:41 +0100 (CET) Received: from localhost (localhost.home.sapienti-sat.org [127.0.0.1]) by nx-01.home.sapienti-sat.org (Postfix) with ESMTP id EAD681B046 for ; Mon, 27 Dec 2004 16:50:39 +0100 (CET) Received: from nx-01.home.sapienti-sat.org ([127.0.0.1]) by localhost (nx-01 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18122-05-2 for ; Mon, 27 Dec 2004 16:50:38 +0100 (CET) Received: by nx-01.home.sapienti-sat.org (Postfix, from userid 9) id 8F97B1B02B; Mon, 27 Dec 2004 16:50:38 +0100 (CET) From: "Juri Haberland" Reply-To: "Juri Haberland" X-Newsgroups: local.sgi.linux.xfs Subject: Re: primary partition problem Date: Mon, 27 Dec 2004 15:50:38 +0000 (UTC) Organization: Newsgate at sapienti-sat.org, Berlin, Germany Distribution: local Message-ID: References: X-Complaints-To: usenet@nx-01.home.sapienti-sat.org Cancel-Lock: sha1:5c3RwRYNS0Z/uNOGlSwf0JN27PA= User-Agent: tin/1.7.6-20040906 ("Baleshare") (UNIX) (Linux/2.4.27-pre3 (i686)) To: X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sapienti-sat.org X-Virus-Status: Clean X-archive-position: 4666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: list-sgi.linux.xfs@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 19 ankor@centrum.cz wrote: > Hi, > I have 1st primary partition hda116MB, 2nd primary hda2 10GB, nad logical hda5 > etc. Hda1 is mounted as /boot. hda2 is free. When I try mkfs.xfs on hda1, > there appears error message: agsize (4008b) is too small, need at least 4096 > blocks. > I thought when I enlarge hda1, then it must be OK, but is not. When I join > hda1 and hda2 together (to hda1 with 10GB), there is still the same error > message: agsize (4008b) is too small, need at least 4096 blocks. But when I > try mkfs.xfs only on hda2 (10GB), that is OK. Can you please explain me what > is going on, and how to solve this problem? Did you reboot after merging the two partitions? Cheers, Juri -- Juri Haberland From owner-linux-xfs Tue Dec 28 06:49:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Dec 2004 06:49:18 -0800 (PST) Received: from mx1.twosigma.com (mx1.twosigma.com [166.84.149.248]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBSEmoJF003006 for ; Tue, 28 Dec 2004 06:49:11 -0800 Received: by mx1.twosigma.com (Postfix, from userid 108) id C7BB54FC95; Tue, 28 Dec 2004 14:50:19 +0000 (UTC) Received: from mxgbl2.twosigma.com (mxgbl2.twosigma.com [192.168.111.34]) by mx1.twosigma.com (Postfix) with ESMTP id 6CD884FC93 for ; Tue, 28 Dec 2004 14:50:19 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4ECEC.8CF4FEEE" Subject: patch for bug #309 ambiguous vns in xfs_iget.c Date: Tue, 28 Dec 2004 09:50:18 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: patch for bug #309 ambiguous vns in xfs_iget.c Thread-Index: AcTs7IyYe6WWadnfRueMf5thiMkD1Q== From: "Stephen Degler" To: X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Stephen.Degler@twosigma.com Precedence: bulk X-list: linux-xfs Content-Length: 4569 Lines: 138 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4ECEC.8CF4FEEE Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4ECEC.8CF4FEEE" ------_=_NextPart_002_01C4ECEC.8CF4FEEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a patch we have used locally to work around bug #309. We get this because of simultaneous r/w via NFS and local access. I'm not on the list so please cc any replies to me. =20 skd =20 =20 ------_=_NextPart_002_01C4ECEC.8CF4FEEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is a patch we have used locally to work around bug #309.  We get this because of simultaneous r/w via NFS and local acces= s.  I’m not on the list so please cc any replies to me.

 

skd

 

 

------_=_NextPart_002_01C4ECEC.8CF4FEEE-- ------_=_NextPart_001_01C4ECEC.8CF4FEEE Content-Type: application/octet-stream; name="xfs_iget.c.patch" Content-Transfer-Encoding: base64 Content-Description: xfs_iget.c.patch Content-Disposition: attachment; filename="xfs_iget.c.patch" LS0tIGxpbnV4L2ZzL3hmcy94ZnNfaWdldC5jLm9yaWcJMTggTm92IDIwMDMg MTU6Mzc6MTUgLTAwMDAKKysrIGxpbnV4L2ZzL3hmcy94ZnNfaWdldC5jCTI4 IEp1bCAyMDA0IDE4OjM1OjMzIC0wMDAwCkBAIC0xODQsMTAgKzE4NCwxMSBA QAogCXhmc19jaGFzaF90CSpjaDsKIAl4ZnNfY2hhc2hsaXN0X3QJKmNobCwg KmNobG5ldzsKIAlTUExERUNMKHMpOworCWludAkJeHNfaWdfbG9vcDsKIAot CisJeHNfaWdfbG9vcCA9IDA7CiAJaWggPSBYRlNfSUhBU0gobXAsIGlubyk7 Ci0KKwkKIGFnYWluOgogCXJlYWRfbG9jaygmaWgtPmloX2xvY2spOwogCkBA IC0yMjUsNiArMjI2LDcgQEAKIAogCQkJfSBlbHNlIGlmICh2cCAhPSBpbm9k ZV92cCkgewogCQkJCXN0cnVjdCBpbm9kZSAqaW5vZGUgPSBMSU5WRlNfR0VU X0lQKGlub2RlX3ZwKTsKKwkJCQlzdHJ1Y3QgaW5vZGUgKm5pbm9kZSA9IExJ TlZGU19HRVRfSVAodnApOwogCiAJCQkJLyogVGhlIGlub2RlIGlzIGJlaW5n IHRvcm4gZG93biwgcGF1c2UgYW5kCiAJCQkJICogdHJ5IGFnYWluLgpAQCAt MjM2LDYgKzIzOCwyNSBAQAogCiAJCQkJCWdvdG8gYWdhaW47CiAJCQkJfQor CQkJCXByaW50aygieGZzX2lnZXRfY29yZTogYW1iaWd1b3VzIHZuczogdnAv MHglcCwgaW52cC8weCVwICIsCisJCQkJCQlpbm9kZV92cCwgdnApOworCQkJ CXByaW50aygibmlub2RlIGZsPSV4IHN0PSVseCAiLCBuaW5vZGUtPmlfZmxh Z3MsCisJCQkJCW5pbm9kZS0+aV9zdGF0ZSk7CisJCQkJcHJpbnRrKCJpbm9k ZSBmbD0leCBzdD0lbHhcbiIsIGlub2RlLT5pX2ZsYWdzLAorCQkJCQlpbm9k ZS0+aV9zdGF0ZSk7CisJCQkJcmVhZF91bmxvY2soJmloLT5paF9sb2NrKTsK KwkJCQlkZWxheSgxKTsKKwkJCQlYRlNfU1RBVFNfSU5DKHhzX2lnX2ZyZWN5 Y2xlKTsKKwkJCQlpZiAoICsreHNfaWdfbG9vcCA9PSAxMDAgKSB7CisJCQkJ ICBjbW5fZXJyKENFX1BBTklDLAorCQkJCQkgICJ4ZnNfaWdldF9jb3JlOiBh bWJpZ3VvdXMgdm5zOiB2cC8weCVwLCBpbnZwLzB4JXAiLAorCQkJCQkgIGlu b2RlX3ZwLCB2cCk7CisJCQkJfQorCQkJCWVsc2UKKwkJCQkgIGdvdG8gYWdh aW47CisjaWZkZWYgbm90ZGVmCisKKwogLyogQ2hhbmNlcyBhcmUgdGhlIG90 aGVyIHZub2RlICh0aGUgb25lIGluIHRoZSBpbm9kZSkgaXMgYmVpbmcgdG9y bgogICogZG93biByaWdodCBub3csIGFuZCB3ZSBsYW5kZWQgb24gdG9wIG9m IGl0LiBRdWVzdGlvbiBpcywgd2hhdCBkbwogICogd2UgZG8/IFVuaG9vayB0 aGUgb2xkIGlub2RlIGFuZCBob29rIHVwIHRoZSBuZXcgb25lPwo= ------_=_NextPart_001_01C4ECEC.8CF4FEEE-- From owner-linux-xfs Tue Dec 28 07:44:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Dec 2004 07:44:14 -0800 (PST) Received: from MXR-3.estpak.ee (ld1.estpak.ee [194.126.101.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBSFhlRJ006171 for ; Tue, 28 Dec 2004 07:44:08 -0800 Received: by portal.hot.ee (Postfix, from userid 65534) id 04AA618776; Tue, 28 Dec 2004 17:45:15 +0200 (EET) To: linux-xfs@oss.sgi.com From: "Vadim" X-Mailer: Hot.ee webmail (http://portal.hot.ee) Content-Transfer-Encoding: 8bit Subject: XFS and "hole". Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <20041228154515.04AA618776@portal.hot.ee> Date: Tue, 28 Dec 2004 17:45:15 +0200 (EET) X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee X-Virus-Status: Clean X-archive-position: 4668 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vadimv@hot.ee Precedence: bulk X-list: linux-xfs Content-Length: 915 Lines: 9 XFS supports "holes". But we created file 100mb with 0 only in it, and it's actual size was 100mb, for zeros this support doesn't work. We created other file wrote some bytes at the beggining then did seek ~1GB and wrote to the end couple more bytes. XFS was showing it's size of 1GB, but actual size of it on the disc was only few bytes, that's called "HOLE" as I understand. But it doesn't work for 0s, if you write a big ammount of zeros. What we have to do, to write an add-on that would work for zeros, but problemm is we can't find any good enough specification. We could dig over whole source that was being written several years, and VERY badly documentated, but we are limited in time... If anybody could help with specification or give an advice, we would really apretiate it! Thank you. Vadim Vohmjanin. ----------------------------------------- ITV - Sinu lemmiksaated internetis! http://www.itv.ee From owner-linux-xfs Wed Dec 29 02:41:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Dec 2004 02:41:13 -0800 (PST) Received: from out.smtp.cz (peter.smtp.cz [81.95.97.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBTAeidu006476 for ; Wed, 29 Dec 2004 02:41:05 -0800 Received: (qmail 29346 invoked from network); 29 Dec 2004 10:44:18 -0000 Received: from unknown (HELO 192.168.1.2) (ondrej@sury.org@84.42.133.245) by peter.smtp.cz with RC4-MD5 encrypted SMTP; 29 Dec 2004 10:44:18 -0000 Subject: XFS_WANT_CORRUPTED_GOTO From: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= To: linux-xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 Date: Wed, 29 Dec 2004 11:42:11 +0100 Message-Id: <1104316931.7994.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ondrej@sury.org Precedence: bulk X-list: linux-xfs Content-Length: 3571 Lines: 41 Hello, we have encountered filesystem shutdown due: Dec 29 11:09:11 localhost kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1610 of file xfs_alloc.c. Caller 0xc01d4354 Dec 29 11:09:11 localhost kernel: f64a7cb0 c01d3261 c03ec04a 00000001 00000000 c03ec03e 0000064a c01d4354 Dec 29 11:09:11 localhost kernel: 00000000 00000000 00000000 002379b1 00000008 00000001 002378ec 0000000f Dec 29 11:09:11 localhost kernel: 00000001 00000000 00000000 f6e3b5b4 00000000 e90ba528 c01d4354 f6e3b5b4 Dec 29 11:09:11 localhost kernel: Call Trace: [xfs_free_ag_extent+1105/1904] [xfs_free_extent+196/240] [xfs_free_extent+196/240] [xfs_trans_get_efd+56/80] [xfs_bmap_finish+305/448] Dec 29 11:09:11 localhost kernel: [xfs_itruncate_finish+527/1072] [xfs_inactive+1280/1376] [vn_rele+175/192] [linvfs_clear_inode+24/48] [clear_inode+176/192] [iput+199/688] Dec 29 11:09:11 localhost kernel: [vfs_unlink+279/480] [nfsd_unlink+283/576] [nfsd3_proc_remove+126/272] [nfs3svc_decode_diropargs+127/240] [nfsd_dispatch+201/485] [nfsd_dispatch+0/485] Dec 29 11:09:11 localhost kernel: [svc_process+887/1396] [nfsd+498/832] [arch_kernel_thread+46/64] [nfsd+0/832] Dec 29 11:09:11 localhost kernel: xfs_force_shutdown(device-mapper(254,3),0x8) called from line 4073 of file xfs_bmap.c. Return address = 0xc023aaeb Dec 29 11:09:11 localhost kernel: Filesystem "device-mapper(254,3)": Corruption of in-memory data detected. Shutting down filesystem: device-mapper(254,3) Dec 29 11:09:11 localhost kernel: Please umount the filesystem, and rectify the problem(s) [...reboot...] Dec 29 11:24:38 localhost kernel: Linux version 2.4.28-smtp-2 (root@master) (gcc version 3.3.4 (Debian 1:3.3.4-9ubuntu5)) #9 SMP Tue Dec 14 14:37:00 CET 2004 [...] Dec 29 11:24:38 localhost kernel: XFS mounting filesystem device-mapper(254,3) Dec 29 11:24:38 localhost kernel: Starting XFS recovery on filesystem: device-mapper(254,3) (dev: device-mapper(254,3)) Dec 29 11:24:38 localhost kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1610 of file xfs_alloc.c. Caller 0xc01d4354 Dec 29 11:24:38 localhost kernel: f7509c10 c01d3261 c03ec04a 00000001 00000000 c03ec03e 0000064a c01d4354 Dec 29 11:24:38 localhost kernel: 00000000 00000000 00000000 002379b1 00000008 00000001 002378ec 0000000f Dec 29 11:24:38 localhost kernel: 00000001 00000000 00000000 f69a7c50 f69a5e98 f6fbab8c c01d4354 f69a7c50 Dec 29 11:24:38 localhost kernel: Call Trace: [xfs_free_ag_extent+1105/1904] [xfs_free_extent+196/240] [xfs_free_extent+196/240] [xfs_trans_get_efd+56/80] [xlog_recover_process_efi+406/528] Dec 29 11:24:38 localhost kernel: [xlog_recover_process_efis+118/144] [xlog_recover_finish+32/196] [xfs_iunlock+62/128] [xfs_log_mount_finish+44/48] [xfs_mountfs+2083/3792] [xfs_xlatesb+68/480] Dec 29 11:24:38 localhost kernel: [xfs_mount+670/1200] [vfs_mount+67/80] [linvfs_read_super+142/456] [alloc_super+26/432] [get_sb_bdev+411/640] [alloc_vfsmnt+135/192] Dec 29 11:24:38 localhost kernel: [do_kern_mount+285/304] [do_add_mount+119/352] [do_mount+324/400] [copy_mount_options+101/192] [sys_mount+190/288] [system_call+51/56] Dec 29 11:24:38 localhost kernel: Ending XFS recovery on filesystem: device-mapper(254,3) (dev: device-mapper(254,3)) This server is NFS mail backend (lots of small files, heavy IO, heavy load etc.) I am scheduling xfs_check / xfs_recover to some after-midnight hours, but meanwhile I would like to know if there is something I should (shouldn't) do to repair and prevent this error. O. -- Ondřej Surý From owner-linux-xfs Wed Dec 29 09:04:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Dec 2004 09:04:13 -0800 (PST) Received: from slurp.thebarn.com (cattelan-host201.dsl.visi.com [208.42.117.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBTH3lPK028145 for ; Wed, 29 Dec 2004 09:04:07 -0800 Received: from [10.0.0.12] (ease.thebarn.com [10.0.0.12]) (authenticated bits=0) by slurp.thebarn.com (8.13.1/8.13.1) with ESMTP id iBTH3m4O025077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Dec 2004 11:03:51 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <41D2E3C0.5070704@thebarn.com> Date: Wed, 29 Dec 2004 11:05:04 -0600 From: Russell Cattelan User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vadim CC: linux-xfs@oss.sgi.com Subject: Re: XFS and "hole". References: <20041228154515.04AA618776@portal.hot.ee> In-Reply-To: <20041228154515.04AA618776@portal.hot.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/633/Thu Dec 16 19:56:33 2004 clamav-milter version 0.80j on slurp.thebarn.com X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1405 Lines: 29 Vadim wrote: >XFS supports "holes". But we created file 100mb with 0 only in it, and it's actual size was 100mb, for zeros this support doesn't work. We created other file wrote some bytes at the beggining then did seek ~1GB and wrote to the end couple more bytes. XFS was showing it's size of 1GB, but actual size of it on the disc was only few bytes, that's called "HOLE" as I understand. But it doesn't work for 0s, if you write a big ammount of zeros. What we have to do, to write an add-on that would work for zeros, but problemm is we can't find any good enough specification. We could dig over whole source that was being written several years, and VERY badly documentated, but we are limited in time... If anybody could help with specification or give an advice, we would really apretiate it! > >Thank you. >Vadim Vohmjanin. > >----------------------------------------- >ITV - Sinu lemmiksaated internetis! >http://www.itv.ee > > > The filesystem does do any sort of: is this block all 0's so I'll skip writting it and create a hole. That would be a large amount of overhead as the content of every block would have to be scanned before written to disk to make that determination. Holes are created by seeking around a file a writing a few bytes wherever you happen to be. Basically it is up to the app do determine it a set of data is just 0's and skip the write. -Russell Cattelan From owner-linux-xfs Thu Dec 30 03:33:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Dec 2004 03:33:47 -0800 (PST) Received: from mercure.inha.fr (mercure.inha.fr [194.214.199.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBUBXEeY016019 for ; Thu, 30 Dec 2004 03:33:35 -0800 Received: from localhost (localhost [127.0.0.1]) by mercure.inha.fr (Postfix) with ESMTP id E66D33C61D7 for ; Thu, 30 Dec 2004 12:36:38 +0100 (CET) Received: from mercure.inha.fr ([127.0.0.1]) by localhost (mercure [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01705-01 for ; Thu, 30 Dec 2004 12:36:38 +0100 (CET) Received: from [192.168.10.103] (unknown [192.168.10.103]) by mercure.inha.fr (Postfix) with ESMTP id 596023C61D2 for ; Thu, 30 Dec 2004 12:36:38 +0100 (CET) Message-ID: <41D3E845.9060405@inha.fr> Date: Thu, 30 Dec 2004 12:36:37 +0100 From: Gildas LE NADAN Organization: Institut National d'Histoire de l'Art (INHA) User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs and lvm2 snapshots bad interaction (kernel 2.6.10) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at inha.fr X-Virus-Status: Clean X-archive-position: 4672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gildas.le-nadan@inha.fr Precedence: bulk X-list: linux-xfs Content-Length: 12996 Lines: 284 Hi all, Sorry if this is considered rude, as this problem was submitted to Linux Kernel Mailing List in the first place, but as it seems more xfs/lvm2 related from other user reports, I guess it might be appropriate to repost here. I experience hangs on samba processes on a filer using xfs over lvm2 as data partitions, when there is active snapshots of the xfs partitions. I have a clone of the production server (same software, same hardware) where the situation can be reproduced perfectly. Tests showed that the result was the same, whether the snapshots were mounted or not : smbd processes are locked and unkillable while the machine is normaly working otherwise, except software reboot is impossible and hardware reset is needed. I noticed Brad Fitzpatrick's case in kernel 2.6.10 changelog (http://lkml.org/lkml/2004/11/14/98) and thought it might have been corrected in kernel 2.6.10 and tested it without success. Configuration is the following : - supermicro m/b with dual Xeon 2,8Ghz (SMT is active) - 1 GB ram, - adaptec u320 raid controler - kernel 2.6.10 - debian sarge - samba 3 - LVM2 - XFS with quota turned on All software are from debian sarge packages, except the kernel. I'm not really able to determine if the problem is more xfs, device mapper or samba related, and was not able to do extensive testings yet. Kernel was rebuild with debugging options on the test machine, traces are below. GLN -- After the hang : # ps afx | grep smbd 2279 ? Ss 0:00 /usr/sbin/smbd -D 2288 ? S 0:00 \_ /usr/sbin/smbd -D 2447 ? D 0:01 \_ /usr/sbin/smbd -D 2487 pts/0 S+ 0:00 | \_ grep smbd # killall -9 smbd # ps afx | grep smbd 2554 pts/0 S+ 0:00 | \_ grep smbd 2447 ? D 0:01 /usr/sbin/smbd -D I did a "echo t > /proc/sysrq-trigger" and tried to clean the resulting logs a bit before sending. Hope this gives enough info, otherwise I kept the whole log so I can send whatever part is needed SysRq : Show State sibling task PC pid father child younger older ... xfslogd/0 S 00000004 0 218 11 220 216 (L-TLB) f7eecf44 00000046 f7eecf34 00000004 00000002 f60ef53c c0427ba0 f60ef5a8 00000282 c01017cc 00000000 f7f28974 f7f2896c 00000000 c170f020 00000000 00000c41 ff6027e0 00000005 00000286 f7eb9530 f7eb96b0 f7eecf94 00000002 Call Trace: [__up+28/32] __up+0x1c/0x20 [worker_thread+565/608] worker_thread+0x235/0x260 [pagebuf_iodone_work+0/80] pagebuf_iodone_work+0x0/0x50 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfslogd/1 S 00000004 0 219 10 221 217 (L-TLB) f7c82f44 00000046 f7c82f30 00000004 00000001 ffffffff f7eb9020 35a49146 00000000 f7eb9020 c170f020 f7eb9020 00000000 c1717a00 c1717020 00000001 000008ae 0395f3e5 00000000 c171705c f7c7e020 f7c7e1a0 00000001 f7f289dc Call Trace: [worker_thread+565/608] worker_thread+0x235/0x260 [schedule+1132/3360] schedule+0x46c/0xd20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfslogd/2 S 00000004 0 220 11 222 218 (L-TLB) f7eedf44 00000046 f7eedf34 00000004 00000004 00000000 f7c1f020 c01f4a99 f714b13c 00000000 00000000 f7f28a74 f7f28a6c 00000000 c171f020 00000002 00000d47 6261fbfd 00000074 00000286 f7eb9020 f7eb91a0 f7eedf94 00000008 Call Trace: [xfs_buf_iodone_callbacks+361/368] xfs_buf_iodone_callbacks+0x169/0x170 [worker_thread+565/608] worker_thread+0x235/0x260 [pagebuf_iodone_work+0/80] pagebuf_iodone_work+0x0/0x50 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfslogd/3 S 00000004 0 221 10 223 219 (L-TLB) f7c84f44 00000046 f7c84f34 00000004 00000003 ffffffff f7c27a40 35a47b19 00000000 03969a3b 03969a3b 00000000 f7c84f28 c0116200 c1727020 00000003 00000ef7 0396cbec 00000000 00000286 f7c83a40 f7c83bc0 f7c84f94 00000004 Call Trace: [activate_task+144/176] activate_task+0x90/0xb0 [worker_thread+565/608] worker_thread+0x235/0x260 [schedule+1132/3360] schedule+0x46c/0xd20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfsdatad/0 S 00000004 0 222 11 224 220 (L-TLB) f7f06f44 00000046 f7f06f30 00000004 00000002 ffffffff f7c83530 35a48050 00000000 f7c83530 c1717020 f7c83530 00000000 c170fa00 c170f020 00000000 00000897 0397ce5a 00000000 c170f05c f7f05a40 f7f05bc0 00000002 f7f28550 Call Trace: [worker_thread+565/608] worker_thread+0x235/0x260 [schedule+1132/3360] schedule+0x46c/0xd20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfsdatad/1 S 00000004 0 223 10 225 221 (L-TLB) f7c85f44 00000046 f7c85f30 00000004 00000001 ffffffff f7f05530 35a47efe 00000000 f7f05530 c170f020 f7f05530 00000000 c1717a00 c1717020 00000001 000008f9 0398532d 00000000 c171705c f7c83530 f7c836b0 00000001 f7f285d0 Call Trace: [worker_thread+565/608] worker_thread+0x235/0x260 [schedule+1132/3360] schedule+0x46c/0xd20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfsdatad/2 S 00000004 0 224 11 903 222 (L-TLB) f7f07f44 00000046 f7f07f34 00000004 00000004 ffffffff f7c1f020 35a493ed 00000000 03985b99 03985b99 00000000 f7f07f28 c0116200 c171f020 00000002 00000d7c 03988e25 00000000 00000286 f7f05530 f7f056b0 f7f07f94 00000008 Call Trace: [activate_task+144/176] activate_task+0x90/0xb0 [worker_thread+565/608] worker_thread+0x235/0x260 [schedule+1132/3360] schedule+0x46c/0xd20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfsdatad/3 S 00000004 0 225 10 902 223 (L-TLB) f7c87f44 00000046 f7c87f34 00000004 00000003 ffffffff f7c27a40 35a49032 00000000 0398e44a 0398e44a 00000000 f7c87f28 c0116200 c1727020 00000003 000010b0 0399175f 00000000 00000286 f7c83020 f7c831a0 f7c87f94 00000004 Call Trace: [activate_task+144/176] activate_task+0x90/0xb0 [worker_thread+565/608] worker_thread+0x235/0x260 [schedule+1132/3360] schedule+0x46c/0xd20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [default_wake_function+0/32] default_wake_function+0x0/0x20 [worker_thread+0/608] worker_thread+0x0/0x260 [kthread+186/192] kthread+0xba/0xc0 [kthread+0/192] kthread+0x0/0xc0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfsbufd S 00000004 0 226 1 815 213 (L-TLB) f7f08f78 00000046 f7f08f68 00000004 00000001 00000000 f7c1f530 c02c1edb f7f70e64 00000000 f7eaa944 c0264f5f 00000004 c04f99e8 c1717020 00000001 00000134 6d117e89 0000009e c0125879 f7f05020 f7f051a0 00000000 00000001 Call Trace: [elv_next_request+27/256] elv_next_request+0x1b/0x100 [kobject_put+31/48] kobject_put+0x1f/0x30 [__mod_timer+249/320] __mod_timer+0xf9/0x140 [schedule_timeout+117/208] schedule_timeout+0x75/0xd0 [process_timeout+0/16] process_timeout+0x0/0x10 [dm_unplug_all+39/64] dm_unplug_all+0x27/0x40 [blk_backing_dev_unplug+0/32] blk_backing_dev_unplug+0x0/0x20 [pagebuf_daemon+118/512] pagebuf_daemon+0x76/0x200 [pagebuf_daemon+0/512] pagebuf_daemon+0x0/0x200 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 ... xfssyncd S 00000004 0 1361 1 1362 1360 (L-TLB) f756ef74 00000046 f756ef64 00000004 00000002 f5735568 c0427ba0 f5735568 f756ef2c 0000022e 00000031 f714be3c f5735568 00000000 c170f020 00000000 000034a1 58c63e72 00000098 c0125879 f6fb6a40 f6fb6bc0 00000000 00000002 Call Trace: [__mod_timer+249/320] __mod_timer+0xf9/0x140 [schedule_timeout+117/208] schedule_timeout+0x75/0xd0 [process_timeout+0/16] process_timeout+0x0/0x10 [xfssyncd+134/480] xfssyncd+0x86/0x1e0 [xfssyncd+0/480] xfssyncd+0x0/0x1e0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 xfssyncd S 00000004 0 1362 1 2233 1361 (L-TLB) f6accf74 00000046 f6accf64 00000004 00000002 f60f4360 c0427ba0 f60efc3c c050ad58 c023a3ee 00000031 f60efc3c f6d6ccd0 00000000 c170f020 00000000 00001568 6080d951 00000098 c0125879 f6a95530 f6a956b0 00000000 00000002 Call Trace: [pagebuf_rele+46/240] pagebuf_rele+0x2e/0xf0 [__mod_timer+249/320] __mod_timer+0xf9/0x140 [schedule_timeout+117/208] schedule_timeout+0x75/0xd0 [process_timeout+0/16] process_timeout+0x0/0x10 [xfssyncd+134/480] xfssyncd+0x86/0x1e0 [xfssyncd+0/480] xfssyncd+0x0/0x1e0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 ... smbd S 00000004 0 2279 1 2288 2285 2277 (NOTLB) f5110ea4 00000082 f5110e90 00000004 00000002 c013ed74 f6770020 c042cd80 000000d0 f6770020 c1717020 f6770020 00000000 c170fa00 c170f020 00000000 0000b4c6 78f5a598 0000006d c170f05c f779a530 f779a6b0 00000002 f5d37028 Call Trace: [__alloc_pages+484/928] __alloc_pages+0x1e4/0x3a0 [schedule_timeout+199/208] schedule_timeout+0xc7/0xd0 [tcp_poll+52/400] tcp_poll+0x34/0x190 [handle_mm_fault+344/384] handle_mm_fault+0x158/0x180 [add_wait_queue+29/80] add_wait_queue+0x1d/0x50 [pipe_poll+52/128] pipe_poll+0x34/0x80 [do_select+401/736] do_select+0x191/0x2e0 [__pollwait+0/208] __pollwait+0x0/0xd0 [sys_select+731/1456] sys_select+0x2db/0x5b0 [syscall_call+7/11] syscall_call+0x7/0xb ... smbd D 00000004 0 2447 2279 2288 (NOTLB) f6736bbc 00000082 f6736bac 00000004 00000002 00000000 c0427ba0 00000000 f6770020 c0118350 00000000 00000000 c17ff080 00000007 c170f020 00000000 00008e96 5602776d 00000071 00000000 f6770020 f67701a0 c023a197 00000002 Call Trace: [default_wake_function+0/32] default_wake_function+0x0/0x20 [pagebuf_associate_memory+103/400] pagebuf_associate_memory+0x67/0x190 [schedule_timeout+199/208] schedule_timeout+0xc7/0xd0 [xlog_sync+630/1216] xlog_sync+0x276/0x4c0 [xlog_state_release_iclog+91/272] xlog_state_release_iclog+0x5b/0x110 [add_wait_queue_exclusive+26/80] add_wait_queue_exclusive+0x1a/0x50 [xlog_state_sync+602/656] xlog_state_sync+0x25a/0x290 [default_wake_function+0/32] default_wake_function+0x0/0x20 [xlog_assign_tail_lsn+73/128] xlog_assign_tail_lsn+0x49/0x80 [default_wake_function+0/32] default_wake_function+0x0/0x20 [xfs_log_force+132/144] xfs_log_force+0x84/0x90 [xfs_trans_commit+631/1008] xfs_trans_commit+0x277/0x3f0 [xfs_trans_dup+191/208] xfs_trans_dup+0xbf/0xd0 [xfs_itruncate_finish+593/1072] xfs_itruncate_finish+0x251/0x430 [xfs_setattr+3578/4128] xfs_setattr+0xdfa/0x1020 [linvfs_setattr+258/384] linvfs_setattr+0x102/0x180 [kmem_cache_alloc+114/192] kmem_cache_alloc+0x72/0xc0 [linvfs_setattr+0/384] linvfs_setattr+0x0/0x180 [notify_change+334/400] notify_change+0x14e/0x190 [do_truncate+147/208] do_truncate+0x93/0xd0 [fget+73/96] fget+0x49/0x60 [sys_ftruncate64+204/304] sys_ftruncate64+0xcc/0x130 [sys_open+108/144] sys_open+0x6c/0x90 [syscall_call+7/11] syscall_call+0x7/0xb From owner-linux-xfs Thu Dec 30 03:32:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Dec 2004 03:32:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBUBWrNF015933 for ; Thu, 30 Dec 2004 03:32:53 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBUBWrvN015931 for linux-xfs@oss.sgi.com; Thu, 30 Dec 2004 03:32:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBUBWpaJ015916 for ; Thu, 30 Dec 2004 03:32:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBUBA1ij014841; Thu, 30 Dec 2004 03:10:01 -0800 Date: Thu, 30 Dec 2004 03:10:01 -0800 Message-Id: <200412301110.iBUBA1ij014841@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 393] New: Main FTP server missing files X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/638/Tue Dec 21 14:41:34 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4671 X-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: 776 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=393 Summary: Main FTP server missing files Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: absinthe@gentoo.org Just thought you folks might need to know that attr, xfsprogs, xfsdump, dmapi source files are missing from your main FTP site. Your mirror site, however, is fine. Good: ftp://xfs.org/mirror/SGI/cmd_tars/ Bad: ftp://oss.sgi.com/projects/xfs/cmd_tars/ ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Dec 30 21:11:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Dec 2004 21:11:58 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBV5BWDW027390 for ; Thu, 30 Dec 2004 21:11:52 -0800 Received: from [10.0.0.2] (sandeen.net [209.173.210.139]) by sandeen.net (Postfix) with ESMTP id DD7032C1DA9; Thu, 30 Dec 2004 23:20:01 -0600 (CST) Message-ID: <41D4E180.6010803@sgi.com> Date: Thu, 30 Dec 2004 23:20:00 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan Cc: Vadim , linux-xfs@oss.sgi.com Subject: Re: XFS and "hole". References: <20041228154515.04AA618776@portal.hot.ee> <41D2E3C0.5070704@thebarn.com> In-Reply-To: <41D2E3C0.5070704@thebarn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4673 X-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: 1903 Lines: 52 if you still really want to do this (note that this sort of data-scanning would be an odd feature, and is not a "fix" for hole support in xfs, which is not broken...) then you can look at http://oss.sgi.com/~sandeen/design/ for more info on how xfs works. these docs should be linked off the xfs pages, but the .htaccess is foo - russell can you fix this please? -Eric Russell Cattelan wrote: > Vadim wrote: > >> XFS supports "holes". But we created file 100mb with 0 only in it, >> and it's actual size was 100mb, for zeros this support doesn't work. >> We created other file wrote some bytes at the beggining then did seek >> ~1GB and wrote to the end couple more bytes. XFS was showing it's size >> of 1GB, but actual size of it on the disc was only few bytes, that's >> called "HOLE" as I understand. But it doesn't work for 0s, if you >> write a big ammount of zeros. What we have to do, to write an add-on >> that would work for zeros, but problemm is we can't find any good >> enough specification. We could dig over whole source that was being >> written several years, and VERY badly documentated, but we are limited >> in time... If anybody could help with specification or give an advice, >> we would really apretiate it! >> >> Thank you. >> Vadim Vohmjanin. >> >> ----------------------------------------- >> ITV - Sinu lemmiksaated internetis! >> http://www.itv.ee >> >> >> > The filesystem does do any sort of: is this block all 0's so I'll skip > writting it and create a hole. > That would be a large amount of overhead as the content of every block > would have to be scanned > before written to disk to make that determination. > > Holes are created by seeking around a file a writing a few bytes > wherever you happen to > be. > > Basically it is up to the app do determine it a set of data is just 0's > and skip the write. > > > -Russell Cattelan > From owner-linux-xfs Thu Dec 30 21:27:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Dec 2004 21:27:46 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBV5Rgnl028903 for ; Thu, 30 Dec 2004 21:27:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBV5RgdN028902 for linux-xfs@oss.sgi.com; Thu, 30 Dec 2004 21:27:42 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBV5ReWs028887 for ; Thu, 30 Dec 2004 21:27:40 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBV5IhIZ028606; Thu, 30 Dec 2004 21:18:43 -0800 Date: Thu, 30 Dec 2004 21:18:43 -0800 Message-Id: <200412310518.iBV5IhIZ028606@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 393] Main FTP server missing files X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4674 X-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: 1905 Lines: 54 http://oss.sgi.com/bugzilla/show_bug.cgi?id=393 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From sandeen@sgi.com 2004-30-12 21:18 PDT ------- Works for me.... Liberator:~ sandeen$ ftp oss.sgi.com Connected to oss.sgi.com. 220---------- Welcome to Pure-FTPd ---------- 220-You are user number 8 of 50 allowed. 220-Local time is now 21:16. Server port: 21. 220 You will be disconnected after 15 minutes of inactivity. Name (oss.sgi.com:sandeen): anonymous 331 Any password will work Password: 230 Any password will work Remote system type is UNIX. Using binary mode to transfer files. ftp> cd projects/xfs/cmd_tars 250 OK. Current directory is /projects/xfs/cmd_tars ftp> ls 500 Unknown command 227 Entering Passive Mode (192,48,159,27,214,131) 150 Accepted data connection drwxrwxr-x 2 10098 100 4096 Oct 12 18:18 . drwxrwxr-x 7 10098 0 123 Oct 14 18:33 .. -rw-r--r-- 1 10098 100 144400 Oct 12 18:16 acl-2.2.27.src.tar.gz -rw-r--r-- 1 10098 100 103599 Oct 12 18:16 attr-2.4.19.src.tar.gz -rw-r--r-- 1 10098 100 78021 Oct 12 18:16 dmapi-2.2.1.src.tar.gz -rw-r--r-- 1 10098 100 589851 Oct 12 18:17 xfsdump-2.2.25.src.tar.gz -rw-r--r-- 1 10098 100 850024 Oct 12 18:17 xfsprogs-2.6.25.src.tar.gz 226-Options: -a -l 226 7 matches total ftp> maybe try a different client? If you can nail down a problem with a client that seems to work for other sites, please re-open, maybe there's some odd firewall config or other... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Dec 30 22:27:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Dec 2004 22:27:45 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBV6RgRW031209 for ; Thu, 30 Dec 2004 22:27:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBV6RgDB031208 for linux-xfs@oss.sgi.com; Thu, 30 Dec 2004 22:27:42 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBV6ReUd031192 for ; Thu, 30 Dec 2004 22:27:41 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBV6MD7F031032; Thu, 30 Dec 2004 22:22:13 -0800 Date: Thu, 30 Dec 2004 22:22:13 -0800 Message-Id: <200412310622.iBV6MD7F031032@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 393] Main FTP server missing files X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4675 X-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: 416 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=393 ------- Additional Comments From absinthe@gentoo.org 2004-30-12 22:22 PDT ------- Well, both wget and mozilla were not working as of the time I posted this bug. We had numerous users complaining about this. But it works now. Go figure. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Dec 31 03:15:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Dec 2004 03:15:47 -0800 (PST) Received: from imo-m27.mx.aol.com (imo-m27.mx.aol.com [64.12.137.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBVBFLeq015920 for ; Fri, 31 Dec 2004 03:15:41 -0800 Received: from AndyLiebman@aol.com by imo-m27.mx.aol.com (mail_out_v37_r3.8.) id 4.1a6.2e57b51b (2519) for ; Fri, 31 Dec 2004 06:23:47 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <1a6.2e57b51b.2f0690c2@aol.com> Date: Fri, 31 Dec 2004 06:23:46 EST Subject: Put Journal on RAID To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5117 X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 4676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 1043 Lines: 21 Earlier today, I was reading through a series of posts on another Linux list about where you should put the journal file for a journaling filesystem such as ext3, xfs, reiserfs, etc. Some argued that putting a journal file on a RAID array was a sure way to have it not work in the event of any RAID corruption -- that a journal file should be on a separate device. Does anybody on this list have some reliable information about this? For instance, is it "safe" to put the xfs journal on a RAID-0 array along with the xfs filesystem? What about on a RAID 50 array (Software RAID-0 on top of 2 or more 3ware Hardware RAID-5 arrays?) What is the generally accepted practice for xfs journals in Linux. Are they put on RAIDS along with the filesystem (especially if you are looking for very high read/write speeds, i.e., > 200 MB/sec for writes and > 600 MB/sec for reads). My experience with trying to put the journal on a separate (and much slower) device is that it completely kills the performance of the RAID. Andy Liebman From owner-linux-xfs Fri Dec 31 08:27:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Dec 2004 08:27:48 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBVGRicQ005544 for ; Fri, 31 Dec 2004 08:27:44 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBVGRiPd005543 for linux-xfs@oss.sgi.com; Fri, 31 Dec 2004 08:27:44 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBVGRgY2005527 for ; Fri, 31 Dec 2004 08:27:42 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iBVGHLjt002006; Fri, 31 Dec 2004 08:17:21 -0800 Date: Fri, 31 Dec 2004 08:17:21 -0800 Message-Id: <200412311617.iBVGHLjt002006@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 393] Main FTP server missing files X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4677 X-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: 336 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=393 ------- Additional Comments From cattelan@thebarn.com 2004-31-12 08:17 PDT ------- One of the drives on oss died. I re-syned the files to a different location. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.