From owner-xfs@oss.sgi.com Sat Jul 1 08:05:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Jul 2006 08:05:38 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k61F5NDW012478 for ; Sat, 1 Jul 2006 08:05:23 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Fwg5m-0005UC-HP for linux-xfs@oss.sgi.com; Sat, 01 Jul 2006 16:05:02 +0200 Received: from 0x50a5b872.bynxx12.adsl-dhcp.tele.dk ([80.165.184.114]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Jul 2006 16:05:02 +0200 Received: from asjo by 0x50a5b872.bynxx12.adsl-dhcp.tele.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Jul 2006 16:05:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: asjo@koldfront.dk (Adam =?iso-8859-1?Q?Sj=F8gren?=) Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Date: Sat, 01 Jul 2006 16:02:35 +0200 Organization: koldfront - analysis & revolution, Copenhagen, Denmark Message-ID: <87veqhfmo4.fsf@topper.koldfront.dk> References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> <20060620164338.A1080488@wobbly.melbourne.sgi.com> <3aa654a40606192350w5c469670t466dfc1344e23a4@mail.gmail.com> <20060620165209.C1080488@wobbly.melbourne.sgi.com> <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com> <20060622125640.C1135236__28424.0987770774$1150945513$gmane$org@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 0x50a5b872.bynxx12.adsl-dhcp.tele.dk X-Face: )qY&CseJ?.:=8F#^~GcSA?F=9eu'{KAFfL1C3/A&:nE?PW\i65"ba0NS)97,Q(^@xk}n4Ou rPuR#V8I(J_@~H($[ym:`K_+]*kjvW>xH5jbgLBVFGXY:(#4P>zVBklLbdL&XxL\M)%T}3S/IS9lMJ ^St'=VZBR On Tue, Jun 20, 2006 at 01:20:39AM -0700, Avuton Olrich wrote: >> fatal error -- can't read block 16777216 for directory inode >> 1507133580 I got the same error on my desktop (Mac Mini PPC, 73GB XFS filesystem, Debian unstable) when running xfs_repair after having problems booting (filesystem shutdown leading to init not being able to start gettys and stuff, I guess): fatal error -- can't read block 1677216 for directory inode 77860837 So I tried this advice (unfortunately I do not have space for taking a copy of the filesystem for analysis): > Once you save a copy of it for further analysis of xfs_repair, > if you can, you can clear out this problem by directly poking at > the device using xfs_db in expert mode. "xfs_db -x /dev/xxx"; > then "inode 1507133580"; then "write core.mode 0"; and then try > another xfs_repair run. The subsequent xfs_repair run gave different, expected I guess, output (it noticed the modified directory inode and stuff), but at the end of Phase 7, it said: cache_purge: share on cache 0x100930b0 left 1 nodes!? cache_purge: share on cache 0x100930b0 left 1 nodes!? done So, I ran xfs_check on it. The output then was: bad directory data magic # 0x30 for dir ino 180 block 8388608 I proceeded to run xfs_repair. In Phase 3 under '- agno 0' it said: bad dir magic number 0x30 in inode 180 bno = 8388608 It continued and in Phase 6 after saying '- traversing filesystem starting at / ...' it said: rebuilding directory inode 128 And a flurry of "disconnected inode [number], moving to lost+found" followed. At the end of Phase 7, I got the two lines: cache_purge: share on cache 0x100930b0 left 1 nodes!? cache_purge: share on cache 0x100930b0 left 1 nodes!? again. Running xfs_repair another time gives the same output/result. (I did this by booting from a Debian unstable net-install cd and using the xfs_repair, _check and _db from xfsprogs_2.8.4-1_powerpc.deb) Any hints on how to fully repair the filesystem, in place? Best regards, Adam -- "Jag tar en mandarin." Adam Sjøgren asjo@koldfront.dk From owner-xfs@oss.sgi.com Mon Jul 3 09:26:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 09:26:13 -0700 (PDT) Received: from stargate.synerway.com (stargate.synerway.com [84.14.10.249]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k63GPvDW017989 for ; Mon, 3 Jul 2006 09:26:02 -0700 Received: from stargate.synerway.com (stargate.synerway.com [127.0.0.1]) by stargate.synerway.com (Postfix) with ESMTP id 0F5EC454091 for ; Mon, 3 Jul 2006 17:30:24 +0200 (CEST) Received: from venus (unknown [172.16.10.150]) by stargate.synerway.com (Postfix) with ESMTP id 029F0454090 for ; Mon, 3 Jul 2006 17:30:23 +0200 (CEST) Received: by venus (Postfix, from userid 1005) id A1953898B3; Mon, 3 Jul 2006 19:18:26 +0200 (CEST) Date: Mon, 3 Jul 2006 19:18:26 +0200 From: Pascal GREGIS To: linux-xfs@oss.sgi.com Subject: determining sunit Message-ID: <20060703171826.GA1267@venus.synerway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.1i X-archive-position: 8083 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pgs@synerway.com Precedence: bulk X-list: xfs Content-Length: 879 Lines: 17 Hello, I am using an XFS filesystem on a Linux box (kernel é.6) on an underlying hardware RAID controller. I am trying to improve the preformance of the XFS filesystem and I read many times that setting the sunit and swidth parameters could improve it significantly. The problem is that I didn't find any explanation on how to determine the values to assign to sunit and swidth. So I am in the incapacity to test my XFS with values for sunit and swidth that make any sense. My RAID is a hardware RAID-5 with 12 disks of 500 GB, so 11 * 500 GB of total capacity. Could anyone be kind enough to explain me how to determine these values? I have a second problem (if it's not toomuch at a time), mount doesn't seem to recognize the options sunit and swidth, I can only set them at filesystem creation, which is not my preference. Thanks in advance for your answer(s). Pascal From owner-xfs@oss.sgi.com Mon Jul 3 15:51:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 15:52:10 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k63MpQDW001226 for ; Mon, 3 Jul 2006 15:51:38 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13392; Tue, 4 Jul 2006 08:50:50 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k63Molgw1490174; Tue, 4 Jul 2006 08:50:47 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k63Mojec1492873; Tue, 4 Jul 2006 08:50:45 +1000 (EST) Date: Tue, 4 Jul 2006 08:50:44 +1000 From: Nathan Scott To: Hungerburg Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: thank you, xfs team Message-ID: <20060704085044.B1462688@wobbly.melbourne.sgi.com> References: <20060703221117.GA27898@lazy.shacknet.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060703221117.GA27898@lazy.shacknet.nu>; from lklm@lazy.shacknet.nu on Tue, Jul 04, 2006 at 12:11:17AM +0200 X-archive-position: 8086 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 950 Lines: 33 On Tue, Jul 04, 2006 at 12:11:17AM +0200, Hungerburg wrote: > hello there, > > I hope this is not the wrong place, yet I have to write this now, before > I forget about it: xfs@oss.sgi.com is the best place. > I had to swap a dying harddrive. after receiving many mails from the > smart daemon, recent kernel patches to xfs made me aware of the full > extent of the problem. Hmm, the second part of that sentence doesn't make sense to me. > keywords: > - XFS internal error XFS_WANT_CORRUPTED_RETURN > - Device: /dev/hda, 1 Currently unreadable (pending) sectors > - Device: /dev/hda, 1 Offline uncorrectable sectors This looks like expected behaviour - XFS shut down the filesystem on detecting IO errors on filesystem metadata blocks. > the tools to copy what is still there (data) are a boon - they require > some reading, but the thing is doable (xfs_copy to good disk, then > xfs_dump from there) OK, good to hear. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 3 17:15:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 17:16:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k640FcDW020040 for ; Mon, 3 Jul 2006 17:15:49 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15073; Tue, 4 Jul 2006 10:14:59 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k640Etgw1492113; Tue, 4 Jul 2006 10:14:56 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k640EpZQ1493248; Tue, 4 Jul 2006 10:14:51 +1000 (EST) Date: Tue, 4 Jul 2006 10:14:51 +1000 From: Nathan Scott To: Pascal GREGIS Cc: linux-xfs@oss.sgi.com Subject: Re: determining sunit Message-ID: <20060704101451.G1462688@wobbly.melbourne.sgi.com> References: <20060703171826.GA1267@venus.synerway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060703171826.GA1267@venus.synerway.com>; from pgs@synerway.com on Mon, Jul 03, 2006 at 07:18:26PM +0200 X-archive-position: 8087 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 551 Lines: 15 On Mon, Jul 03, 2006 at 07:18:26PM +0200, Pascal GREGIS wrote: > The problem is that I didn't find any explanation on how to determine > the values to assign to sunit and swidth. So I am in the incapacity to > test my XFS with values for sunit and swidth that make any sense. Did mkfs.xfs(8) not help? Also search the list archive, this has come up and been answered before, by Dave most recently. I guess this is getting pretty close to requiring a FAQ entry, if anyone has the time... (some diagrams would be good I guess). cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 3 17:41:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 17:41:56 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k640fdDW022736 for ; Mon, 3 Jul 2006 17:41:39 -0700 Received: by nf-out-0910.google.com with SMTP id a25so858970nfc for ; Mon, 03 Jul 2006 17:41:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=J+wRG5hFvp3ZUy182u0rF6/QmLpFyBoSGgR2L4a22PofrP12FWYUgEPsDOxFcgLCQ1IeLuZKxiFdWz8VSCohoL8d+LmdBg9P1nsiNLwf9t42wGl2mLLQHltqIFfP9F6iEUcduDK2+k+lAJhrNhJCYWt+HOtsRL28MT1XBiJpecU= Received: by 10.49.31.14 with SMTP id i14mr2849423nfj; Mon, 03 Jul 2006 17:41:19 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id l22sm3702271nfc.2006.07.03.17.41.18; Mon, 03 Jul 2006 17:41:19 -0700 (PDT) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Tue, 4 Jul 2006 04:41:18 +0400 (MSD) Date: Tue, 4 Jul 2006 04:41:16 +0400 From: Alexey Dobriyan To: Ingo Molnar Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704004116.GA7612@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 8088 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: xfs Content-Length: 1336 Lines: 37 2.6.17-912b2539e1e062cec73e2e61448e507f7719bd08 While trying to remove 2 small files, 2 empty dirs and 1 empty dir on xfs partition ============================================= [ INFO: possible recursive locking detected ] --------------------------------------------- rm/7596 is trying to acquire lock: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x6e but task is already holding lock: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x6e other info that might help us debug this: 3 locks held by rm/7596: #0: (&inode->i_mutex/1){--..}, at: [] do_rmdir+0x6c/0xc3 #1: (&inode->i_mutex){--..}, at: [] mutex_lock+0x8/0xa #2: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x6e stack backtrace: [] show_trace+0xd/0xf [] dump_stack+0x17/0x19 [] print_deadlock_bug+0x94/0x9e [] check_deadlock+0x3e/0x52 [] __lock_acquire+0x747/0x7ea [] lock_acquire+0x5e/0x7e [] down_write+0x19/0x33 [] xfs_ilock+0x4d/0x6e [] xfs_lock_dir_and_entry+0x8e/0xc8 [] xfs_rmdir+0x1ce/0x3c9 [] xfs_vn_rmdir+0x1c/0x44 [] vfs_rmdir+0x5c/0x92 [] do_rmdir+0x8c/0xc3 [] sys_rmdir+0x10/0x12 [] syscall_call+0x7/0xb From owner-xfs@oss.sgi.com Mon Jul 3 18:26:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 18:26:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k641PqDW028230 for ; Mon, 3 Jul 2006 18:26:03 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16808; Tue, 4 Jul 2006 11:25:15 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k641P9gw1497735; Tue, 4 Jul 2006 11:25:10 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k641P3kP1492619; Tue, 4 Jul 2006 11:25:03 +1000 (EST) Date: Tue, 4 Jul 2006 11:25:03 +1000 From: Nathan Scott To: Alexey Dobriyan , Ingo Molnar , Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704112503.H1495869@wobbly.melbourne.sgi.com> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060704011858.GG1605@parisc-linux.org>; from matthew@wil.cx on Mon, Jul 03, 2006 at 07:18:58PM -0600 X-archive-position: 8089 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 623 Lines: 19 On Mon, Jul 03, 2006 at 07:18:58PM -0600, Matthew Wilcox wrote: > On Tue, Jul 04, 2006 at 04:41:16AM +0400, Alexey Dobriyan wrote: > > 2.6.17-912b2539e1e062cec73e2e61448e507f7719bd08 > > > > While trying to remove 2 small files, 2 empty dirs and 1 empty dir on > > xfs partition > > Probably spurious. xfs_ilock can be called on both the parent and child, > which wouldn't be a deadlock. Hmm... they'd be different inodes though, so different lock addresses in memory - is lockdep taking that into account? Would we need to go annotate xfs_ilock somehow to give better hints to the lockdep code? thanks. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 3 18:48:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 18:48:48 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k641m2DW031182 for ; Mon, 3 Jul 2006 18:48:21 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17288; Tue, 4 Jul 2006 11:47:27 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k641lOgw1496009; Tue, 4 Jul 2006 11:47:25 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k641lLRI1495146; Tue, 4 Jul 2006 11:47:21 +1000 (EST) Date: Tue, 4 Jul 2006 11:47:21 +1000 From: Nathan Scott To: Adam Sj?gren Cc: linux-xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Message-ID: <20060704114721.I1495869@wobbly.melbourne.sgi.com> References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> <20060620164338.A1080488@wobbly.melbourne.sgi.com> <3aa654a40606192350w5c469670t466dfc1344e23a4@mail.gmail.com> <20060620165209.C1080488@wobbly.melbourne.sgi.com> <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com> <20060622125640.C1135236__28424.0987770774$1150945513$gmane$org@wobbly.melbourne.sgi.com> <87veqhfmo4.fsf@topper.koldfront.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87veqhfmo4.fsf@topper.koldfront.dk>; from asjo@koldfront.dk on Sat, Jul 01, 2006 at 04:02:35PM +0200 X-archive-position: 8090 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1382 Lines: 44 On Sat, Jul 01, 2006 at 04:02:35PM +0200, Adam Sj?gren wrote: > On Thu, 22 Jun 2006 12:56:40 +1000, Nathan wrote: > The subsequent xfs_repair run gave different, expected I guess, output > (it noticed the modified directory inode and stuff), but at the end of > Phase 7, it said: > > cache_purge: share on cache 0x100930b0 left 1 nodes!? > cache_purge: share on cache 0x100930b0 left 1 nodes!? > done Thats some diagnostic stuff for us developers. Don't worry about it, its just telling us we have inode refcounting issues which we will have to resolve for a parallel xfs_repair. > ... > I proceeded to run xfs_repair. In Phase 3 under '- agno 0' it said: > > bad dir magic number 0x30 in inode 180 bno = 8388608 > > It continued and in Phase 6 after saying '- traversing filesystem > starting at / ...' it said: > > rebuilding directory inode 128 Thats your root directory. Its being rebuilt due to a lost+found directory being earlier unlinked, most likely. > And a flurry of "disconnected inode [number], moving to lost+found" > followed. Yeah, anything that was in lost+found after the first run, gets put back there each time. > Any hints on how to fully repair the filesystem, in place? It sounds like your filesystem is repaired at this point - you need to fix up (remove) lost+found, and you should get no issues reported thereafter. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 3 19:09:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 19:10:03 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6429QDW001742 for ; Mon, 3 Jul 2006 19:09:37 -0700 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 MAA17732; Tue, 4 Jul 2006 12:08:53 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 108C64A588DC; Tue, 4 Jul 2006 12:08:52 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 954365 - fix some Makefile dependency problems Message-Id: <20060704020852.108C64A588DC@chook.melbourne.sgi.com> Date: Tue, 4 Jul 2006 12:08:52 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-archive-position: 8091 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 4368 Lines: 89 some Makefile dependency fixes Date: Tue Jul 4 12:07:37 AEST 2006 Workarea: chook.melbourne.sgi.com:/home/tes/isms/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26405a acl/include/buildrules - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/buildrules.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - use depend flags for makedepend and if we are not using a .dep file then make the objects depend on the headers. acl/include/builddefs.in - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/builddefs.in.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h - specify platform for depend flags attr/include/buildrules - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/buildrules.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - use depend flags for makedepend and if we are not using a .dep file then make the objects depend on the headers. attr/include/builddefs.in - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/builddefs.in.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h - specify platform for depend flags xfsprogs/include/buildrules - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/buildrules.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - use depend flags for makedepend and if we are not using a .dep file then make the objects depend on the headers. xfsprogs/include/builddefs.in - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h - specify platform for depend flags xfsdump/dump/Makefile - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/Makefile.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Fix up HFILES to include the symlinked headers. Get rid of unneeded dependencies. xfsdump/include/buildrules - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/buildrules.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - use depend flags for makedepend and if we are not using a .dep file then make the objects depend on the headers. xfsdump/include/builddefs.in - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/builddefs.in.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h - specify platform for depend flags xfsdump/restore/Makefile - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/Makefile.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsdump/invutil/Makefile - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/invutil/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h - Fix up HFILES to include the symlinked headers. Get rid of unneeded dependencies. xfstests/include/buildrules - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/include/buildrules.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h - use depend flags for makedepend and if we are not using a .dep file then make the objects depend on the headers. xfstests/include/builddefs.in - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/include/builddefs.in.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - specify platform for depend flags dmapi/VERSION - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/VERSION.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h - bump version# for depend changes dmapi/doc/CHANGES - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/doc/CHANGES.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h - mention depend changes dmapi/include/buildrules - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/include/buildrules.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - use depend flags for makedepend and if we are not using a .dep file then make the objects depend on the headers. dmapi/include/builddefs.in - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/include/builddefs.in.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h - specify platform for depend flags xfsdump/include/buildmacros - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/buildmacros.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - don't have src package or tarball with symlinks From owner-xfs@oss.sgi.com Mon Jul 3 19:18:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 19:18:44 -0700 (PDT) Received: from palinux.external.hp.com (palinux.external.hp.com [192.25.206.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k642IUDW003513 for ; Mon, 3 Jul 2006 19:18:30 -0700 Received: by palinux.external.hp.com (Postfix, from userid 26919) id 50BC4494005; Mon, 3 Jul 2006 19:18:58 -0600 (MDT) Date: Mon, 3 Jul 2006 19:18:58 -0600 From: Matthew Wilcox To: Alexey Dobriyan Cc: Ingo Molnar , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704011858.GG1605@parisc-linux.org> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060704004116.GA7612@martell.zuzino.mipt.ru> User-Agent: Mutt/1.5.9i X-archive-position: 8092 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: xfs Content-Length: 1783 Lines: 46 On Tue, Jul 04, 2006 at 04:41:16AM +0400, Alexey Dobriyan wrote: > 2.6.17-912b2539e1e062cec73e2e61448e507f7719bd08 > > While trying to remove 2 small files, 2 empty dirs and 1 empty dir on > xfs partition Probably spurious. xfs_ilock can be called on both the parent and child, which wouldn't be a deadlock. > ============================================= > [ INFO: possible recursive locking detected ] > --------------------------------------------- > rm/7596 is trying to acquire lock: > (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x6e > > but task is already holding lock: > (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x6e > > other info that might help us debug this: > 3 locks held by rm/7596: > #0: (&inode->i_mutex/1){--..}, at: [] do_rmdir+0x6c/0xc3 > #1: (&inode->i_mutex){--..}, at: [] mutex_lock+0x8/0xa > #2: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x6e > > stack backtrace: > [] show_trace+0xd/0xf > [] dump_stack+0x17/0x19 > [] print_deadlock_bug+0x94/0x9e > [] check_deadlock+0x3e/0x52 > [] __lock_acquire+0x747/0x7ea > [] lock_acquire+0x5e/0x7e > [] down_write+0x19/0x33 > [] xfs_ilock+0x4d/0x6e > [] xfs_lock_dir_and_entry+0x8e/0xc8 > [] xfs_rmdir+0x1ce/0x3c9 > [] xfs_vn_rmdir+0x1c/0x44 > [] vfs_rmdir+0x5c/0x92 > [] do_rmdir+0x8c/0xc3 > [] sys_rmdir+0x10/0x12 > [] syscall_call+0x7/0xb > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html From owner-xfs@oss.sgi.com Mon Jul 3 20:15:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 20:16:18 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k643FgDW010959 for ; Mon, 3 Jul 2006 20:15:52 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k643FEnx031022 for ; Mon, 3 Jul 2006 22:15:14 -0500 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 k645dVSN026691 for ; Mon, 3 Jul 2006 22:39:31 -0700 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 k643EanB44519029; Mon, 3 Jul 2006 20:14:37 -0700 (PDT) Message-ID: <44A9DD1C.6050705@sgi.com> Date: Mon, 03 Jul 2006 22:14:36 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Chris Wedgwood CC: ORI IDAN , xfs@oss.sgi.com Subject: Re: Snapshot in XFS References: <20060627135402.C91D22580B4@mail.wietec.com> <20060628065523.GA1045@tuatara.stupidest.org> In-Reply-To: <20060628065523.GA1045@tuatara.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8093 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: xfs Content-Length: 305 Lines: 13 Chris Wedgwood wrote: > On Tue, Jun 27, 2006 at 04:53:42PM +0200, ORI IDAN wrote: > >> 3. If not, is it possible to reduce the freeze time, and what is the >> minimum time? > > if you fsync before the freeze does that help? > Presumably then you'd wait about as long for the sync to return :) -Eric From owner-xfs@oss.sgi.com Mon Jul 3 22:14:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 22:14:59 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k645EcDW030717 for ; Mon, 3 Jul 2006 22:14:39 -0700 Received: (qmail 75378 invoked from network); 4 Jul 2006 05:14:19 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 4 Jul 2006 05:14:18 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id A2E521812D3B; Mon, 3 Jul 2006 22:14:17 -0700 (PDT) Date: Mon, 3 Jul 2006 22:14:17 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: ORI IDAN , xfs@oss.sgi.com Subject: Re: Snapshot in XFS Message-ID: <20060704051417.GA22365@tuatara.stupidest.org> References: <20060627135402.C91D22580B4@mail.wietec.com> <20060628065523.GA1045@tuatara.stupidest.org> <44A9DD1C.6050705@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A9DD1C.6050705@sgi.com> X-archive-position: 8094 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 380 Lines: 10 On Mon, Jul 03, 2006 at 10:14:36PM -0500, Eric Sandeen wrote: > Presumably then you'd wait about as long for the sync to return :) Except that it would force the write-out of dirty buffers immediately and not prevent new IO's from being submitted during this time. The idea is that (depending on access pattern) there would be less to write out when the actual freeze occurs. From owner-xfs@oss.sgi.com Mon Jul 3 23:57:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Jul 2006 23:57:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k646uqDW010887 for ; Mon, 3 Jul 2006 23:57:04 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23941; Tue, 4 Jul 2006 16:56:17 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k646uBgw1503077; Tue, 4 Jul 2006 16:56:12 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k646u5Y11503100; Tue, 4 Jul 2006 16:56:05 +1000 (EST) Date: Tue, 4 Jul 2006 16:56:05 +1000 From: Nathan Scott To: Ingo Molnar Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704165605.B1497438@wobbly.melbourne.sgi.com> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060704063225.GA2752@elte.hu>; from mingo@elte.hu on Tue, Jul 04, 2006 at 08:32:26AM +0200 X-archive-position: 8095 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1534 Lines: 38 On Tue, Jul 04, 2006 at 08:32:26AM +0200, Ingo Molnar wrote: > > * Nathan Scott wrote: > > > > > While trying to remove 2 small files, 2 empty dirs and 1 empty dir > > > > on xfs partition > > > > > > Probably spurious. xfs_ilock can be called on both the parent and > > > child, which wouldn't be a deadlock. > > > > Hmm... they'd be different inodes though, so different lock addresses > > in memory - is lockdep taking that into account? Would we need to go > > annotate xfs_ilock somehow to give better hints to the lockdep code? > > correct, lockdep has to be taught about relations between locks within > the same lock-class. (it detects relations between different > lock-classes automatically) It's usually a straightforward process. > > In this particular case we probably need to do something similar to the > VFS's 'enum inode_i_mutex_lock_class' subclass categorizations: we need > xfs_ilock_nested(.., subclass), where in xfs_lock_dir_and_entry() we'd > pass in ILOCK_PARENT. [normal locking calls have a default subclass ID > of 0] > > I suspect simply creating an XFS filesystem and doing a couple of VFS > ops on it should trigger these locking patterns? Yep, looks like its really easy to trigger - I pulled Linus' tree, enabled everything I could see that looked lockdep related and I immediately saw warnings during bootup... that was with an XFS root, should be able to hit it pretty quickly with any simple filesystem interaction though (root or not). cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 4 01:46:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 01:47:22 -0700 (PDT) Received: from mx3.mail.elte.hu (mx3.mail.elte.hu [157.181.1.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k648keDW003934 for ; Tue, 4 Jul 2006 01:46:45 -0700 Received: from chiara.elte.hu ([157.181.151.252]) by mx3.mail.elte.hu with esmtp (Exim) id 1FxgXu-0005BO-Ko from ; Tue, 04 Jul 2006 10:46:15 +0200 Received: by chiara.elte.hu (Postfix, from userid 17806) id B6AA81FC2; Tue, 4 Jul 2006 10:46:15 +0200 (CEST) Date: Tue, 4 Jul 2006 10:41:43 +0200 From: Ingo Molnar To: Nathan Scott Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704084143.GA12931@elte.hu> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060704063225.GA2752@elte.hu> User-Agent: Mutt/1.4.2.1i Received-SPF: softfail (mx3: transitioning domain of elte.hu does not designate 157.181.151.252 as permitted sender) client-ip=157.181.151.252; envelope-from=mingo@elte.hu; helo=chiara.elte.hu; X-ELTE-SpamScore: 0.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.1 required=5.9 tests=AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] 0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean X-archive-position: 8096 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingo@elte.hu Precedence: bulk X-list: xfs Content-Length: 6573 Lines: 227 * Ingo Molnar wrote: > > > > While trying to remove 2 small files, 2 empty dirs and 1 empty dir > > > > on xfs partition > > > > > > Probably spurious. xfs_ilock can be called on both the parent and > > > child, which wouldn't be a deadlock. > > > > Hmm... they'd be different inodes though, so different lock addresses > > in memory - is lockdep taking that into account? Would we need to go > > annotate xfs_ilock somehow to give better hints to the lockdep code? > > correct, lockdep has to be taught about relations between locks within > the same lock-class. (it detects relations between different > lock-classes automatically) It's usually a straightforward process. > > In this particular case we probably need to do something similar to > the VFS's 'enum inode_i_mutex_lock_class' subclass categorizations: we > need xfs_ilock_nested(.., subclass), where in xfs_lock_dir_and_entry() > we'd pass in ILOCK_PARENT. [normal locking calls have a default > subclass ID of 0] the patch below should solve the case mentioned above, but i'm sure there will be other cases as well. XFS locking seems quite complex all around. All this dynamic flag-passing into an opaque function (such as xfs_ilock), just to have them untangled in xfs_ilock(): if (lock_flags & XFS_IOLOCK_EXCL) { mrupdate(&ip->i_iolock); } else if (lock_flags & XFS_IOLOCK_SHARED) { mraccess(&ip->i_iolock); } if (lock_flags & XFS_ILOCK_EXCL) { mrupdate(&ip->i_lock); } else if (lock_flags & XFS_ILOCK_SHARED) { mraccess(&ip->i_lock); } is pretty inefficient too - there are 85 calls to xfs_ilock(), and 74 of them have static flags. Also, mrunlock() does: static inline void mrunlock(mrlock_t *mrp) { if (mrp->mr_writer) { mrp->mr_writer = 0; up_write(&mrp->mr_lock); } else { up_read(&mrp->mr_lock); } } while xfs_iunlock() knows whether the release is for read or for write! So ->mr_writer seems like a totally unnecessary layer. In fact basically all codepaths should be well aware of whether they locked the inode for read or for write. i'd really suggest to clean this up and to convert: xfs_ilock(ip, XFS_ILOCK_EXCL); to: down_write(&ip->i_lock); and: xfs_iunlock(ip, XFS_ILOCK_EXCL); to: up_write(&ip->i_lock); and eliminate all those layers of indirection. Ingo --- fs/xfs/linux-2.6/mrlock.h | 33 +++++++++++++++++++++++++++++++++ fs/xfs/xfs_iget.c | 12 ++++++++---- fs/xfs/xfs_inode.h | 3 ++- fs/xfs/xfs_vnodeops.c | 8 ++++---- 4 files changed, 47 insertions(+), 9 deletions(-) Index: linux/fs/xfs/linux-2.6/mrlock.h =================================================================== --- linux.orig/fs/xfs/linux-2.6/mrlock.h +++ linux/fs/xfs/linux-2.6/mrlock.h @@ -27,12 +27,33 @@ typedef struct { int mr_writer; } mrlock_t; +/* + * ilock nesting subclasses for the lock validator: + * + * 0: the object of the current VFS operation + * 1: parent + * 2: child/target + * 3: quota file + * + * The locking order between these classes is + * parent -> child -> normal -> quota + */ +enum xfs_ilock_class +{ + ILOCK_NORMAL, + ILOCK_PARENT, + ILOCK_CHILD, + ILOCK_QUOTA +}; + #define mrinit(mrp, name) \ do { (mrp)->mr_writer = 0; init_rwsem(&(mrp)->mr_lock); } while (0) #define mrlock_init(mrp, t,n,s) mrinit(mrp, n) #define mrfree(mrp) do { } while (0) #define mraccess(mrp) mraccessf(mrp, 0) +#define mraccess_nested(mrp, s) mraccessf_nested(mrp, 0, s) #define mrupdate(mrp) mrupdatef(mrp, 0) +#define mrupdate_nested(mrp, s) mrupdatef_nested(mrp, 0, s) static inline void mraccessf(mrlock_t *mrp, int flags) { @@ -45,6 +66,18 @@ static inline void mrupdatef(mrlock_t *m mrp->mr_writer = 1; } +static inline void mraccessf_nested(mrlock_t *mrp, int flags, int subclass) +{ + down_read_nested(&mrp->mr_lock, subclass); +} + +static inline void mrupdatef_nested(mrlock_t *mrp, int flags, int subclass) +{ + down_write_nested(&mrp->mr_lock, subclass); + mrp->mr_writer = 1; +} + + static inline int mrtryaccess(mrlock_t *mrp) { return down_read_trylock(&mrp->mr_lock); Index: linux/fs/xfs/xfs_iget.c =================================================================== --- linux.orig/fs/xfs/xfs_iget.c +++ linux/fs/xfs/xfs_iget.c @@ -859,10 +859,14 @@ xfs_ilock(xfs_inode_t *ip, } else if (lock_flags & XFS_IOLOCK_SHARED) { mraccess(&ip->i_iolock); } - if (lock_flags & XFS_ILOCK_EXCL) { - mrupdate(&ip->i_lock); - } else if (lock_flags & XFS_ILOCK_SHARED) { - mraccess(&ip->i_lock); + if (lock_flags & XFS_ILOCK_EXCL_PARENT) + mrupdate_nested(&ip->i_lock, ILOCK_PARENT); + else { + if (lock_flags & XFS_ILOCK_EXCL) { + mrupdate(&ip->i_lock); + } else if (lock_flags & XFS_ILOCK_SHARED) { + mraccess(&ip->i_lock); + } } xfs_ilock_trace(ip, 1, lock_flags, (inst_t *)__return_address); } Index: linux/fs/xfs/xfs_inode.h =================================================================== --- linux.orig/fs/xfs/xfs_inode.h +++ linux/fs/xfs/xfs_inode.h @@ -352,11 +352,12 @@ typedef struct xfs_inode { #define XFS_SIZE_TOKEN_WR (XFS_SIZE_TOKEN_RD | XFS_WILLLEND) #define XFS_EXTSIZE_WR (XFS_EXTSIZE_RD | XFS_WILLLEND) /* XFS_SIZE_TOKEN_WANT 0x200 */ +#define XFS_ILOCK_EXCL_PARENT 0x400 #define XFS_LOCK_MASK \ (XFS_IOLOCK_EXCL | XFS_IOLOCK_SHARED | XFS_ILOCK_EXCL | \ XFS_ILOCK_SHARED | XFS_EXTENT_TOKEN_RD | XFS_SIZE_TOKEN_RD | \ - XFS_WILLLEND) + XFS_WILLLEND | XFS_ILOCK_EXCL_PARENT) /* * Flags for xfs_iflush() Index: linux/fs/xfs/xfs_vnodeops.c =================================================================== --- linux.orig/fs/xfs/xfs_vnodeops.c +++ linux/fs/xfs/xfs_vnodeops.c @@ -1942,7 +1942,7 @@ xfs_create( goto error_return; } - xfs_ilock(dp, XFS_ILOCK_EXCL); + xfs_ilock(dp, XFS_ILOCK_EXCL_PARENT); XFS_BMAP_INIT(&free_list, &first_block); @@ -2137,7 +2137,7 @@ xfs_lock_dir_and_entry( attempts = 0; again: - xfs_ilock(dp, XFS_ILOCK_EXCL); + xfs_ilock(dp, XFS_ILOCK_EXCL_PARENT); e_inum = ip->i_ino; @@ -2836,7 +2836,7 @@ xfs_mkdir( goto error_return; } - xfs_ilock(dp, XFS_ILOCK_EXCL); + xfs_ilock(dp, XFS_ILOCK_EXCL_PARENT); /* * Check for directory link count overflow. @@ -3385,7 +3385,7 @@ xfs_symlink( goto error_return; } - xfs_ilock(dp, XFS_ILOCK_EXCL); + xfs_ilock(dp, XFS_ILOCK_EXCL_PARENT); /* * Check whether the directory allows new symlinks or not. From owner-xfs@oss.sgi.com Tue Jul 4 02:12:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 02:12:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k649BuDW008192 for ; Tue, 4 Jul 2006 02:12:10 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA26663; Tue, 4 Jul 2006 19:11:12 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k649B6gw1419737; Tue, 4 Jul 2006 19:11:07 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k649B0Mq1465436; Tue, 4 Jul 2006 19:11:00 +1000 (EST) Date: Tue, 4 Jul 2006 19:11:00 +1000 From: Nathan Scott To: Ingo Molnar Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704191100.C1497438@wobbly.melbourne.sgi.com> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060704084143.GA12931@elte.hu>; from mingo@elte.hu on Tue, Jul 04, 2006 at 10:41:43AM +0200 X-archive-position: 8097 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 2088 Lines: 64 On Tue, Jul 04, 2006 at 10:41:43AM +0200, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > the patch below should solve the case mentioned above, but i'm sure > there will be other cases as well. Thanks Ingo! I'll run with this for awhile and see if I can find any other issues. > XFS locking seems quite complex all around. All this dynamic Mhmm. > flag-passing into an opaque function (such as xfs_ilock), just to have > them untangled in xfs_ilock(): > > if (lock_flags & XFS_IOLOCK_EXCL) { > mrupdate(&ip->i_iolock); > } else if (lock_flags & XFS_IOLOCK_SHARED) { > mraccess(&ip->i_iolock); > } > if (lock_flags & XFS_ILOCK_EXCL) { > mrupdate(&ip->i_lock); > } else if (lock_flags & XFS_ILOCK_SHARED) { > mraccess(&ip->i_lock); > } > > is pretty inefficient too - there are 85 calls to xfs_ilock(), and 74 of > them have static flags. Right... but that leaves plenty that don't, and they're not simple to change. There are generic routines that need to be called from different contexts with different locking requirements (xfs_iget). > while xfs_iunlock() knows whether the release is for read or for write! > So ->mr_writer seems like a totally unnecessary layer. In fact basically Hmm, I did look into removing that sometime back, but didn't get there for some reason that escapes me now... (I have a vague memory of the use of downgrade_write messing me up there). I'll take another look when I get some time, it would be beneficial to remove that if we possibly can. > i'd really suggest to clean this up and to convert: > xfs_ilock(ip, XFS_ILOCK_EXCL); > to: > down_write(&ip->i_lock); > and: > xfs_iunlock(ip, XFS_ILOCK_EXCL); > to: > up_write(&ip->i_lock); > and eliminate all those layers of indirection. That would be good, but it doesn't work for all situations unfortunately, and it would loose that debug-kernel sanity checking that we have in there which validates ilock/iolock ordering rules. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 4 02:17:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 02:18:21 -0700 (PDT) Received: from mx3.mail.elte.hu (mx3.mail.elte.hu [157.181.1.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k649HcDW009364 for ; Tue, 4 Jul 2006 02:17:58 -0700 Received: from chiara.elte.hu ([157.181.151.252]) by mx3.mail.elte.hu with esmtp (Exim) id 1Fxh1x-0007dK-Mq from ; Tue, 04 Jul 2006 11:17:17 +0200 Received: by chiara.elte.hu (Postfix, from userid 17806) id 164BB1FC2; Tue, 4 Jul 2006 11:17:19 +0200 (CEST) Date: Tue, 4 Jul 2006 11:12:47 +0200 From: Ingo Molnar To: Nathan Scott Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704091247.GA15982@elte.hu> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060704191100.C1497438@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i Received-SPF: softfail (mx3: transitioning domain of elte.hu does not designate 157.181.151.252 as permitted sender) client-ip=157.181.151.252; envelope-from=mingo@elte.hu; helo=chiara.elte.hu; X-ELTE-SpamScore: 0.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.1 required=5.9 tests=AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5022] 0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean X-archive-position: 8098 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingo@elte.hu Precedence: bulk X-list: xfs Content-Length: 669 Lines: 23 * Nathan Scott wrote: > > i'd really suggest to clean this up and to convert: > > xfs_ilock(ip, XFS_ILOCK_EXCL); > > to: > > down_write(&ip->i_lock); > > and: > > xfs_iunlock(ip, XFS_ILOCK_EXCL); > > to: > > up_write(&ip->i_lock); > > and eliminate all those layers of indirection. > > That would be good, but it doesn't work for all situations > unfortunately, and it would loose that debug-kernel sanity checking > that we have in there which validates ilock/iolock ordering rules. do you have anything in there that spinlock/mutex debugging or lockdep does not catch? If yes then i'll add it to the generic lock debugging code. Ingo From owner-xfs@oss.sgi.com Tue Jul 4 03:02:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 03:03:12 -0700 (PDT) Received: from mx3.mail.elte.hu (mx3.mail.elte.hu [157.181.1.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64A2gDW015965 for ; Tue, 4 Jul 2006 03:02:43 -0700 Received: from chiara.elte.hu ([157.181.151.252]) by mx3.mail.elte.hu with esmtp (Exim) id 1FxhjU-0002gX-SN from ; Tue, 04 Jul 2006 12:02:17 +0200 Received: by chiara.elte.hu (Postfix, from userid 17806) id A910E1FC2; Tue, 4 Jul 2006 12:02:17 +0200 (CEST) Date: Tue, 4 Jul 2006 11:57:43 +0200 From: Ingo Molnar To: Nathan Scott Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704095743.GA21480@elte.hu> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060704191100.C1497438@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i Received-SPF: softfail (mx3: transitioning domain of elte.hu does not designate 157.181.151.252 as permitted sender) client-ip=157.181.151.252; envelope-from=mingo@elte.hu; helo=chiara.elte.hu; X-ELTE-SpamScore: 0.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.1 required=5.9 tests=AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] 0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean X-archive-position: 8099 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingo@elte.hu Precedence: bulk X-list: xfs Content-Length: 1935 Lines: 55 * Nathan Scott wrote: > > flag-passing into an opaque function (such as xfs_ilock), just to have > > them untangled in xfs_ilock(): > > > > if (lock_flags & XFS_IOLOCK_EXCL) { > > mrupdate(&ip->i_iolock); > > } else if (lock_flags & XFS_IOLOCK_SHARED) { > > mraccess(&ip->i_iolock); > > } > > if (lock_flags & XFS_ILOCK_EXCL) { > > mrupdate(&ip->i_lock); > > } else if (lock_flags & XFS_ILOCK_SHARED) { > > mraccess(&ip->i_lock); > > } > > > > is pretty inefficient too - there are 85 calls to xfs_ilock(), and > > 74 of them have static flags. > > Right... but that leaves plenty that don't, and they're not simple to > change. There are generic routines that need to be called from > different contexts with different locking requirements (xfs_iget). the main variation in xfs_iget() is whether we lock the inode read-write, read-only or not at all, correct? (XFS_ILOCK_EXCL, XFS_ILOCK_SHARED and 0) That could be cleaned up the following way: - rename the current xfs_iget() to __xfs_iget() and remove ilock locking from it. - add 3 new APIs: xfs_iget_read(), xfs_iget_write() and xfs_iget_nolock(): - xfs_iget_read() just calls __xfs_iget() and does a down_read() if the inode was looked up successfully. - xfs_iget_write() does the same but with down_write() - xfs_iget_nolock() is just an alias to __xfs_iget(). - update all 13 uses of xfs_iget() to one of the 3 API variants - [ there might be other details i missed, but this seems to be the rough list of things to do. ] NOTE: since the majority (9 out of 13) of xfs_iget() uses are for the 'no lock' variant, this construction of functions, besides making the code more readable, _further_ reduces overhead, because there is no ilock-flags checking overhead in __xfs_iget() anymore. Ingo From owner-xfs@oss.sgi.com Tue Jul 4 05:55:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 05:56:19 -0700 (PDT) Received: from mail.protei.ru (ns.protei.ru [195.239.28.26] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64CtmDW014138 for ; Tue, 4 Jul 2006 05:55:49 -0700 Received: from lab111.protei (lab111 [10.0.0.2]) by mail.protei.ru (Postfix) with ESMTP id EBB3E706E45 for ; Tue, 4 Jul 2006 15:44:17 +0400 (MSD) Received: by lab111.protei (Postfix, from userid 99) id E90629C014FB; Tue, 4 Jul 2006 15:44:17 +0400 (MSD) Received: from [192.168.100.182] (nickolay.protei [192.168.100.182]) by lab111.protei (Postfix) with ESMTP id 677369C014F7 for ; Tue, 4 Jul 2006 15:44:17 +0400 (MSD) Message-ID: <44AA54BB.7040608@protei.ru> Date: Tue, 04 Jul 2006 15:44:59 +0400 From: Nickolay User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: BUG with inode allocating Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8100 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nickolay@protei.ru Precedence: bulk X-list: xfs Content-Length: 831 Lines: 26 Hello. Kernel: 2.4.29 and 2.4.32. root@192_168_15_15:/usr/test$ mkdir test mkdir: cannot create directory `test': No space left on device root@192_168_15_15:/usr/test$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/ram0 30720 26304 4416 86% / /dev/cciss/c0d0p2 1953600 1882788 70812 97% /usr/test root@192_168_15_15:/usr/test$ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/ram0 19408 1400 18008 8% / /dev/cciss/c0d0p2 1095232 815104 280128 75% /usr/test I can delete one small file, and create big file instead. I think, the problem not with the free space, but with the inode allocation. -- Nickolay Vinogradov Protei Reseach and Development Center St.Petersburg, 194044, Russia Tel.: +7 812 449 47 27 From owner-xfs@oss.sgi.com Tue Jul 4 06:08:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 06:09:19 -0700 (PDT) Received: from mx3.mail.elte.hu (mx3.mail.elte.hu [157.181.1.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64D8aDW016175 for ; Tue, 4 Jul 2006 06:08:37 -0700 Received: from chiara.elte.hu ([157.181.151.252]) by mx3.mail.elte.hu with esmtp (Exim) id 1FxkdN-0007mQ-3w from ; Tue, 04 Jul 2006 15:08:09 +0200 Received: by chiara.elte.hu (Postfix, from userid 17806) id 704321FC2; Tue, 4 Jul 2006 15:08:10 +0200 (CEST) Date: Tue, 4 Jul 2006 15:03:38 +0200 From: Ingo Molnar To: Nathan Scott Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060704130338.GA4354@elte.hu> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> <20060704095743.GA21480@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060704095743.GA21480@elte.hu> User-Agent: Mutt/1.4.2.1i Received-SPF: softfail (mx3: transitioning domain of elte.hu does not designate 157.181.151.252 as permitted sender) client-ip=157.181.151.252; envelope-from=mingo@elte.hu; helo=chiara.elte.hu; X-ELTE-SpamScore: 0.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.1 required=5.9 tests=AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5002] 0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean X-archive-position: 8101 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingo@elte.hu Precedence: bulk X-list: xfs Content-Length: 872 Lines: 22 another thing: i have added real 'lock allocation debugging' (CONFIG_DEBUG_LOCK_ALLOC) to the kernel, which covers spinlocks, rwlocks, mutexes and rw-semaphores. It does the following: This feature will check whether any held lock (spinlock, rwlock, mutex or rwsem) is incorrectly freed by the kernel, via any of the memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), vfree(), etc.), whether a live lock is incorrectly reinitialized via spin_lock_init()/mutex_init()/etc., or whether there is any lock held during task exit. so i suspect: fs/xfs/xfs_mount.h:#define AIL_LOCK_DESTROY(x) spinlock_destroy(x) fs/xfs/linux-2.6/spin.h:#define spinlock_destroy(lock) needs to change and we need to implement spinlock_destroy(), a'ka mutex_destroy()? [which i added recently too] Ingo From owner-xfs@oss.sgi.com Tue Jul 4 06:12:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 06:12:27 -0700 (PDT) Received: from stargate.synerway.com (stargate.synerway.com [84.14.10.249]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64DC8DW016893 for ; Tue, 4 Jul 2006 06:12:13 -0700 Received: from stargate.synerway.com (stargate.synerway.com [127.0.0.1]) by stargate.synerway.com (Postfix) with ESMTP id 64D50454091 for ; Tue, 4 Jul 2006 15:22:12 +0200 (CEST) Received: from venus (unknown [172.16.10.150]) by stargate.synerway.com (Postfix) with ESMTP id 56D1B454090 for ; Tue, 4 Jul 2006 15:22:12 +0200 (CEST) Received: by venus (Postfix, from userid 1005) id CADE5898B2; Tue, 4 Jul 2006 17:10:09 +0200 (CEST) Date: Tue, 4 Jul 2006 17:10:09 +0200 From: pgs@synerway.com To: linux-xfs@oss.sgi.com Subject: Re: determining sunit Message-ID: <20060704151009.GA2816@venus.synerway.com> References: <20060703171826.GA1267@venus.synerway.com> <20060704101451.G1462688@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060704101451.G1462688@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8102 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pgs@synerway.com Precedence: bulk X-list: xfs Content-Length: 1453 Lines: 23 Nathan Scott a écrit, le Tue 04 Jul 2006 à 10:14:51AM : > On Mon, Jul 03, 2006 at 07:18:26PM +0200, Pascal GREGIS wrote: > > The problem is that I didn't find any explanation on how to determine > > the values to assign to sunit and swidth. So I am in the incapacity to > > test my XFS with values for sunit and swidth that make any sense. > > Did mkfs.xfs(8) not help? Also search the list archive, this has > come up and been answered before, by Dave most recently. I guess > this is getting pretty close to requiring a FAQ entry, if anyone > has the time... (some diagrams would be good I guess). > > cheers. Unfortunately, it didn't really answer to my question. Maybe it's because I don't know enough about RAID arrays. Well, what I want to know is : how can I know the value to assign to sunit and swidth? All I know at this time for my RAID array is that there are 12 disks of 500 GB, so 11 * 500 GB of usable space (last disk for checksum), and it's not enough to know which value to set to sunit, it seems that sunit must not be equal to the size of one of the disk in my RAID array. I heard here and there about chunk size and stripe size. But I don't know what is the cunk size of a RAID array and how can I know it, (it's not me that bought this RAID array), someone of my company told me that its stripe size was 64k, but are stripe size and chunk size the same? And must sunit be equal to the chunk size? And swidth? Thanks Pascal From owner-xfs@oss.sgi.com Tue Jul 4 06:54:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 06:54:55 -0700 (PDT) Received: from mx1.suse.de (mx1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64DsUDW025053 for ; Tue, 4 Jul 2006 06:54:31 -0700 Received: from Relay1.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 mx1.suse.de (Postfix) with ESMTP id A208FEE72; Tue, 4 Jul 2006 14:43:07 +0200 (CEST) To: Nathan Scott Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven , mingo@elte.hu Subject: Re: [LOCKDEP] xfs: possible recursive locking detected References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438__38681.8935432986$1152004607$gmane$org@wobbly.melbourne.sgi.com> From: Andi Kleen Date: 04 Jul 2006 14:42:42 +0200 In-Reply-To: <20060704191100.C1497438__38681.8935432986$1152004607$gmane$org@wobbly.melbourne.sgi.com> 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: 8103 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: xfs Content-Length: 291 Lines: 10 Nathan Scott writes: > > That would be good, but it doesn't work for all situations > unfortunately, and it would loose that debug-kernel sanity > checking that we have in there which validates ilock/iolock > ordering rules. Isn't that obsolete now with lockdep? -Andi From owner-xfs@oss.sgi.com Tue Jul 4 07:29:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 07:29:41 -0700 (PDT) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64ETSDW001163 for ; Tue, 4 Jul 2006 07:29:29 -0700 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k64Cr0Ra002684 for ; Tue, 4 Jul 2006 22:06:44 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by tyo201.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k64Cqpp5025850; Tue, 4 Jul 2006 21:52:51 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k64CqpW12928; Tue, 4 Jul 2006 21:52:51 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k64CqoG01033; Tue, 4 Jul 2006 21:52:50 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k64Cqnlr028110; Tue, 4 Jul 2006 21:52:50 +0900 To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] xfs: i_state of inode is changed after the inode is freed Message-Id: <20060704215256m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Tue, 4 Jul 2006 21:52:56 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8104 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 5850 Lines: 163 Hi, I found the case that i_state of the inode was changed when the inode was freed in xfs filesystem. It's as follows to be concrete. (1) xfs_fs_destroy function is called. (2) after (1), i_state of the inode is changed within __mark_inode_dirty function. In addition to the case of the above, I confirm the case that i_state of the inode is changed after xfs_inode is reclaimed. It occurs when xfs_inode reclaim transaction is running with the transaction mentioned above in parallel. My machine has 32way CPUs(IA-64). The kernel is linux-2.6.17.1. I think that the cause of the case is that xfs_inode is not locked. For this reason, these two(or three) transactions can be running in parallel. Here is the typical pattern. (transaction A runs while transaction B is running) generic_delete_inode xfs_iunpin --------------------------------------------------------------------------- if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) +-vnode_t *vp = XFS_ITOV_NULL(ip) ==================(transaction B-Start)============== +-if (vp) +-struct inode *inode = vn_to_inode(vp) +-if (!(inode->i_state & I_NEW)) | +-mark_inode_dirty_sync(inode) | +-__mark_inode_dirty(inode, I_DIRTY_SYNC) : ==============(transaction A)================= (XFS_IRECLAIMABLE or XFS_IRECLAIM set) (I_CLEAR set) +-destroy_inode +-security_inode_free +-inode->i_sb->s_op->destroy_inode +-xfs_fs_destroy_inode +-kmem_zone_free ============================================== : | +-spin_lock(&inode_lock) =================(transaction B-End)============= | +-inode->i_state |= flags(I_DIRTY_SYNC set) --------------------------------------------------------------------------- I fixed this problem with adding spinlock for appropriate places. The patch is against 2.6.17.1. I confirmed with this patch that the inode of i_state is not changed after the inode is freed. Please comments. Signed-off-by: Masayuki Saito --- --- linux-2.6.17.1/fs/xfs/xfs_inode.h.orig 2006-06-29 16:43:21.783055861 +0900 +++ linux-2.6.17.1/fs/xfs/xfs_inode.h 2006-06-29 16:44:44.720968782 +0900 @@ -267,6 +267,7 @@ typedef struct xfs_inode { sema_t i_flock; /* inode flush lock */ atomic_t i_pincount; /* inode pin count */ wait_queue_head_t i_ipin_wait; /* inode pinning wait queue */ + spinlock_t i_vlock; /* inode lock when inode link/unlink vnode */ #ifdef HAVE_REFCACHE struct xfs_inode **i_refcache; /* ptr to entry in ref cache */ struct xfs_inode *i_release; /* inode to unref */ --- linux-2.6.17.1/fs/xfs/xfs_inode.c.orig 2006-06-29 16:45:00.297510902 +0900 +++ linux-2.6.17.1/fs/xfs/xfs_inode.c 2006-06-29 17:54:41.929675716 +0900 @@ -861,6 +861,7 @@ xfs_iread( ip = kmem_zone_zalloc(xfs_inode_zone, KM_SLEEP); ip->i_ino = ino; ip->i_mount = mp; + spin_lock_init(&ip->i_vlock); /* * Get pointer's to the on-disk inode and the buffer containing it. @@ -2744,6 +2745,7 @@ xfs_iunpin( * call as the inode reclaim may be blocked waiting for * the inode to become unpinned. */ + spin_lock(&ip->i_vlock); if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) { vnode_t *vp = XFS_ITOV_NULL(ip); @@ -2755,6 +2757,8 @@ xfs_iunpin( mark_inode_dirty_sync(inode); } } + spin_unlock(&ip->i_vlock); + wake_up(&ip->i_ipin_wait); } } --- linux-2.6.17.1/fs/xfs/linux-2.6/xfs_super.c.orig 2006-06-29 16:49:56.987695062 +0900 +++ linux-2.6.17.1/fs/xfs/linux-2.6/xfs_super.c 2006-06-29 17:55:25.518797628 +0900 @@ -213,11 +213,13 @@ xfs_initialize_vnode( xfs_inode_t *ip = XFS_BHVTOI(inode_bhv); struct inode *inode = vn_to_inode(vp); + spin_lock(&ip->i_vlock); if (!inode_bhv->bd_vobj) { vp->v_vfsp = bhvtovfs(bdp); bhv_desc_init(inode_bhv, ip, vp, &xfs_vnodeops); bhv_insert(VN_BHV_HEAD(vp), inode_bhv); } + spin_unlock(&ip->i_vlock); /* * We need to set the ops vectors, and unlock the inode, but if --- linux-2.6.17.1/fs/xfs/xfs_vnodeops.c.orig 2006-06-29 16:52:06.513256745 +0900 +++ linux-2.6.17.1/fs/xfs/xfs_vnodeops.c 2006-06-29 16:54:56.107495843 +0900 @@ -3834,9 +3834,13 @@ xfs_reclaim( /* Protect sync from us */ XFS_MOUNT_ILOCK(mp); - vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip)); - list_add_tail(&ip->i_reclaim, &mp->m_del_inodes); - ip->i_flags |= XFS_IRECLAIMABLE; + spin_lock(&ip->i_vlock); + if (!(ip->i_flags & XFS_IRECLAIMABLE)) { + vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip)); + list_add_tail(&ip->i_reclaim, &mp->m_del_inodes); + ip->i_flags |= XFS_IRECLAIMABLE; + } + spin_unlock(&ip->i_vlock); XFS_MOUNT_IUNLOCK(mp); } return 0; --- linux-2.6.17.1/fs/xfs/xfs_iget.c.orig 2006-06-29 16:55:45.379720997 +0900 +++ linux-2.6.17.1/fs/xfs/xfs_iget.c 2006-06-29 16:56:51.574275914 +0900 @@ -675,10 +675,12 @@ xfs_ireclaim(xfs_inode_t *ip) /* * Pull our behavior descriptor from the vnode chain. */ + spin_lock(&ip->i_vlock); vp = XFS_ITOV_NULL(ip); if (vp) { vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip)); } + spin_unlock(&ip->i_vlock); /* * Free all memory associated with the inode. --- linux-2.6.17.1/fs/xfs/xfs_itable.c.orig 2006-06-29 16:58:48.376845205 +0900 +++ linux-2.6.17.1/fs/xfs/xfs_itable.c 2006-06-29 16:59:49.857144001 +0900 @@ -559,6 +559,8 @@ xfs_bulkstat( KM_SLEEP); ip->i_ino = ino; ip->i_mount = mp; + spin_lock_init(&ip->i_vlock); + if (bp) xfs_buf_relse(bp); error = xfs_itobp(mp, NULL, ip, From owner-xfs@oss.sgi.com Tue Jul 4 08:56:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 08:56:40 -0700 (PDT) Received: from mail.protei.ru (mail2.protei.ru [62.152.87.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64FuRDW018655 for ; Tue, 4 Jul 2006 08:56:28 -0700 Received: from lab111.protei (lab111 [10.0.0.2]) by mail.protei.ru (Postfix) with ESMTP id 446FB705A5A; Tue, 4 Jul 2006 19:56:09 +0400 (MSD) Received: by lab111.protei (Postfix, from userid 99) id 4409C9C014FB; Tue, 4 Jul 2006 19:56:09 +0400 (MSD) Received: from [192.168.100.182] (nickolay.protei [192.168.100.182]) by lab111.protei (Postfix) with ESMTP id B8A729C014CB; Tue, 4 Jul 2006 19:56:08 +0400 (MSD) Message-ID: <44AA8FC2.50605@protei.ru> Date: Tue, 04 Jul 2006 19:56:50 +0400 From: Nickolay User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: christian.guggenberger@physik.uni-regensburg.de Cc: xfs@oss.sgi.com Subject: Re: BUG with inode allocating References: <44AA54BB.7040608@protei.ru> <20060704153317.GA30461@pc51072.physik.uni-regensburg.de> In-Reply-To: <20060704153317.GA30461@pc51072.physik.uni-regensburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8105 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nickolay@protei.ru Precedence: bulk X-list: xfs Content-Length: 1601 Lines: 54 Christian Guggenberger wrote: >On Tue, Jul 04, 2006 at 03:44:59PM +0400, Nickolay wrote: > > >>Hello. >> >>Kernel: 2.4.29 and 2.4.32. >> >>root@192_168_15_15:/usr/test$ mkdir test >>mkdir: cannot create directory `test': No space left on device >> >>root@192_168_15_15:/usr/test$ df >>Filesystem 1k-blocks Used Available Use% Mounted on >>/dev/ram0 30720 26304 4416 86% / >>/dev/cciss/c0d0p2 1953600 1882788 70812 97% /usr/test >> >>root@192_168_15_15:/usr/test$ df -i >>Filesystem Inodes IUsed IFree IUse% Mounted on >>/dev/ram0 19408 1400 18008 8% / >>/dev/cciss/c0d0p2 1095232 815104 280128 75% /usr/test >> >>I can delete one small file, and create big file instead. >>I think, the problem not with the free space, but with the inode allocation. >> >> >> > >what does 'xfs_info /usr/test' tell ? >you're probably reaching imaxpct. > >cheers. > - Christian > > > imaxpct was 25%(default). I'm change it to 100%, but that doesn't resolve the problem. root@192_168_15_15:/usr/test$ xfs_info /usr/test meta-data=/usr/test isize=256 agcount=8, agsize=61200 blks data = bsize=4096 blocks=489600, imaxpct=100 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 -- Nickolay Vinogradov Protei Reseach and Development Center St.Petersburg, 194044, Russia Tel.: +7 812 449 47 27 From owner-xfs@oss.sgi.com Tue Jul 4 09:38:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 09:39:03 -0700 (PDT) Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64GcmDW025245 for ; Tue, 4 Jul 2006 09:38:49 -0700 Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 867E345936; Tue, 4 Jul 2006 17:33:26 +0200 (CEST) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id 60CD345984; Tue, 4 Jul 2006 17:33:24 +0200 (CEST) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id C11F3503106; Tue, 4 Jul 2006 17:33:17 +0200 (CEST) Date: Tue, 4 Jul 2006 17:33:17 +0200 From: Christian Guggenberger To: Nickolay Cc: xfs@oss.sgi.com Subject: Re: BUG with inode allocating Message-ID: <20060704153317.GA30461@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: <44AA54BB.7040608@protei.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AA54BB.7040608@protei.ru> User-Agent: Mutt/1.5.9i X-archive-position: 8106 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: xfs Content-Length: 908 Lines: 28 On Tue, Jul 04, 2006 at 03:44:59PM +0400, Nickolay wrote: > Hello. > > Kernel: 2.4.29 and 2.4.32. > > root@192_168_15_15:/usr/test$ mkdir test > mkdir: cannot create directory `test': No space left on device > > root@192_168_15_15:/usr/test$ df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/ram0 30720 26304 4416 86% / > /dev/cciss/c0d0p2 1953600 1882788 70812 97% /usr/test > > root@192_168_15_15:/usr/test$ df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/ram0 19408 1400 18008 8% / > /dev/cciss/c0d0p2 1095232 815104 280128 75% /usr/test > > I can delete one small file, and create big file instead. > I think, the problem not with the free space, but with the inode allocation. > what does 'xfs_info /usr/test' tell ? you're probably reaching imaxpct. cheers. - Christian From owner-xfs@oss.sgi.com Tue Jul 4 10:20:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 10:20:09 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64HJtDW030521 for ; Tue, 4 Jul 2006 10:19:55 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.13.1/8.13.1) with ESMTP id k64FTwKg005463; Tue, 4 Jul 2006 11:29:58 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.13.1/8.13.1/Submit) with ESMTP id k64FTsVE005460; Tue, 4 Jul 2006 11:29:58 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 4 Jul 2006 11:29:54 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: pgs@synerway.com cc: linux-xfs@oss.sgi.com Subject: Re: determining sunit In-Reply-To: <20060704151009.GA2816@venus.synerway.com> Message-ID: References: <20060703171826.GA1267@venus.synerway.com> <20060704101451.G1462688@wobbly.melbourne.sgi.com> <20060704151009.GA2816@venus.synerway.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8107 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: xfs Content-Length: 1534 Lines: 31 On Tue, 4 Jul 2006 at 5:10pm, pgs@synerway.com wrote > Unfortunately, it didn't really answer to my question. > Maybe it's because I don't know enough about RAID arrays. > Well, what I want to know is : > how can I know the value to assign to sunit and swidth? > All I know at this time for my RAID array is that there are 12 disks of 500 GB, so 11 * 500 GB of usable space (last disk for checksum), and it's not enough to know which value to set to sunit, it seems that sunit must not be equal to the size of one of the disk in my RAID array. > I heard here and there about chunk size and stripe size. But I don't know what is the cunk size of a RAID array and how can I know it, (it's not me that bought this RAID array), someone of my company told me that its stripe size was 64k, but are stripe size and chunk size the same? And must sunit be equal to the chunk size? And swidth? Quoting an email sent by Steve Lord *long* ago regarding my 8 disk RAID5 w/ 32KB stripe size (also referred to as chunksize): \begin{quote} Actually this is incorrect, you need -d sunit=64,swidth=448 The sunit is the amount of data on each disk in 512 byte chunks, the swidth is the total amount of data before we go back to the first disk again. You have 8 disks in raid5 so 7 data disks and a parity disk. You need 7 * 64 as the stripe width. \end{quote} So for your system, it'd be "-d sunit=128,swidth=1408" (assuming you're not using a hot spare). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-xfs@oss.sgi.com Tue Jul 4 12:06:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 12:06:38 -0700 (PDT) Received: from gigamail.giga.de (85.14.253.20.static.rdns-uclo.net [85.14.253.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64J6NDW011408 for ; Tue, 4 Jul 2006 12:06:24 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by gigamail.giga.de (Postfix) with ESMTP id 59F7A80045A4 for ; Tue, 4 Jul 2006 20:08:00 +0200 (CEST) Received: from gigamail.giga.de ([127.0.0.1]) by localhost (gigamail.giga.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05004-10 for ; Tue, 4 Jul 2006 20:07:59 +0200 (CEST) Received: from [192.168.1.99] (cable-81-173-128-95.netcologne.de [81.173.128.95]) by gigamail.giga.de (Postfix) with ESMTP id DBD8A80045A2 for ; Tue, 4 Jul 2006 20:07:59 +0200 (CEST) Message-ID: <44AAADD7.1070105@giga.de> Date: Tue, 04 Jul 2006 20:05:11 +0200 From: Sebastian Lenz User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: xfs EVMS problem Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Jul 4 20:08:00 2006 X-DSPAM-Confidence: 0.7880 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 44aaae80189111804284693 X-DSPAM-Factors: 27, X-archive-position: 8108 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sebastian.lenz@giga.de Precedence: bulk X-list: xfs Content-Length: 1091 Lines: 38 we have an ISCSI system with two heartbeated nas and a 12 TB private container behind this. after a firmware update EVMS still lists the container but without any filesystem so we cant access to the storage. we had a lot of discussions and help ending in this command: xfs_repair -v -n /dev/sdb1 with the result ...............................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... and a fatel error like "cant find super block". is there anyone who can help us. we dont want to lose the data and we are willing to pay. thank you -- Sebastian Lenz Systemadministrator GIGA DIGITAL Television GmbH Siegburger Str. 189 D-50679 Cologne Tel.: +49 (0) 221 | 65045-752 E-Mail: sebastian.lenz@giga.de http://www.giga.de GIGA - auf Astra digital 19,2° Transponder: 103 | Freq: 12.460,50 MHz | Pol:H | 27,5 MSymb/s | FEC: 3/4 From owner-xfs@oss.sgi.com Tue Jul 4 12:16:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 12:16:28 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64JGIDW014422 for ; Tue, 4 Jul 2006 12:16:18 -0700 Received: from [192.168.110.101] (account mmontour HELO [192.168.110.101]) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTPA id 878318 for xfs@oss.sgi.com; Tue, 04 Jul 2006 11:15:58 -0700 Message-ID: <44AAB05D.8010106@bycast.com> Date: Tue, 04 Jul 2006 11:15:57 -0700 From: Mike Montour User-Agent: Thunderbird 1.5.0.4 (X11/20060527) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: BUG with inode allocating References: <44AA54BB.7040608@protei.ru> In-Reply-To: <44AA54BB.7040608@protei.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-archive-position: 8109 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmontour@bycast.com Precedence: bulk X-list: xfs Content-Length: 390 Lines: 13 Nickolay wrote: > Hello. > > Kernel: 2.4.29 and 2.4.32. > > root@192_168_15_15:/usr/test$ mkdir test > mkdir: cannot create directory `test': No space left on device What does "xfs_db -r -c freesp /dev/cciss/c0d0p2" show? XFS allocates inodes in chunks of 64, and if your free space is fragmented into lots of little extents then there may not be one big enough for the inode allocation. From owner-xfs@oss.sgi.com Tue Jul 4 12:26:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 12:27:02 -0700 (PDT) Received: from mail.protei.ru (ns.protei.ru [195.239.28.26] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64JQoDW020730 for ; Tue, 4 Jul 2006 12:26:51 -0700 Received: from lab111.protei (lab111 [10.0.0.2]) by mail.protei.ru (Postfix) with ESMTP id 7C916706084; Tue, 4 Jul 2006 23:26:27 +0400 (MSD) Received: by lab111.protei (Postfix, from userid 99) id 621A39C01915; Tue, 4 Jul 2006 23:26:27 +0400 (MSD) Received: from [192.168.100.182] (nickolay.protei [192.168.100.182]) by lab111.protei (Postfix) with ESMTP id D8D5A9C01803; Tue, 4 Jul 2006 23:26:26 +0400 (MSD) Message-ID: <44AAC10D.1040206@protei.ru> Date: Tue, 04 Jul 2006 23:27:09 +0400 From: Nickolay User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Montour Cc: xfs@oss.sgi.com Subject: Re: BUG with inode allocating References: <44AA54BB.7040608@protei.ru> <44AAB05D.8010106@bycast.com> In-Reply-To: <44AAB05D.8010106@bycast.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8110 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nickolay@protei.ru Precedence: bulk X-list: xfs Content-Length: 2707 Lines: 85 Mike Montour wrote: >Nickolay wrote: > > >>Hello. >> >>Kernel: 2.4.29 and 2.4.32. >> >>root@192_168_15_15:/usr/test$ mkdir test >>mkdir: cannot create directory `test': No space left on device >> >> >What does "xfs_db -r -c freesp /dev/cciss/c0d0p2" show? > >XFS allocates inodes in chunks of 64, and if your free space is >fragmented into lots of little extents then there may not be one big >enough for the inode allocation. > > > > root@192_168_15_15:/usr/protei$ xfs_db -r -c freesp /dev/cciss/c0d0p2 can't seek in filesystem at bb 134217728 can't read btree block 0/16777216 can't seek in filesystem at bb 1744830464 can't read btree block 0/218103808 can't seek in filesystem at bb 536870912 can't read btree block 0/67108864 can't seek in filesystem at bb 134707328 can't read btree block 1/16777216 can't seek in filesystem at bb 1077377152 can't read btree block 1/134610944 can't seek in filesystem at bb 17314576512 can't read btree block 1/2164260864 can't seek in filesystem at bb 135196928 can't read btree block 2/16777216 can't seek in filesystem at bb 672067840 can't read btree block 2/83886080 can't seek in filesystem at bb 11022561536 can't read btree block 2/1377697792 can't seek in filesystem at bb 11290996992 can't read btree block 2/1411252224 can't seek in filesystem at bb 1880027392 can't read btree block 2/234881024 can't seek in filesystem at bb 135686528 can't read btree block 3/16777216 can't seek in filesystem at bb 17189726592 can't read btree block 3/2148532224 can't seek in filesystem at bb 806775168 can't read btree block 3/100663296 can't seek in filesystem at bb 136176128 can't read btree block 4/16777216 can't seek in filesystem at bb 24431682048 can't read btree block 4/3053715456 can't seek in filesystem at bb 11144651264 can't read btree block 4/1392836608 can't seek in filesystem at bb 136665728 can't read btree block 5/16777216 can't seek in filesystem at bb 13021567616 can't read btree block 5/1627389952 can't seek in filesystem at bb 7923915392 can't read btree block 5/990183424 can't seek in filesystem at bb 137155328 can't read btree block 6/16777216 can't seek in filesystem at bb 6311170816 can't read btree block 6/788529152 can't seek in filesystem at bb 28601799424 can't read btree block 6/3574857728 can't seek in filesystem at bb 137644928 can't read btree block 7/16777216 can't seek in filesystem at bb 674515840 can't read btree block 7/83886080 can't seek in filesystem at bb 14101007232 can't read btree block 7/1762197504 from to extents blocks pct 1 1 32 32 100.00 -- Nickolay Vinogradov Protei Reseach and Development Center St.Petersburg, 194044, Russia Tel.: +7 812 449 47 27 From owner-xfs@oss.sgi.com Tue Jul 4 12:58:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 12:59:00 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64JwkDW025930 for ; Tue, 4 Jul 2006 12:58:46 -0700 Received: from [192.168.110.101] (account mmontour HELO [192.168.110.101]) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTPA id 878692; Tue, 04 Jul 2006 12:58:28 -0700 Message-ID: <44AAC864.3090507@bycast.com> Date: Tue, 04 Jul 2006 12:58:28 -0700 From: Mike Montour User-Agent: Thunderbird 1.5.0.4 (X11/20060527) MIME-Version: 1.0 To: Nickolay CC: xfs@oss.sgi.com Subject: Re: BUG with inode allocating References: <44AA54BB.7040608@protei.ru> <44AAB05D.8010106@bycast.com> <44AAC10D.1040206@protei.ru> In-Reply-To: <44AAC10D.1040206@protei.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-archive-position: 8111 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmontour@bycast.com Precedence: bulk X-list: xfs Content-Length: 1072 Lines: 22 Nickolay wrote: > root@192_168_15_15:/usr/protei$ xfs_db -r -c freesp /dev/cciss/c0d0p2 > can't seek in filesystem at bb 134217728 > can't read btree block 0/16777216 > can't seek in filesystem at bb 1744830464 I don't know what that's all about (although Google suggests it may be a bug in old versions of the xfs_db command - http://oss.sgi.com/archives/xfs/2003-02/msg00077.html ). > [...] > from to extents blocks pct > 1 1 32 32 100.00 This says that all of your free space is in single blocks, which would explain why XFS can't allocate a new chunk of inodes. However the total amount of free space here is much less than your previous 'df' showed (and there were the other errors above) so this may not be accurate. If you can temporarily move some large old files (ones written before the filesystem became fragmented) off this partition you might free up some larger extents. 'xfs_fsr' might also help if you are able to free up enough temporary space for it to work, however I do not have any direct experience using this tool. From owner-xfs@oss.sgi.com Tue Jul 4 13:30:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 13:31:10 -0700 (PDT) Received: from mail.protei.ru (ns.protei.ru [195.239.28.26] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64KUuDW030125 for ; Tue, 4 Jul 2006 13:30:57 -0700 Received: from lab111.protei (lab111 [10.0.0.2]) by mail.protei.ru (Postfix) with ESMTP id 06F0070608C; Wed, 5 Jul 2006 00:30:39 +0400 (MSD) Received: by lab111.protei (Postfix, from userid 99) id 027D49C01915; Wed, 5 Jul 2006 00:30:38 +0400 (MSD) Received: from [192.168.100.182] (nickolay.protei [192.168.100.182]) by lab111.protei (Postfix) with ESMTP id D45699C01803; Wed, 5 Jul 2006 00:30:37 +0400 (MSD) Message-ID: <44AAD018.9090400@protei.ru> Date: Wed, 05 Jul 2006 00:31:20 +0400 From: Nickolay User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Montour Cc: xfs@oss.sgi.com Subject: Re: BUG with inode allocating References: <44AA54BB.7040608@protei.ru> <44AAB05D.8010106@bycast.com> <44AAC10D.1040206@protei.ru> <44AAC864.3090507@bycast.com> In-Reply-To: <44AAC864.3090507@bycast.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8112 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nickolay@protei.ru Precedence: bulk X-list: xfs Content-Length: 2449 Lines: 73 Mike Montour wrote: >Nickolay wrote: > > >>root@192_168_15_15:/usr/protei$ xfs_db -r -c freesp /dev/cciss/c0d0p2 >>can't seek in filesystem at bb 134217728 >>can't read btree block 0/16777216 >>can't seek in filesystem at bb 1744830464 >> >> >I don't know what that's all about (although Google suggests it may be a >bug in old versions of the xfs_db command - >http://oss.sgi.com/archives/xfs/2003-02/msg00077.html ). > > >>[...] >> from to extents blocks pct >> 1 1 32 32 100.00 >> >> >This says that all of your free space is in single blocks, which would >explain why XFS can't allocate a new chunk of inodes. However the total >amount of free space here is much less than your previous 'df' showed >(and there were the other errors above) so this may not be accurate. > >If you can temporarily move some large old files (ones written before >the filesystem became fragmented) off this partition you might free up >some larger extents. 'xfs_fsr' might also help if you are able to free >up enough temporary space for it to work, however I do not have any >direct experience using this tool. > > > Yeah, this is really xfs_db utility bug. New version works fine, but with a warning(can't get sector size), new mkfs.xfs warns too. This is a new result: -------------------------------------------- root@192_168_15_15:/usr/test$ xfs_db -r -c "freesp -s" /dev/cciss/c0d0p2 xfs_db: warning - cannot get sector size from block device /dev/cciss/c0d0p2: Invalid request code from to extents blocks pct 1 1 4097 4097 24.27 2 3 5694 12771 75.66 4 7 3 12 0.07 total free extents 9794 total free blocks 16880 average free extent size 1.7235 -------------------------------------------- And /bin/df show to us: root@192_168_15_15:/usr/test$ /bin/df /dev/cciss/c0d0p2 Filesystem 1k-blocks Used Available Use% Mounted on /dev/cciss/c0d0p2 1953600 1886020 67580 97% /usr/test Now, if we multiple total free block(from all extents), we get almost precisely the same freespace, which show to us /bin/df: 16880 * 4096 / 1024 = 67520 Kb Now, as I understand, the problem here because XFS can't finds free extent, for allocating new chunk of inodes, and there is no way to tune the chunk size? -- Nickolay Vinogradov Protei Reseach and Development Center St.Petersburg, 194044, Russia Tel.: +7 812 449 47 27 From owner-xfs@oss.sgi.com Tue Jul 4 13:43:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 13:43:30 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k64KgnDW031847 for ; Tue, 4 Jul 2006 13:43:00 -0700 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 GAA09604; Wed, 5 Jul 2006 06:42:11 +1000 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 k64KfoEo21783407; Wed, 5 Jul 2006 06:41:50 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k64KfjZG21799854; Wed, 5 Jul 2006 06:41:45 +1000 (AEST) Date: Wed, 5 Jul 2006 06:41:45 +1000 From: David Chinner To: Masayuki Saito Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xfs: i_state of inode is changed after the inode is freed Message-ID: <20060704204145.GU15160733@melbourne.sgi.com> References: <20060704215256m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060704215256m-saito@mail.aom.tnes.nec.co.jp> User-Agent: Mutt/1.4.2.1i X-archive-position: 8113 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2996 Lines: 76 On Tue, Jul 04, 2006 at 09:52:56PM +0900, Masayuki Saito wrote: > Hi, > > I found the case that i_state of the inode was changed when > the inode was freed in xfs filesystem. It's as follows to be > concrete. > > (1) xfs_fs_destroy function is called. > (2) after (1), i_state of the inode is changed within > __mark_inode_dirty function. You'd be talking about xfs_iunpin(), wouldn't you ;) > In addition to the case of the above, I confirm the case that > i_state of the inode is changed after xfs_inode is reclaimed. > It occurs when xfs_inode reclaim transaction is running with > the transaction mentioned above in parallel. Well, it occurs because the xfs_inode_t has a different life cycle to the linux inode (inherited from Irix). Basically, we can still be doing transactions on the xfs_inode_t whilst the linux inode is being freed or has been freed. Indeed, there was a long standing use-after-free in this code, as fixed here: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=58829e490ee805f1c8b3009abc90e2a1a7a0d278 Initially I thought this was all that was necessary to fix the problem. The problem you are seeing is a fast log transaction completion (NVRAM in front of your disks, perhaps?), and so the transaction completion is occurring before the linux inode has been completely freed. This is the condition the above fix does not handle..... > I think that the cause of the case is that xfs_inode is not > locked. For this reason, these two(or three) transactions > can be running in parallel. The inode is locked while the transaction is being built and unlocked when the transaction is committed to the incore log buffer. The inode is pinned during the transaction commit, so we can have multiple _committed_ transactions in flight on the one inode at the same time, but we only allow an inode to be part of a single uncommitted transaction at a time. FYI, see xfs_trans_iget(), xfs_trans_ijoin(), etc for an explanation of inode transaction locking rules. > Here is the typical pattern. (transaction A runs while transaction > B is running) > > generic_delete_inode xfs_iunpin > --------------------------------------------------------------------------- > if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) > +-vnode_t *vp = XFS_ITOV_NULL(ip) > ==================(transaction B-Start)============== > +-if (vp) > +-struct inode *inode = vn_to_inode(vp) > +-if (!(inode->i_state & I_NEW)) This check fails to detect the fact the inode is in the process of being freed. http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=714250879ea61cdb1a39bb96fe9d934ee0c669a2 This fixed the reproducable test case I had for the problem. Can you see if it fixes your problem as well? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jul 4 14:27:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 14:27:52 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k64LRgDW005947 for ; Tue, 4 Jul 2006 14:27:42 -0700 Received: from [192.168.110.101] (account mmontour HELO [192.168.110.101]) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTPA id 878786; Tue, 04 Jul 2006 14:27:23 -0700 Message-ID: <44AADD3B.1080906@bycast.com> Date: Tue, 04 Jul 2006 14:27:23 -0700 From: Mike Montour User-Agent: Thunderbird 1.5.0.4 (X11/20060527) MIME-Version: 1.0 To: Nickolay CC: xfs@oss.sgi.com Subject: Re: BUG with inode allocating References: <44AA54BB.7040608@protei.ru> <44AAB05D.8010106@bycast.com> <44AAC10D.1040206@protei.ru> <44AAC864.3090507@bycast.com> <44AAD018.9090400@protei.ru> In-Reply-To: <44AAD018.9090400@protei.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-archive-position: 8114 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmontour@bycast.com Precedence: bulk X-list: xfs Content-Length: 1031 Lines: 26 Nickolay wrote: > > -------------------------------------------- > root@192_168_15_15:/usr/test$ xfs_db -r -c "freesp -s" /dev/cciss/c0d0p2 > xfs_db: warning - cannot get sector size from block device > /dev/cciss/c0d0p2: Invalid request code > from to extents blocks pct > 1 1 4097 4097 24.27 > 2 3 5694 12771 75.66 > 4 7 3 12 0.07 > total free extents 9794 > total free blocks 16880 > average free extent size 1.7235 > -------------------------------------------- > [...] > > Now, as I understand, the problem here because XFS can't finds free > extent, > for allocating new chunk of inodes, and there is no way to tune the > chunk size? I suspect that is the problem, although based on your results there should still be room for 192 more inodes (3 extents of at least 4 blocks, and 4 blocks = 16K = 64 * 256 bytes). You could try remounting with the "noalign" option to see if it makes a difference. I don't think there's any way to change the chunk size. From owner-xfs@oss.sgi.com Tue Jul 4 18:18:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 18:19:27 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k651IVDW005643 for ; Tue, 4 Jul 2006 18:18:42 -0700 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 LAA14523; Wed, 5 Jul 2006 11:17:56 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id BC1A84A588DC; Wed, 5 Jul 2006 11:17:56 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954378 - translation fu for Ubuntu Message-Id: <20060705011756.BC1A84A588DC@chook.melbourne.sgi.com> Date: Wed, 5 Jul 2006 11:17:56 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8115 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 6931 Lines: 127 Update acl package to better integrate into the Ubuntu localisation up-to-dated-ness tracking system (Rosetta). Date: Wed Jul 5 10:04:12 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: martin.pitt@ubuntu.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26416a acl/VERSION - 1.80 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h acl/doc/CHANGES - 1.89 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h acl/include/buildrules - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/buildrules.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h acl/include/builddefs.in - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/builddefs.in.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h acl/debian/changelog - 1.77 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/changelog.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h acl/po/acl.pot - 1.8 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/po/acl.pot.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h acl/po/Makefile - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/po/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h acl/aclocal.m4 - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/aclocal.m4.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h acl/m4/package_utilies.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/m4/package_utilies.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h Update attr package to better integrate into the Ubuntu localisation up-to-dated-ness tracking system (Rosetta). Date: Wed Jul 5 10:08:57 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: martin.pitt@ubuntu.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26417a attr/VERSION - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h attr/doc/CHANGES - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h attr/include/buildrules - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/buildrules.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h attr/include/builddefs.in - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/builddefs.in.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h attr/debian/changelog - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h attr/po/attr.pot - 1.5 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/attr.pot.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h attr/po/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h attr/m4/package_utilies.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/m4/package_utilies.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h attr/aclocal.m4 - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/aclocal.m4.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h Update xfsdump package to better integrate into the Ubuntu localisation up-to-dated-ness tracking system (Rosetta). Date: Wed Jul 5 11:14:50 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: martin.pitt@ubuntu.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26420a xfsdump/VERSION - 1.81 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/VERSION.diff?r1=text&tr1=1.81&r2=text&tr2=1.80&f=h xfsdump/doc/CHANGES - 1.93 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/doc/CHANGES.diff?r1=text&tr1=1.93&r2=text&tr2=1.92&f=h xfsdump/include/buildrules - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/buildrules.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsdump/include/builddefs.in - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/builddefs.in.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfsdump/debian/changelog - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/debian/changelog.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h xfsdump/po/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/po/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsdump/po/xfsdump.pot - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/po/xfsdump.pot.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsdump/aclocal.m4 - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/aclocal.m4.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsdump/m4/package_utilies.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_utilies.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h Update xfsprogs package to better integrate into the Ubuntu localisation up-to-dated-ness tracking system (Rosetta). Date: Wed Jul 5 11:16:59 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: martin.pitt@ubuntu.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26421a xfsprogs/VERSION - 1.155 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.155&r2=text&tr2=1.154&f=h xfsprogs/doc/CHANGES - 1.209 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.209&r2=text&tr2=1.208&f=h xfsprogs/include/buildrules - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/buildrules.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/include/builddefs.in - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h xfsprogs/debian/changelog - 1.142 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.142&r2=text&tr2=1.141&f=h xfsprogs/po/Makefile - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/po/Makefile.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/po/xfsprogs.pot - 1.12 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/po/xfsprogs.pot.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/m4/package_utilies.m4 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/package_utilies.m4.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/aclocal.m4 - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/aclocal.m4.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h From owner-xfs@oss.sgi.com Tue Jul 4 18:37:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 18:37:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k651bCDW007823 for ; Tue, 4 Jul 2006 18:37:24 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA15000; Wed, 5 Jul 2006 11:36:33 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k651aTgw1526234; Wed, 5 Jul 2006 11:36:30 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k651aOII1524571; Wed, 5 Jul 2006 11:36:24 +1000 (EST) Date: Wed, 5 Jul 2006 11:36:24 +1000 From: Nathan Scott To: Nickolay Cc: Mike Montour , xfs@oss.sgi.com, mike.miller@hp.com, iss_storagedev@hp.com Subject: Missing cciss ioctl handler? (was Re: BUG with inode allocating) Message-ID: <20060705113624.A1521039@wobbly.melbourne.sgi.com> References: <44AA54BB.7040608@protei.ru> <44AAB05D.8010106@bycast.com> <44AAC10D.1040206@protei.ru> <44AAC864.3090507@bycast.com> <44AAD018.9090400@protei.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44AAD018.9090400@protei.ru>; from nickolay@protei.ru on Wed, Jul 05, 2006 at 12:31:20AM +0400 X-archive-position: 8116 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 608 Lines: 22 On Wed, Jul 05, 2006 at 12:31:20AM +0400, Nickolay wrote: > ... > New version works fine, but with a warning(can't get sector size), > new mkfs.xfs warns too. > > This is a new result: > > -------------------------------------------- > root@192_168_15_15:/usr/test$ xfs_db -r -c "freesp -s" /dev/cciss/c0d0p2 > xfs_db: warning - cannot get sector size from block device > /dev/cciss/c0d0p2: Invalid request code > ... This is a problem in the cciss kernel driver, its not handling the BLKSSZGET ioctl (adding people from the kernel MAINTAINERS file to the CC to get that fixed up). cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 4 20:24:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 20:25:28 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k653OTDW026861 for ; Tue, 4 Jul 2006 20:24:41 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA17090; Wed, 5 Jul 2006 13:23:43 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k653Nagw1524712; Wed, 5 Jul 2006 13:23:38 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k653NTmZ1527478; Wed, 5 Jul 2006 13:23:29 +1000 (EST) Date: Wed, 5 Jul 2006 13:23:29 +1000 From: Nathan Scott To: Ingo Molnar Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060705132328.C1521039@wobbly.melbourne.sgi.com> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> <20060704091247.GA15982@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060704091247.GA15982@elte.hu>; from mingo@elte.hu on Tue, Jul 04, 2006 at 11:12:47AM +0200 X-archive-position: 8117 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 669 Lines: 19 On Tue, Jul 04, 2006 at 11:12:47AM +0200, Ingo Molnar wrote: > * Nathan Scott wrote: > > That would be good, but it doesn't work for all situations > > unfortunately, and it would loose that debug-kernel sanity checking > > that we have in there which validates ilock/iolock ordering rules. > > do you have anything in there that spinlock/mutex debugging or lockdep > does not catch? If yes then i'll add it to the generic lock debugging > code. The thing we're catching automatically there is potential ordering violations on the XFS inode iolock vs ilock. I don't know if the other methods can help us there too or not. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 4 20:38:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 20:39:26 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k653ckDW029574 for ; Tue, 4 Jul 2006 20:38:58 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA17378; Wed, 5 Jul 2006 13:37:56 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k653bmgw1502478; Wed, 5 Jul 2006 13:37:50 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k653bgcn1527270; Wed, 5 Jul 2006 13:37:42 +1000 (EST) Date: Wed, 5 Jul 2006 13:37:42 +1000 From: Nathan Scott To: Ingo Molnar , cattelan@thebarn.com Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060705133742.D1521039@wobbly.melbourne.sgi.com> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> <20060704095743.GA21480@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060704095743.GA21480@elte.hu>; from mingo@elte.hu on Tue, Jul 04, 2006 at 11:57:43AM +0200 X-archive-position: 8118 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1398 Lines: 35 On Tue, Jul 04, 2006 at 11:57:43AM +0200, Ingo Molnar wrote: > > Right... but that leaves plenty that don't, and they're not simple to > > change. There are generic routines that need to be called from > > different contexts with different locking requirements (xfs_iget). > > the main variation in xfs_iget() is whether we lock the inode > read-write, read-only or not at all, correct? (XFS_ILOCK_EXCL, > XFS_ILOCK_SHARED and 0) > > That could be cleaned up the following way: *nod*. One difficulty is that xfs_iget_core would also need this treatment (the lock_mode parameter is passed down there), and we may end up be with quite a few functions and/or duplicated code. But maybe that can be avoided by arranging that code differently. > NOTE: since the majority (9 out of 13) of xfs_iget() uses are for the > 'no lock' variant, this construction of functions, besides making the > code more readable, _further_ reduces overhead, because there is no > ilock-flags checking overhead in __xfs_iget() anymore. Indeed; its fairly minimal overhead though really, the readability angle appeals to me more. Its just a fair bit of churn for not a very tangible gain, so I'm balking at it atm. Russell is looking at reworking xfs_iget for other reasons, so maybe he can stew on all of this and clean it up in the context of his other changes in there. Thanks Ingo. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 4 22:28:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 22:28:41 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k655RwDW010569 for ; Tue, 4 Jul 2006 22:28:09 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19435; Wed, 5 Jul 2006 15:27:05 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k655Qxgw1529571; Wed, 5 Jul 2006 15:27:00 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k655Qr9k1530707; Wed, 5 Jul 2006 15:26:53 +1000 (EST) Date: Wed, 5 Jul 2006 15:26:52 +1000 From: Nathan Scott To: Ingo Molnar Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060705152652.F1521039@wobbly.melbourne.sgi.com> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> <20060704095743.GA21480@elte.hu> <20060704130338.GA4354@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060704130338.GA4354@elte.hu>; from mingo@elte.hu on Tue, Jul 04, 2006 at 03:03:38PM +0200 X-archive-position: 8119 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 554 Lines: 18 On Tue, Jul 04, 2006 at 03:03:38PM +0200, Ingo Molnar wrote: > so i suspect: > > fs/xfs/xfs_mount.h:#define AIL_LOCK_DESTROY(x) spinlock_destroy(x) > fs/xfs/linux-2.6/spin.h:#define spinlock_destroy(lock) > > needs to change and we need to implement spinlock_destroy(), a'ka > mutex_destroy()? [which i added recently too] Hmm, don't think so - only if you needed to change all other spinlock uses in the kernel to have a teardown too? Can't see that in current git trees, anyway, so I expect that to be OK as is. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 4 22:59:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 23:00:07 -0700 (PDT) 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 k655xeDW015351 for ; Tue, 4 Jul 2006 22:59:40 -0700 Received: from a222036.upc-a.chello.nl ([62.163.222.36] helo=[172.31.3.43]) by pentafluge.infradead.org with esmtpsa (Exim 4.62 #1 (Red Hat Linux)) id 1FxzFr-0000Fs-CF; Wed, 05 Jul 2006 05:44:51 +0100 Subject: Re: [LOCKDEP] xfs: possible recursive locking detected From: Arjan van de Ven To: Nathan Scott Cc: Ingo Molnar , Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060705132328.C1521039@wobbly.melbourne.sgi.com> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> <20060704091247.GA15982@elte.hu> <20060705132328.C1521039@wobbly.melbourne.sgi.com> Content-Type: text/plain Date: Wed, 05 Jul 2006 06:44:50 +0200 Message-Id: <1152074690.3201.0.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8121 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: xfs Content-Length: 701 Lines: 16 On Wed, 2006-07-05 at 13:23 +1000, Nathan Scott wrote: > On Tue, Jul 04, 2006 at 11:12:47AM +0200, Ingo Molnar wrote: > > * Nathan Scott wrote: > > > That would be good, but it doesn't work for all situations > > > unfortunately, and it would loose that debug-kernel sanity checking > > > that we have in there which validates ilock/iolock ordering rules. > > > > do you have anything in there that spinlock/mutex debugging or lockdep > > does not catch? If yes then i'll add it to the generic lock debugging > > code. > > The thing we're catching automatically there is potential ordering > violations on the XFS inode iolock vs ilock. lockdep will catch those just fine. From owner-xfs@oss.sgi.com Tue Jul 4 23:51:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Jul 2006 23:52:08 -0700 (PDT) Received: from mx3.mail.elte.hu (mx3.mail.elte.hu [157.181.1.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k656plDW022692 for ; Tue, 4 Jul 2006 23:51:47 -0700 Received: from chiara.elte.hu ([157.181.151.252]) by mx3.mail.elte.hu with esmtp (Exim) id 1Fy1EG-0000Fx-N7 from ; Wed, 05 Jul 2006 08:51:20 +0200 Received: by chiara.elte.hu (Postfix, from userid 17806) id C30251FC2; Wed, 5 Jul 2006 08:51:21 +0200 (CEST) Date: Wed, 5 Jul 2006 08:46:51 +0200 From: Ingo Molnar To: Nathan Scott Cc: Alexey Dobriyan , Matthew Wilcox , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, Arjan van de Ven Subject: Re: [LOCKDEP] xfs: possible recursive locking detected Message-ID: <20060705064651.GA28084@elte.hu> References: <20060704004116.GA7612@martell.zuzino.mipt.ru> <20060704011858.GG1605@parisc-linux.org> <20060704112503.H1495869@wobbly.melbourne.sgi.com> <20060704063225.GA2752@elte.hu> <20060704084143.GA12931@elte.hu> <20060704191100.C1497438@wobbly.melbourne.sgi.com> <20060704095743.GA21480@elte.hu> <20060704130338.GA4354@elte.hu> <20060705152652.F1521039@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060705152652.F1521039@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i Received-SPF: softfail (mx3: transitioning domain of elte.hu does not designate 157.181.151.252 as permitted sender) client-ip=157.181.151.252; envelope-from=mingo@elte.hu; helo=chiara.elte.hu; X-ELTE-SpamScore: 0.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.1 required=5.9 tests=AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5001] 0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean X-archive-position: 8122 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingo@elte.hu Precedence: bulk X-list: xfs Content-Length: 1263 Lines: 30 * Nathan Scott wrote: > > fs/xfs/xfs_mount.h:#define AIL_LOCK_DESTROY(x) spinlock_destroy(x) > > fs/xfs/linux-2.6/spin.h:#define spinlock_destroy(lock) > > > > needs to change and we need to implement spinlock_destroy(), a'ka > > mutex_destroy()? [which i added recently too] > > Hmm, don't think so - only if you needed to change all other spinlock > uses in the kernel to have a teardown too? Can't see that in current > git trees, anyway, so I expect that to be OK as is. i should have formulated this as a question: should i implement spin_lock_destroy()? A few months ago i implemented mutex_destroy() for XFS's use, and now we could do it for spinlocks too. Right now the only upstream requirement wrt. spinlock disposal is that it should not be in locked state when it's destroyed. (PREEMPT_RT in the -rt tree needed that semantic detail too and there were a handful of places in the kernel that freed held locks - we fixed those up in the past year or so.) spin_lock_destroy() would work like mutex_destroy(): the magic number in the lock is overwritten and hence no further locking API will allow the use of that lock from that point on. (up until the lock is reinitialized via spin_lock_init()) Ingo From owner-xfs@oss.sgi.com Tue Jul 4 23:59:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Jul 2006 00:00:10 -0700 (PDT) Received: from larry.melbourne.sg