From owner-linux-xfs@oss.sgi.com Thu Dec 1 03:24:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Dec 2005 03:24:03 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB1BNrO0029904 for ; Thu, 1 Dec 2005 03:23:59 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.54 #1 (Red Hat Linux)) id 1EhmU9-00013s-Hp; Thu, 01 Dec 2005 11:20:21 +0000 Date: Thu, 1 Dec 2005 11:20:21 +0000 From: Christoph Hellwig To: Nathan Scott Cc: XFS Mailing List , Stephen Smalley Subject: Re: fixing SELINUX-support in XFS-2.6.14 Message-ID: <20051201112021.GB3958@infradead.org> References: <20051130163424.GA4724@m.safari.iki.fi> <20051201082709.C7104341@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051201082709.C7104341@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6653 X-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 On Thu, Dec 01, 2005 at 08:27:09AM +1100, Nathan Scott wrote: > | I had actually suggested that the patch removing the old post hooks from > | the VFS be deferred until after 2.6.14 to avoid breaking the unconverted > | filesystems while still allowing the converted ones to use the new > | support, but it seems my request was misunderstood. We could possibly > | ask to have the removal patch reverted > > Please do that, we are not going to be able to fix this quickly in > XFS, as there is an underlying issue here that makes this alot more > tricky to resolve in XFS. But we are aware of the problem and do > plan to fix it, so if you could cater for XFS/SE-Linux users for a > little while longer, that would be great. No, reverting this is bogus. If you really want to support selinux without real transaction support just implement the new inode initialization method without doing adding the labeling to the transaction. Personally I believe XFS shouldn't claim to support things it doesn't yet, though. From owner-linux-xfs@oss.sgi.com Thu Dec 1 11:26:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Dec 2005 11:26:59 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB1JQpO0014878 for ; Thu, 1 Dec 2005 11:26: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 GAA02016; Fri, 2 Dec 2005 06:23:11 +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 jB1JNLkt7130000; Fri, 2 Dec 2005 06:23:22 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jB1JNJtv7130080; Fri, 2 Dec 2005 06:23:19 +1100 (EST) Date: Fri, 2 Dec 2005 06:23:19 +1100 From: Nathan Scott To: Christoph Hellwig Cc: XFS Mailing List , Stephen Smalley Subject: Re: fixing SELINUX-support in XFS-2.6.14 Message-ID: <20051202062318.A7097967@wobbly.melbourne.sgi.com> References: <20051130163424.GA4724@m.safari.iki.fi> <20051201082709.C7104341@wobbly.melbourne.sgi.com> <20051201112021.GB3958@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: <20051201112021.GB3958@infradead.org>; from hch@infradead.org on Thu, Dec 01, 2005 at 11:20:21AM +0000 X-archive-position: 6654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Dec 01, 2005 at 11:20:21AM +0000, Christoph Hellwig wrote: > On Thu, Dec 01, 2005 at 08:27:09AM +1100, Nathan Scott wrote: > > | I had actually suggested that the patch removing the old post hooks from > > | the VFS be deferred until after 2.6.14 to avoid breaking the unconverted > > | filesystems while still allowing the converted ones to use the new > > | support, but it seems my request was misunderstood. We could possibly > > | ask to have the removal patch reverted > > > > Please do that, we are not going to be able to fix this quickly in > > XFS, as there is an underlying issue here that makes this alot more > > tricky to resolve in XFS. But we are aware of the problem and do > > plan to fix it, so if you could cater for XFS/SE-Linux users for a > > little while longer, that would be great. > > No, reverting this is bogus. If you really want to support selinux without > real transaction support Well, I mainly want to not cause a huge regression for those people who were using it in the stable kernel series. > just implement the new inode initialization method > without doing adding the labeling to the transaction. Hmmm ... if its that simple, then that should have been done for reiserfs and XFS before this change was merged at all, surely? That would've kept the old (albeit not quite correct) behaviour without the regression, and given ample opportunity for the remaining filesystems to get properly fixed up... no? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Dec 2 06:11:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Dec 2005 06:11:28 -0800 (PST) Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB2EBOO0030905 for ; Fri, 2 Dec 2005 06:11:24 -0800 Received: from tycho.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id jB2E6xIP022272; Fri, 2 Dec 2005 14:07:00 GMT Received: from moss-spartans.epoch.ncsc.mil (moss-spartans [144.51.25.121]) by tycho.ncsc.mil (8.12.8/8.12.8) with ESMTP id jB2ECRMA017373; Fri, 2 Dec 2005 09:12:27 -0500 (EST) Subject: Re: fixing SELINUX-support in XFS-2.6.14 From: Stephen Smalley To: Nathan Scott Cc: Christoph Hellwig , XFS Mailing List In-Reply-To: <20051202062318.A7097967@wobbly.melbourne.sgi.com> References: <20051130163424.GA4724@m.safari.iki.fi> <20051201082709.C7104341@wobbly.melbourne.sgi.com> <20051201112021.GB3958@infradead.org> <20051202062318.A7097967@wobbly.melbourne.sgi.com> Content-Type: text/plain Organization: National Security Agency Date: Fri, 02 Dec 2005 09:14:23 -0500 Message-Id: <1133532863.28437.120.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-archive-position: 6657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sds@tycho.nsa.gov Precedence: bulk X-list: linux-xfs Content-Length: 1384 Lines: 29 On Fri, 2005-12-02 at 06:23 +1100, Nathan Scott wrote: > Well, I mainly want to not cause a huge regression for those > people who were using it in the stable kernel series. > Hmmm ... if its that simple, then that should have been done > for reiserfs and XFS before this change was merged at all, > surely? That would've kept the old (albeit not quite correct) > behaviour without the regression, and given ample opportunity > for the remaining filesystems to get properly fixed up... no? I don't know whether that would be simple or not (not having looked closely at the xfs implementation), but these patches were discussed on linux-fsdevel and lived in -mm for a while without such a suggestion being made. Meanwhile, we did update the filesystems we use and test ourselves, and the jfs maintainers took care of their fs. And even my suggestion to hold the patch removing the old post hooks was only to hold it until after 2.6.14 was released and then immediately put it in, so it appears we would still be running into this issue for 2.6.15 since it is already at -rc4 and neither xfs nor reiserfs have been updated yet. I'm open to suggestions, but I'm not getting a consistent message from xfs folks, so it is difficult to know how to proceed. I'm also not clear on what we can hope to get into 2.6.15 at this point. -- Stephen Smalley National Security Agency From owner-linux-xfs@oss.sgi.com Sun Dec 4 06:01:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 06:01:18 -0800 (PST) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB4E15O0016796 for ; Sun, 4 Dec 2005 06:01:09 -0800 Received: from gateway-att.yingternet.com (c-24-126-232-179.hsd1.ca.comcast.net [24.126.232.179]) by ying.yingternet.com (Postfix) with ESMTP id CF7E630009E for ; Sun, 4 Dec 2005 05:59:21 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id E3C73204C0F for ; Sun, 4 Dec 2005 05:57:29 -0800 (PST) Message-ID: <4392F5C5.5000706@yingternet.com> Date: Sun, 04 Dec 2005 21:57:25 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: out of vmalloc space - use vmalloc to increase size when mounting xfs FS X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 708 Lines: 26 Hi there, we are currently running linux kernel 2.6.14.2 with HIGHMEM enabled (the machine has 1GB of RAM) Whenever mounting the xfs filesystem (200GB partition), it shows "allocation failed : out of vmalloc space - use vmalloc to increase size" it is reproduceable by simply rebooting the machine via shutdown -r now We only see this message when the system is mounting xfs filesystem (200GB partition). However, if we turnoff the HIGHMEM option, the message disappeared. I have tried use vmalloc=256m, but system won't let me boot at all, has anyone seen this? is this strictly linux kernel problem or has something to do with xfs impelmentation in the kernel? Please advice, Thanks, -Ying From owner-linux-xfs@oss.sgi.com Sun Dec 4 06:28:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 06:28:55 -0800 (PST) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB4ESoO0020497 for ; Sun, 4 Dec 2005 06:28:50 -0800 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 22EBEC000DB9 for ; Sun, 4 Dec 2005 22:25:13 +0800 (PHT) Received: from musang.free.net.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id C1C13C000B7C for ; Sun, 4 Dec 2005 22:25:09 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id D407D16009D63; Sun, 4 Dec 2005 22:25:06 +0800 (PHT) Date: Sun, 4 Dec 2005 22:25:06 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Filesystem Consistency Issues Message-ID: <20051204142506.GE2605@free.net.ph> Mail-Followup-To: Linux-XFS Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 6666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 2771 Lines: 66 Hi, We use XFS (Linux kernel 2.6.12 on Debian 3.1 Sarge) on fat client point-of-sale terminals. Right now we have four hypermarts with about 40 terminals each, all running the same setup. The POS application regularly writes transaction audit information and maintains a local cache of the product database on the local drive, which for simplicity we've partitioned with a single root filesystem. Recently, we noticed that we have a growing discrepancy between actual disk usage and disk free reports. Most of the systems have 20GB to 40GB hard drives, but actually only use about 800MB all in. Disk usage as reported by # du -csh / stays at around 800MB, but disk usage as reported by # df -h continuously increases until the filesystem reaches 100% utilization. It only takes a couple of months of daily use (power-on in the morning, power-off in the evening) for this to happen. When I investigated one of the machines, mounting the filesystem in read/write mode after having booted from a rescue CD automatically fixed part of it, freeing about 60% of the filesystem. Running xfs_repair further freed up space by moving disconnected inodes to lost+found. I found that these machines were regularly powered off without a proper shutdown, and presumably with dirty data in the buffers. Of course the "if it hurts, don't do it" rule applies here, and we're working to correct this procedure by having store personnel shut down the machines properly. I find XFS's behavior troubling, though. First, that I had to mount the filesystem (the root partition) from a rescue CD for the log replay to "fix" things properly. Isn't it supposed to do this by itself on bootup? And second, that the filesystem's consistency needed xfs_repair to completely repair things. Data loss during incorrect shutdown is understandable and acceptable, but we use a journaling filesystem like XFS in particular so that filesystem consistency is guaranteed, right? The systems are configured so that hdparm disables write caching on the drives, so I've ruled that common mistake out. We don't have ECC RAM, though, since these are POS terminals, not servers. What's the known behavior of XFS as far as not being properly unmounted on a regular basis is concerned? I have a number of projects where this is a "way of life" and where the best thing we can do on the application level is to issue an fsync() after critical operations, and I want to know if I should continue to stick by my stand to use XFS, or if I should begin playing around with other filesystems. Thanks in advance for any insights. Cheers! --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs@oss.sgi.com Sun Dec 4 16:35:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 16:35:23 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB50ZDO0009606 for ; Sun, 4 Dec 2005 16:35: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 LAA21366; Mon, 5 Dec 2005 11:31:39 +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 jB50Vmkt7207897; Mon, 5 Dec 2005 11:31:49 +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 jB50UGqA001236; Mon, 5 Dec 2005 11:30:16 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id jB50UEGV001234; Mon, 5 Dec 2005 11:30:14 +1100 Date: Mon, 5 Dec 2005 11:30:14 +1100 From: Nathan Scott To: Ying-Hung Chen Cc: linux-xfs@oss.sgi.com Subject: Re: out of vmalloc space - use vmalloc to increase size when mounting xfs FS Message-ID: <20051205003014.GA1158@frodo> References: <4392F5C5.5000706@yingternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4392F5C5.5000706@yingternet.com> User-Agent: Mutt/1.5.3i X-archive-position: 6669 X-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: 425 Lines: 18 On Sun, Dec 04, 2005 at 09:57:25PM +0800, Ying-Hung Chen wrote: > Hi there, > > we are currently running linux kernel 2.6.14.2 with HIGHMEM enabled (the > machine has 1GB of RAM) > > Whenever mounting the xfs filesystem (200GB partition), it shows > > "allocation failed : out of vmalloc space - use vmalloc to > increase size" Which mount options are you using? (xfs_info output too please) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Dec 4 17:35:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 17:35:27 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB51ZLO0015149 for ; Sun, 4 Dec 2005 17:35:22 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22592; Mon, 5 Dec 2005 12:31:45 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 658A0494A261; Mon, 5 Dec 2005 12:31:45 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 946444 - pquota Message-Id: <20051205013145.658A0494A261@chook.melbourne.sgi.com> Date: Mon, 5 Dec 2005 12:31:45 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6670 X-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: 757 Lines: 19 Fix an intermittent pquota panic caused by dodgey quota flags to an umount dquot flush call. Date: Mon Dec 5 12:31:16 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24680a xfsidbg.c - 1.290 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.290&r2=text&tr2=1.289&f=h xfs_mount.c - 1.368 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.368&r2=text&tr2=1.367&f=h quota/xfs_qm.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h From owner-linux-xfs@oss.sgi.com Sun Dec 4 17:45:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 17:45:12 -0800 (PST) Received: from mail.davidb.org (adsl-64-172-240-129.dsl.sndg02.pacbell.net [64.172.240.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB51j9O0015926 for ; Sun, 4 Dec 2005 17:45:09 -0800 Received: from davidb by mail.davidb.org with local (Exim 4.54 #1 (Debian)) id 1Ej5MH-00023E-Kk for ; Sun, 04 Dec 2005 17:41:37 -0800 Date: Sun, 4 Dec 2005 17:41:37 -0800 From: David Brown To: Linux-XFS Mailing List Subject: Re: Filesystem Consistency Issues Message-ID: <20051205014137.GA7685@old.davidb.org> References: <20051204142506.GE2605@free.net.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051204142506.GE2605@free.net.ph> User-Agent: Mutt/1.5.11 X-archive-position: 6671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@davidb.org Precedence: bulk X-list: linux-xfs Content-Length: 822 Lines: 18 On Sun, Dec 04, 2005 at 10:25:06PM +0800, Federico Sevilla III wrote: > When I investigated one of the machines, mounting the filesystem in > read/write mode after having booted from a rescue CD automatically fixed > part of it, freeing about 60% of the filesystem. Running xfs_repair > further freed up space by moving disconnected inodes to lost+found. Most likely, the problem is that the root filesystem is being mounted readonly by the kernel. This is default, and I believe Debian leaves that as the default. The problem is that the readonly root mount prevents the recovery when the filesystem is mounted. Apparently, remounting as read/write doesn't cause this recovery to happen. Perhaps this should be added to the XFS FAQ, rather than just saying that "Yes", XFS can be used for the root FS. Dave Brown From owner-linux-xfs@oss.sgi.com Sun Dec 4 17:56:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 17:56:38 -0800 (PST) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB51uWO0016896 for ; Sun, 4 Dec 2005 17:56:34 -0800 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 6C9BEC003364 for ; Mon, 5 Dec 2005 09:53:00 +0800 (PHT) Received: from musang.free.net.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 0B405C000B68 for ; Mon, 5 Dec 2005 09:52:58 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 19B77160002A2; Mon, 5 Dec 2005 09:52:55 +0800 (PHT) Date: Mon, 5 Dec 2005 09:52:55 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Re: Filesystem Consistency Issues Message-ID: <20051205015255.GB2581@free.net.ph> Mail-Followup-To: Linux-XFS Mailing List References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051205014137.GA7685@old.davidb.org> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 6672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 855 Lines: 22 On Sun, Dec 04, 2005 at 05:41:37PM -0800, David Brown wrote: > Most likely, the problem is that the root filesystem is being mounted > readonly by the kernel. This is default, and I believe Debian leaves > that as the default. The problem is that the readonly root mount > prevents the recovery when the filesystem is mounted. Apparently, > remounting as read/write doesn't cause this recovery to happen. > > Perhaps this should be added to the XFS FAQ, rather than just saying > that "Yes", XFS can be used for the root FS. You're right. It looks like /etc/lilo.conf on the machines still has the "read-only" parameter built-in. We will change this and see if things get fixed. Thanks! --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs@oss.sgi.com Sun Dec 4 18:24:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 18:24:19 -0800 (PST) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB52OBO0019386 for ; Sun, 4 Dec 2005 18:24:11 -0800 Received: from gateway-att.yingternet.com (c-24-126-232-179.hsd1.ca.comcast.net [24.126.232.179]) by ying.yingternet.com (Postfix) with ESMTP id 0791D30009E; Sun, 4 Dec 2005 18:22:31 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id D172A204C0F; Sun, 4 Dec 2005 18:20:37 -0800 (PST) Message-ID: <4393A579.5090307@yingternet.com> Date: Mon, 05 Dec 2005 10:27:05 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott Cc: linux-xfs@oss.sgi.com, Ying-Hung Chen Subject: Re: out of vmalloc space - use vmalloc to increase size when mounting xfs FS References: <4392F5C5.5000706@yingternet.com> <20051205003014.GA1158@frodo> In-Reply-To: <20051205003014.GA1158@frodo> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 1703 Lines: 51 Hi Nathan, Nathan Scott wrote: > On Sun, Dec 04, 2005 at 09:57:25PM +0800, Ying-Hung Chen wrote: > >>Hi there, >> >>we are currently running linux kernel 2.6.14.2 with HIGHMEM enabled (the >>machine has 1GB of RAM) >> >>Whenever mounting the xfs filesystem (200GB partition), it shows >> >>"allocation failed : out of vmalloc space - use vmalloc to >>increase size" > > > Which mount options are you using? (xfs_info output too please) > > cheers. > default mount option, mount -t xfs /dev/hdb1 /Repository/01 mount -t xfs /dev/hdc1 /Repository/02 ... [root@localhost ~]# xfs_info /dev/hdb1 meta-data=/usr/local/MatriVideo/bin/Repository/01 isize=256 agcount=16, agsize=3052475 blks = sectsz=512 data = bsize=4096 blocks=48839600, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=23847, version=2 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@localhost ~]# xfs_info /dev/hdc1 meta-data=/usr/local/MatriVideo/bin/Repository/02 isize=256 agcount=16, agsize=3052475 blks = sectsz=512 data = bsize=4096 blocks=48839600, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=23847, version=2 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 -Ying From owner-linux-xfs@oss.sgi.com Sun Dec 4 19:20:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 19:20:18 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB53KAO0026596 for ; Sun, 4 Dec 2005 19:20:11 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA24440; Mon, 5 Dec 2005 14:16:37 +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 jB53Gkkt7197731; Mon, 5 Dec 2005 14:16: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 jB53FDqA001676; Mon, 5 Dec 2005 14:15:14 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id jB53FCoa001674; Mon, 5 Dec 2005 14:15:12 +1100 Date: Mon, 5 Dec 2005 14:15:12 +1100 From: Nathan Scott To: Ying-Hung Chen Cc: linux-xfs@oss.sgi.com Subject: Re: out of vmalloc space - use vmalloc to increase size when mounting xfs FS Message-ID: <20051205031512.GD1158@frodo> References: <4392F5C5.5000706@yingternet.com> <20051205003014.GA1158@frodo> <4393A579.5090307@yingternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4393A579.5090307@yingternet.com> User-Agent: Mutt/1.5.3i X-archive-position: 6674 X-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: 1064 Lines: 32 On Mon, Dec 05, 2005 at 10:27:05AM +0800, Ying-Hung Chen wrote: > Hi Nathan, > > mount -t xfs /dev/hdb1 /Repository/01 > mount -t xfs /dev/hdc1 /Repository/02 > ... > > [root@localhost ~]# xfs_info /dev/hdb1 > meta-data=/usr/local/MatriVideo/bin/Repository/01 isize=256 > agcount=16, agsize=3052475 blks > = sectsz=512 > data = bsize=4096 blocks=48839600, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=23847, version=2 > = sectsz=512 sunit=0 blks Hmm, I don't understand that then - with these parameters, your incore log buffers are 32K, which will not cause any vmalloc calls, which was my first thought at a possible cause. I guess you could instrument the __vmalloc code in the kernel to printk the size parameter and do a dump_stack when its invoked, and see where all your vmalloc space is going... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Dec 4 23:15:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Dec 2005 23:15:05 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB57F1O0020854 for ; Sun, 4 Dec 2005 23:15:02 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 6D56A1D102; Mon, 5 Dec 2005 08:11:28 +0100 (CET) To: David Brown Cc: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> From: Andi Kleen Date: 05 Dec 2005 04:41:05 -0700 In-Reply-To: <20051205014137.GA7685@old.davidb.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6675 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1155 Lines: 26 David Brown writes: > On Sun, Dec 04, 2005 at 10:25:06PM +0800, Federico Sevilla III wrote: > > > When I investigated one of the machines, mounting the filesystem in > > read/write mode after having booted from a rescue CD automatically fixed > > part of it, freeing about 60% of the filesystem. Running xfs_repair > > further freed up space by moving disconnected inodes to lost+found. > > Most likely, the problem is that the root filesystem is being mounted > readonly by the kernel. This is default, and I believe Debian leaves that > as the default. The problem is that the readonly root mount prevents the > recovery when the filesystem is mounted. Apparently, remounting as > read/write doesn't cause this recovery to happen. That sounds like a bug. Shouldn't log replay happening on ro->rw mount? BTW I think ext3/reiser solve the problem by replaying the logs even when the mount is ro. That would be another alternative. > Perhaps this should be added to the XFS FAQ, rather than just saying that > "Yes", XFS can be used for the root FS. It's a nasty trap that I bet most people and distributions get wrong. -Andi From owner-linux-xfs@oss.sgi.com Mon Dec 5 05:26:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Dec 2005 05:26:33 -0800 (PST) Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.182.167]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB5DQSO0029734 for ; Mon, 5 Dec 2005 05:26:28 -0800 Received: from [192.168.1.65] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay04.roc.ny.frontiernet.net (Postfix) with ESMTP id A4D0B3582E2; Mon, 5 Dec 2005 13:22:51 +0000 (UTC) Message-ID: <43943F3E.5080804@xfs.org> Date: Mon, 05 Dec 2005 07:23:10 -0600 From: Stephen Lord User-Agent: Thunderbird 1.4.1 (X11/20051006) MIME-Version: 1.0 To: Andi Kleen CC: David Brown , linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1408 Lines: 35 XFS runs recovery on a readonly filesystem. It has been doing that for years. There are log messages which come out when recovery runs, you should see them in dmesg or the syslog after boot up. Steve Andi Kleen wrote: > David Brown writes: > >> On Sun, Dec 04, 2005 at 10:25:06PM +0800, Federico Sevilla III wrote: >> >>> When I investigated one of the machines, mounting the filesystem in >>> read/write mode after having booted from a rescue CD automatically fixed >>> part of it, freeing about 60% of the filesystem. Running xfs_repair >>> further freed up space by moving disconnected inodes to lost+found. >> Most likely, the problem is that the root filesystem is being mounted >> readonly by the kernel. This is default, and I believe Debian leaves that >> as the default. The problem is that the readonly root mount prevents the >> recovery when the filesystem is mounted. Apparently, remounting as >> read/write doesn't cause this recovery to happen. > > That sounds like a bug. Shouldn't log replay happening on ro->rw mount? > > BTW I think ext3/reiser solve the problem by replaying the logs even > when the mount is ro. That would be another alternative. > >> Perhaps this should be added to the XFS FAQ, rather than just saying that >> "Yes", XFS can be used for the root FS. > > It's a nasty trap that I bet most people and distributions get wrong. > > -Andi > From owner-linux-xfs@oss.sgi.com Mon Dec 5 07:10:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Dec 2005 07:10:24 -0800 (PST) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB5FAKO0008917 for ; Mon, 5 Dec 2005 07:10:20 -0800 Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0IR100H6O4ZCJO@mailgw2.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 05 Dec 2005 08:57:00 -0600 (CST) Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2005120508565902856 for ; Mon, 05 Dec 2005 08:56:59 -0600 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0IR100M015AJW0@mailgw1.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Mon, 05 Dec 2005 08:57:00 -0600 (CST) Received: from [131.225.86.155] (wynand.fnal.gov [131.225.86.155]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTPSA id <0IR100MOK5IZ9E@mailgw1.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 05 Dec 2005 08:57:00 -0600 (CST) Date: Mon, 05 Dec 2005 08:56:35 -0600 From: Dan Yocum Subject: Re: RHEL ES4 To: linux-xfs@oss.sgi.com Message-id: <43945523.1070703@fnal.gov> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Fedora/1.7.12-1.5.1 X-archive-position: 6678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 1436 Lines: 38 Rob, Sorry to be the johnny-come-lately to this discussion. > Hi everyone, > I am attempting to use XFS on a number of RHEL ES 4 servers. I need help. > I have downloaded the patch, installed the xfsprogs and was able to use > mkfs.xfs to format a partition. When trying to mount the filesystem, it > tells me the kernel does not support XFS. I know that I need to recompile > the kernel to get this thing working, but I have no idea on how to do > this. I am wanting to use XFS to create a 120 TB filesystem (growable up > to 300 TB). XFS is my only option if I want a filesystem this large, is > this correct? Thanks in advance for your help. > > Rob Thompson You realize, of course, that XFS isn't cXFS, and that if you create a single 120TB volume only *one* machine will be able to mount that volume read-write. I'm not even sure if another system could mount that volume as read-only in parallel. If anyone has that kind of data, we (Fermilab) do, so I'd be interested in your (public) findings. I think the latest count of XFS disks here at Fermi is in the 800-900TB range (and growing), all of it white-box NAS, and a lot of it used as dCache pool nodes (http://www.dcache.org). Cheers, Dan PS, I'm not currently subscribed to linux-xfs, so please cc me directly. Thanks. -- Dan Yocum Fermilab 630.840.6509 yocum@fnal.gov, http://computing.fnal.gov/ccf/ftp.html Fermilab. Computing the quantum universe. From owner-linux-xfs@oss.sgi.com Mon Dec 5 09:35:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Dec 2005 09:35:13 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB5HZ9qY027147 for ; Mon, 5 Dec 2005 09:35:09 -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 jB5HVbxT011260 for ; Mon, 5 Dec 2005 11:31:37 -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 jB5HVasL26628427; Mon, 5 Dec 2005 11:31:36 -0600 (CST) Message-ID: <43947977.8070904@sgi.com> Date: Mon, 05 Dec 2005 11:31:35 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: jijo@free.net.ph Subject: Re: Filesystem Consistency Issues References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> In-Reply-To: <43943F3E.5080804@xfs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6679 X-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: 404 Lines: 14 Stephen Lord wrote: > XFS runs recovery on a readonly filesystem. It has been doing that > for years. There are log messages which come out when recovery runs, > you should see them in dmesg or the syslog after boot up. Yep. That code has changed a bit but the results should be the same... Federico, can you verify that you see the log recovery messages when your machines boot up? -Eric > Steve From owner-linux-xfs@oss.sgi.com Mon Dec 5 15:53:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Dec 2005 15:53:14 -0800 (PST) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB5NrAqY024477 for ; Mon, 5 Dec 2005 15:53:10 -0800 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 64166C0033FB for ; Tue, 6 Dec 2005 07:49:38 +0800 (PHT) Received: from musang.free.net.ph (unknown [203.177.60.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 8B4CEC0033F7 for ; Tue, 6 Dec 2005 07:49:35 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 96658160002A2; Tue, 6 Dec 2005 07:49:32 +0800 (PHT) Date: Tue, 6 Dec 2005 07:49:32 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues Message-ID: <20051205234932.GA3406@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> <43947977.8070904@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43947977.8070904@sgi.com> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 6683 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 1208 Lines: 30 On Mon, Dec 05, 2005 at 11:31:35AM -0600, Eric Sandeen wrote: > Stephen Lord wrote: > > XFS runs recovery on a readonly filesystem. It has been doing that > > for years. There are log messages which come out when recovery runs, > > you should see them in dmesg or the syslog after boot up. > > Yep. That code has changed a bit but the results should be the same... > > Federico, can you verify that you see the log recovery messages when > your machines boot up? pos01:~# dmesg | grep -i xfs SGI XFS with no debug enabled XFS mounting filesystem hda1 Starting XFS recovery on filesystem: hda1 (dev: hda1) Ending XFS recovery on filesystem: hda1 (dev: hda1) VFS: Mounted root (xfs filesystem) readonly. So the logs "advertise" that log recovery is done. However, "ghost" disk usage continues to increase until the disks are full, and this can only be fixed first by mounting the filesystem read-write using a rescue system, which partially recovers free space, and then by running xfs_repair which recovers the rest. --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs@oss.sgi.com Mon Dec 5 21:53:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Dec 2005 21:53:35 -0800 (PST) Received: from arke.acsalaska.net (arke.acsalaska.net [209.112.173.225]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB65rTqY029300 for ; Mon, 5 Dec 2005 21:53:31 -0800 Received: from erbenson.alaska.net (66-230-89-249-dial-as3.nwc.acsalaska.net [66.230.89.249]) by arke.acsalaska.net (8.13.4/8.13.4) with ESMTP id jB65ntHw081857 for ; Mon, 5 Dec 2005 20:49:56 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 86744394F for ; Mon, 5 Dec 2005 20:49:54 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id DCDC040FF35; Mon, 5 Dec 2005 20:49:53 -0900 (AKST) Date: Mon, 5 Dec 2005 20:49:53 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues Message-ID: <20051206054953.GP14319@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <43943F3E.5080804@xfs.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.52; SA 3.0.4; spamdefang 1.116 X-archive-position: 6688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1729 Lines: 53 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 05, 2005 at 07:23:10AM -0600, Stephen Lord wrote: > XFS runs recovery on a readonly filesystem. It has been doing that > for years. There are log messages which come out when recovery runs, > you should see them in dmesg or the syslog after boot up. I believe there may be a slight problem with how this works in certain circumstances. I have observed the following problem, but have not had time to do proper tests to confirm it. Basically the situation is as follows: 1) /etc/fstab contains a filesystem mounted read-only by default. 2) said filesystem is remounted read-write, and files which are in use (running executables for example) are unlinked (such that link count becomes 0). 3) time passes. (more then enough for everything to be synced). 4) system crashes or is rebooted uncleanly. 5) filesystem is mounted read-only, log recovery occurs anyway. 6) xfs_check or xfs_repair will report orphaned inodes which need to be moved to lost+found, if repair is performed inodes are indeed moved to lost+found, the inodes in question are the previously deleted files. I have not had the chance to prove this, but I have seen enough instances close enough to this that I believe it to be true. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkOVJoEACgkQJKx7GixEevxDQQCgjaft+oeLf1XTmi3g42i1tNQD p4YAn3oGK10pxnfnqSbvhZfD1sEU2iW6 =Gtrc -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-linux-xfs@oss.sgi.com Tue Dec 6 06:13:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 06:13:55 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB6EDpqY019575 for ; Tue, 6 Dec 2005 06:13:51 -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 jB6EAIxT010593 for ; Tue, 6 Dec 2005 08:10:18 -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 jB6EAGOS9483232; Tue, 6 Dec 2005 06:10:17 -0800 (PST) Message-ID: <43959BC8.60403@sgi.com> Date: Tue, 06 Dec 2005 08:10:16 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Federico Sevilla III CC: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> <43947977.8070904@sgi.com> <20051205234932.GA3406@free.net.ph> In-Reply-To: <20051205234932.GA3406@free.net.ph> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6691 X-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: 542 Lines: 17 Federico Sevilla III wrote: > So the logs "advertise" that log recovery is done. However, "ghost" disk > usage continues to increase until the disks are full, and this can only > be fixed first by mounting the filesystem read-write using a rescue > system, which partially recovers free space, and then by running > xfs_repair which recovers the rest. Out of curiosity, how much space is reclaimed by the rescue mount, and how much by the repair? What is the output of repair when you run it? That may offer some clues. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Dec 6 06:15:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 06:15:11 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB6EF8qY019854 for ; Tue, 6 Dec 2005 06:15:08 -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 jB6EBZxT010979 for ; Tue, 6 Dec 2005 08:11:35 -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 jB6EBYOS9475805; Tue, 6 Dec 2005 06:11:34 -0800 (PST) Message-ID: <43959C16.4090108@sgi.com> Date: Tue, 06 Dec 2005 08:11:34 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> <20051206054953.GP14319@plato.local.lan> In-Reply-To: <20051206054953.GP14319@plato.local.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6692 X-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: 1448 Lines: 41 Ethan Benson wrote: > On Mon, Dec 05, 2005 at 07:23:10AM -0600, Stephen Lord wrote: > >>XFS runs recovery on a readonly filesystem. It has been doing that >>for years. There are log messages which come out when recovery runs, >>you should see them in dmesg or the syslog after boot up. > > > I believe there may be a slight problem with how this works in certain > circumstances. I have observed the following problem, but have > not had time to do proper tests to confirm it. > > Basically the situation is as follows: > > 1) /etc/fstab contains a filesystem mounted read-only by default. > > 2) said filesystem is remounted read-write, and files which are in use > (running executables for example) are unlinked (such that link > count becomes 0). > > 3) time passes. (more then enough for everything to be synced). > > 4) system crashes or is rebooted uncleanly. > > 5) filesystem is mounted read-only, log recovery occurs anyway. > > 6) xfs_check or xfs_repair will report orphaned inodes which need to > be moved to lost+found, if repair is performed inodes are indeed moved > to lost+found, the inodes in question are the previously deleted files. > > I have not had the chance to prove this, but I have seen enough > instances close enough to this that I believe it to be true. > There is something called "unlinked list processing" which should be handling this... bears investigation, I guess. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Dec 6 10:06:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 10:06:25 -0800 (PST) Received: from mail.linbit.com (aug.linbit.com [212.69.162.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB6I6JqY018831 for ; Tue, 6 Dec 2005 10:06:20 -0800 Received: from soda (office.linbit [213.229.1.138]) by mail.linbit.com (LINBIT Mail Daemon) with ESMTP id 67B2815FD5; Tue, 6 Dec 2005 19:02:45 +0100 (CET) Date: Tue, 6 Dec 2005 19:02:46 +0100 From: Lars Ellenberg To: drbd-user@linbit.com Cc: Linux-XFS Mailing List Subject: Re: [DRBD-user] Unrecoverable XFS Dinode Corruption on DRBD Message-ID: <20051206180246.GB4518@soda.linbit> Mail-Followup-To: drbd-user@lists.linbit.com, Linux-XFS Mailing List References: <20051205232537.GA2489@free.net.ph> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051205232537.GA2489@free.net.ph> X-archive-position: 6694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Lars.Ellenberg@linbit.com Precedence: bulk X-list: linux-xfs Content-Length: 1020 Lines: 28 / 2005-12-06 07:25:37 +0800 \ Federico Sevilla III: > Hi, > > Today we ran into unrecoverable XFS dinode corruption on a DRBD cluster > that's been in production for two years, with 146 day uptime on the > machines. This is the first time we've ran into this problem. Both > machines run Debian GNU/Linux Sarge with Linux 2.6.12.2 and DRBD 0.7.10. please have a look at http://bugzilla.kernel.org/show_bug.cgi?id=4946 aka the bio_clone bug, introduced in mainline kernel 2.6.11-rcX and fixed in mainline 2.6.12.4 (so it is probably present in debian 2.6.12.2, which you happen to use). there is also a thread about this in this mailing lists archives, about August 5. I'm not saying it is this bug, I just suggest it might be. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client. From owner-linux-xfs@oss.sgi.com Tue Dec 6 13:35:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 13:35:14 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB6LZ9qY007188 for ; Tue, 6 Dec 2005 13:35:09 -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 jB6NaA6v023919 for ; Tue, 6 Dec 2005 15:36:11 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jB6LUaDN21238807 for ; Tue, 6 Dec 2005 15:30:36 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id jB6LTiLL21618142; Tue, 6 Dec 2005 15:29:44 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id jB6LUYvM003753; Tue, 6 Dec 2005 15:30:35 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id jB6LUYAm003751; Tue, 6 Dec 2005 15:30:34 -0600 Date: Tue, 6 Dec 2005 15:30:34 -0600 From: Eric Sandeen Message-Id: <200512062130.jB6LUYAm003751@penguin.americas.sgi.com> To: sgi.bugs.xfs@fido.engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 946611 - remove unused "readonly" variable in some log recovery functions X-archive-position: 6695 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 808 Lines: 20 remove unused "readonly" arg from xlog_find_tail and xlog_recover Date: Tue Dec 6 13:29:47 PST 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:203307a xfs_log.c - 1.314 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.314&r2=text&tr2=1.313&f=h xfs_log_priv.h - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h xfs_log_recover.c - 1.304 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.304&r2=text&tr2=1.303&f=h - remove unused "readonly" arg from xlog_find_tail and xlog_recover From owner-linux-xfs@oss.sgi.com Tue Dec 6 13:42:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 13:42:22 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB6LgFqY007887 for ; Tue, 6 Dec 2005 13:42:16 -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 IAA17394 for ; Wed, 7 Dec 2005 08:38:40 +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 jB6Lcpkt7284108 for ; Wed, 7 Dec 2005 08:38:52 +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 jB6LbGgh000851 for ; Wed, 7 Dec 2005 08:37:17 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id jB6LbG43000849 for linux-xfs@oss.sgi.com; Wed, 7 Dec 2005 08:37:16 +1100 Date: Wed, 7 Dec 2005 08:37:16 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues Message-ID: <20051206213715.GA756@frodo> References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> <43947977.8070904@sgi.com> <20051205234932.GA3406@free.net.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051205234932.GA3406@free.net.ph> User-Agent: Mutt/1.5.3i X-archive-position: 6696 X-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: 555 Lines: 16 On Tue, Dec 06, 2005 at 07:49:32AM +0800, Federico Sevilla III wrote: > So the logs "advertise" that log recovery is done. However, "ghost" disk > usage continues to increase until the disks are full, and this can only > be fixed first by mounting the filesystem read-write using a rescue > system, which partially recovers free space, and then by running > xfs_repair which recovers the rest. Is it easily reproduced (sounds like it)? If so, could you come up with a test case for us to analyse? That would be a huge help here.. thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Tue Dec 6 20:29:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 20:29:10 -0800 (PST) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB74T3qY013250 for ; Tue, 6 Dec 2005 20:29:03 -0800 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id BD6D4C00325B for ; Wed, 7 Dec 2005 12:25:30 +0800 (PHT) Received: from musang.free.net.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 39AD1C000DD9 for ; Wed, 7 Dec 2005 12:25:28 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 89025160002A2; Wed, 7 Dec 2005 12:25:24 +0800 (PHT) Date: Wed, 7 Dec 2005 12:25:24 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues Message-ID: <20051207042524.GB2539@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> <43947977.8070904@sgi.com> <20051205234932.GA3406@free.net.ph> <20051206213715.GA756@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051206213715.GA756@frodo> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 6699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 946 Lines: 22 On Wed, Dec 07, 2005 at 08:37:16AM +1100, Nathan Scott wrote: > Is it easily reproduced (sounds like it)? If so, could you come up > with a test case for us to analyse? That would be a huge help here.. Basically our POS application writes a bunch of audit information to disk after what we call a terminal reading, which is done to every operational POS terminal at the end of a selling day. The store personnel incorrectly turn off the machine after this terminal reading is over instead of correctly shutting it down. This is done everyday. It takes a few months for the single filesystem (per terminal) to finally hit 100% usage. I'll send the list more information -- average file size, exact usage drop after rescue mount, exact messages of xfs_repair -- as soon as I can. --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs@oss.sgi.com Tue Dec 6 20:26:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 20:26:14 -0800 (PST) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB74QBqY012833 for ; Tue, 6 Dec 2005 20:26:11 -0800 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id B3454C00325B for ; Wed, 7 Dec 2005 12:22:35 +0800 (PHT) Received: from musang.free.net.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 03B5FC000DD9 for ; Wed, 7 Dec 2005 12:22:33 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id DF530160002A2; Wed, 7 Dec 2005 12:22:28 +0800 (PHT) Date: Wed, 7 Dec 2005 12:22:28 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Filesystem Consistency Issues Message-ID: <20051207042228.GA2539@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20051204142506.GE2605@free.net.ph> <20051205014137.GA7685@old.davidb.org> <43943F3E.5080804@xfs.org> <43947977.8070904@sgi.com> <20051205234932.GA3406@free.net.ph> <43959BC8.60403@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43959BC8.60403@sgi.com> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 6698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 981 Lines: 26 On Tue, Dec 06, 2005 at 08:10:16AM -0600, Eric Sandeen wrote: > Out of curiosity, how much space is reclaimed by the rescue mount, and > how much by the repair? I don't have exact figures, but for a 20GB filesystem with only 800MB used "for real", the rescue mount brought usage down to about 15GB, and then the repair took care of the rest. > What is the output of repair when you run it? That may offer some > clues. Basically just disconnected inodes that were dumped in lost+found, which correspond to data that our POS system had just created locally for audit purposes when the machines were turned off (part of our fix is correcting this practice and maybe adding an fsync() after the audit files are written). I'll make it a point to have better answers for these questions during our next clean up run. --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs@oss.sgi.com Tue Dec 6 21:13:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 21:13:33 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB75DSqY017139 for ; Tue, 6 Dec 2005 21:13:28 -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 jB77EUpN020302 for ; Tue, 6 Dec 2005 23:14:30 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jB758rDN21256765 for ; Tue, 6 Dec 2005 23:08:53 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id jB7581LL21967387; Tue, 6 Dec 2005 23:08:01 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id jB758pvM004640; Tue, 6 Dec 2005 23:08:51 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id jB758pCQ004638; Tue, 6 Dec 2005 23:08:51 -0600 Date: Tue, 6 Dec 2005 23:08:51 -0600 From: Eric Sandeen Message-Id: <200512070508.jB758pCQ004638@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 946641 - remove some dead code from xfs_iozero & friends X-archive-position: 6701 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 845 Lines: 21 remove unused vars, args, & unneeded intermediate vars from zeroing code Date: Tue Dec 6 21:08:24 PST 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:203328a xfs_inode.c - 1.423 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.423&r2=text&tr2=1.422&f=h linux-2.6/xfs_lrw.c - 1.230 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.230&r2=text&tr2=1.229&f=h linux-2.4/xfs_lrw.c - 1.225 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.225&r2=text&tr2=1.224&f=h - remove unused vars, args, & unneeded intermediate vars from zeroing code From owner-linux-xfs@oss.sgi.com Tue Dec 6 21:31:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 21:31:11 -0800 (PST) Received: from mail.davidb.org (adsl-64-172-240-129.dsl.sndg02.pacbell.net [64.172.240.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB75V5qY018787 for ; Tue, 6 Dec 2005 21:31:06 -0800 Received: from davidb by mail.davidb.org with local (Exim 4.54 #1 (Debian)) id 1Ejrq0-0005zi-Ux for ; Tue, 06 Dec 2005 21:27:32 -0800 Date: Tue, 6 Dec 2005 21:27:32 -0800 From: David Brown To: XFS Mailing List Subject: xfsdump timestamp patch. Message-ID: <20051207052732.GA22418@old.davidb.org> Mail-Followup-To: XFS Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 6702 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@davidb.org Precedence: bulk X-list: linux-xfs Content-Length: 3795 Lines: 130 The patch below adds an option to xfsdump to set the timestamp that a backup will happen based on. This can be used to correct a problem that occurs in files that are touched after making a snapshot volume. For example: - make snapshot - touch a file on r/w volume - xfsdump the r/o snapshot - undo the snapshot The touched file will not be included in the dump, but since the timestamp for the backup happens after this file was touched, the file will also not be included in future incrementals. This can be fixed as follows: - touch /tmp/snapstamp - make snapshot - xfsdump -t /tmp/snapstamp ... - undo snapshot The '-t' option causes xfsdump to use the timestamp of the named file as the dump time, rather than the current time. Thanks, David Brown Subject: [PATCH] Add '-t' option to allow dump time to be specified. --- common/global.c | 29 ++++++++++++++++++++++++++++- common/main.c | 3 +++ dump/getopt.h | 4 ++-- 3 files changed, 33 insertions(+), 3 deletions(-) applies-to: fac8fc29c114fa28618b82a9f5918ff6b9521f37 102ce75c083379636394ec2851b8f07d0610b515 diff --git a/common/global.c b/common/global.c index d793175..2e05ef9 100644 --- a/common/global.c +++ b/common/global.c @@ -76,6 +76,9 @@ global_hdr_alloc( intgen_t argc, char *a #endif /* DUMP */ intgen_t rval; +#ifdef DUMP + struct stat64 statbuf; +#endif /* DUMP */ /* sanity checks */ @@ -96,7 +99,8 @@ global_hdr_alloc( intgen_t argc, char *a ghdrp->gh_version = GLOBAL_HDR_VERSION; /* fill in the timestamp: all changes made at or after this moment - * will be included in increments on this base. + * will be included in increments on this base. This may be + * overridden by the '-t' option. */ ghdrp->gh_timestamp = (time32_t) time( 0 ); @@ -190,6 +194,29 @@ global_hdr_alloc( intgen_t argc, char *a ghdrp->gh_version = GLOBAL_HDR_VERSION_0; break; #endif /* EXTATTR */ + case GETOPT_DUMPTIME: + /* Use the timestamp of the specified file, rather + * than the current time as the dump time. + */ + if ( ! optarg || optarg[ 0 ] == '-' ) { + mlog( MLOG_NORMAL | MLOG_ERROR, + _("-%c argument missing\n"), + optopt ); + usage( ); + return 0; + } + rval = lstat64( optarg, &statbuf ); + if ( rval ) { + mlog( MLOG_NORMAL | MLOG_ERROR, + _("unable to get status of %s: %s\n"), + optarg, + strerror( errno )); + usage( ); + return 0; + } + ghdrp->gh_timestamp = statbuf.st_mtime; + break; + #endif /* DUMP */ } } diff --git a/common/main.c b/common/main.c index 3d0b89e..ee53026 100644 --- a/common/main.c +++ b/common/main.c @@ -1102,6 +1102,9 @@ usage( void ) #ifdef REVEAL ULO(_("(miniroot restrictions)"), GETOPT_MINIROOT ); #endif /* REVEAL */ +#ifdef DUMP + ULO(_(" (use time of file)"), GETOPT_DUMPTIME ); +#endif /* DUMP */ ULN(_("- (stdin)") ); ULN(_("") ); #endif /* RESTORE */ diff --git a/dump/getopt.h b/dump/getopt.h index 0aeaa7d..df3393e 100644 --- a/dump/getopt.h +++ b/dump/getopt.h @@ -41,7 +41,7 @@ * facilitating easy changes. */ -#define GETOPT_CMDSTRING "ab:c:d:ef:hl:mop:qs:v:z:AB:CEFG:H:I:JL:M:NO:PRSTUVWY:Z" +#define GETOPT_CMDSTRING "ab:c:d:ef:hl:mop:qs:t:v:z:AB:CEFG:H:I:JL:M:NO:PRSTUVWY:Z" #define GETOPT_DUMPASOFFLINE 'a' /* dump DMF dualstate files as offline */ #define GETOPT_BLOCKSIZE 'b' /* blocksize for rmt */ @@ -62,7 +62,7 @@ #define GETOPT_QIC 'q' /* option to tell dump it's a QIC tape */ /* 'r' */ #define GETOPT_SUBTREE 's' /* subtree dump (content_inode.c) */ -/* 't' */ +#define GETOPT_DUMPTIME 't' /* use stat of file as dump time. */ /* 'u' */ #define GETOPT_VERBOSITY 'v' /* verbosity level (0 to 4 ) */ /* 'w' */ --- 0.99.9j From owner-linux-xfs@oss.sgi.com Tue Dec 6 22:35:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 22:35:59 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB76ZqqY025547 for ; Tue, 6 Dec 2005 22:35:53 -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 RAA00067; Wed, 7 Dec 2005 17:31:29 +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 jB76Vbkt7268696; Wed, 7 Dec 2005 17:31:39 +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 jB76U0gh010987; Wed, 7 Dec 2005 17:30:00 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id jB76Tvwp010985; Wed, 7 Dec 2005 17:29:57 +1100 Date: Wed, 7 Dec 2005 17:29:56 +1100 From: Nathan Scott To: Stephen Smalley Cc: Christoph Hellwig , XFS Mailing List Subject: Re: fixing SELINUX-support in XFS-2.6.14 Message-ID: <20051207062956.GB10603@frodo> References: <20051130163424.GA4724@m.safari.iki.fi> <20051201082709.C7104341@wobbly.melbourne.sgi.com> <20051201112021.GB3958@infradead.org> <20051202062318.A7097967@wobbly.melbourne.sgi.com> <1133532863.28437.120.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1133532863.28437.120.camel@moss-spartans.epoch.ncsc.mil> User-Agent: Mutt/1.5.3i X-archive-position: 6704 X-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: 1463 Lines: 41 Hi Stephen, Apologies for the delay in replying, I've been away for a bit. On Fri, Dec 02, 2005 at 09:14:23AM -0500, Stephen Smalley wrote: > On Fri, 2005-12-02 at 06:23 +1100, Nathan Scott wrote: > > Well, I mainly want to not cause a huge regression for those > > people who were using it in the stable kernel series. > > > Hmmm ... if its that simple, then that should have been done > > for reiserfs and XFS before this change was merged at all, > > surely? That would've kept the old (albeit not quite correct) > > behaviour without the regression, and given ample opportunity > > for the remaining filesystems to get properly fixed up... no? > > I don't know whether that would be simple or not (not having looked > closely at the xfs implementation), but these patches were discussed on > linux-fsdevel and lived in -mm for a while without such a suggestion > being made. > ... It wasn't clear to me when I initially read those that the unmodified (but working) filesystems would now be broken. > I'm open to suggestions, but I'm not getting a consistent message from > xfs folks, so it is difficult to know how to proceed. Heh, Christoph wears many hats - here he's wearing both VFS and XFS hats at once... :) > I'm also not > clear on what we can hope to get into 2.6.15 at this point. Yes, its too late for 2.6.15. I'll cook up a patch to reinstate the functionality for XFS and make sure its included for 2.6.16. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Dec 6 22:41:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Dec 2005 22:41:46 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB76fbqY026206 for ; Tue, 6 Dec 2005 22:41: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 RAA00193; Wed, 7 Dec 2005 17:38:01 +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 jB76c8kt7295242; Wed, 7 Dec 2005 17:38:11 +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 jB76aWgh011071; Wed, 7 Dec 2005 17:36:33 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id jB76aUX3011069; Wed, 7 Dec 2005 17:36:30 +1100 Date: Wed, 7 Dec 2005 17:36:30 +1100 From: Nathan Scott To: Sami Farin Cc: XFS Mailing List Subject: Re: fixing SELINUX-support in XFS-2.6.14 Message-ID: <20051207063630.GB11031@frodo> References: <20051130163424.GA4724@m.safari.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051130163424.GA4724@m.safari.iki.fi> User-Agent: Mutt/1.5.3i X-archive-position: 6705 X-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: 1791 Lines: 76 On Wed, Nov 30, 2005 at 06:34:25PM +0200, Sami Farin wrote: > Does XFS team have plans to make 2.6.14 work with SELINUX? > http://marc.theaimsgroup.com/?l=selinux&m=112653995009765&w=2 Does this patch help? (Its a -p1 patch, to be applied from inside fs/xfs in the kernel). thanks. -- Nathan Index: xfs-linux/linux-2.6/xfs_iops.c =================================================================== --- xfs-linux.orig/linux-2.6/xfs_iops.c +++ xfs-linux/linux-2.6/xfs_iops.c @@ -53,6 +53,7 @@ #include #include +#include /* * Change the requested timestamp in the given inode. @@ -210,6 +211,39 @@ validate_fields( } /* + * Hook in SELinux. This is not quite correct yet, what we really need + * here (as we do for default ACLs) is a mechanism by which creation of + * these attrs can be journalled at inode creation time (along with the + * inode, of course, such that log replay can't cause these to be lost). + */ +STATIC int +linvfs_init_security( + struct vnode *vp, + struct inode *dir) +{ + struct inode *ip = LINVFS_GET_IP(vp); + size_t length; + void *value; + char *name; + int error; + + error = security_inode_init_security(ip, dir, &name, &value, &length); + if (error) { + if (error == -EOPNOTSUPP) + return 0; + return -error; + } + + VOP_ATTR_SET(vp, name, value, length, ATTR_SECURE, NULL, error); + if (!error) + VMODIFY(vp); + + kfree(name); + kfree(value); + return error; +} + +/* * Determine whether a process has a valid fs_struct (kernel daemons * like knfsd don't have an fs_struct). * @@ -274,6 +308,9 @@ linvfs_mknod( break; } + if (!error) + error = linvfs_init_security(vp, dir); + if (default_acl) { if (!error) { error = _ACL_INHERIT(vp, &va, default_acl); From owner-linux-xfs@oss.sgi.com Wed Dec 7 01:39:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 01:39:15 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB79d7qY017429 for ; Wed, 7 Dec 2005 01:39:08 -0800 Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id jB79ZWVp015802 for ; Wed, 7 Dec 2005 18:35:32 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id jB79ZWgg024152 for ; Wed, 7 Dec 2005 18:35:32 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id jB79ZVj9024145 for ; Wed, 7 Dec 2005 18:35:31 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id C2EF84345 for ; Wed, 7 Dec 2005 18:35:31 +0900 (JST) Received: from nabal.nict.go.jp (unknown [133.243.93.85]) by mail1.nict.go.jp (Postfix) with SMTP id 889D342E6 for ; Wed, 7 Dec 2005 18:35:31 +0900 (JST) Date: Wed, 7 Dec 2005 18:35:31 +0900 From: CHIKAMA masaki To: linux-xfs@oss.sgi.com Subject: deep chmod|chown -R begin to start OOMkiller Message-Id: <20051207183531.5c13e8c5.masaki-c@nict.go.jp> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6706 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masaki-c@nict.go.jp Precedence: bulk X-list: linux-xfs Content-Length: 621 Lines: 25 Hello all. I have trouble about a storange behavior on xfs fileststem. When I did "chmod -R 755 ." on deep directory, the system became slow down and began to start OOMkiller after a while. At that time, slabtop showed that the number of xfs_ili, xfs_inode, and linvfs_icache objects are becoming very large. My kernel version is 2.6.13.4. A similar report is found at http://oss.sgi.com/archives/linux-xfs/2003-03/msg00018.html Is this a expected bihavior? Now I use "find -exec" insted of "chmod -R". The usage of slab memory with "find" is calm and does not start OOM killker. -- CHIKAMA Masaki @ NICT From owner-linux-xfs@oss.sgi.com Wed Dec 7 05:22:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 05:22:23 -0800 (PST) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB7DMFqY007764 for ; Wed, 7 Dec 2005 05:22:16 -0800 Received: from safari.iki.fi (80.223.105.208) by pne-smtpout2-sn1.fre.skanova.net (7.2.069.1) id 4394B97C00083796 for linux-xfs@oss.sgi.com; Wed, 7 Dec 2005 14:18:42 +0100 Received: (qmail 5271 invoked by uid 500); 7 Dec 2005 13:18:40 -0000 Date: Wed, 7 Dec 2005 15:18:39 +0200 From: Sami Farin To: XFS Mailing List Subject: Re: fixing SELINUX-support in XFS-2.6.14 Message-ID: <20051207131839.GA4827@m.safari.iki.fi> Mail-Followup-To: XFS Mailing List References: <20051130163424.GA4724@m.safari.iki.fi> <20051207063630.GB11031@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051207063630.GB11031@frodo> User-Agent: Mutt/1.5.11 X-archive-position: 6711 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: safari-xfs@safari.iki.fi Precedence: bulk X-list: linux-xfs Content-Length: 467 Lines: 17 On Wed, Dec 07, 2005 at 05:36:30PM +1100, Nathan Scott wrote: > On Wed, Nov 30, 2005 at 06:34:25PM +0200, Sami Farin wrote: > > Does XFS team have plans to make 2.6.14 work with SELINUX? > > http://marc.theaimsgroup.com/?l=selinux&m=112653995009765&w=2 > > Does this patch help? (Its a -p1 patch, to be applied from Yes, it seems to work. At least the system boots and security context is created for new files. > inside fs/xfs in the kernel). > > thanks. -- From owner-linux-xfs@oss.sgi.com Wed Dec 7 10:29:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 10:29:57 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB7ITqqY004417 for ; Wed, 7 Dec 2005 10:29:53 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jB7KV2FA026149 for ; Wed, 7 Dec 2005 12:31:02 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jB7IQ6vD5439876; Wed, 7 Dec 2005 10:26:06 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jB7IQJ3J003337; Wed, 7 Dec 2005 12:26:19 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jB7IQIno003333; Wed, 7 Dec 2005 12:26:18 -0600 Date: Wed, 7 Dec 2005 12:26:18 -0600 From: Christoph Hellwig Message-Id: <200512071826.jB7IQIno003333@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Cc: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 946205 - turn xlog helper macros into real functions X-archive-position: 6715 X-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@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 15 Date: Wed Dec 7 10:25:53 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:203360a fs/xfs/xfs_log.c - 1.315 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.315&r2=text&tr2=1.314&f=h fs/xfs/xfs_log_priv.h - 1.114 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.114&r2=text&tr2=1.113&f=h From owner-linux-xfs@oss.sgi.com Wed Dec 7 11:07:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 11:07:44 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB7J7aqY006723 for ; Wed, 7 Dec 2005 11:07:38 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jB7L8jgE000997 for ; Wed, 7 Dec 2005 13:08:45 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jB7J2nvD5449134; Wed, 7 Dec 2005 11:02:49 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jB7J32IU008584; Wed, 7 Dec 2005 13:03:02 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jB7J31Pg008583; Wed, 7 Dec 2005 13:03:01 -0600 Date: Wed, 7 Dec 2005 13:03:01 -0600 From: Christoph Hellwig Message-Id: <200512071903.jB7J31Pg008583@naboo.americas.sgi.com> To: Cc: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 946679 - fix, speedup and simplify atime handling X-archive-position: 6716 X-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@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2152 Lines: 37 let the VFS handle atime updates and only sync back to the xfs inode when nessecary Date: Wed Dec 7 11:02:48 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.4.x Inspected by: dgc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:203362a fs/xfs/xfs_vnodeops.c - 1.661 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.661&r2=text&tr2=1.660&f=h fs/xfs/xfs_itable.c - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h fs/xfs/xfs_dmapi.c - 1.136 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmapi.c.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h fs/xfs/xfs_inode_item.c - 1.123 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h fs/xfs/xfs_inode.c - 1.424 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.424&r2=text&tr2=1.423&f=h fs/xfs/xfs_inode.h - 1.206 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.206&r2=text&tr2=1.205&f=h fs/xfs/linux-2.6/xfs_lrw.c - 1.231 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.231&r2=text&tr2=1.230&f=h fs/xfs/linux-2.6/xfs_vnode.c - 1.135 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h fs/xfs/linux-2.6/xfs_iops.c - 1.231 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.231&r2=text&tr2=1.230&f=h fs/xfs/linux-2.4/xfs_lrw.c - 1.226 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.226&r2=text&tr2=1.225&f=h fs/xfs/linux-2.4/xfs_vnode.c - 1.135 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h fs/xfs/linux-2.4/xfs_iops.c - 1.214 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.214&r2=text&tr2=1.213&f=h From owner-linux-xfs@oss.sgi.com Wed Dec 7 11:54:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 11:54:40 -0800 (PST) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB7JsVqY010123 for ; Wed, 7 Dec 2005 11:54:31 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1Ej3UE-0004Qg-Rz for ; Sun, 04 Dec 2005 23:41:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17299.32438.100855.316477@base.ty.sabi.co.UK> Date: Sun, 4 Dec 2005 23:41:42 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: Filesystem Consistency Issues In-Reply-To: <20051204142506.GE2605@free.net.ph> References: <20051204142506.GE2605@free.net.ph> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 6717 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 4763 Lines: 116 >>> On Sun, 4 Dec 2005 22:25:06 +0800, Federico Sevilla III >>> said: jijo> Hi, We use XFS (Linux kernel 2.6.12 on Debian 3.1 Sarge) jijo> on fat client point-of-sale terminals. Somewhat odd idea... XFS is designed towards really large systems, even if it supports small ones fairly decently. jijo> [ ... ] The POS application regularly writes transaction jijo> audit information and maintains a local cache of the jijo> product database on the local drive, [ ... ] jijo> [ ... 800MB used out of 20-40GB, but in two months the free jijo> list is gone ... ] When I investigated one of the machines, jijo> mounting the filesystem in read/write mode after having jijo> booted from a rescue CD automatically fixed part of it, jijo> freeing about 60% of the filesystem. Running xfs_repair jijo> further freed up space by moving disconnected inodes to jijo> lost+found. I found that these machines were regularly jijo> powered off without a proper shutdown, and presumably with jijo> dirty data in the buffers. [ ... ] jijo> I find XFS's behavior troubling, though. Perhaps, but that is about as good as it goes. jijo> First, that I had to mount the filesystem (the root jijo> partition) from a rescue CD for the log replay to "fix" jijo> things properly. IIRC Debian Sarge mounts the root filesystem in a way that for example does not necessarily trigger the mount count/time based check. At least it did not happen on my mostly-Sarge PC. jijo> Isn't it supposed to do this by itself on bootup? This really depends on how the distribution handles that. I would check the system log for any messages saying that checking has been skipped, or should be done. jijo> And second, that the filesystem's consistency needed jijo> xfs_repair to completely repair things. That's not surprising; several journaling filesystems don't journal freelist transactions, because they can reconstruct it from a filesystem scan, and that is usually cheaper/faster. jijo> Data loss during incorrect shutdown is understandable and jijo> acceptable, but we use a journaling filesystem like XFS in jijo> particular so that filesystem consistency is guaranteed, jijo> right? I would guess that means consistent as far as it goes; that is, the _visible_ parts of the filesystem metadata are consistent. Things like the free list and unattached inodes are invisible to user programs. Making sure that on restart they are fine means either lots more overhead journaling, or running a full scan on restart. jijo> The systems are configured so that hdparm disables write jijo> caching on the drives, [ ... ] That's a good idea, but check it actually works; some drives (especially 2.5" ones) don't support that or just ignore that command... http://WWW.sabi.co.UK/Notes/anno05-3rd.html#050912 jijo> We don't have ECC RAM, though, since these are POS jijo> terminals, not servers. That's a different topic, and a pet peeve of mine: _everybody_ not just servers should use ECC RAM. There are good arguments that even with reliable memory, as soon as it get over around 64MiB things are dangerous, and at least _detection_ of RAM errors should be there (and then parity can then do ECC too). But must PC buyers don't know, so it is hard to find chipsets and motherboards that support it. Bah! jijo> What's the known behavior of XFS as far as not being jijo> properly unmounted on a regular basis is concerned? Just like with any other modern file system, very bad things may happen, more so because of the delayed allocation policy for data blocks. Applications that care about that should indeed use 'fsync' (and perhaps on directories too [I wonder if it is supported] if files are created/deleted) as you say: jijo> I have a number of projects where this is a "way of life" jijo> and where the best thing we can do on the application level jijo> is to issue an fsync() after critical operations, [ ... ] but 'sync' as a mount option is very likely a good idea; no modern (post-MS-DOS/MS-Win 9x) file system is designed to behave well without proper unmounting, except in 'sync' mode. There is a rather important issue for all journaled file systems: how often is the in-memory journal written to disk? With 'ext3' one can use the 'commit' mount parameter to set an interval in seconds, and XFS and JFS are subject instead to the parameters like 'dirty_background_ratio' and 'dirty_ratio' for the kernel 'pdflush' daemon. But even setting the journal writing interval to as low as say 1 second (or equivalent) means that there is a 1 second window of vulnerability, and in on second one can conceivably journal _a lot_ of stuff, and bye-bye if someone powers off the machine at that point. There is probably no way around it other than '-o sync'. From owner-linux-xfs@oss.sgi.com Wed Dec 7 12:07:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 12:07:10 -0800 (PST) Received: from mail.davidb.org (adsl-64-172-240-129.dsl.sndg02.pacbell.net [64.172.240.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB7K77qY012183 for ; Wed, 7 Dec 2005 12:07:07 -0800 Received: from davidb by mail.davidb.org with local (Exim 4.54 #1 (Debian)) id 1Ek5Vl-0001Pq-Ia for ; Wed, 07 Dec 2005 12:03:33 -0800 Date: Wed, 7 Dec 2005 12:03:33 -0800 From: David Brown To: Linux-XFS Mailing List Subject: Re: Filesystem Consistency Issues Message-ID: <20051207200333.GA5279@old.davidb.org> Mail-Followup-To: Linux-XFS Mailing List References: <20051204142506.GE2605@free.net.ph> <17299.32438.100855.316477@base.ty.sabi.co.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17299.32438.100855.316477@base.ty.sabi.co.UK> User-Agent: Mutt/1.5.11 X-archive-position: 6719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@davidb.org Precedence: bulk X-list: linux-xfs Content-Length: 625 Lines: 16 On Sun, Dec 04, 2005 at 11:41:42PM +0000, Peter Grandi wrote: > jijo> First, that I had to mount the filesystem (the root > jijo> partition) from a rescue CD for the log replay to "fix" > jijo> things properly. > > IIRC Debian Sarge mounts the root filesystem in a way that for > example does not necessarily trigger the mount count/time based > check. At least it did not happen on my mostly-Sarge PC. The distributions mount count/time checks would only invoke fsck.xfs, which never does anything. It shouldn't be possible to mount the root filesystem without replaying logs, so this is likely to be a real bug. Dave From owner-linux-xfs@oss.sgi.com Wed Dec 7 12:32:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 12:32:11 -0800 (PST) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB7KW7qY019067 for ; Wed, 7 Dec 2005 12:32:07 -0800 Received: from [172.16.82.67] ([172.16.82.67]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 12:28:27 -0800 Message-ID: <439745EB.3050903@xfs.org> Date: Wed, 07 Dec 2005 14:28:27 -0600 From: Steve Lord User-Agent: Thunderbird 1.4.1 (X11/20051006) MIME-Version: 1.0 To: Linux-XFS Mailing List Subject: Re: Filesystem Consistency Issues References: <20051204142506.GE2605@free.net.ph> <17299.32438.100855.316477@base.ty.sabi.co.UK> <20051207200333.GA5279@old.davidb.org> In-Reply-To: <20051207200333.GA5279@old.davidb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2005 20:28:28.0007 (UTC) FILETIME=[C7FACF70:01C5FB6C] X-archive-position: 6720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1195 Lines: 30 David Brown wrote: > On Sun, Dec 04, 2005 at 11:41:42PM +0000, Peter Grandi wrote: > >> jijo> First, that I had to mount the filesystem (the root >> jijo> partition) from a rescue CD for the log replay to "fix" >> jijo> things properly. >> >> IIRC Debian Sarge mounts the root filesystem in a way that for >> example does not necessarily trigger the mount count/time based >> check. At least it did not happen on my mostly-Sarge PC. > > The distributions mount count/time checks would only invoke fsck.xfs, which > never does anything. It shouldn't be possible to mount the root filesystem > without replaying logs, so this is likely to be a real bug. > > Dave > XFS always does a scan of the log on mount, it always replays the log if it is not terminated with an unmount record. The fact that the filesystem is mounted readonly during startup should have no affect on this. XFS will run recovery on a read only mount. On inode unlink, XFS adds inodes to an unlinked inode list until the space in the inode is freed when the last reference count is released. Removing these inodes is part of the recovery process. It sounds like there may be an issue with this part of recovery. Steve From owner-linux-xfs@oss.sgi.com Wed Dec 7 12:58:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 12:58:55 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB7KwkqY021525 for ; Wed, 7 Dec 2005 12:58: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 HAA18045; Thu, 8 Dec 2005 07:55: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 jB7KtHkt7310898; Thu, 8 Dec 2005 07:55:18 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jB7KtD3R7315195; Thu, 8 Dec 2005 07:55:13 +1100 (EST) Date: Thu, 8 Dec 2005 07:55:12 +1100 From: Nathan Scott To: Shlomi Fish Cc: Linux Kernel Mailing List , Linux-IL , linux-xfs@oss.sgi.com Subject: Re: XFS Mount Hangs the Partition (on latest kernel + many old 2.6.x ones) Message-ID: <20051208075512.F7282696@wobbly.melbourne.sgi.com> References: <200512071357.39121.shlomif@iglu.org.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200512071357.39121.shlomif@iglu.org.il>; from shlomif@iglu.org.il on Wed, Dec 07, 2005 at 01:57:38PM +0200 X-archive-position: 6721 X-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: 2946 Lines: 67 On Wed, Dec 07, 2005 at 01:57:38PM +0200, Shlomi Fish wrote: > Hi all! Hi there, > (Please CC me on replies) > > I encountered a problem with the Linux kernel handling of XFS, in which > attempting to mount a certain XFS partition (but not a different one on the > same hard-disk) caused the mount process to hang, and all other XFS-aware > apps (like "xfs_check" or "xfs_repair") to hang too. However, running > xfs_check > or xfs_repair before the first mount (after a reboot) worked, and eventually > resolved this problem. > > I blogged about it (relatively incoherently) here: > > http://www.livejournal.com/~shlomif/7182.html?mode=reply > http://www.livejournal.com/~shlomif/7547.html?mode=reply Unfortunately there's not much information here in your mail or there that would help us to analyse this further. If you see this behaviour again could you: - get sysrq-t information for all hung processes, esp. mount; - send xfs_info output for the filesystem in question; - dump the log (xfs_logprint -C) and send it to us. > It all happened after I detected some problems on my Mandriva 2006 system > (that was using kernel 2.4.15-rc2 from Linus), and then rebooted twice, > thinking something went wrong. Then a loadlin-booted kernel was unable to > load the kernel. > > Knoppix ran fine, but it also hang up on attempting to mount the XFS > partition. It used a much older kernel. I then tried to boot Kubuntu (which > was on another XFS partition on the same disk) and it booted fine. Still, it > was unable to mount the partition. (It too had an older kernel). > > After I compiled a 2.6.14.3 kernel, and booted Kubuntu with it, it again > could not mount the XFS partition, and after doing that xfs_check and > xfs_repair both hanged up as well. After a reboot, I tried running xfs_check This was probably caused by the block device being held open exclusively by the stuck mount process. > right away on that partition and it worked. So I ran xfs_repair, and after it > finished, tried to mount the partition it worked. Then Mandriva booted fine. > > I did not had any problems since then (I have an uptime of 11 days now using > kernel 2.6.14.3), and so it doesn't seem like a hard disk problem. Something > using kernel 2.6.15-rc2 caused the XFS partition to become defected, and > worse - something in all the kernels starting from that of the first official > Kubuntu release, (or the Knoppix I had), caused an attempt to mount the > Mandriva partition to hang the process, and subsequent accesses to the > partition by xfs_check and xfs_repair to fail as well. > > I can no longer reproduce the problem, but it might be worth going over the > code. If it helps I can privately send a dump of the first 131,072,000 bytes > of the XFS partition to someone trustworthy. Thats unlikely to help now - repair will have wiped your log clean, so all evidence of the problem will be gone. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Dec 7 21:43:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 21:43:36 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB85hVqY006652 for ; Wed, 7 Dec 2005 21:43:32 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jB87iipA026986 for ; Wed, 7 Dec 2005 23:44:44 -0800 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 jB85dvOS9854190; Wed, 7 Dec 2005 21:39:57 -0800 (PST) Message-ID: <4397C72E.5010700@sgi.com> Date: Wed, 07 Dec 2005 23:39:58 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Linux-XFS Mailing List Subject: Re: Filesystem Consistency Issues References: <20051204142506.GE2605@free.net.ph> <17299.32438.100855.316477@base.ty.sabi.co.UK> <20051207200333.GA5279@old.davidb.org> <439745EB.3050903@xfs.org> In-Reply-To: <439745EB.3050903@xfs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6726 X-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: 818 Lines: 23 Steve Lord wrote: > XFS always does a scan of the log on mount, it always replays the log if it > is not terminated with an unmount record. The fact that the filesystem is > mounted readonly during startup should have no affect on this. XFS will run > recovery on a read only mount. The only time xfs will not replay the log on mount is if the -block device- itself is readonly; for example a read-only snapshot or... um... maybe a cdrom? :) But Steve is right (of course!) - the "ro" option does not prevent log replay. > On inode unlink, XFS adds inodes to an unlinked inode list until the > space in > the inode is freed when the last reference count is released. Removing > these > inodes is part of the recovery process. It sounds like there may be an > issue > with this part of recovery. Yep. -Eric From owner-linux-xfs@oss.sgi.com Wed Dec 7 23:12:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Dec 2005 23:12:51 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jB87CbqY015037 for ; Wed, 7 Dec 2005 23:12:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02353; Thu, 8 Dec 2005 18:08:56 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jB878inp27865950; Thu, 8 Dec 2005 18:08:44 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jB878fWN27814045; Thu, 8 Dec 2005 18:08:41 +1100 (EST) Date: Thu, 8 Dec 2005 18:08:41 +1100 From: David Chinner To: CHIKAMA masaki Cc: linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller Message-ID: <20051208070841.GJ501696@melbourne.sgi.com> References: <20051207183531.5c13e8c5.masaki-c@nict.go.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051207183531.5c13e8c5.masaki-c@nict.go.jp> User-Agent: Mutt/1.4.2.1i X-archive-position: 6727 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1115 Lines: 43 On Wed, Dec 07, 2005 at 06:35:31PM +0900, CHIKAMA masaki wrote: > Hello all. > > I have trouble about a storange behavior on xfs fileststem. > When I did "chmod -R 755 ." on deep directory, the system became > slow down and began to start OOMkiller after a while. How many files in the directory structure and how deep is it? What is the machine you are running this test on (CPU, ram, etc). > At that time, slabtop showed that the number of xfs_ili, xfs_inode, > and linvfs_icache objects are becoming very large. > > My kernel version is 2.6.13.4. Can you send the output of /proc/meminfo, /proc/slabinfo and the OOM killer output at the time of the problem? > A similar report is found at > http://oss.sgi.com/archives/linux-xfs/2003-03/msg00018.html > > > Is this a expected bihavior? No. > Now I use "find -exec" insted of "chmod -R". > The usage of slab memory with "find" is calm and does not start > OOM killker. The output of the meminfo and slabinfo files under this test would also be interesting.... Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu Dec 8 08:05:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Dec 2005 08:05:50 -0800 (PST) Received: from sa3.bezeqint.net (sa3.bezeqint.net [192.115.104.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB8G5bqY011876 for ; Thu, 8 Dec 2005 08:05:43 -0800 Received: from localhost (unknown [127.0.0.1]) by sa3.bezeqint.net (Bezeq International SMTP out Mail Server) with ESMTP id 4A75633DA8; Thu, 8 Dec 2005 18:02:02 +0200 (IST) Received: from sa3.bezeqint.net ([127.0.0.1]) by localhost (sa3 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19444-02; Thu, 8 Dec 2005 18:01:57 +0200 (IST) Received: from [192.168.1.105] (unknown [82.80.153.71]) by sa3.bezeqint.net (Bezeq International SMTP out Mail Server) with ESMTP; Thu, 8 Dec 2005 18:01:57 +0200 (IST) From: Shlomi Fish To: Nathan Scott Subject: Re: XFS Mount Hangs the Partition (on latest kernel + many old 2.6.x ones) Date: Thu, 8 Dec 2005 17:55:57 +0200 User-Agent: KMail/1.8.2 Cc: Linux Kernel Mailing List , Linux-IL , linux-xfs@oss.sgi.com References: <200512071357.39121.shlomif@iglu.org.il> <20051208075512.F7282696@wobbly.melbourne.sgi.com> In-Reply-To: <20051208075512.F7282696@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: <200512081755.58078.shlomif@iglu.org.il> X-archive-position: 6732 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shlomif@iglu.org.il Precedence: bulk X-list: linux-xfs Content-Length: 3519 Lines: 89 On Wednesday 07 December 2005 22:55, Nathan Scott wrote: > On Wed, Dec 07, 2005 at 01:57:38PM +0200, Shlomi Fish wrote: > > Hi all! > > Hi there, Hi Mr. Scott (and all)! > > > (Please CC me on replies) > > > > I encountered a problem with the Linux kernel handling of XFS, in which > > attempting to mount a certain XFS partition (but not a different one on > > the same hard-disk) caused the mount process to hang, and all other > > XFS-aware apps (like "xfs_check" or "xfs_repair") to hang too. However, > > running xfs_check > > or xfs_repair before the first mount (after a reboot) worked, and > > eventually resolved this problem. > > > > I blogged about it (relatively incoherently) here: > > > > http://www.livejournal.com/~shlomif/7182.html?mode=reply > > http://www.livejournal.com/~shlomif/7547.html?mode=reply > > Unfortunately there's not much information here in your mail or > there that would help us to analyse this further. If you see this > behaviour again could you: > - get sysrq-t information for all hung processes, esp. mount; > - send xfs_info output for the filesystem in question; > - dump the log (xfs_logprint -C) and send it to us. Sure. But in what order should I do all that? > > > It all happened after I detected some problems on my Mandriva 2006 system > > (that was using kernel 2.4.15-rc2 from Linus), and then rebooted twice, > > thinking something went wrong. Then a loadlin-booted kernel was unable to > > load the kernel. > > > > Knoppix ran fine, but it also hang up on attempting to mount the XFS > > partition. It used a much older kernel. I then tried to boot Kubuntu > > (which was on another XFS partition on the same disk) and it booted fine. > > Still, it was unable to mount the partition. (It too had an older > > kernel). > > > > After I compiled a 2.6.14.3 kernel, and booted Kubuntu with it, it again > > could not mount the XFS partition, and after doing that xfs_check and > > xfs_repair both hanged up as well. After a reboot, I tried running > > xfs_check > > This was probably caused by the block device being held open > exclusively by the stuck mount process. I see. > > > right away on that partition and it worked. So I ran xfs_repair, and > > after it finished, tried to mount the partition it worked. Then Mandriva > > booted fine. > > > > I did not had any problems since then (I have an uptime of 11 days now > > using kernel 2.6.14.3), and so it doesn't seem like a hard disk problem. > > Something using kernel 2.6.15-rc2 caused the XFS partition to become > > defected, and worse - something in all the kernels starting from that of > > the first official Kubuntu release, (or the Knoppix I had), caused an > > attempt to mount the Mandriva partition to hang the process, and > > subsequent accesses to the partition by xfs_check and xfs_repair to fail > > as well. > > > > I can no longer reproduce the problem, but it might be worth going over > > the code. If it helps I can privately send a dump of the first > > 131,072,000 bytes of the XFS partition to someone trustworthy. > > Thats unlikely to help now - repair will have wiped your log clean, > so all evidence of the problem will be gone. Yes. I thought one can try looking in the XFS mounting code for possible bugs. Regards, Shlomi Fish --------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%. From owner-linux-xfs@oss.sgi.com Thu Dec 8 09:39:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Dec 2005 09:39:13 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB8Hd8qY023568 for ; Thu, 8 Dec 2005 09:39:08 -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 jB8JePfQ030084 for ; Thu, 8 Dec 2005 11:40:25 -0800 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jB8HYUsL26815682; Thu, 8 Dec 2005 11:34:30 -0600 (CST) Message-ID: <43986EA6.2060207@sgi.com> Date: Thu, 08 Dec 2005 11:34:30 -0600 From: Bill Kendall User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Brown CC: XFS Mailing List Subject: Re: xfsdump timestamp patch. References: <20051207052732.GA22418@old.davidb.org> In-Reply-To: <20051207052732.GA22418@old.davidb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4161 Lines: 136 Thanks David. Looks good, we'll get this incorporated soon. Bill On 12/06/05 23:27, David Brown wrote: > The patch below adds an option to xfsdump to set the timestamp that a > backup will happen based on. This can be used to correct a problem that > occurs in files that are touched after making a snapshot volume. > > For example: > > - make snapshot > - touch a file on r/w volume > - xfsdump the r/o snapshot > - undo the snapshot > > The touched file will not be included in the dump, but since the timestamp > for the backup happens after this file was touched, the file will also not > be included in future incrementals. This can be fixed as follows: > > - touch /tmp/snapstamp > - make snapshot > - xfsdump -t /tmp/snapstamp ... > - undo snapshot > > The '-t' option causes xfsdump to use the timestamp of the named file as > the dump time, rather than the current time. > > Thanks, > David Brown > > Subject: [PATCH] Add '-t' option to allow dump time to be specified. > > --- > > common/global.c | 29 ++++++++++++++++++++++++++++- > common/main.c | 3 +++ > dump/getopt.h | 4 ++-- > 3 files changed, 33 insertions(+), 3 deletions(-) > > applies-to: fac8fc29c114fa28618b82a9f5918ff6b9521f37 > 102ce75c083379636394ec2851b8f07d0610b515 > diff --git a/common/global.c b/common/global.c > index d793175..2e05ef9 100644 > --- a/common/global.c > +++ b/common/global.c > @@ -76,6 +76,9 @@ global_hdr_alloc( intgen_t argc, char *a > #endif /* DUMP */ > > intgen_t rval; > +#ifdef DUMP > + struct stat64 statbuf; > +#endif /* DUMP */ > > /* sanity checks > */ > @@ -96,7 +99,8 @@ global_hdr_alloc( intgen_t argc, char *a > ghdrp->gh_version = GLOBAL_HDR_VERSION; > > /* fill in the timestamp: all changes made at or after this moment > - * will be included in increments on this base. > + * will be included in increments on this base. This may be > + * overridden by the '-t' option. > */ > ghdrp->gh_timestamp = (time32_t) time( 0 ); > > @@ -190,6 +194,29 @@ global_hdr_alloc( intgen_t argc, char *a > ghdrp->gh_version = GLOBAL_HDR_VERSION_0; > break; > #endif /* EXTATTR */ > + case GETOPT_DUMPTIME: > + /* Use the timestamp of the specified file, rather > + * than the current time as the dump time. > + */ > + if ( ! optarg || optarg[ 0 ] == '-' ) { > + mlog( MLOG_NORMAL | MLOG_ERROR, > + _("-%c argument missing\n"), > + optopt ); > + usage( ); > + return 0; > + } > + rval = lstat64( optarg, &statbuf ); > + if ( rval ) { > + mlog( MLOG_NORMAL | MLOG_ERROR, > + _("unable to get status of %s: %s\n"), > + optarg, > + strerror( errno )); > + usage( ); > + return 0; > + } > + ghdrp->gh_timestamp = statbuf.st_mtime; > + break; > + > #endif /* DUMP */ > } > } > diff --git a/common/main.c b/common/main.c > index 3d0b89e..ee53026 100644 > --- a/common/main.c > +++ b/common/main.c > @@ -1102,6 +1102,9 @@ usage( void ) > #ifdef REVEAL > ULO(_("(miniroot restrictions)"), GETOPT_MINIROOT ); > #endif /* REVEAL */ > +#ifdef DUMP > + ULO(_(" (use time of file)"), GETOPT_DUMPTIME ); > +#endif /* DUMP */ > ULN(_("- (stdin)") ); > ULN(_("") ); > #endif /* RESTORE */ > diff --git a/dump/getopt.h b/dump/getopt.h > index 0aeaa7d..df3393e 100644 > --- a/dump/getopt.h > +++ b/dump/getopt.h > @@ -41,7 +41,7 @@ > * facilitating easy changes. > */ > > -#define GETOPT_CMDSTRING "ab:c:d:ef:hl:mop:qs:v:z:AB:CEFG:H:I:JL:M:NO:PRSTUVWY:Z" > +#define GETOPT_CMDSTRING "ab:c:d:ef:hl:mop:qs:t:v:z:AB:CEFG:H:I:JL:M:NO:PRSTUVWY:Z" > > #define GETOPT_DUMPASOFFLINE 'a' /* dump DMF dualstate files as offline */ > #define GETOPT_BLOCKSIZE 'b' /* blocksize for rmt */ > @@ -62,7 +62,7 @@ > #define GETOPT_QIC 'q' /* option to tell dump it's a QIC tape */ > /* 'r' */ > #define GETOPT_SUBTREE 's' /* subtree dump (content_inode.c) */ > -/* 't' */ > +#define GETOPT_DUMPTIME 't' /* use stat of file as dump time. */ > /* 'u' */ > #define GETOPT_VERBOSITY 'v' /* verbosity level (0 to 4 ) */ > /* 'w' */ > --- > 0.99.9j > From owner-linux-xfs@oss.sgi.com Thu Dec 8 17:45:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Dec 2005 17:45:47 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jB91jemq025392 for ; Thu, 8 Dec 2005 17:45:41 -0800 Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id jB91fnWn005922; Fri, 9 Dec 2005 10:41:49 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id jB91fnxS019068; Fri, 9 Dec 2005 10:41:49 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id jB91fnWk019065; Fri, 9 Dec 2005 10:41:49 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 0A4586E39; Fri, 9 Dec 2005 10:41:49 +0900 (JST) Received: from nabal.nict.go.jp (unknown [133.243.93.85]) by mail2.nict.go.jp (Postfix) with SMTP id 9B09F6E23; Fri, 9 Dec 2005 10:41:48 +0900 (JST) Date: Fri, 9 Dec 2005 10:41:48 +0900 From: CHIKAMA masaki To: David Chinner Cc: linux-xfs@oss.sgi.com Subject: Re: deep chmod|chown -R begin to start OOMkiller Message-Id: <20051209104148.346f2ff5.masaki-c@nict.go.jp> In-Reply-To: <20051208070841.GJ501696@melbourne.sgi.com> References: <20051207183531.5c13e8c5.masaki-c@nict.go.jp> <20051208070841.GJ501696@melbourne.sgi.com> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__9_Dec_2005_10_41_48_+0900_DWHQvOvO8oKCjIHX" X-archive-position: 6738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masaki-c@nict.go.jp Precedence: bulk X-list: linux-xfs Content-Length: 41064 Lines: 552 This is a multi-part message in MIME format. --Multipart=_Fri__9_Dec_2005_10_41_48_+0900_DWHQvOvO8oKCjIHX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello. On Thu, 8 Dec 2005 18:08:41 +1100 David Chinner wrote: > > I have trouble about a storange behavior on xfs fileststem. > > When I did "chmod -R 755 ." on deep directory, the system became > > slow down and began to start OOMkiller after a while. > > How many files in the directory structure and how deep is it? > > What is the machine you are running this test on (CPU, ram, > etc). The directory structure is like this. A/B/C/D/E/F.jpg A: from "1" to "14" B: from "0" to "16" C: "00" D: from "0" to "6" E: from "0" to "255" F: from "0" to "255" The number of files should be around 100 millions. Machine spec. CPU : Pentium4 3.0G (512KB chache) HT enabled MEM : 512MB (+ 1GB swap) SCSI HA: Adaptec AHA-3960D DISK: External RAID unit (10TB) filesystem: xfs on lvm2 > > At that time, slabtop showed that the number of xfs_ili, xfs_inode, > > and linvfs_icache objects are becoming very large. > > > > My kernel version is 2.6.13.4. > > Can you send the output of /proc/meminfo, /proc/slabinfo > and the OOM killer output at the time of the problem? I can't send these infos at the moment of OOM killer starting. But I'll send a close situation's info in which swap I/O happened. Because I think it's also strange and this will trigger of OOM killer. procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- 0 0 47472 13236 322668 18812 0 0 0 0 271 36 0 0 100 0 0 0 47472 13236 322668 18812 0 0 0 8 253 24 0 0 100 0 (start chmod -R) 0 1 47472 14004 312156 22304 0 0 3476 2048 821 1365 1 11 84 3 1 0 47472 14432 294144 27588 0 0 6588 3704 1294 2770 1 25 66 8 1 0 47472 13524 277672 33400 0 0 6092 3264 1219 2303 1 22 72 4 0 0 47472 13396 261832 38840 0 0 5584 3168 1133 2271 1 21 74 3 .... 3 1 64796 10452 166856 8136 0 0 4860 3096 1484 4041 0 12 29 58 2 3 64796 10568 166840 7372 0 0 880 648 505 972 0 6 5 88 1 5 64816 10592 166860 6544 472 572 5948 3304 1812 4025 0 14 6 80 0 5 64812 10284 166900 8240 1196 304 13196 8416 2940 8380 0 23 6 70 (around here that I got meminfo and slabinfo attached) 0 6 64812 10284 166864 6844 432 0 1456 604 574 1176 0 6 1 94 0 8 64812 10388 166852 6588 68 52 1244 916 673 1414 0 10 2 88 0 6 64816 10936 166872 6720 1032 368 7948 4568 1921 5235 0 30 2 68 0 10 64816 10368 166872 6644 396 0 2364 1016 625 1475 0 10 2 88 0 9 64812 10244 166880 6936 1300 236 9992 5308 2045 5798 1 25 0 74 The attached OOM killer output is previous one that I got. > > A similar report is found at > > http://oss.sgi.com/archives/linux-xfs/2003-03/msg00018.html > > > > > > Is this a expected bihavior? > > No. Ok. Thanks. > > Now I use "find -exec" insted of "chmod -R". > > The usage of slab memory with "find" is calm and does not start > > OOM killker. > > The output of the meminfo and slabinfo files under this test > would also be interesting.... I also attached. Best regard. Thanks. -- CHIKAMA Masaki @ NICT --Multipart=_Fri__9_Dec_2005_10_41_48_+0900_DWHQvOvO8oKCjIHX Content-Type: text/plain; name="meminfo.chmod.txt" Content-Disposition: attachment; filename="meminfo.chmod.txt" Content-Transfer-Encoding: 7bit MemTotal: 514428 kB MemFree: 54232 kB Buffers: 166988 kB Cached: 22868 kB SwapCached: 4364 kB Active: 96672 kB Inactive: 97924 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 514428 kB LowFree: 54232 kB SwapTotal: 1048568 kB SwapFree: 983884 kB Dirty: 0 kB Writeback: 0 kB Mapped: 8160 kB Slab: 254960 kB CommitLimit: 1305780 kB Committed_AS: 119648 kB PageTables: 2104 kB VmallocTotal: 509944 kB VmallocUsed: 6308 kB VmallocChunk: 502944 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB --Multipart=_Fri__9_Dec_2005_10_41_48_+0900_DWHQvOvO8oKCjIHX Content-Type: text/plain; name="meminfo.find.txt" Content-Disposition: attachment; filename="meminfo.find.txt" Content-Transfer-Encoding: 7bit MemTotal: 514428 kB MemFree: 23944 kB Buffers: 168316 kB Cached: 121380 kB SwapCached: 8524 kB Active: 155000 kB Inactive: 144112 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 514428 kB LowFree: 23944 kB SwapTotal: 1048568 kB SwapFree: 984204 kB Dirty: 8 kB Writeback: 0 kB Mapped: 11504 kB Slab: 179888 kB CommitLimit: 1305780 kB Committed_AS: 120132 kB PageTables: 2132 kB VmallocTotal: 509944 kB VmallocUsed: 6308 kB VmallocChunk: 502944 kB HugePages_Total: 0 HugePages_Free: 0 Hugepa