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.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 k656xWDW024098 for ; Tue, 4 Jul 2006 23:59:44 -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 QAA21352; Wed, 5 Jul 2006 16:58:39 +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 k656wXgw1526622; Wed, 5 Jul 2006 16:58:34 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k656wOnw1532470; Wed, 5 Jul 2006 16:58:24 +1000 (EST) Date: Wed, 5 Jul 2006 16:58:24 +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: <20060705165824.A1531920@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> <20060705152652.F1521039@wobbly.melbourne.sgi.com> <20060705064651.GA28084@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: <20060705064651.GA28084@elte.hu>; from mingo@elte.hu on Wed, Jul 05, 2006 at 08:46:51AM +0200 X-archive-position: 8123 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: 666 Lines: 19 On Wed, Jul 05, 2006 at 08:46:51AM +0200, Ingo Molnar wrote: > > 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. > ... > 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()) Oh, right, I see - yes, I think that could be generally useful and we'd get some value out of that in XFS for sure. Thanks. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jul 5 12:56:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Jul 2006 12:56:27 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k65Ju4DW022925 for ; Wed, 5 Jul 2006 12:56:04 -0700 Received: from beardog.cca.cpqcorp.net (beardog.cca.cpqcorp.net [16.101.176.144]) by palrel11.hp.com (Postfix) with ESMTP id 8549435622; Wed, 5 Jul 2006 11:03:34 -0700 (PDT) Received: by beardog.cca.cpqcorp.net (Postfix, from userid 1000) id 25DF34B707; Wed, 5 Jul 2006 13:03:34 -0500 (CDT) Date: Wed, 5 Jul 2006 13:03:34 -0500 From: "Mike Miller (OS Dev)" To: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org Cc: hch@infradead.org, xfs@oss.sgi.com, nickolay@protei.ru, mmontour@bycast.com, iss_storagedev@hp.com Subject: [PATCH 1/2] cciss: add BLKSSZGET back to 2.4 driver Message-ID: <20060705180334.GA9656@beardog.cca.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 8128 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikem@beardog.cca.cpqcorp.net Precedence: bulk X-list: xfs Content-Length: 789 Lines: 24 PATCH 1/2 This patch adds BLKSSZGET into the cciss driver. Not sure why it isn't in there. I'm sure it used to be. :) Thanks to Nicolay and others for reporting this. Signed-off-by: Mike Miller ------------------------------------------------------------------------------------------ cciss.c | 1 + 1 files changed, 1 insertion(+) diff -burNp linux-2.4.32.orig/drivers/block/cciss.c linux-2.4.32/drivers/block/cciss.c --- linux-2.4.32.orig/drivers/block/cciss.c 2005-11-16 13:12:54.000000000 -0600 +++ linux-2.4.32/drivers/block/cciss.c 2006-07-05 12:54:41.000000000 -0500 @@ -740,6 +740,7 @@ static int cciss_ioctl(struct inode *ino case BLKFLSBUF: case BLKBSZSET: case BLKBSZGET: + case BLKSSZGET: case BLKROSET: case BLKROGET: case BLKRASET: From owner-xfs@oss.sgi.com Wed Jul 5 16:16:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Jul 2006 16:17:09 -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 k65NGQDW012352 for ; Wed, 5 Jul 2006 16:16: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 JAA11680; Thu, 6 Jul 2006 09:15:46 +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 k65NFegw1550881; Thu, 6 Jul 2006 09:15:40 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k65NFaB81550983; Thu, 6 Jul 2006 09:15:36 +1000 (EST) Date: Thu, 6 Jul 2006 09:15:35 +1000 From: Nathan Scott To: Ingo Molnar Cc: xfs@oss.sgi.com Subject: Annotating xfs_lock_inodes Message-ID: <20060706091535.B1548326@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8129 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: 2789 Lines: 80 Hi Ingo, On Tue, Jul 04, 2006 at 10:41:43AM +0200, Ingo Molnar wrote: > * Ingo Molnar wrote: > > 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. OK, I'm looking at the next one - we have a routine which will take two arbitary xfs_inode's and lock them in inode number order, named xfs_lock_inodes. Its used on link, rename, and by the online file defragmenter... how could I approach annotating that? I can't see an obvious way to fit it into this "nesting subclasses" model you've outlined (below). Also, how/where does your new xfs_ilock_class enum get used? > +/* > + * 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 > +}; Thanks. Oh, here's the details of the lockdep report from a link operation, for example: ============================================= [ INFO: possible recursive locking detected ] --------------------------------------------- mount/997 is trying to acquire lock: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0xae/0xe0 but task is already holding lock: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0xae/0xe0 other info that might help us debug this: 3 locks held by mount/997: #0: (&inode->i_mutex/1){--..}, at: [] lookup_create+0x25/0x80 #1: (&inode->i_mutex){--..}, at: [] mutex_lock+0x8/0x10 #2: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0xae/0xe0 stack backtrace: [] show_trace+0x1b/0x20 [] dump_stack+0x24/0x30 [] __lock_acquire+0x606/0xd10 [] lock_acquire+0x69/0x90 [] down_write+0x37/0x50 [] xfs_ilock+0xae/0xe0 [] xfs_lock_inodes+0x123/0x150 [] xfs_link+0x1a4/0x510 [] xfs_vn_link+0x4b/0xb0 [] vfs_link+0xe0/0x150 [] sys_linkat+0xfc/0x120 [] sys_link+0x2f/0x40 [] syscall_call+0x7/0xb -- Nathan From owner-xfs@oss.sgi.com Wed Jul 5 23:34:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Jul 2006 23:35:13 -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 k666YZDW003559 for ; Wed, 5 Jul 2006 23:34:47 -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 PAA19971; Thu, 6 Jul 2006 15:27:33 +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 k665REEo22616460; Thu, 6 Jul 2006 15:27:14 +1000 (AEST) Received: (from bnaujok@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k665RC1F22625631; Thu, 6 Jul 2006 15:27:12 +1000 (AEST) Date: Thu, 6 Jul 2006 15:27:12 +1000 (AEST) From: Barry Naujok Message-Id: <200607060527.k665RC1F22625631@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 858691 - X-archive-position: 8130 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 589 Lines: 18 xfs_repair deletes duplicate name. Deleted entries end up in lost+found. Date: Thu Jul 6 15:23:12 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: mvalluri@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26446a xfsprogs/repair/phase6.c - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h - pv:858691 xfs_repair deletes duplicate name. Deleted entries end up in lost+found. From owner-xfs@oss.sgi.com Thu Jul 6 04:21:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 04:21:27 -0700 (PDT) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k66BL7DW003490 for ; Thu, 6 Jul 2006 04:21:12 -0700 Received: from saturn.flamingspork.com (ppp163-199.static.internode.on.net [150.101.163.199]) by ash25e.internode.on.net (8.13.6/8.13.5) with ESMTP id k66BKYAa086553 for ; Thu, 6 Jul 2006 20:50:38 +0930 (CST) (envelope-from stewart@flamingspork.com) Received: from localhost.localdomain (unknown [192.168.1.100]) by saturn.flamingspork.com (Postfix) with ESMTP id D51C0C3B3CF for ; Thu, 6 Jul 2006 21:20:34 +1000 (EST) Received: by localhost.localdomain (Postfix, from userid 1000) id 85A8A140F83B; Thu, 6 Jul 2006 21:20:34 +1000 (EST) Subject: [Fwd: [Bug 120622] Default isize of 256 bytes is too small for SE Linux] From: Stewart Smith To: linux-xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rAkO2fN+LS3zuWkYBYXK" Date: Thu, 06 Jul 2006 21:20:33 +1000 Message-Id: <1152184834.7813.139.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-archive-position: 8131 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: xfs Content-Length: 1679 Lines: 59 --=-rAkO2fN+LS3zuWkYBYXK Content-Type: text/plain Content-Transfer-Encoding: quoted-printable People using RH/FC and XFS with SELinux should defaultly see much better performance with XFS in new versions now. The fix to make the default inode size bigger (to allow the SELinux xattrs to fit in the inode) has been committed! -------- Forwarded Message -------- > From: bugzilla@redhat.com > To: stewart@flamingspork.com > Subject: [Bug 120622] Default isize of 256 bytes is too small for SE > Linux > Date: Wed, 5 Jul 2006 09:27:43 -0400 >=20 > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. >=20 > Summary: Default isize of 256 bytes is too small for SE Linux >=20 >=20 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D120622 >=20 >=20 > katzj@redhat.com changed: >=20 > What |Removed |Added > -------------------------------------------------------------------------= --- > Status|NEW |CLOSED > Resolution| |RAWHIDE >=20 >=20 >=20 >=20 > ------- Additional Comments From katzj@redhat.com 2006-07-05 09:18 EST -= ------ > Committed >=20 --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-rAkO2fN+LS3zuWkYBYXK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBErPIBKglWCUL+FDoRAoLyAJ0QoLXgr3mBj593Pa/Bzis8TNvF6wCbB25F lowD3/nwDv1/obqPohTh928= =yEhY -----END PGP SIGNATURE----- --=-rAkO2fN+LS3zuWkYBYXK-- From owner-xfs@oss.sgi.com Thu Jul 6 14:04:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 14:04:51 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k66L4cDW031048 for ; Thu, 6 Jul 2006 14:04:39 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id EC4786362239; Thu, 6 Jul 2006 17:04:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id E7DA01615BD41 for ; Thu, 6 Jul 2006 17:04:09 -0400 (EDT) Date: Thu, 6 Jul 2006 17:04:09 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com Subject: Anyone use xfs_growfs under Linux? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8132 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 291 Lines: 5 I have a 6 disk RAID5, I just added another disk, I plan to use the kernel feature in 2.6.17 to "hot-add" an additional disk to the array (not a spare), then I plan to use xfs_growfs to grow the filesystem to the maximum size it can support. Has anyone used this or done this in Linux? From owner-xfs@oss.sgi.com Thu Jul 6 14:50:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 14:51:10 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k66LolDW004121 for ; Thu, 6 Jul 2006 14:50:47 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 3F03D636223A; Thu, 6 Jul 2006 17:50:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 39BF31615BD41; Thu, 6 Jul 2006 17:50:29 -0400 (EDT) Date: Thu, 6 Jul 2006 17:50:29 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Keith Owens cc: xfs@oss.sgi.com Subject: Re: Anyone use xfs_growfs under Linux? In-Reply-To: <10206.1152222039@ocs3.ocs.com.au> Message-ID: References: <10206.1152222039@ocs3.ocs.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8133 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 545 Lines: 16 On Fri, 7 Jul 2006, Keith Owens wrote: > Justin Piszcz (on Thu, 6 Jul 2006 17:04:09 -0400 (EDT)) wrote: >> I have a 6 disk RAID5, I just added another disk, I plan to use the kernel >> feature in 2.6.17 to "hot-add" an additional disk to the array (not a >> spare), then I plan to use xfs_growfs to grow the filesystem to the >> maximum size it can support. Has anyone used this or done this in Linux? > > Several times. Not a problem, as long as the filesystem is not mounted > at the time. > Cool, will give it a shot tomorrow, thanks. From owner-xfs@oss.sgi.com Thu Jul 6 15:53:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 15:53:51 -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 k66MrMDW011447 for ; Thu, 6 Jul 2006 15:53:33 -0700 Received: from mail.ocs.com.au (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA08789 for ; Fri, 7 Jul 2006 07:40:41 +1000 Received: from ocs3.ocs.com.au (ocs3w.ocs.com.au [192.168.254.3]) by mail.ocs.com.au (Postfix) with ESMTP id D9567E0B20A; Fri, 7 Jul 2006 07:40:40 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 7918C2E6D; Fri, 7 Jul 2006 07:40:39 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 749DF81EF4; Fri, 7 Jul 2006 07:40:39 +1000 (EST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1 From: Keith Owens To: Justin Piszcz cc: xfs@oss.sgi.com Subject: Re: Anyone use xfs_growfs under Linux? In-reply-to: Your message of "Thu, 06 Jul 2006 17:04:09 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jul 2006 07:40:39 +1000 Message-ID: <10206.1152222039@ocs3.ocs.com.au> X-archive-position: 8134 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: xfs Content-Length: 444 Lines: 9 Justin Piszcz (on Thu, 6 Jul 2006 17:04:09 -0400 (EDT)) wrote: >I have a 6 disk RAID5, I just added another disk, I plan to use the kernel >feature in 2.6.17 to "hot-add" an additional disk to the array (not a >spare), then I plan to use xfs_growfs to grow the filesystem to the >maximum size it can support. Has anyone used this or done this in Linux? Several times. Not a problem, as long as the filesystem is not mounted at the time. From owner-xfs@oss.sgi.com Thu Jul 6 16:34:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 16:34:31 -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 k66NXpDW021424 for ; Thu, 6 Jul 2006 16:34:05 -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 JAA11320; Fri, 7 Jul 2006 09:33:12 +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 k66NWoEo23272118; Fri, 7 Jul 2006 09:32:52 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k66NWkEU22599298; Fri, 7 Jul 2006 09:32:46 +1000 (AEST) Date: Fri, 7 Jul 2006 09:32:46 +1000 From: David Chinner To: Adrian Bunk Cc: xfs-masters@oss.sgi.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: fs/xfs/xfs_vnodeops.c:xfs_readdir(): NULL variable dereferenced Message-ID: <20060706233246.GB15160733@melbourne.sgi.com> References: <20060706211320.GW26941@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060706211320.GW26941@stusta.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 8135 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: 1324 Lines: 51 On Thu, Jul 06, 2006 at 11:13:20PM +0200, Adrian Bunk wrote: > The Coverity checker spotted the following: > > <-- snip --> > > ... > STATIC int > xfs_readdir( > bhv_desc_t *dir_bdp, > uio_t *uiop, > cred_t *credp, > int *eofp) > { > xfs_inode_t *dp; > xfs_trans_t *tp = NULL; > int error = 0; > uint lock_mode; > > vn_trace_entry(BHV_TO_VNODE(dir_bdp), __FUNCTION__, > (inst_t *)__return_address); > dp = XFS_BHVTOI(dir_bdp); > > if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > return XFS_ERROR(EIO); > > lock_mode = xfs_ilock_map_shared(dp); > error = xfs_dir_getdents(tp, dp, uiop, eofp); > xfs_iunlock_map_shared(dp, lock_mode); > return error; > } > ... > > <-- snip --> > > Note that tp is never assigned any value other than NULL (and the > Coverity checker found a way how tp might be dereferenced four function > calls later). Then the bug is probably in the function call that uses tp without first checking whether it's null. Can you tell us where that dereference occurs? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jul 6 17:51:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 17:51: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 k670opDW032408 for ; Thu, 6 Jul 2006 17:51:05 -0700 Received: from mail.ocs.com.au (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11748 for ; Fri, 7 Jul 2006 09:52:05 +1000 Received: from ocs3.ocs.com.au (ocs3w.ocs.com.au [192.168.254.3]) by mail.ocs.com.au (Postfix) with ESMTP id 76531E0B20A; Fri, 7 Jul 2006 09:52:04 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 45CC52E6D; Fri, 7 Jul 2006 09:52:03 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 14CCF81EF4; Fri, 7 Jul 2006 09:52:03 +1000 (EST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1 From: Keith Owens To: Chris Wedgwood cc: linux-xfs@oss.sgi.com Subject: Re: Anyone use xfs_growfs under Linux? In-reply-to: Your message of "Thu, 06 Jul 2006 16:35:38 MST." <20060706233538.GA9665@tuatara.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jul 2006 09:52:03 +1000 Message-ID: <5908.1152229923@ocs3.ocs.com.au> X-archive-position: 8136 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: xfs Content-Length: 587 Lines: 18 Chris Wedgwood (on Thu, 6 Jul 2006 16:35:38 -0700) wrote: >(off the list) > >On Fri, Jul 07, 2006 at 07:40:39AM +1000, Keith Owens wrote: > >> Several times. Not a problem, as long as the filesystem is not >> mounted at the time. > >growfs should work when mounted > >why the caveat? AFAIK you cannot change the kernel's view of the partition size while the partition is mounted. Adding the extra disk has to be done with the partition (and hence the filesystem) offline. xfs_growfs works on mounted filesystems. My comment mistakenly merged the two, quite separate, requirements. From owner-xfs@oss.sgi.com Thu Jul 6 19:09:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 19:09:34 -0700 (PDT) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.182.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6728wDW011033 for ; Thu, 6 Jul 2006 19:09:12 -0700 X-Trace: 53616c7465645f5f379c162871a9495459e3650ecd06771a457fad39eadc30e1d115a83fecd0c3c399f1ab165d1b499205cb7ba48ac1a8407be716e61b5542277b910b8d01e167b8f950ec8dd908765dea43b33977be239fc714d3667fe33202 Received: from [127.0.0.1] (67-137-114-185.dsl2.brv.mn.frontiernet.net [67.137.114.185]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 5063236417F; Fri, 7 Jul 2006 00:09:44 +0000 (UTC) Message-ID: <44ADA638.7080308@xfs.org> Date: Thu, 06 Jul 2006 19:09:28 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Piszcz CC: Keith Owens , xfs@oss.sgi.com Subject: Re: Anyone use xfs_growfs under Linux? References: <10206.1152222039@ocs3.ocs.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8138 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: xfs Content-Length: 706 Lines: 31 Keith should know better ;-) xfs_growfs runs on a mounted filesystem, not an unmounted one. Steve Justin Piszcz wrote: > > > On Fri, 7 Jul 2006, Keith Owens wrote: > >> Justin Piszcz (on Thu, 6 Jul 2006 17:04:09 -0400 (EDT)) wrote: >> >>> I have a 6 disk RAID5, I just added another disk, I plan to use the >>> kernel >>> feature in 2.6.17 to "hot-add" an additional disk to the array (not a >>> spare), then I plan to use xfs_growfs to grow the filesystem to the >>> maximum size it can support. Has anyone used this or done this in >>> Linux? >> >> >> Several times. Not a problem, as long as the filesystem is not mounted >> at the time. >> > > Cool, will give it a shot tomorrow, thanks. > > From owner-xfs@oss.sgi.com Thu Jul 6 22:20:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Jul 2006 22:20:34 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k675K9DW012095 for ; Thu, 6 Jul 2006 22:20:13 -0700 Received: (qmail 15978 invoked from network); 7 Jul 2006 03:48:34 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 7 Jul 2006 03:48:34 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 6A2B91812D3B; Thu, 6 Jul 2006 20:48:33 -0700 (PDT) Date: Thu, 6 Jul 2006 20:48:33 -0700 From: Chris Wedgwood To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: Anyone use xfs_growfs under Linux? Message-ID: <20060707034833.GB12908@tuatara.stupidest.org> References: <20060706233538.GA9665@tuatara.stupidest.org> <5908.1152229923@ocs3.ocs.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5908.1152229923@ocs3.ocs.com.au> X-archive-position: 8139 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: 481 Lines: 11 On Fri, Jul 07, 2006 at 09:52:03AM +1000, Keith Owens wrote: > AFAIK you cannot change the kernel's view of the partition size > while the partition is mounted. Adding the extra disk has to be > done with the partition (and hence the filesystem) offline. > xfs_growfs works on mounted filesystems. My comment mistakenly > merged the two, quite separate, requirements. for parition tables that's correct, but if he is using LVM or similar it should work w/o needing to remount From owner-xfs@oss.sgi.com Fri Jul 7 03:27:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Jul 2006 03:27:50 -0700 (PDT) Received: from mail1.gnw.de (mx1.turtle-entertainment.de [193.41.200.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k67ARPDW030968; Fri, 7 Jul 2006 03:27:26 -0700 Received: from 85.14.195.124.static.rdns-uclo.net ([85.14.195.124] helo=localhost) by mail1.gnw.de with esmtpa (Exim 4.50) id 1FymOR-0007FF-6U; Fri, 07 Jul 2006 11:12:59 +0200 Received: from [212.6.194.97] (helo=[212.6.194.97]) by localhost with asmtp (Exim 3.22 #7 (Debian)) id 1FymOR-0003SA-00; Fri, 07 Jul 2006 11:12:59 +0200 Message-ID: <44AE2597.2020601@turtle-entertainment.de> Date: Fri, 07 Jul 2006 11:12:55 +0200 From: Bjoern Metzdorf User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, xfs@oss.sgi.com CC: Kevin Corry Subject: XFS corruption problem References: <23706.212.23.126.27.1152216708.squirrel@mail.office.turtle-entertainment.de> <200607061541.05192.kevcorry@us.ibm.com> In-Reply-To: <200607061541.05192.kevcorry@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8141 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bm@turtle-entertainment.de Precedence: bulk X-list: xfs Content-Length: 2921 Lines: 67 Hello everybody, we have some major problems with a 10 TB XFS filesystem mounted as an ISCSI device under Linux 2.6. After a firmware upgrade on the underlying raid-controller, the device (/dev/sdb) has lost its partition table. /dev/sdb1 was the only device in an EVMS cluster volume. Kevin Corry, one of the fellow EVMS developers who tries to help us, had a look at the first 1024k bytes of /dev/sdb1 and could not find rests of EVMS metadata, but suspected rests of the XFS filesystem beginning at sector 31: Here are his comments: > There doesn't appear to be any EVMS metadata at the front of sdb1, but there > does seem to be some sort of filesystem data starting at sector 31. There are > definitely XFS inode signatures, but unfortunately I don't see anything that > looks like an XFS superblock signature. > > One thing you could do to see if you can find an alternate superblock is run: > hexdump -C /dev/evms/.nodes/sdb1 |grep XFSB > It could take a while, since you've got a 9 TB disk. You might want to just > let it run for a bit and then kill it. Let me know if that reveals anything. > > To get the EVMS cluster container back, you can simply recreate it on sdb1. > Just delete the /dev/evms/sdb1 compatibility volume, and assign the Cluster > Segment Manager to sdb1 with the same name/options you used when you > originally created it. If you had an EVMS volume on that cluster segment, you > can recreate it as well. None of these operations will overwrite any of the > filesystem data. > > Unfortunately, I don't know how to restore the XFS superblock without running > mkfs.xfs (which you probably don't want to do). That's outside the scope of > what EVMS handles. At this point I would suspect some sort of data > corruption, seemingly related to the firmware update. You might ask on the > XFS mailing lists if there are any recovery tools that would help in this > situation, since it seems like a lot of your data is still there. We already tried running xfs_repair -n on /dev/sdb1, with only the following results repeating like 10 times: primary superblock not found, looking for secodaries ... .......... .. found candidate secondary superblock... .. unable to verify superblock, continuing... .. found candidate secondary superblock... .. unable to verify superblock, continuing... and so on. We did not run xfs_repair without -n yet, because we still were not able to make a full dump of the whole 10 TB to another device :/ Is there anything we can do to get our data back? Are there any other tools or manual debug methods we can use to recover things? This is an urgent case for us, we appreciate every help we can get, we are also willing to pay for consulting and support. Please reply also off list to me, as I am not subscribed to linux-xfs right now, and please excuse my cross post to xfs and linux-xfs. Thanks in advance Regards, Bjoern From owner-xfs@oss.sgi.com Fri Jul 7 05:48:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Jul 2006 05:48:47 -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 k67CmODW025651 for ; Fri, 7 Jul 2006 05:48:25 -0700 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k67Cm0fw006638 for ; Fri, 7 Jul 2006 21:48:00 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by tyo202.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k67CfXob004163; Fri, 7 Jul 2006 21:41:33 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k67CfXE26369; Fri, 7 Jul 2006 21:41:33 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id k67CfWr21007; Fri, 7 Jul 2006 21:41:32 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k67CfWoM008305; Fri, 7 Jul 2006 21:41:32 +0900 To: David Chinner 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 In-reply-to: <20060704204145.GU15160733@melbourne.sgi.com> Message-Id: <20060707214131m-saito@mail.aom.tnes.nec.co.jp> References: <20060704204145.GU15160733@melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Fri, 7 Jul 2006 21:41:31 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8142 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: 631 Lines: 18 Thank you for comments. >You'd be talking about xfs_iunpin(), wouldn't you ;) Yes, of course. >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? We applied the above TAKE to linux-2.6.17.1 and tested it. However, we confirm the case that i_state of the inode was changed when the inode was freed in xfs filesystem. We think that the TAKE reduces the occurrence only. And we think that our patch fixes the problem. Could you review our patch again? From owner-xfs@oss.sgi.com Fri Jul 7 11:02:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Jul 2006 11:02:34 -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 k67I0wDW017333 for ; Fri, 7 Jul 2006 11:02:13 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FyucP-0001fI-By for linux-xfs@oss.sgi.com; Fri, 07 Jul 2006 19:59:57 +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 ; Fri, 07 Jul 2006 19:59:57 +0200 Received: from asjo by 0x50a5b872.bynxx12.adsl-dhcp.tele.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Jul 2006 19:59:57 +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: Fri, 07 Jul 2006 19:59:36 +0200 Organization: koldfront - analysis & revolution, Copenhagen, Denmark Message-ID: <87fyhd1ek7.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> <87veqhfmo4.fsf@topper.koldfront.dk> <20060704114721.I1495869@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 Sat, Jul 01, 2006 at 04:02:35PM +0200, Adam Sj?gren wrote: >> I proceeded to run xfs_repair. In Phase 3 under '- agno 0' it said: >> bad dir magic number 0x30 in inode 180 bno = 8388608 (That is my /lost+found/, 'ls -i' says). >> 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. Ah, ok - thanks. >> 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. I see - thanks. >> 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. I can't. 'rm' hangs in diskwait (ps says 'D') indefinitely (I let it sit for several hours) if I try. Even 'ls /lost+found/' does so. I've just run 'badblocks' and 'dd_rescue' (to /dev/null) on the disk to double check that it isn't a physical problem. Neither reported errors. Any pointers on what to look at? Thanks! Adam -- "Subdued flamboyance" Adam Sjøgren asjo@koldfront.dk From owner-xfs@oss.sgi.com Fri Jul 7 11:24:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Jul 2006 11:24:55 -0700 (PDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k67IO7DW021151 for ; Fri, 7 Jul 2006 11:24:27 -0700 Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (sccrmhc14) with ESMTP id <20060707172229014004ggtde>; Fri, 7 Jul 2006 17:22:29 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k67HMqEE065362; Fri, 7 Jul 2006 13:22:52 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k67HMq1P065361; Fri, 7 Jul 2006 13:22:52 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 7 Jul 2006 13:22:51 -0400 From: Craig Rodrigues To: xfs@oss.sgi.com Cc: nathans@sgi.com Subject: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060707172251.GA65338@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 8144 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 395 Lines: 21 Hi, I see some new additions to xfsprogs/po/Makefile: TOPDIR = .. include $(TOPDIR)/include/builddefs POTHEAD = $(PKG_NAME).pot LINGUAS = pl LSRCFILES = $(LINGUAS:%=%.po) $(POTHEAD) LDIRT = $(POTHEAD) Before, LINGUAS was an empty variable, but now it seems to be set to install the Polish locale message files. Why was this change made? -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Fri Jul 7 11:29:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Jul 2006 11:30:08 -0700 (PDT) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k67ITfDW022145 for ; Fri, 7 Jul 2006 11:29:44 -0700 Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (sccrmhc15) with ESMTP id <2006070718291301500d2gsde>; Fri, 7 Jul 2006 18:29:17 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k67ITarL065856; Fri, 7 Jul 2006 14:29:36 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k67ITa43065855; Fri, 7 Jul 2006 14:29:36 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 7 Jul 2006 14:29:36 -0400 From: Craig Rodrigues To: xfs@oss.sgi.com Cc: nathans@sgi.com Subject: xfsprogs 2.8.4 log_misc.c patch Message-ID: <20060707182936.GA65851@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 8145 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 1259 Lines: 38 Hi, I'm not sure what to do about other platforms, but on FreeBSD, I could not compile this file in xfsprogs 2.8.4 without this patch: Index: log_misc.c =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/logprint/log_misc.c,v retrieving revision 1.21 diff -u -u -r1.21 log_misc.c --- log_misc.c 16 Jun 2006 03:52:27 -0000 1.21 +++ log_misc.c 7 Jul 2006 18:28:07 -0000 @@ -1530,7 +1530,7 @@ in_f->ilf_dsize = in_f32->ilf_dsize; in_f->ilf_ino = in_f32->ilf_ino; /* copy biggest */ - memcpy(in_f->ilf_u.ilfu_uuid, in_f32->ilf_u.ilfu_uuid, sizeof(uuid_t)); + memcpy(&in_f->ilf_u.ilfu_uuid, &in_f32->ilf_u.ilfu_uuid, sizeof(uuid_t)); in_f->ilf_blkno = in_f32->ilf_blkno; in_f->ilf_len = in_f32->ilf_len; in_f->ilf_boffset = in_f32->ilf_boffset; @@ -1546,7 +1546,7 @@ in_f->ilf_dsize = in_f64->ilf_dsize; in_f->ilf_ino = in_f64->ilf_ino; /* copy biggest */ - memcpy(in_f->ilf_u.ilfu_uuid, in_f64->ilf_u.ilfu_uuid, sizeof(uuid_t)); + memcpy(&in_f->ilf_u.ilfu_uuid, &in_f64->ilf_u.ilfu_uuid, sizeof(uuid_t)); in_f->ilf_blkno = in_f64->ilf_blkno; in_f->ilf_len = in_f64->ilf_len; in_f->ilf_boffset = in_f64->ilf_boffset; -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Sat Jul 8 11:13:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 11:13:45 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k68IDDDW015342 for ; Sat, 8 Jul 2006 11:13:14 -0700 Received: by nf-out-0910.google.com with SMTP id c31so449583nfb for ; Sat, 08 Jul 2006 11:12:52 -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=W9RLWeFjiV9AkMUvYLLpAXfpdAAa9CT9PXXgioyhd+iwxxdtmMf8CY7y2njwqT4vNyUHj2ll1tXSSYIktcrlAr3lmgLxefs9AF4XkqvPNKvFdgq7DgKU+0Egc6yNoNzcjm6ayLo9PdPmH0GVkd6/Cxy71uCzLT4UGNLusGgV2WU= Received: by 10.49.9.4 with SMTP id m4mr55557nfi; Sat, 08 Jul 2006 11:12:52 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id o9sm4535790nfa.2006.07.08.11.12.51; Sat, 08 Jul 2006 11:12:52 -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; Sat, 8 Jul 2006 22:12:57 +0400 (MSD) Date: Sat, 8 Jul 2006 22:12:52 +0400 From: Alexey Dobriyan To: Andrew Morton Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: [PATCH] xfs: move XFS_IOC_GETVERSION to main multiplexer Message-ID: <20060708181252.GA8091@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: 8148 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: 954 Lines: 37 * Don't do inode => vnode => inode conversion, use passed inode directly * Don't allocate and free memory on each call * As a consequence, don't have a chance to return ENOMEM, which would be truly bizarre error code for this ioctl. Signed-off-by: Alexey Dobriyan --- fs/xfs/linux-2.6/xfs_ioctl.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/fs/xfs/linux-2.6/xfs_ioctl.c +++ b/fs/xfs/linux-2.6/xfs_ioctl.c @@ -763,6 +763,8 @@ xfs_ioctl( return xfs_ioc_fsgeometry(mp, arg); case XFS_IOC_GETVERSION: + return put_user(inode->i_generation, (int __user *)arg); + case XFS_IOC_GETXFLAGS: case XFS_IOC_SETXFLAGS: case XFS_IOC_FSGETXATTR: @@ -1264,13 +1266,6 @@ xfs_ioc_xattr( break; } - case XFS_IOC_GETVERSION: { - flags = vn_to_inode(vp)->i_generation; - if (copy_to_user(arg, &flags, sizeof(flags))) - error = -EFAULT; - break; - } - default: error = -ENOTTY; break; From owner-xfs@oss.sgi.com Sat Jul 8 12:22:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 12:22:44 -0700 (PDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k68JMXDW027266 for ; Sat, 8 Jul 2006 12:22:34 -0700 Received: from [10.86.240.161] (bxb-natpool-121.cisco.com[12.159.148.121]) by comcast.net (sccrmhc14) with ESMTP id <20060708182131014005q7o0e>; Sat, 8 Jul 2006 18:21:31 +0000 Message-ID: <44AFF7AA.2040001@comcast.net> Date: Sat, 08 Jul 2006 14:21:30 -0400 From: Brian Davis User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Output of mkfs.xfs su/sw values don't match the command line su/sw values Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8149 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bridavis@comcast.net Precedence: bulk X-list: xfs Content-Length: 1084 Lines: 26 Hi, I have a 3Ware 7506-4LP card running RAID 5 across 3 x 300GB disks and 64KB stripe size with an xfs fs. I setup xfs like so: localhost ~ # mkfs.xfs -f -d sunit=128,swidth=256 /dev/sda1 meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578992 blks = sectsz=512 attr=0 data = bsize=4096 blocks=146527744, imaxpct=25 = sunit=16 swidth=32 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Why does the output display the sunit=16 and swidth=32 when I wanted it configured with 128 and 256 respectively? It looks like the output is displaying the fs block size (4096) rather than 512 blocks specified on the command line and the man page. Is this correct? Can someone confirm that the sunit and swidth are set correctly for my array setting? Thanks! From owner-xfs@oss.sgi.com Sat Jul 8 14:53:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 14:53:56 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k68LrfDW008047 for ; Sat, 8 Jul 2006 14:53:42 -0700 Received: by ug-out-1314.google.com with SMTP id e2so365221ugf for ; Sat, 08 Jul 2006 14:53:20 -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=Vby2Oks3vYDyWYvS66Q1p3TE1OTtSKeYaCuCkqbDvTStQC96+dUTXX0AAgHSfuVOFLTiIAoAU8p+PsE2CEnPpULQtgPcMcKiHPT0HFAcDewc1Y1PJpJS16+6cIrXvogDeGFfry4rFWvQyNHUXwgyxvWoOxGk+9V5y73YHZ0ZJps= Received: by 10.66.224.19 with SMTP id w19mr3363093ugg; Sat, 08 Jul 2006 14:53:20 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id w40sm1299866ugc.2006.07.08.14.53.19; Sat, 08 Jul 2006 14:53:20 -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; Sun, 9 Jul 2006 01:53:26 +0400 (MSD) Date: Sun, 9 Jul 2006 01:53:24 +0400 From: Alexey Dobriyan To: Andrew Morton Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: [PATCH] xfs: remove unused locking flags Message-ID: <20060708215324.GA7522@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: 8150 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: 3114 Lines: 96 Signed-off-by: Alexey Dobriyan --- fs/xfs/linux-2.6/xfs_lrw.c | 10 +++++----- fs/xfs/xfs_inode.h | 12 +----------- fs/xfs/xfs_iomap.c | 4 ++-- 3 files changed, 8 insertions(+), 18 deletions(-) --- a/fs/xfs/linux-2.6/xfs_lrw.c +++ b/fs/xfs/linux-2.6/xfs_lrw.c @@ -473,13 +473,13 @@ xfs_zero_last_block( * out sync. We need to drop the ilock while we do this so we * don't deadlock when the buffer cache calls back to us. */ - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL| XFS_EXTSIZE_RD); + XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL); loff = XFS_FSB_TO_B(mp, last_fsb); zero_len = mp->m_sb.sb_blocksize - zero_offset; error = xfs_iozero(ip, loff + zero_offset, zero_len, end_size); - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + XFS_ILOCK(mp, io, XFS_ILOCK_EXCL); ASSERT(error >= 0); return error; } @@ -580,7 +580,7 @@ xfs_zero_eof( * Drop the inode lock while we're doing the I/O. * We'll still have the iolock to protect us. */ - XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL); error = xfs_iozero(ip, XFS_FSB_TO_B(mp, start_zero_fsb), @@ -593,14 +593,14 @@ xfs_zero_eof( start_zero_fsb = imap.br_startoff + imap.br_blockcount; ASSERT(start_zero_fsb <= (end_zero_fsb + 1)); - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + XFS_ILOCK(mp, io, XFS_ILOCK_EXCL); } return 0; out_lock: - XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); + XFS_ILOCK(mp, io, XFS_ILOCK_EXCL); ASSERT(error >= 0); return error; } --- a/fs/xfs/xfs_inode.h +++ b/fs/xfs/xfs_inode.h @@ -343,20 +343,10 @@ #define XFS_IOLOCK_SHARED 0x002 #define XFS_ILOCK_EXCL 0x004 #define XFS_ILOCK_SHARED 0x008 #define XFS_IUNLOCK_NONOTIFY 0x010 -/* XFS_IOLOCK_NESTED 0x020 */ -#define XFS_EXTENT_TOKEN_RD 0x040 -#define XFS_SIZE_TOKEN_RD 0x080 -#define XFS_EXTSIZE_RD (XFS_EXTENT_TOKEN_RD|XFS_SIZE_TOKEN_RD) -#define XFS_WILLLEND 0x100 /* Always acquire tokens for lending */ -#define XFS_EXTENT_TOKEN_WR (XFS_EXTENT_TOKEN_RD | XFS_WILLLEND) -#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_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_ILOCK_SHARED) /* * Flags for xfs_iflush() --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -211,14 +211,14 @@ xfs_iomap( break; case BMAPI_WRITE: xfs_iomap_enter_trace(XFS_IOMAP_WRITE_ENTER, io, offset, count); - lockmode = XFS_ILOCK_EXCL|XFS_EXTSIZE_WR; + lockmode = XFS_ILOCK_EXCL; if (flags & BMAPI_IGNSTATE) bmapi_flags |= XFS_BMAPI_IGSTATE|XFS_BMAPI_ENTIRE; XFS_ILOCK(mp, io, lockmode); break; case BMAPI_ALLOCATE: xfs_iomap_enter_trace(XFS_IOMAP_ALLOC_ENTER, io, offset, count); - lockmode = XFS_ILOCK_SHARED|XFS_EXTSIZE_RD; + lockmode = XFS_ILOCK_SHARED; bmapi_flags = XFS_BMAPI_ENTIRE; /* Attempt non-blocking lock */ if (flags & BMAPI_TRYLOCK) { From owner-xfs@oss.sgi.com Sat Jul 8 16:12:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 16:13:19 -0700 (PDT) Received: from mail.merakdemo.com (dsl-KK-static-static-247.198.95.61.touchtelindia.net [61.95.198.247] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k68NClDW014599 for ; Sat, 8 Jul 2006 16:12:53 -0700 Received: from indiatimes.com ([192.168.1.11]) by mail.merakdemo.com (Merak 7.6.1) with SMTP id EQ584343 for ; Sun, 09 Jul 2006 02:38:45 +0530 Message-ID: <414559-22006768211120890@indiatimes.com> X-Priority: 1 Reply-To: CRM4BUSINESS From: "CRM4BUSINESS" To: "linux-xfs@oss.sgi.com" Subject: Delhi IT Directory - 2006 Date: Sun, 9 Jul 2006 02:41:20 +0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 8151 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: delhi_it2006@indiatimes.com Precedence: bulk X-list: xfs Content-Length: 1077 Lines: 28 Hi, The IT Industry in Delhi is booming! Here is a great opportunity for you to sell your products and services to this industry which is rapidly expanding. We offer the Delhi IT Directory 2006 that gives you over 2002 records of IT companies in Delhi including names of over 1779 top executives, Designations, Contact details including e-mails. Call us now and see your business increase in Delhi. Features of Delhi IT Directory: >> IT Companies >> IT Top Executives Features: >>Contains Company Name, Contact Person, Designation, Email, Address, Area, Pincode, Phone No, Fax, URL & Products/Services >> Available as different Excel Files in one pack ->Available in excel ->Revision: 1.0 / June 28 2006 ->File Size: 1.7 MB, Records: IT Companies 2002, IT Executives 1779 You can log on to http://www.crm4business.com/products/marketingdb/delhi_it.htm to know more about the Delhi IT Directory. Should you have any further questions, please do not hesitate to contact us. Renaissance Technologies Ph: +91 80 2353 7776. Ext. 1 URL: http://www.crm4business.com From owner-xfs@oss.sgi.com Sat Jul 8 17:51:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 17:51:46 -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 k690p4DW027607 for ; Sat, 8 Jul 2006 17:51:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03831; Sun, 9 Jul 2006 10:50:23 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k690oKgw1646153; Sun, 9 Jul 2006 10:50:20 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k690oEgw1646657; Sun, 9 Jul 2006 10:50:14 +1000 (EST) Date: Sun, 9 Jul 2006 10:50:14 +1000 From: Nathan Scott To: Alexey Dobriyan Cc: Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: move XFS_IOC_GETVERSION to main multiplexer Message-ID: <20060709105014.C1640104@wobbly.melbourne.sgi.com> References: <20060708181252.GA8091@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060708181252.GA8091@martell.zuzino.mipt.ru>; from adobriyan@gmail.com on Sat, Jul 08, 2006 at 10:12:52PM +0400 X-archive-position: 8152 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: 621 Lines: 20 On Sat, Jul 08, 2006 at 10:12:52PM +0400, Alexey Dobriyan wrote: > * Don't do inode => vnode => inode conversion, use passed inode directly > * Don't allocate and free memory on each call > * As a consequence, don't have a chance to return ENOMEM, which would be > truly bizarre error code for this ioctl. Yoohoo, I'm over here... send XFS patches to me please. Thats the second time I've asked you that... is there a problem there? > + return put_user(inode->i_generation, (int __user *)arg); > + Looks fine, I'll merge it when I'm in the office tomorrow. You've tested this change, right? cheers. -- Nathan From owner-xfs@oss.sgi.com Sat Jul 8 17:55:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 17:56:15 -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 k690tcDW028127 for ; Sat, 8 Jul 2006 17:55: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 KAA03887; Sun, 9 Jul 2006 10:55:02 +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 k690swgw1647902; Sun, 9 Jul 2006 10:54:59 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k690st6n1647998; Sun, 9 Jul 2006 10:54:55 +1000 (EST) Date: Sun, 9 Jul 2006 10:54:54 +1000 From: Nathan Scott To: Alexey Dobriyan Cc: Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060709105454.D1640104@wobbly.melbourne.sgi.com> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060708215324.GA7522@martell.zuzino.mipt.ru>; from adobriyan@gmail.com on Sun, Jul 09, 2006 at 01:53:24AM +0400 X-archive-position: 8153 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: 371 Lines: 14 On Sun, Jul 09, 2006 at 01:53:24AM +0400, Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan NACK. These macros get used by other SGI code (not merged in mainline). Their presence here has zero runtime cost, and keeps merges simpler for me, so they need to stay. Thanks for the cleanup patches though, keep 'em coming. cheers. -- Nathan From owner-xfs@oss.sgi.com Sat Jul 8 18:05:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 18:06: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 k6915kDW029373 for ; Sat, 8 Jul 2006 18:05:57 -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 LAA04118; Sun, 9 Jul 2006 11:05:06 +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 k69153gw1647448; Sun, 9 Jul 2006 11:05:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6914xXo1648037; Sun, 9 Jul 2006 11:04:59 +1000 (EST) Date: Sun, 9 Jul 2006 11:04:59 +1000 From: Nathan Scott To: Adrian Bunk Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [xfs-masters] Re: fs/xfs/xfs_vnodeops.c:xfs_readdir(): NULL variable dereferenced Message-ID: <20060709110459.F1640104@wobbly.melbourne.sgi.com> References: <20060706211320.GW26941@stusta.de> <20060706233246.GB15160733@melbourne.sgi.com> <20060708194609.GB5020@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060708194609.GB5020@stusta.de>; from bunk@stusta.de on Sat, Jul 08, 2006 at 09:46:09PM +0200 X-archive-position: 8154 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: 894 Lines: 30 On Sat, Jul 08, 2006 at 09:46:09PM +0200, Adrian Bunk wrote: > On Fri, Jul 07, 2006 at 09:32:46AM +1000, David Chinner wrote: > > > Coverity checker found a way how tp might be dereferenced four function > > > calls later). Keyword being "might". ;) > > Then the bug is probably in the function call that uses tp without > > first checking whether it's null. Can you tell us where that dereference > > occurs? > > xfs_readdir() > xfs_dir_getdents() > xfs_dir2_leaf_getdents() > xfs_bmapi() > xfs_trans_log_inode() > tp->t_flags |= XFS_TRANS_DIRTY; This actually cant happen due to the flags passed into xfs_bmapi (ie. request for a extent map _read_, which wont result in the inode being logged, which means no transaction dirtying). That suggestion to remove the local "tp" variable was valid though, we may as well do that (will do). cheers. -- Nathan From owner-xfs@oss.sgi.com Sat Jul 8 19:09:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 19:09:54 -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 k6929HDW001990 for ; Sat, 8 Jul 2006 19:09:28 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04890; Sun, 9 Jul 2006 12:08:42 +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 k6928egw1647865; Sun, 9 Jul 2006 12:08:40 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6928bhx1647215; Sun, 9 Jul 2006 12:08:37 +1000 (EST) Date: Sun, 9 Jul 2006 12:08:37 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com, nathans@sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060709120837.B1648127@wobbly.melbourne.sgi.com> References: <20060707172251.GA65338@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060707172251.GA65338@crodrigues.org>; from rodrigc@crodrigues.org on Fri, Jul 07, 2006 at 01:22:51PM -0400 X-archive-position: 8155 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: 700 Lines: 20 On Fri, Jul 07, 2006 at 01:22:51PM -0400, Craig Rodrigues wrote: > ... > Before, LINGUAS was an empty variable, but now it seems to > be set to install the Polish locale message files. > > Why was this change made? xfsprogs/docs/CHANGES has hints... the initial Polish translation was added 31 January 2006 (that was when LINGUAS was updated). I don't know what the underlying reason for your question is (?) but there were also recent changes to enforce the head .pot file to be regenerated on each build (previously this was a static file that was manually updated)... I suspect its this latter change which is causing you grief somehow (do you have xgettext on FreeBSD?). cheers. -- Nathan From owner-xfs@oss.sgi.com Sat Jul 8 19:14:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Jul 2006 19:14:39 -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 k692E2DW002498 for ; Sat, 8 Jul 2006 19:14:13 -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 MAA04926; Sun, 9 Jul 2006 12:13:26 +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 k692DNgw1648183; Sun, 9 Jul 2006 12:13:24 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k692DLdt1647532; Sun, 9 Jul 2006 12:13:21 +1000 (EST) Date: Sun, 9 Jul 2006 12:13:21 +1000 From: Nathan Scott To: Brian Davis Cc: xfs@oss.sgi.com Subject: Re: Output of mkfs.xfs su/sw values don't match the command line su/sw values Message-ID: <20060709121321.C1648127@wobbly.melbourne.sgi.com> References: <44AFF7AA.2040001@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44AFF7AA.2040001@comcast.net>; from bridavis@comcast.net on Sat, Jul 08, 2006 at 02:21:30PM -0400 X-archive-position: 8156 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: 1099 Lines: 27 On Sat, Jul 08, 2006 at 02:21:30PM -0400, Brian Davis wrote: > ... > localhost ~ # mkfs.xfs -f -d sunit=128,swidth=256 /dev/sda1 > meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578992 > blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=146527744, imaxpct=25 > = sunit=16 swidth=32 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > Why does the output display the sunit=16 and swidth=32 when I wanted it > configured with 128 and 256 respectively? It looks like the output is > displaying the fs block size (4096) rather than 512 blocks specified on > the command line and the man page. > Is this correct? Thats correct. Odd, isn't it? Dunno why it was done this way (waay before my time) ... its been like that forever though. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 9 06:59:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 07:00:14 -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 k69DxhDW020013 for ; Sun, 9 Jul 2006 06:59:44 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1FzYq3-0007qp-Vw; Sun, 09 Jul 2006 13:56:44 +0100 Date: Sun, 9 Jul 2006 13:56:43 +0100 From: Christoph Hellwig To: Nathan Scott Cc: Alexey Dobriyan , Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060709125643.GA28769@infradead.org> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060709105454.D1640104@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8159 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 729 Lines: 16 On Sun, Jul 09, 2006 at 10:54:54AM +1000, Nathan Scott wrote: > On Sun, Jul 09, 2006 at 01:53:24AM +0400, Alexey Dobriyan wrote: > > Signed-off-by: Alexey Dobriyan > > NACK. These macros get used by other SGI code (not merged in mainline). > Their presence here has zero runtime cost, and keeps merges simpler for > me, so they need to stay. > > Thanks for the cleanup patches though, keep 'em coming. I don't think theres a valid reason to keep such dead code around. If you want these flags to stay merge the code in mainline. And while we're at that it would be nice if git tree merges would go via -fsdevel with a full set of patches. There seem to be some rather odd things creeping in lately. From owner-xfs@oss.sgi.com Sun Jul 9 10:11:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 10:11:43 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k69HBJDW020262 for ; Sun, 9 Jul 2006 10:11:20 -0700 Received: by nf-out-0910.google.com with SMTP id p46so345724nfa for ; Sun, 09 Jul 2006 10:10:56 -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:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=KsyLOKzcUrfFl79mf6MTwvy+BnqvTRoCstdpmMcnOj+dpGD/eDgkgCHA/yUM3SjNsw7pwwB7TDpquVFBA2K+sh96ZyrMYxJr7H8FWXv2IApw7vjAH5C4xwpx7oS0dmMGLN5pjXomkSB9+OC73crVVZrxR1eKMuVchcqMFJre/7c= Received: by 10.48.249.9 with SMTP id w9mr766729nfh; Sun, 09 Jul 2006 10:10:56 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id i1sm5880632nfe.2006.07.09.10.10.55; Sun, 09 Jul 2006 10:10:56 -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; Sun, 9 Jul 2006 21:11:05 +0400 (MSD) Date: Sun, 9 Jul 2006 21:11:03 +0400 From: Alexey Dobriyan To: Nathan Scott Cc: Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060709170529.GA7539@martell.zuzino.mipt.ru> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060709105454.D1640104@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.11 X-archive-position: 8160 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: 677 Lines: 17 On Sun, Jul 09, 2006 at 10:54:54AM +1000, Nathan Scott wrote: > On Sun, Jul 09, 2006 at 01:53:24AM +0400, Alexey Dobriyan wrote: > > Signed-off-by: Alexey Dobriyan > > NACK. These macros get used by other SGI code (not merged in mainline). > Their presence here has zero runtime cost, and keeps merges simpler for > me, so they need to stay. In this case, yes, runtime overhead in nil. What about passing dummy credentials? What about DMAPI stubbed to errors since XFS hit mainline (at least 900 lines which can be removed)? They have runtime overhead. I can add "behavoir chains" here but patch for dealing with them doesn't exists yet, so I won't. From owner-xfs@oss.sgi.com Sun Jul 9 14:00:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 14:00:34 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k69L0ADW022834 for ; Sun, 9 Jul 2006 14:00:10 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 52C3B616D162; Sun, 9 Jul 2006 16:59:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 4CA2916195E53; Sun, 9 Jul 2006 16:59:48 -0400 (EDT) Date: Sun, 9 Jul 2006 16:59:48 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nathan Scott cc: Brian Davis , xfs@oss.sgi.com Subject: Re: Output of mkfs.xfs su/sw values don't match the command line su/sw values In-Reply-To: <20060709121321.C1648127@wobbly.melbourne.sgi.com> Message-ID: References: <44AFF7AA.2040001@comcast.net> <20060709121321.C1648127@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8161 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1471 Lines: 40 On Sun, 9 Jul 2006, Nathan Scott wrote: > On Sat, Jul 08, 2006 at 02:21:30PM -0400, Brian Davis wrote: >> ... >> localhost ~ # mkfs.xfs -f -d sunit=128,swidth=256 /dev/sda1 >> meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578992 >> blks >> = sectsz=512 attr=0 >> data = bsize=4096 blocks=146527744, imaxpct=25 >> = sunit=16 swidth=32 blks, unwritten=1 >> naming =version 2 bsize=4096 >> log =internal log bsize=4096 blocks=32768, version=1 >> = sectsz=512 sunit=0 blks >> realtime =none extsz=65536 blocks=0, rtextents=0 >> >> Why does the output display the sunit=16 and swidth=32 when I wanted it >> configured with 128 and 256 respectively? It looks like the output is >> displaying the fs block size (4096) rather than 512 blocks specified on >> the command line and the man page. >> Is this correct? > > Thats correct. Odd, isn't it? Dunno why it was done this way (waay > before my time) ... its been like that forever though. > > cheers. > > -- > Nathan > > You have to subtract/divide the units by a certain number, the PAGE SIZE or something, I do not have the docs in front of me but that is why it converts it, also, I have found mkfs.xfs default options automatically optimize for the number of drives in the raid (at least with SW raid). Justin. From owner-xfs@oss.sgi.com Sun Jul 9 15:18:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 15:18: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 k69MI4DW000628 for ; Sun, 9 Jul 2006 15:18:15 -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 IAA22692; Mon, 10 Jul 2006 08:17:20 +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 k69MHGgw1668804; Mon, 10 Jul 2006 08:17:16 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k69MHBEW1670505; Mon, 10 Jul 2006 08:17:11 +1000 (EST) Date: Mon, 10 Jul 2006 08:17:11 +1000 From: Nathan Scott To: Christoph Hellwig Cc: Alexey Dobriyan , Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060710081711.A1670244@wobbly.melbourne.sgi.com> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709125643.GA28769@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060709125643.GA28769@infradead.org>; from hch@infradead.org on Sun, Jul 09, 2006 at 01:56:43PM +0100 X-archive-position: 8162 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: 1154 Lines: 33 On Sun, Jul 09, 2006 at 01:56:43PM +0100, Christoph Hellwig wrote: > On Sun, Jul 09, 2006 at 10:54:54AM +1000, Nathan Scott wrote: > I don't think theres a valid reason to keep such dead code around. If Its not dead code. I will and have been happily removing dead code. > If you want these flags to stay merge the code in mainline. And while we're Well, if it makes my maintenance task more difficult without any gain whatsoever obviously thats not going to happen, sorry. > at that it would be nice if git tree merges would go via -fsdevel with > a full set of patches. Hmm - well, I could CC the mail I send Linus to xfs@oss if there's enough interest (fsdevel doesn't sound right to me), but the full patchset gets way too large (like when dir1 got removed the other day...), and interested people can easily get that anyway, so just hasn't seemed worth it. > There seem to be some rather odd things creeping in lately. Er, such as? And why not point these things out at the time, when people are working on it and committing the changes (and sending commit mail to xfs@oss), instead of this odd vague reference now? cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 9 15:48:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 15:48: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 k69Mm8DW004373 for ; Sun, 9 Jul 2006 15: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 IAA23256; Mon, 10 Jul 2006 08:47:31 +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 k69MlRgw1660946; Mon, 10 Jul 2006 08:47:28 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k69MlOPw1635604; Mon, 10 Jul 2006 08:47:24 +1000 (EST) Date: Mon, 10 Jul 2006 08:47:24 +1000 From: Nathan Scott To: Alexey Dobriyan Cc: Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060710084724.B1670244@wobbly.melbourne.sgi.com> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709170529.GA7539@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060709170529.GA7539@martell.zuzino.mipt.ru>; from adobriyan@gmail.com on Sun, Jul 09, 2006 at 09:11:03PM +0400 X-archive-position: 8163 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: 2624 Lines: 61 Hi Alexey, On Sun, Jul 09, 2006 at 09:11:03PM +0400, Alexey Dobriyan wrote: > On Sun, Jul 09, 2006 at 10:54:54AM +1000, Nathan Scott wrote: > > On Sun, Jul 09, 2006 at 01:53:24AM +0400, Alexey Dobriyan wrote: > > > Signed-off-by: Alexey Dobriyan > > > > NACK. These macros get used by other SGI code (not merged in mainline). > > Their presence here has zero runtime cost, and keeps merges simpler for > > me, so they need to stay. > > In this case, yes, runtime overhead in nil. > > What about passing dummy credentials? Yes, what about it? Is there any measurable cost there? Show me, I'm interested, really. If there is, I'm sure we can do things differently to remove that. I'm starting to get a little hesitant about your intentions here though to be honest, you seem to have a bit of an axe to grind (do you? why? was it something I said?). > What about DMAPI stubbed to errors > since XFS hit mainline (at least 900 lines which can be removed)? They > have runtime overhead. DMAPI is useful, and used - if its unfit for mainline (which a number of people seem to agree to) then why not be constructive and massage it into a form more fit for mainline, if thats the issue here? I did have a patch a little while back which made the mainline DMAPI "if (event-enabled)" stuff be compile-time conditional (which should be done independently of whether full-blown DMAPI is in mainline) -- I got side-tracked before thoroughly testing that change though. If you'd like that WIP patch, lemme know, and I'll happily pass it along. > I can add "behavoir chains" here but patch for dealing with them doesn't > exists yet, so I won't. You're a bit confused, there I think - behaviours are used today, in mainline, and there is active XFS feature development work relying on them even further. As such, that patch would also get NACKed. There is no harm in asking though. If you're unhappy with the way XFS is maintained, then it is GPL code and you're free to make of it as you will, of course, as far as the license permits. I'd prefer to work with you though to make useful changes to the mainline version, and would caution you that it is a very complex body of code that a few weeks of cleanup efforts really wont have prepared you for. Its also my hope that you'll find us XFS folks all round nice guys though :) and I'd vastly prefer to work with you to cleanup the version we maintain, in mutually satisfactory ways, but the choice is always yours. cheers. ps: you've not answered my question as to whether you tested your last change at all - did you? thanks. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 9 16:38:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 16:38:42 -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 k69NcJDW015068 for ; Sun, 9 Jul 2006 16:38:19 -0700 Received: by nf-out-0910.google.com with SMTP id y38so507232nfb for ; Sun, 09 Jul 2006 16:37:55 -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:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=LpUkxGbAmnRlzLMhOU7JBzoURMC+W5ImbyJCGcGQSeY0F1FXrRhPYNGuLHHt5kP7SJuErpOJBMYUxE64wiKRqdhr5nJ4Nv3qx2D0uJHSX5qe/HMh5LbUuKA9SSBCdu+ZDwxbhM9NiFSB/J+oP6f79Zj04FVFUkw5BQ0vAzWFm9Y= Received: by 10.48.143.9 with SMTP id q9mr3205283nfd; Sun, 09 Jul 2006 16:37:55 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id p72sm7435011nfc.2006.07.09.16.37.54; Sun, 09 Jul 2006 16:37:55 -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; Mon, 10 Jul 2006 03:38:04 +0400 (MSD) Date: Mon, 10 Jul 2006 03:38:03 +0400 From: Alexey Dobriyan To: Nathan Scott Cc: Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060709233423.GA7521@martell.zuzino.mipt.ru> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709170529.GA7539@martell.zuzino.mipt.ru> <20060710084724.B1670244@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060710084724.B1670244@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.11 X-archive-position: 8165 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: 224 Lines: 6 On Mon, Jul 10, 2006 at 08:47:24AM +1000, Nathan Scott wrote: > ps: you've not answered my question as to whether you tested your last > change at all - did you? thanks. I forgot again... Yes, patch was tested and is OK. From owner-xfs@oss.sgi.com Sun Jul 9 16:36:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 16:36:25 -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 k69NZqDW014649 for ; Sun, 9 Jul 2006 16:36:04 -0700 Received: from SGIGORT (mtv-vpn-sw-corp-0-55.corp.sgi.com [134.15.0.55]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA22767; Mon, 10 Jul 2006 08:25:34 +1000 Reply-To: From: "Mike Gigante" To: "'Alexey Dobriyan'" , "'Nathan Scott'" Cc: "'Andrew Morton'" , , Subject: RE: [PATCH] xfs: remove unused locking flags Date: Mon, 10 Jul 2006 08:25:07 +1000 Organization: Fileserving Technologies Message-ID: <016101c6a3a6$8d26d9b0$43000f86@SGIGORT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060709170529.GA7539@martell.zuzino.mipt.ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcajfBT8n9kaFSTKTTSQvTot5bsmAQAKdklA X-archive-position: 8164 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mg@sgi.com Precedence: bulk X-list: xfs Content-Length: 229 Lines: 11 > I can add "behavoir chains" here but patch for dealing with > them doesn't exists yet, so I won't. I wouldn't bother generating it either -- we have some very significant work-in-progress that relies on behaviours. Mike From owner-xfs@oss.sgi.com Sun Jul 9 17:04:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 17:05:12 -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 k6A04ZDW019438 for ; Sun, 9 Jul 2006 17:04:46 -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 KAA24665; Mon, 10 Jul 2006 10:03:58 +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 k6A03rgw1673298; Mon, 10 Jul 2006 10:03:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6A03nPC1672756; Mon, 10 Jul 2006 10:03:49 +1000 (EST) Date: Mon, 10 Jul 2006 10:03:49 +1000 From: Nathan Scott To: Alexey Dobriyan Cc: Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060710100349.F1670244@wobbly.melbourne.sgi.com> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709170529.GA7539@martell.zuzino.mipt.ru> <20060710084724.B1670244@wobbly.melbourne.sgi.com> <20060709233423.GA7521@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060709233423.GA7521@martell.zuzino.mipt.ru>; from adobriyan@gmail.com on Mon, Jul 10, 2006 at 03:38:03AM +0400 X-archive-position: 8167 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: 342 Lines: 12 On Mon, Jul 10, 2006 at 03:38:03AM +0400, Alexey Dobriyan wrote: > On Mon, Jul 10, 2006 at 08:47:24AM +1000, Nathan Scott wrote: > > ps: you've not answered my question as to whether you tested your last > > change at all - did you? thanks. > > I forgot again... Yes, patch was tested and is OK. Thanks Alexey, patch applied. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 9 17:02:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 17:03:12 -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 k6A02jDW019081 for ; Sun, 9 Jul 2006 17:02:57 -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 KAA24642 for ; Mon, 10 Jul 2006 10:02:15 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 0ED1C4831BA9; Mon, 10 Jul 2006 10:02:14 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - ioctl cleanup Message-Id: <20060710000214.0ED1C4831BA9@chook.melbourne.sgi.com> Date: Mon, 10 Jul 2006 10:02:14 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8166 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: 790 Lines: 21 Move XFS_IOC_GETVERSION to main multiplexer. Avoids doing an unnecessary inode to vnode conversion and avoids a memory allocation. Signed-off-by: Alexey Dobriyan Date: Mon Jul 10 10:01:36 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Alexey Dobriyan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26492a linux-2.6/xfs_ioctl.c - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h linux-2.4/xfs_ioctl.c - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h From owner-xfs@oss.sgi.com Sun Jul 9 17:38:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 17:39:14 -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 k6A0cWDW025390 for ; Sun, 9 Jul 2006 17:38:43 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25301; Mon, 10 Jul 2006 10:37: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 k6A0bkgw1615885; Mon, 10 Jul 2006 10:37:48 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6A0bejm1671533; Mon, 10 Jul 2006 10:37:40 +1000 (EST) Date: Mon, 10 Jul 2006 10:37:40 +1000 From: Nathan Scott To: Masayuki Saito Cc: David Chinner , 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: <20060710103740.B1674239@wobbly.melbourne.sgi.com> References: <20060704204145.GU15160733@melbourne.sgi.com> <20060707214131m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060707214131m-saito@mail.aom.tnes.nec.co.jp>; from m-saito@tnes.nec.co.jp on Fri, Jul 07, 2006 at 09:41:31PM +0900 X-archive-position: 8168 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: 1353 Lines: 34 On Fri, Jul 07, 2006 at 09:41:31PM +0900, Masayuki Saito wrote: > Thank you for comments. > > >You'd be talking about xfs_iunpin(), wouldn't you ;) > Yes, of course. > > >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? > We applied the above TAKE to linux-2.6.17.1 and tested it. > However, we confirm the case that i_state of the inode was changed > when the inode was freed in xfs filesystem. > > We think that the TAKE reduces the occurrence only. > And we think that our patch fixes the problem. > > Could you review our patch again? I'll leave it to Dave to comment more later (he's travelling at the moment), since he's had his head deep in this area of the code most recently - but my first thoughts on your patch are that its solving the problem incorrectly. We should not be in the destroy_inode code if the inode reference counting is correct everywhere - I would have expected the fix to be a get/put style change, rather than adding an inode lock and new lock/unlock semantics around an individual field; ... and if that cannot be done to fix this (eh?), then some comments as to why refcounting didn't solve the problem here. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 9 18:40:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 18:40:54 -0700 (PDT) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [216.148.227.155] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6A1eODW002477 for ; Sun, 9 Jul 2006 18:40:27 -0700 Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (rwcrmhc15) with ESMTP id <20060710014002m15004f20ie>; Mon, 10 Jul 2006 01:40:02 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k6A1e2ZS015542; Sun, 9 Jul 2006 21:40:02 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k6A1e2Kn015541; Sun, 9 Jul 2006 21:40:02 -0400 (EDT) (envelope-from rodrigc) Date: Sun, 9 Jul 2006 21:40:01 -0400 From: Craig Rodrigues To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060710014001.GA15511@crodrigues.org> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060709120837.B1648127@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8169 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 617 Lines: 18 On Sun, Jul 09, 2006 at 12:08:37PM +1000, Nathan Scott wrote: > xfsprogs/docs/CHANGES has hints... the initial Polish translation > was added 31 January 2006 (that was when LINGUAS was updated). I > was manually updated)... I suspect its this latter change which is > causing you grief somehow (do you have xgettext on FreeBSD?). I was just wondering why the xfsprogs build was suddenly installing this file: share/locale/pl/LC_MESSAGES/xfsprogs.mo when previous xfsprogs versions were not installing this file, but looks like this is "as-designed" behavior. -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Sun Jul 9 18:50:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 18:50:40 -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 k6A1o1DW004180 for ; Sun, 9 Jul 2006 18:50:17 -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 LAA26685; Mon, 10 Jul 2006 11:49:24 +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 k6A1nLgw1674042; Mon, 10 Jul 2006 11:49:22 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6A1nJN11674010; Mon, 10 Jul 2006 11:49:19 +1000 (EST) Date: Mon, 10 Jul 2006 11:49:19 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060710114919.C1675766@wobbly.melbourne.sgi.com> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> <20060710014001.GA15511@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060710014001.GA15511@crodrigues.org>; from rodrigc@crodrigues.org on Sun, Jul 09, 2006 at 09:40:01PM -0400 X-archive-position: 8170 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: 896 Lines: 25 On Sun, Jul 09, 2006 at 09:40:01PM -0400, Craig Rodrigues wrote: > On Sun, Jul 09, 2006 at 12:08:37PM +1000, Nathan Scott wrote: > > xfsprogs/docs/CHANGES has hints... the initial Polish translation > > was added 31 January 2006 (that was when LINGUAS was updated). I > > > was manually updated)... I suspect its this latter change which is > > causing you grief somehow (do you have xgettext on FreeBSD?). > > I was just wondering why the xfsprogs build was suddenly installing this file: > share/locale/pl/LC_MESSAGES/xfsprogs.mo > > when previous xfsprogs versions were not installing this file, but looks like this > is "as-designed" behavior. Yep. Polish speaking FreeBSD users the world over will thank you. ;) BTW, while I've got you - what does "id -u root" give on FreeBSD? (is it "id: root: No such user" and then exit with a non-zero error code?) thanks! cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 9 18:52:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 18:52:30 -0700 (PDT) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6A1qJDW004722 for ; Sun, 9 Jul 2006 18:52:20 -0700 Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (sccrmhc15) with ESMTP id <2006071001515701500d6355e>; Mon, 10 Jul 2006 01:51:58 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k6A1px73016893 for ; Sun, 9 Jul 2006 21:51:59 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k6A1px5G016892 for xfs@oss.sgi.com; Sun, 9 Jul 2006 21:51:59 -0400 (EDT) (envelope-from rodrigc) Date: Sun, 9 Jul 2006 21:51:59 -0400 From: Craig Rodrigues To: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060710015159.GA16864@crodrigues.org> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> <20060710014001.GA15511@crodrigues.org> <20060710114919.C1675766@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060710114919.C1675766@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8171 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 288 Lines: 13 On Mon, Jul 10, 2006 at 11:49:19AM +1000, Nathan Scott wrote: > BTW, while I've got you - what does "id -u root" give on FreeBSD? > (is it "id: root: No such user" and then exit with a non-zero error > code?) thanks! % id -u root 0 -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Sun Jul 9 19:22:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 19:22:37 -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 k6A2M0DW009766 for ; Sun, 9 Jul 2006 19:22:11 -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 MAA27314; Mon, 10 Jul 2006 12:21:24 +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 k6A2LLgw1673900; Mon, 10 Jul 2006 12:21:22 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6A2LJI21671220; Mon, 10 Jul 2006 12:21:19 +1000 (EST) Date: Mon, 10 Jul 2006 12:21:19 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060710122119.D1675766@wobbly.melbourne.sgi.com> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> <20060710014001.GA15511@crodrigues.org> <20060710114919.C1675766@wobbly.melbourne.sgi.com> <20060710015159.GA16864@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060710015159.GA16864@crodrigues.org>; from rodrigc@crodrigues.org on Sun, Jul 09, 2006 at 09:51:59PM -0400 X-archive-position: 8172 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: 392 Lines: 16 On Sun, Jul 09, 2006 at 09:51:59PM -0400, Craig Rodrigues wrote: > On Mon, Jul 10, 2006 at 11:49:19AM +1000, Nathan Scott wrote: > > BTW, while I've got you - what does "id -u root" give on FreeBSD? > > (is it "id: root: No such user" and then exit with a non-zero error > > code?) thanks! > > % id -u root > 0 Oh. Ah, wait, what about group (-g)? (and exit code). thanks. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 9 23:49:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Jul 2006 23:49:43 -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 k6A6n6DW023609 for ; Sun, 9 Jul 2006 23:49:18 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02265; Mon, 10 Jul 2006 16:48:28 +1000 Message-ID: <44B1F7FB.6080703@sgi.com> Date: Mon, 10 Jul 2006 16:47:23 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues CC: xfs@oss.sgi.com, nathans@sgi.com Subject: Re: xfsprogs 2.8.4 log_misc.c patch References: <20060707182936.GA65851@crodrigues.org> In-Reply-To: <20060707182936.GA65851@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8173 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: 1767 Lines: 55 Hi Craig, Craig Rodrigues wrote: > Hi, > > I'm not sure what to do about other platforms, > but on FreeBSD, I could not compile this > file in xfsprogs 2.8.4 without this patch: > > Looks good. The difference seems to be the definition of the uuid as an array of 16 unsigned chars versus a structure with the only field as the array. Taking the address (&) as you did, should work in both cases. (The other alternative, I guess, would be to define explicitly the type here instead of using the system one, since this is an ondisk type; however, I don't think that is really warranted as a uuid should be 128 bits) Thanks. --Tim > Index: log_misc.c > =================================================================== > RCS file: /cvs/xfs-cmds/xfsprogs/logprint/log_misc.c,v > retrieving revision 1.21 > diff -u -u -r1.21 log_misc.c > --- log_misc.c 16 Jun 2006 03:52:27 -0000 1.21 > +++ log_misc.c 7 Jul 2006 18:28:07 -0000 > @@ -1530,7 +1530,7 @@ > in_f->ilf_dsize = in_f32->ilf_dsize; > in_f->ilf_ino = in_f32->ilf_ino; > /* copy biggest */ > - memcpy(in_f->ilf_u.ilfu_uuid, in_f32->ilf_u.ilfu_uuid, sizeof(uuid_t)); > + memcpy(&in_f->ilf_u.ilfu_uuid, &in_f32->ilf_u.ilfu_uuid, sizeof(uuid_t)); > in_f->ilf_blkno = in_f32->ilf_blkno; > in_f->ilf_len = in_f32->ilf_len; > in_f->ilf_boffset = in_f32->ilf_boffset; > @@ -1546,7 +1546,7 @@ > in_f->ilf_dsize = in_f64->ilf_dsize; > in_f->ilf_ino = in_f64->ilf_ino; > /* copy biggest */ > - memcpy(in_f->ilf_u.ilfu_uuid, in_f64->ilf_u.ilfu_uuid, sizeof(uuid_t)); > + memcpy(&in_f->ilf_u.ilfu_uuid, &in_f64->ilf_u.ilfu_uuid, sizeof(uuid_t)); > in_f->ilf_blkno = in_f64->ilf_blkno; > in_f->ilf_len = in_f64->ilf_len; > in_f->ilf_boffset = in_f64->ilf_boffset; > > > > From owner-xfs@oss.sgi.com Mon Jul 10 00:42:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 00:43:09 -0700 (PDT) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6A7gqDW004799 for ; Mon, 10 Jul 2006 00:42:55 -0700 Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id E73FFB58FB4 for ; Mon, 10 Jul 2006 08:37:15 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12356-04 for ; Mon, 10 Jul 2006 08:37:14 +0200 (CEST) Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id 612F1B565BD for ; Mon, 10 Jul 2006 08:37:14 +0200 (CEST) From: Rainer Krienke To: linux-xfs@oss.sgi.com Subject: Re: Anyone use xfs_growfs under Linux? Date: Mon, 10 Jul 2006 08:37:12 +0200 User-Agent: KMail/1.9.3 References: <20060706233538.GA9665@tuatara.stupidest.org> <5908.1152229923@ocs3.ocs.com.au> <20060707034833.GB12908@tuatara.stupidest.org> In-Reply-To: <20060707034833.GB12908@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2560146.JaVKpJgKjA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607100837.13348.krienke@uni-koblenz.de> X-archive-position: 8174 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: xfs Content-Length: 1724 Lines: 48 --nextPart2560146.JaVKpJgKjA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 7. Juli 2006 05:48 schrieb Chris Wedgwood: > On Fri, Jul 07, 2006 at 09:52:03AM +1000, Keith Owens wrote: > > AFAIK you cannot change the kernel's view of the partition size > > while the partition is mounted. Adding the extra disk has to be > > done with the partition (and hence the filesystem) offline. > > xfs_growfs works on mounted filesystems. My comment mistakenly > > merged the two, quite separate, requirements. > > for parition tables that's correct, but if he is using LVM or similar > it should work w/o needing to remount It does. I am doing exactly this on several XFS filesystems that reside on= =20 LVM2 logical volumes. In this case there is no need for umounting the fs.= =20 Without taking the fs out of service in any way I can simply resize the LV= =20 and then run xfs_growfs. Have a nice day Rainer=20 --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --nextPart2560146.JaVKpJgKjA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBEsfWZaldtjc/KDEoRAn3IAKCT5KolG8drFu9n3fwUzcoMpdCzyQCglU7M 1lEiNEQTO4jZQSmIjwzfy5o= =HmFP -----END PGP SIGNATURE----- --nextPart2560146.JaVKpJgKjA-- From owner-xfs@oss.sgi.com Mon Jul 10 02:35:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 02:35:16 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6A9Z5DW021722 for ; Mon, 10 Jul 2006 02:35:05 -0700 Received: by nf-out-0910.google.com with SMTP id m19so33741nfc for ; Mon, 10 Jul 2006 02:34:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gOwMYfOyN78z6f6QkxBxgH0LE+0fMUrAJaZAucGdT8AG2LNgGfTehkKcnfAlF3+TJLP0BwA+dx9zYI8PHo0Rnm6Y35gmQC1a9xde+PusK3RhJqtody95YnLXq0ytaMBFz5cpFiMdZwIftyGyK+arNZRH/7ujM8bnB5nxj2nAhF8= Received: by 10.49.21.3 with SMTP id y3mr3441594nfi; Mon, 10 Jul 2006 01:31:09 -0700 (PDT) Received: by 10.48.208.16 with HTTP; Mon, 10 Jul 2006 01:31:09 -0700 (PDT) Message-ID: <3a6555a90607100131h46a3375u3f9a1c9ed19e62f4@mail.gmail.com> Date: Mon, 10 Jul 2006 10:31:09 +0200 From: "Simone Marcuzzi" To: xfs@oss.sgi.com Subject: XFS SUPPORT ON WINDOWS PLATFORMS MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8176 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: simone.marcuzzi@gmail.com Precedence: bulk X-list: xfs Content-Length: 520 Lines: 15 Hello, I'm interested in using the XFS filesystem on Windows XP after I've tried its performances on Linux platforms. This because I want to share a HD drive between the Windows and Linux installations on my PC so I can have a common storage drive when I work with one or the other OS. In the end, is there actually an efficient and reliable XFS driver available for Windows? Thanks for your time and congratulations for the excellent job done on XFS. -- Simone Marcuzzi (Italy) [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Jul 10 03:54:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 03:54:35 -0700 (PDT) Received: from msg-mx3.usc.edu (msg-mx3.usc.edu [128.125.137.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AAs9DW003514 for ; Mon, 10 Jul 2006 03:54:15 -0700 Received: from sphinx.usc.edu ([128.125.253.149]) by msg-mx3.usc.edu (Sun Java System Messaging Server 6.2-5.02 (built Dec 1 2005)) with ESMTP id <0J2600KLRJZDRG70@msg-mx3.usc.edu> for linux-xfs@oss.sgi.com; Mon, 10 Jul 2006 02:06:49 -0700 (PDT) Received: (from root@localhost) by sphinx.usc.edu (8.10.1/8.10.1/usc) id k6A96nB18580; Mon, 10 Jul 2006 02:06:49 -0700 (PDT) Date: Mon, 10 Jul 2006 02:06:49 -0700 (PDT) From: clarify@usc.edu Subject: Case C622187 (Returned mail: see transcript for details) To: linux-xfs@oss.sgi.com Reply-to: clarify@usc.edu Message-id: <200607100906.k6A96nB18580@sphinx.usc.edu> Content-transfer-encoding: 7BIT X-archive-position: 8177 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: clarify@usc.edu Precedence: bulk X-list: xfs Content-Length: 680 Lines: 17 Case C622187 created. Thank you for your e-mail. This is an automatic reply to inform you that we have created a case identifier for your request, which appears above and in the subject line of this e-mail. If you would like to send additional information about your request to us, please reply to this message. We will then automatically link your new message to your existing case identifier. If you call our Customer Support Center at (213) 740-5555 regarding this request, please refer to your case identifier when speaking with a support representative. Should you have an urgent issue, such as a network or system failure, please call our Customer Support Center now. From owner-xfs@oss.sgi.com Mon Jul 10 06:57:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 06:58:16 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6ADviDW006681 for ; Mon, 10 Jul 2006 06:57:54 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k6AE9WDu39693833 for ; Mon, 10 Jul 2006 07:09:33 -0700 (PDT) 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 k6AGMhmI014878 for ; Mon, 10 Jul 2006 09:22:43 -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 k6ADuqnB45416347; Mon, 10 Jul 2006 06:56:52 -0700 (PDT) Message-ID: <44B25CA7.7040400@sgi.com> Date: Mon, 10 Jul 2006 08:56:55 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Simone Marcuzzi CC: xfs@oss.sgi.com Subject: Re: XFS SUPPORT ON WINDOWS PLATFORMS References: <3a6555a90607100131h46a3375u3f9a1c9ed19e62f4@mail.gmail.com> In-Reply-To: <3a6555a90607100131h46a3375u3f9a1c9ed19e62f4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8178 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: 616 Lines: 16 see www.crossmeta.com. And if the source code for the GPL-based bits isn't available yet, ask them for it ;-) -Eric Simone Marcuzzi wrote: > Hello, > > I'm interested in using the XFS filesystem on Windows XP after I've tried > its performances on Linux platforms. This because I want to share a HD drive > between the Windows and Linux installations on my PC so I can have a common > storage drive when I work with one or the other OS. In the end, is there > actually an efficient and reliable XFS driver available for Windows? > > Thanks for your time and congratulations for the excellent job done on XFS. From owner-xfs@oss.sgi.com Mon Jul 10 10:49:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 10:49:39 -0700 (PDT) Received: from mail.max-t.com (h216-18-124-229.gtcust.grouptelecom.net [216.18.124.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AHn2DW018696 for ; Mon, 10 Jul 2006 10:49:03 -0700 Received: from madrid.max-t.internal ([192.168.1.189] ident=[U2FsdGVkX19xD/op2L779EzCpCtmf9zERLYzAfYwGTA=]) by mail.max-t.com with esmtp (Exim 4.43) id 1FzyvI-00017s-Eu; Mon, 10 Jul 2006 12:47:53 -0400 Date: Mon, 10 Jul 2006 12:46:23 -0400 (EDT) From: Stephane Doyon X-X-Sender: sdoyon@madrid.max-t.internal To: Christoph Hellwig , Nathan Scott cc: Suzuki , linux-fsdevel@vger.kernel.org, "linux-aio kvack.org" , lkml , suparna , akpm@osdl.org, linux-xfs@oss.sgi.com In-Reply-To: <20060310005020.GF1135@frodo> Message-ID: References: <440FDF3E.8060400@in.ibm.com> <20060309120306.GA26682@infradead.org> <20060309223042.GC1135@frodo> <20060309224219.GA6709@infradead.org> <20060309231422.GD1135@frodo> <20060310005020.GF1135@frodo> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.1.189 X-SA-Exim-Mail-From: sdoyon@max-t.com Subject: Re: [RFC] Badness in __mutex_unlock_slowpath with XFS stress tests Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Version: 4.1 (built Thu, 08 Sep 2005 14:17:48 -0500) X-SA-Exim-Scanned: Yes (on mail.max-t.com) X-archive-position: 8179 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sdoyon@max-t.com Precedence: bulk X-list: xfs Content-Length: 6541 Lines: 160 Hi, A few months back, a fix was introduced for a mutex double unlock warning related to direct I/O in XFS. I believe that fix has a lock ordering problem that can cause a deadlock. The problem was that __blockdev_direct_IO() would unlock the i_mutex in the READ and DIO_OWN_LOCKING case, and the mutex would be unlocked again in xfs_read() soon after returning from __generic_file_aio_read(). Because there are lots of execution paths down from __generic_file_aio_read() that do not consistently release the i_mutex, the safest fix was deemed to be to reacquire the i_mutex before returning from __blockdev_direct_IO(). At this point however, the reader is holding an xfs ilock, and AFAICT the i_mutex is usually taken BEFORE the xfs ilock. We are seeing a deadlock between a process writing and another process reading the same file, when the reader is using direct I/O. (The writer must apparently be growing the file, using either direct or buffered I/O.) Something like this, on XFS: (dd if=/dev/zero of=f bs=128K count=5000 & ) ; sleep 1 ; dd of=/dev/null if=f iflag=direct bs=128K count=5000 Seen on kernels 2.6.16 and 2.6.17. The deadlock scenario appears to be this: -The reader goes into xfs_read(), takes the i_mutex and then an xfs_ilock XFS_IOLOCK_SHARED, then calls down to __generic_file_aio_read() which eventually goes down to __blockdev_direct_IO(). In there it drops the i_mutex. -The writer goes into xfs_write() and obtains the i_mutex. It then tries to get an xfs_ilock XFS_ILOCK_EXCL and must wait on it since it's held by the reader. -The reader, still in __blockdev_direct_IO(), executes directio_worker() and then tries to reacquire the i_mutex, and must wait on it because the writer has it. And so we have a deadlock. I leave it to the experts to figure out what the right fix for this might be. A workaround might be to not release the i_mutex during __blockdev_direct_IO(). Thanks On Thu, 9 Mar 2006, Christoph Hellwig wrote: > On Thu, Mar 09, 2006 at 01:24:38PM +0530, Suzuki wrote: >> >> Missed out linux-aio & linux-fs-devel lists. Forwarding. >> >> Comments ? > > I've seen this too. The problem is that __generic_file_aio_read can return > with or without the i_mutex locked in the direct I/O case for filesystems > that set DIO_OWN_LOCKING. It's a nasty one and I haven't found a better solution > than copying lots of code from filemap.c into xfs. > > > On Fri, 10 Mar 2006, Nathan Scott wrote: > On Thu, Mar 09, 2006 at 12:47:01PM +0530, Suzuki wrote: >> Hi all, > > Hi there Suzuki, > >> I was working on an issue with getting "Badness in >> __mutex_unlock_slowpath" and hence a stack trace, while running FS >> stress tests on XFS on 2.6.16-rc5 kernel. > > Thanks for looking into this. > >> The dmesg looks like : >> >> Badness in __mutex_unlock_slowpath at kernel/mutex.c:207 >> [] show_trace+0x20/0x22 >> [] dump_stack+0x1e/0x20 >> [] __mutex_unlock_slowpath+0x12a/0x23b >> [] mutex_unlock+0xb/0xd >> [] xfs_read+0x230/0x2d9 >> [] linvfs_aio_read+0x8d/0x98 >> [] do_sync_read+0xb8/0x107 >> [] vfs_read+0xc9/0x19b >> [] sys_read+0x47/0x6e >> [] sysenter_past_esp+0x54/0x75 > > Yeah, test 008 from the xfstests suite was reliably hitting this for > me, it'd just not percolated to the top of my todo list yet. > >> This happens with XFS DIO reads. xfs_read holds the i_mutex and issues a >> __generic_file_aio_read(), which falls into __blockdev_direct_IO with >> DIO_OWN_LOCKING flag (since xfs uses own_locking ). Now >> __blockdev_direct_IO releases the i_mutex for READs with >> DIO_OWN_LOCKING.When it returns to xfs_read, it tries to unlock the >> i_mutex ( which is now already unlocked), causing the "Badness". > > Indeed. And there's the problem - why is XFS releasing i_mutex > for the direct read in xfs_read? Shouldn't be - fs/direct-io.c > will always release i_mutex for a direct read in the own-locking > case, so XFS shouldn't be doing it too (thats what the code does > and thats what the comment preceding __blockdev_direct_IO says). > > The only piece of the puzzle I don't understand is why we don't > always get that badness message at the end of every direct read. > Perhaps its some subtle fastpath/slowpath difference, or maybe > "debug_mutex_on" gets switched off after the first occurance... > > Anyway, with the above change (remove 2 lines near xfs_read end), > I can no longer reproduce the problem in that previously-warning > test case, and all the other XFS tests seem to be chugging along > OK (which includes a healthy mix of dio testing). > >> The possible solution which we can think of, is not to unlock the >> i_mutex for DIO_OWN_LOCKING. This will only affect the DIO_OWN_LOCKING >> users (as of now, only XFS ) with concurrent DIO sync read requests. AIO >> read requests would not suffer this problem since they would just return >> once the DIO is submitted. > > I don't think that level of invasiveness is necessary at this stage, > but perhaps you're seeing something that I've missed? Do you see > any reason why removing the xfs_read unlock wont work? > >> Another work around for this can be adding a check "mutex_is_locked" >> before trying to unlock i_mutex in xfs_read. But this seems to be an >> ugly hack. :( > > Hmm, that just plain wouldn't work - what if the lock was released > in generic direct IO code, and someone else had acquired it before > we got to the end of xfs_read? Badness for sure. > > cheers. > > On Fri, 10 Mar 2006, Nathan Scott wrote: > On Fri, Mar 10, 2006 at 10:14:22AM +1100, Nathan Scott wrote: >> On Thu, Mar 09, 2006 at 10:42:19PM +0000, Christoph Hellwig wrote: >>> On Fri, Mar 10, 2006 at 09:30:42AM +1100, Nathan Scott wrote: >>>> Not for reads AFAICT - __generic_file_aio_read + own-locking >>>> should always have released i_mutex at the end of the direct >>>> read - are you thinking of writes or have I missed something? >>> >>> if an error occurs before a_ops->direct_IO is called __generic_file_aio_read >>> will return with i_mutex still locked. Note that checking for negative >>> return values is not enough as __blockdev_direct_IO can return errors >>> aswell. >> >> *groan* - right you are. Another option may be to have the >> generic dio+own-locking case reacquire i_mutex if it drops >> it, before returning... thoughts? Seems alot less invasive >> than the filemap.c code dup'ing thing. > > Something like this (works OK for me)... > > cheers. > > From owner-xfs@oss.sgi.com Mon Jul 10 10:59:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:00:14 -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 k6AHxiDW020700 for ; Mon, 10 Jul 2006 10:59:45 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1FzyyK-0003PL-FM; Mon, 10 Jul 2006 17:51:00 +0100 Date: Mon, 10 Jul 2006 17:51:00 +0100 From: Christoph Hellwig To: Nathan Scott Cc: Alexey Dobriyan , Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060710165100.GA11567@infradead.org> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709125643.GA28769@infradead.org> <20060710081711.A1670244@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060710081711.A1670244@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8180 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 1690 Lines: 36 On Mon, Jul 10, 2006 at 08:17:11AM +1000, Nathan Scott wrote: > On Sun, Jul 09, 2006 at 01:56:43PM +0100, Christoph Hellwig wrote: > > On Sun, Jul 09, 2006 at 10:54:54AM +1000, Nathan Scott wrote: > > I don't think theres a valid reason to keep such dead code around. If > > Its not dead code. I will and have been happily removing dead > code. It's 100% dead code in mainline. Please don't push in new code that doesn't do anything. > > There seem to be some rather odd things creeping in lately. > > Er, such as? And why not point these things out at the time, > when people are working on it and committing the changes (and > sending commit mail to xfs@oss), instead of this odd vague > reference now? Sorry about the odd reference. I don't really have time to look up the changes for each TAKE message in cvsweb nevermind especially odd changes seem to not come with TAKE messages sometimes. So I have to look at the changes between two linus releases to see changes. Anyway, the odd changes from 2.6.17 to 2.6.18-rc are: - replacing PFLAGS_* with even more obsfucation - the big renaming of the vnode/vfs thingies. I take this as an official go-ahead that this cruft isn't for irix-compatibility anymore and remove it. I have a nice patch pending that reduces xfs size big time with this (unfortunatly needs a nasty rebase now) - the VN_TRUNC looks interesting. I wish we had a public discussion about this and could see whether or not to handle it at the VFS level - adding a new inherit_nodfrg flag that's not actually used anywhere - addding a VFS_UMOUNT flag that isn't actually used anywhere and shouldn't exist with Linux's unmount handling From owner-xfs@oss.sgi.com Mon Jul 10 11:04:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:41 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDa021824 for ; Mon, 10 Jul 2006 11:04:19 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH44RT026980 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:04:04 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH44Fj026978; Mon, 10 Jul 2006 19:04:04 +0200 Date: Mon, 10 Jul 2006 19:04:04 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH 1/7] xfs: endianess annotation for xfs_agfl_t Message-ID: <20060710170404.GA26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8182 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 1907 Lines: 50 trivial, xfs_agfl_t is always used for ondisk values. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/xfs_ag.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_ag.h 2006-07-09 19:28:15.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_ag.h 2006-07-09 19:34:47.000000000 +0200 @@ -150,7 +150,7 @@ #define XFS_BUF_TO_AGFL(bp) ((xfs_agfl_t *)XFS_BUF_PTR(bp)) typedef struct xfs_agfl { - xfs_agblock_t agfl_bno[1]; /* actually XFS_AGFL_SIZE(mp) */ + __be32 agfl_bno[1]; /* actually XFS_AGFL_SIZE(mp) */ } xfs_agfl_t; /* Index: xfs-2.6.x/fs/xfs/xfs_alloc.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_alloc.c 2006-07-09 19:28:15.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_alloc.c 2006-07-09 19:34:47.000000000 +0200 @@ -2011,7 +2011,7 @@ /* * Get the block number and update the data structures. */ - bno = INT_GET(agfl->agfl_bno[be32_to_cpu(agf->agf_flfirst)], ARCH_CONVERT); + bno = be32_to_cpu(agfl->agfl_bno[be32_to_cpu(agf->agf_flfirst)]); be32_add(&agf->agf_flfirst, 1); xfs_trans_brelse(tp, agflbp); if (be32_to_cpu(agf->agf_flfirst) == XFS_AGFL_SIZE(mp)) @@ -2098,7 +2098,7 @@ { xfs_agf_t *agf; /* a.g. freespace structure */ xfs_agfl_t *agfl; /* a.g. free block array */ - xfs_agblock_t *blockp;/* pointer to array entry */ + __be32 *blockp;/* pointer to array entry */ int error; #ifdef XFS_ALLOC_TRACE static char fname[] = "xfs_alloc_put_freelist"; @@ -2122,7 +2122,7 @@ pag->pagf_flcount++; ASSERT(be32_to_cpu(agf->agf_flcount) <= XFS_AGFL_SIZE(mp)); blockp = &agfl->agfl_bno[be32_to_cpu(agf->agf_fllast)]; - INT_SET(*blockp, ARCH_CONVERT, bno); + *blockp = cpu_to_be32(bno); TRACE_MODAGF(NULL, agf, XFS_AGF_FLLAST | XFS_AGF_FLCOUNT); xfs_alloc_log_agf(tp, agbp, XFS_AGF_FLLAST | XFS_AGF_FLCOUNT); xfs_trans_log_buf(tp, agflbp, From owner-xfs@oss.sgi.com Mon Jul 10 11:04:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:41 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDY021824 for ; Mon, 10 Jul 2006 11:04:18 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH4KRT027032 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:04:20 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH4KQq027030; Mon, 10 Jul 2006 19:04:20 +0200 Date: Mon, 10 Jul 2006 19:04:20 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH 4/7] xfs: add xfs_btree_check_lptr_disk Message-ID: <20060710170420.GD26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8183 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 5571 Lines: 146 This is a variant of xfs_btree_check_lptr that handles the endianess conversion as many callers need it. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/xfs_bmap.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap.c 2006-07-09 19:28:16.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_bmap.c 2006-07-09 19:37:01.000000000 +0200 @@ -3013,7 +3013,7 @@ pp = XFS_BMAP_BROOT_PTR_ADDR(rblock, 1, ifp->if_broot_bytes); *logflagsp = 0; #ifdef DEBUG - if ((error = xfs_btree_check_lptr(cur, INT_GET(*pp, ARCH_CONVERT), 1))) + if ((error = xfs_btree_check_lptr_disk(cur, *pp, 1))) return error; #endif cbno = INT_GET(*pp, ARCH_CONVERT); Index: xfs-2.6.x/fs/xfs/xfs_bmap_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:28:16.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:37:01.000000000 +0200 @@ -382,7 +382,7 @@ pp = XFS_BMAP_PTR_IADDR(block, 1, cur); #ifdef DEBUG for (i = ptr; i < numrecs; i++) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(pp[i], ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, pp, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); goto error0; } @@ -621,7 +621,7 @@ rpp = XFS_BMAP_PTR_IADDR(right, 1, cur); #ifdef DEBUG for (i = 0; i < numrrecs; i++) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(rpp[i], ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, rpp[i], level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); goto error0; } @@ -858,7 +858,7 @@ pp = XFS_BMAP_PTR_IADDR(block, 1, cur); #ifdef DEBUG for (i = numrecs; i >= ptr; i--) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(pp[i - 1], ARCH_CONVERT), + if ((error = xfs_btree_check_lptr_disk(cur, pp[i - 1], level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; @@ -988,7 +988,7 @@ cpp = XFS_BMAP_PTR_IADDR(cblock, 1, cur); #ifdef DEBUG for (i = 0; i < be16_to_cpu(cblock->bb_numrecs); i++) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(cpp[i], ARCH_CONVERT), level - 1))) { + if ((error = xfs_btree_check_lptr_disk(cur, cpp[i], level - 1))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -1190,7 +1190,7 @@ keyno = 1; pp = XFS_BMAP_PTR_IADDR(block, keyno, cur); #ifdef DEBUG - if ((error = xfs_btree_check_lptr(cur, INT_GET(*pp, ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, *pp, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -1313,7 +1313,7 @@ lpp = XFS_BMAP_PTR_IADDR(left, lrecs, cur); rpp = XFS_BMAP_PTR_IADDR(right, 1, cur); #ifdef DEBUG - if ((error = xfs_btree_check_lptr(cur, INT_GET(*rpp, ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, *rpp, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -1340,7 +1340,7 @@ if (level > 0) { #ifdef DEBUG for (i = 0; i < rrecs; i++) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(rpp[i + 1], ARCH_CONVERT), + if ((error = xfs_btree_check_lptr_disk(cur, rpp[i + 1], level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; @@ -1445,7 +1445,7 @@ rpp = XFS_BMAP_PTR_IADDR(right, 1, cur); #ifdef DEBUG for (i = be16_to_cpu(right->bb_numrecs) - 1; i >= 0; i--) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(rpp[i], ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, rpp[i] level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -1454,7 +1454,7 @@ memmove(rkp + 1, rkp, be16_to_cpu(right->bb_numrecs) * sizeof(*rkp)); memmove(rpp + 1, rpp, be16_to_cpu(right->bb_numrecs) * sizeof(*rpp)); #ifdef DEBUG - if ((error = xfs_btree_check_lptr(cur, INT_GET(*lpp, ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, *lpp, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -1619,7 +1619,7 @@ rpp = XFS_BMAP_PTR_IADDR(right, 1, cur); #ifdef DEBUG for (i = 0; i < be16_to_cpu(right->bb_numrecs); i++) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(lpp[i], ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, lpp[i], level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -2356,7 +2356,7 @@ args.firstblock = args.fsbno; if (args.fsbno == NULLFSBLOCK) { #ifdef DEBUG - if ((error = xfs_btree_check_lptr(cur, INT_GET(*pp, ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, *pp, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -2393,7 +2393,7 @@ cpp = XFS_BMAP_PTR_IADDR(cblock, 1, cur); #ifdef DEBUG for (i = 0; i < be16_to_cpu(cblock->bb_numrecs); i++) { - if ((error = xfs_btree_check_lptr(cur, INT_GET(pp[i], ARCH_CONVERT), level))) { + if ((error = xfs_btree_check_lptr_disk(cur, pp[i], level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } Index: xfs-2.6.x/fs/xfs/xfs_btree.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_btree.h 2006-07-09 19:34:52.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_btree.h 2006-07-09 19:37:01.000000000 +0200 @@ -243,6 +243,9 @@ xfs_dfsbno_t ptr, /* btree block disk address */ int level); /* btree block level */ +#define xfs_btree_check_lptr_disk(cur, ptr, level) \ + xfs_btree_check_lptr(cur, INT_GET(ptr, ARCH_CONVERT), level) + /* * Checking routine: check that short form block header is ok. */ From owner-xfs@oss.sgi.com Mon Jul 10 11:04:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:43 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDg021824 for ; Mon, 10 Jul 2006 11:04:23 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH4FRT027014 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:04:16 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH4F9s027008; Mon, 10 Jul 2006 19:04:15 +0200 Date: Mon, 10 Jul 2006 19:04:15 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH 3/7] xfs: remove left over INT_ comments in *alloc*.c Message-ID: <20060710170415.GC26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8185 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 4032 Lines: 123 We can verify endianess handling with sparse now, no need for comments. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/xfs_alloc_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_alloc_btree.c 2006-07-09 19:28:15.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_alloc_btree.c 2006-07-09 19:34:56.000000000 +0200 @@ -774,7 +774,7 @@ * Now stuff the new record in, bump numrecs * and log the new data. */ - rp[ptr - 1] = *recp; /* INT_: struct copy */ + rp[ptr - 1] = *recp; be16_add(&block->bb_numrecs, 1); xfs_alloc_log_recs(cur, bp, ptr, be16_to_cpu(block->bb_numrecs)); #ifdef DEBUG @@ -819,8 +819,8 @@ */ *bnop = nbno; if (nbno != NULLAGBLOCK) { - *recp = nrec; /* INT_: struct copy */ - *curp = ncur; /* INT_: struct copy */ + *recp = nrec; + *curp = ncur; } *stat = 1; return 0; @@ -1229,7 +1229,7 @@ if ((error = xfs_btree_check_sptr(cur, be32_to_cpu(*rpp), level))) return error; #endif - *lpp = *rpp; /* INT_: copy */ + *lpp = *rpp; xfs_alloc_log_ptrs(cur, lbp, nrec, nrec); xfs_btree_check_key(cur->bc_btnum, lkp - 1, lkp); } @@ -1406,8 +1406,8 @@ kp = XFS_ALLOC_KEY_ADDR(new, 1, cur); if (be16_to_cpu(left->bb_level) > 0) { - kp[0] = *XFS_ALLOC_KEY_ADDR(left, 1, cur); /* INT_: structure copy */ - kp[1] = *XFS_ALLOC_KEY_ADDR(right, 1, cur);/* INT_: structure copy */ + kp[0] = *XFS_ALLOC_KEY_ADDR(left, 1, cur); + kp[1] = *XFS_ALLOC_KEY_ADDR(right, 1, cur); } else { xfs_alloc_rec_t *rp; /* btree record pointer */ @@ -1527,8 +1527,8 @@ if ((error = xfs_btree_check_sptr(cur, be32_to_cpu(*lpp), level))) return error; #endif - *rkp = *lkp; /* INT_: copy */ - *rpp = *lpp; /* INT_: copy */ + *rkp = *lkp; + *rpp = *lpp; xfs_alloc_log_keys(cur, rbp, 1, be16_to_cpu(right->bb_numrecs) + 1); xfs_alloc_log_ptrs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs) + 1); xfs_btree_check_key(cur->bc_btnum, rkp, rkp + 1); Index: xfs-2.6.x/fs/xfs/xfs_ialloc_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_ialloc_btree.c 2006-07-09 19:34:52.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_ialloc_btree.c 2006-07-09 19:34:56.000000000 +0200 @@ -681,7 +681,7 @@ if ((error = xfs_btree_check_sptr(cur, *bnop, level))) return error; #endif - kp[ptr - 1] = key; /* INT_: struct copy */ + kp[ptr - 1] = key; pp[ptr - 1] = cpu_to_be32(*bnop); numrecs++; block->bb_numrecs = cpu_to_be16(numrecs); @@ -698,7 +698,7 @@ * Now stuff the new record in, bump numrecs * and log the new data. */ - rp[ptr - 1] = *recp; /* INT_: struct copy */ + rp[ptr - 1] = *recp; numrecs++; block->bb_numrecs = cpu_to_be16(numrecs); xfs_inobt_log_recs(cur, bp, ptr, numrecs); @@ -731,7 +731,7 @@ */ *bnop = nbno; if (nbno != NULLAGBLOCK) { - *recp = nrec; /* INT_: struct copy */ + *recp = nrec; *curp = ncur; } *stat = 1; @@ -1117,7 +1117,7 @@ if ((error = xfs_btree_check_sptr(cur, be32_to_cpu(*rpp), level))) return error; #endif - *lpp = *rpp; /* INT_: no-change copy */ + *lpp = *rpp; xfs_inobt_log_ptrs(cur, lbp, nrec, nrec); } /* @@ -1297,8 +1297,8 @@ */ kp = XFS_INOBT_KEY_ADDR(new, 1, cur); if (be16_to_cpu(left->bb_level) > 0) { - kp[0] = *XFS_INOBT_KEY_ADDR(left, 1, cur); /* INT_: struct copy */ - kp[1] = *XFS_INOBT_KEY_ADDR(right, 1, cur); /* INT_: struct copy */ + kp[0] = *XFS_INOBT_KEY_ADDR(left, 1, cur); + kp[1] = *XFS_INOBT_KEY_ADDR(right, 1, cur); } else { rp = XFS_INOBT_REC_ADDR(left, 1, cur); kp[0].ir_startino = rp->ir_startino; @@ -1410,8 +1410,8 @@ if ((error = xfs_btree_check_sptr(cur, be32_to_cpu(*lpp), level))) return error; #endif - *rkp = *lkp; /* INT_: no change copy */ - *rpp = *lpp; /* INT_: no change copy */ + *rkp = *lkp; + *rpp = *lpp; xfs_inobt_log_keys(cur, rbp, 1, be16_to_cpu(right->bb_numrecs) + 1); xfs_inobt_log_ptrs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs) + 1); } else { From owner-xfs@oss.sgi.com Mon Jul 10 11:04:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:37 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDW021824 for ; Mon, 10 Jul 2006 11:04:16 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH5oRT027115 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:05:50 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH5oIs027113; Mon, 10 Jul 2006 19:05:50 +0200 Date: Mon, 10 Jul 2006 19:05:50 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH] xfs: remove bhv_lookup Message-ID: <20060710170550.GA27082@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8181 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 5745 Lines: 158 There's no point in using bhv_lookup. The _range version works aswell in all cases and has much more useful semantics. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/dmapi/xfs_dm.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/dmapi/xfs_dm.c 2006-07-09 19:28:18.000000000 +0200 +++ xfs-2.6.x/fs/xfs/dmapi/xfs_dm.c 2006-07-09 19:30:52.000000000 +0200 @@ -50,10 +50,6 @@ #define MAXNAMLEN MAXNAMELEN -#define XFS_BHV_LOOKUP(vp, xbdp) \ - xbdp = vn_bhv_lookup(VN_BHV_HEAD(vp), &xfs_vnodeops); \ - ASSERT(xbdp); - #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) #define MIN_DIO_SIZE(mp) ((mp)->m_sb.sb_sectsize) #define MAX_DIO_SIZE(mp) (INT_MAX & ~(MIN_DIO_SIZE(mp) - 1)) @@ -179,7 +175,10 @@ /* Returns positive errors to XFS */ - XFS_BHV_LOOKUP(vp, bdp); + bdp = bhv_lookup_range(VN_BHV_HEAD(vp), + VNODE_POSITION_XFS, VNODE_POSITION_XFS); + ASSERT(bdp); + ip = xfs_vtoi(vp); do { dmstate = ip->i_iocore.io_dmstate; @@ -2378,7 +2377,10 @@ if (error) return -EBUSY; - XFS_BHV_LOOKUP(vp, xbdp); + xbdp = bhv_lookup_range(VN_BHV_HEAD(vp), + VNODE_POSITION_XFS, VNODE_POSITION_XFS); + ASSERT(xbdp); + xip = xfs_vtoi(vp); mp = xip->i_mount; bsize = mp->m_sb.sb_blocksize; Index: xfs-2.6.x/fs/xfs/linux-2.4/xfs_vnode.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/linux-2.4/xfs_vnode.h 2006-07-09 19:28:20.000000000 +0200 +++ xfs-2.6.x/fs/xfs/linux-2.4/xfs_vnode.h 2006-07-09 19:30:52.000000000 +0200 @@ -83,8 +83,6 @@ #define VN_BHV_HEAD(vp) ((bhv_head_t *)(&((vp)->v_bh))) #define vn_bhv_head_init(bhp,name) bhv_head_init(bhp,name) #define vn_bhv_remove(bhp,bdp) bhv_remove(bhp,bdp) -#define vn_bhv_lookup(bhp,ops) bhv_lookup(bhp,ops) -#define vn_bhv_lookup_unlocked(bhp,ops) bhv_lookup_unlocked(bhp,ops) /* * Vnode to Linux inode mapping. Index: xfs-2.6.x/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/linux-2.6/xfs_vnode.h 2006-07-09 19:28:21.000000000 +0200 +++ xfs-2.6.x/fs/xfs/linux-2.6/xfs_vnode.h 2006-07-09 19:30:52.000000000 +0200 @@ -85,8 +85,6 @@ #define VN_BHV_HEAD(vp) ((bhv_head_t *)(&((vp)->v_bh))) #define vn_bhv_head_init(bhp,name) bhv_head_init(bhp,name) #define vn_bhv_remove(bhp,bdp) bhv_remove(bhp,bdp) -#define vn_bhv_lookup(bhp,ops) bhv_lookup(bhp,ops) -#define vn_bhv_lookup_unlocked(bhp,ops) bhv_lookup_unlocked(bhp,ops) /* * Vnode to Linux inode mapping. Index: xfs-2.6.x/fs/xfs/xfs_behavior.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_behavior.c 2006-07-09 19:28:16.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_behavior.c 2006-07-09 19:30:52.000000000 +0200 @@ -110,26 +110,6 @@ } /* - * Look for a specific ops vector on the specified behavior chain. - * Return the associated behavior descriptor. Or NULL, if not found. - */ -bhv_desc_t * -bhv_lookup(bhv_head_t *bhp, void *ops) -{ - bhv_desc_t *curdesc; - - for (curdesc = bhp->bh_first; - curdesc != NULL; - curdesc = curdesc->bd_next) { - - if (curdesc->bd_ops == ops) - return curdesc; - } - - return NULL; -} - -/* * Looks for the first behavior within a specified range of positions. * Return the associated behavior descriptor. Or NULL, if none found. */ Index: xfs-2.6.x/fs/xfs/xfs_behavior.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_behavior.h 2006-07-09 19:28:16.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_behavior.h 2006-07-09 19:30:52.000000000 +0200 @@ -179,12 +179,10 @@ * Behavior module prototypes. */ extern void bhv_remove_not_first(bhv_head_t *bhp, bhv_desc_t *bdp); -extern bhv_desc_t * bhv_lookup(bhv_head_t *bhp, void *ops); extern bhv_desc_t * bhv_lookup_range(bhv_head_t *bhp, int low, int high); extern bhv_desc_t * bhv_base(bhv_head_t *bhp); /* No bhv locking on Linux */ -#define bhv_lookup_unlocked bhv_lookup #define bhv_base_unlocked bhv_base #endif /* __XFS_BEHAVIOR_H__ */ Index: xfs-2.6.x/fs/xfs/xfs_mount.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_mount.h 2006-07-09 19:28:17.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_mount.h 2006-07-09 19:30:52.000000000 +0200 @@ -541,7 +541,8 @@ #define XFS_VFSTOM(vfs) xfs_vfstom(vfs) static inline xfs_mount_t *xfs_vfstom(bhv_vfs_t *vfs) { - return XFS_BHVTOM(bhv_lookup(VFS_BHVHEAD(vfs), &xfs_vfsops)); + return XFS_BHVTOM(bhv_lookup_range(VFS_BHVHEAD(vfs), + VFS_POSITION_XFS, VFS_POSITION_XFS)); } #define XFS_DADDR_TO_AGNO(mp,d) xfs_daddr_to_agno(mp,d) Index: xfs-2.6.x/fs/xfs/linux-2.4/xfs_ksyms.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/linux-2.4/xfs_ksyms.c 2006-07-09 19:28:20.000000000 +0200 +++ xfs-2.6.x/fs/xfs/linux-2.4/xfs_ksyms.c 2006-07-09 19:30:52.000000000 +0200 @@ -158,7 +158,6 @@ EXPORT_SYMBOL(bhv_head_destroy); EXPORT_SYMBOL(bhv_insert); EXPORT_SYMBOL(bhv_insert_initial); -EXPORT_SYMBOL(bhv_lookup); EXPORT_SYMBOL(bhv_lookup_range); EXPORT_SYMBOL(bhv_remove_vfsops); EXPORT_SYMBOL(bhv_remove_all_vfsops); Index: xfs-2.6.x/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2006-07-09 19:28:21.000000000 +0200 +++ xfs-2.6.x/fs/xfs/linux-2.6/xfs_ksyms.c 2006-07-09 19:30:52.000000000 +0200 @@ -142,7 +142,6 @@ EXPORT_SYMBOL(bhv_head_destroy); EXPORT_SYMBOL(bhv_insert); EXPORT_SYMBOL(bhv_insert_initial); -EXPORT_SYMBOL(bhv_lookup); EXPORT_SYMBOL(bhv_lookup_range); EXPORT_SYMBOL(bhv_module_init); EXPORT_SYMBOL(bhv_module_exit); From owner-xfs@oss.sgi.com Mon Jul 10 11:04:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:43 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDe021824 for ; Mon, 10 Jul 2006 11:04:21 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH4VRT027060 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:04:31 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH4VeC027058; Mon, 10 Jul 2006 19:04:31 +0200 Date: Mon, 10 Jul 2006 19:04:31 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH 6/7] xfs: endianess annotate XFS_BMAP_BROOT_PTR_ADDR Message-ID: <20060710170431.GF26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8184 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 12063 Lines: 335 Make sure it returns a __be64 and let the callers use the proper macros. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/xfs_bmap.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap.c 2006-07-09 19:37:01.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_bmap.c 2006-07-09 19:38:02.000000000 +0200 @@ -2999,7 +2999,7 @@ int error; /* error return value */ xfs_ifork_t *ifp; /* inode fork data */ xfs_mount_t *mp; /* mount point structure */ - xfs_bmbt_ptr_t *pp; /* ptr to block address */ + __be64 *pp; /* ptr to block address */ xfs_bmbt_block_t *rblock;/* root btree block */ ifp = XFS_IFORK_PTR(ip, whichfork); @@ -3011,12 +3011,12 @@ ASSERT(XFS_BMAP_BROOT_MAXRECS(ifp->if_broot_bytes) == 1); mp = ip->i_mount; pp = XFS_BMAP_BROOT_PTR_ADDR(rblock, 1, ifp->if_broot_bytes); + cbno = be64_to_cpu(*pp); *logflagsp = 0; #ifdef DEBUG - if ((error = xfs_btree_check_lptr_disk(cur, *pp, 1))) + if ((error = xfs_btree_check_lptr(cur, cbno, 1))) return error; #endif - cbno = INT_GET(*pp, ARCH_CONVERT); if ((error = xfs_btree_read_bufl(mp, tp, cbno, 0, &cbp, XFS_BMAP_BTREE_REF))) return error; @@ -3514,7 +3514,7 @@ arp = XFS_BMAP_REC_IADDR(ablock, 1, cur); INT_SET(kp->br_startoff, ARCH_CONVERT, xfs_bmbt_disk_get_startoff(arp)); pp = XFS_BMAP_PTR_IADDR(block, 1, cur); - INT_SET(*pp, ARCH_CONVERT, args.fsbno); + *pp = cpu_to_be64(args.fsbno); /* * Do all this logging at the end so that * the root is at the right level. @@ -4494,7 +4494,7 @@ xfs_ifork_t *ifp; /* fork structure */ int level; /* btree level, for checking */ xfs_mount_t *mp; /* file system mount structure */ - xfs_bmbt_ptr_t *pp; /* pointer to block address */ + __be64 *pp; /* pointer to block address */ /* REFERENCED */ xfs_extnum_t room; /* number of entries there's room for */ @@ -4510,10 +4510,10 @@ level = be16_to_cpu(block->bb_level); ASSERT(level > 0); pp = XFS_BMAP_BROOT_PTR_ADDR(block, 1, ifp->if_broot_bytes); - ASSERT(INT_GET(*pp, ARCH_CONVERT) != NULLDFSBNO); - ASSERT(XFS_FSB_TO_AGNO(mp, INT_GET(*pp, ARCH_CONVERT)) < mp->m_sb.sb_agcount); - ASSERT(XFS_FSB_TO_AGBNO(mp, INT_GET(*pp, ARCH_CONVERT)) < mp->m_sb.sb_agblocks); - bno = INT_GET(*pp, ARCH_CONVERT); + bno = be64_to_cpu(*pp); + ASSERT(bno != NULLDFSBNO); + ASSERT(XFS_FSB_TO_AGNO(mp, bno) < mp->m_sb.sb_agcount); + ASSERT(XFS_FSB_TO_AGBNO(mp, bno) < mp->m_sb.sb_agblocks); /* * Go down the tree until leaf level is reached, following the first * pointer (leftmost) at each level. @@ -4530,10 +4530,8 @@ break; pp = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, block, 1, mp->m_bmap_dmxr[1]); - XFS_WANT_CORRUPTED_GOTO( - XFS_FSB_SANITY_CHECK(mp, INT_GET(*pp, ARCH_CONVERT)), - error0); - bno = INT_GET(*pp, ARCH_CONVERT); + bno = be64_to_cpu(*pp); + XFS_WANT_CORRUPTED_GOTO(XFS_FSB_SANITY_CHECK(mp, bno), error0); xfs_trans_brelse(tp, bp); } /* @@ -6141,7 +6139,7 @@ short sz) { int i, j, dmxr; - xfs_bmbt_ptr_t *pp, *thispa; /* pointer to block address */ + __be64 *pp, *thispa; /* pointer to block address */ xfs_bmbt_key_t *prevp, *keyp; ASSERT(be16_to_cpu(block->bb_level) > 0); @@ -6179,11 +6177,10 @@ thispa = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, block, j, dmxr); } - if (INT_GET(*thispa, ARCH_CONVERT) == - INT_GET(*pp, ARCH_CONVERT)) { + if (*thispa == *pp) { cmn_err(CE_WARN, "%s: thispa(%d) == pp(%d) %Ld", __FUNCTION__, j, i, - INT_GET(*thispa, ARCH_CONVERT)); + (unsigned long long)be64_to_cpu(*thispa)); panic("%s: ptrs are equal in node\n", __FUNCTION__); } @@ -6210,7 +6207,7 @@ xfs_ifork_t *ifp; /* fork structure */ int level; /* btree level, for checking */ xfs_mount_t *mp; /* file system mount structure */ - xfs_bmbt_ptr_t *pp; /* pointer to block address */ + __be64 *pp; /* pointer to block address */ xfs_bmbt_rec_t *ep; /* pointer to current extent */ xfs_bmbt_rec_t *lastp; /* pointer to previous extent */ xfs_bmbt_rec_t *nextp; /* pointer to next extent */ @@ -6231,10 +6228,12 @@ ASSERT(level > 0); xfs_check_block(block, mp, 1, ifp->if_broot_bytes); pp = XFS_BMAP_BROOT_PTR_ADDR(block, 1, ifp->if_broot_bytes); - ASSERT(INT_GET(*pp, ARCH_CONVERT) != NULLDFSBNO); - ASSERT(XFS_FSB_TO_AGNO(mp, INT_GET(*pp, ARCH_CONVERT)) < mp->m_sb.sb_agcount); - ASSERT(XFS_FSB_TO_AGBNO(mp, INT_GET(*pp, ARCH_CONVERT)) < mp->m_sb.sb_agblocks); - bno = INT_GET(*pp, ARCH_CONVERT); + bno = be64_to_cpu(*pp); + + ASSERT(bno != NULLDFSBNO); + ASSERT(XFS_FSB_TO_AGNO(mp, bno) < mp->m_sb.sb_agcount); + ASSERT(XFS_FSB_TO_AGBNO(mp, bno) < mp->m_sb.sb_agblocks); + /* * Go down the tree until leaf level is reached, following the first * pointer (leftmost) at each level. @@ -6265,8 +6264,8 @@ xfs_check_block(block, mp, 0, 0); pp = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, block, 1, mp->m_bmap_dmxr[1]); - XFS_WANT_CORRUPTED_GOTO(XFS_FSB_SANITY_CHECK(mp, INT_GET(*pp, ARCH_CONVERT)), error0); - bno = INT_GET(*pp, ARCH_CONVERT); + bno = be64_to_cpu(*pp); + XFS_WANT_CORRUPTED_GOTO(XFS_FSB_SANITY_CHECK(mp, bno), error0); if (bp_release) { bp_release = 0; xfs_trans_brelse(NULL, bp); @@ -6372,7 +6371,7 @@ xfs_ifork_t *ifp; /* fork structure */ int level; /* btree level, for checking */ xfs_mount_t *mp; /* file system mount structure */ - xfs_bmbt_ptr_t *pp; /* pointer to block address */ + __be64 *pp; /* pointer to block address */ bno = NULLFSBLOCK; mp = ip->i_mount; @@ -6395,10 +6394,10 @@ level = be16_to_cpu(block->bb_level); ASSERT(level > 0); pp = XFS_BMAP_BROOT_PTR_ADDR(block, 1, ifp->if_broot_bytes); - ASSERT(INT_GET(*pp, ARCH_CONVERT) != NULLDFSBNO); - ASSERT(XFS_FSB_TO_AGNO(mp, INT_GET(*pp, ARCH_CONVERT)) < mp->m_sb.sb_agcount); - ASSERT(XFS_FSB_TO_AGBNO(mp, INT_GET(*pp, ARCH_CONVERT)) < mp->m_sb.sb_agblocks); - bno = INT_GET(*pp, ARCH_CONVERT); + bno = be64_to_cpu(*pp); + ASSERT(bno != NULLDFSBNO); + ASSERT(XFS_FSB_TO_AGNO(mp, bno) < mp->m_sb.sb_agcount); + ASSERT(XFS_FSB_TO_AGBNO(mp, bno) < mp->m_sb.sb_agblocks); if (unlikely(xfs_bmap_count_tree(mp, tp, ifp, bno, level, count) < 0)) { XFS_ERROR_REPORT("xfs_bmap_count_blocks(2)", XFS_ERRLEVEL_LOW, @@ -6425,7 +6424,7 @@ int error; xfs_buf_t *bp, *nbp; int level = levelin; - xfs_bmbt_ptr_t *pp; + __be64 *pp; xfs_fsblock_t bno = blockno; xfs_fsblock_t nextbno; xfs_bmbt_block_t *block, *nextblock; @@ -6452,7 +6451,7 @@ /* Dive to the next level */ pp = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, block, 1, mp->m_bmap_dmxr[1]); - bno = INT_GET(*pp, ARCH_CONVERT); + bno = be64_to_cpu(*pp); if (unlikely((error = xfs_bmap_count_tree(mp, tp, ifp, bno, level, count)) < 0)) { xfs_trans_brelse(tp, bp); Index: xfs-2.6.x/fs/xfs/xfs_bmap_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:37:01.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:37:17.000000000 +0200 @@ -382,7 +382,7 @@ pp = XFS_BMAP_PTR_IADDR(block, 1, cur); #ifdef DEBUG for (i = ptr; i < numrecs; i++) { - if ((error = xfs_btree_check_lptr_disk(cur, pp, level))) { + if ((error = xfs_btree_check_lptr_disk(cur, *pp, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); goto error0; } @@ -870,14 +870,13 @@ memmove(&pp[ptr], &pp[ptr - 1], /* INT_: direct copy */ (numrecs - ptr + 1) * sizeof(*pp)); #ifdef DEBUG - if ((error = xfs_btree_check_lptr(cur, (xfs_bmbt_ptr_t)*bnop, - level))) { + if ((error = xfs_btree_check_lptr(cur, *bnop, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } #endif kp[ptr - 1] = key; - INT_SET(pp[ptr - 1], ARCH_CONVERT, *bnop); + pp[ptr - 1] = cpu_to_be64(*bnop); numrecs++; block->bb_numrecs = cpu_to_be16(numrecs); xfs_bmbt_log_keys(cur, bp, ptr, numrecs); @@ -1189,13 +1188,13 @@ if (diff > 0 && --keyno < 1) keyno = 1; pp = XFS_BMAP_PTR_IADDR(block, keyno, cur); + fsbno = be64_to_cpu(*pp); #ifdef DEBUG - if ((error = xfs_btree_check_lptr_disk(cur, *pp, level))) { + if ((error = xfs_btree_check_lptr(cur, fsbno, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } #endif - fsbno = INT_GET(*pp, ARCH_CONVERT); cur->bc_ptrs[level] = keyno; } } @@ -1445,7 +1444,7 @@ rpp = XFS_BMAP_PTR_IADDR(right, 1, cur); #ifdef DEBUG for (i = be16_to_cpu(right->bb_numrecs) - 1; i >= 0; i--) { - if ((error = xfs_btree_check_lptr_disk(cur, rpp[i] level))) { + if ((error = xfs_btree_check_lptr_disk(cur, rpp[i], level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } @@ -1728,9 +1727,9 @@ { int dmxr; xfs_bmbt_key_t *fkp; - xfs_bmbt_ptr_t *fpp; + __be64 *fpp; xfs_bmbt_key_t *tkp; - xfs_bmbt_ptr_t *tpp; + __be64 *tpp; rblock->bb_magic = cpu_to_be32(XFS_BMAP_MAGIC); rblock->bb_level = dblock->bb_level; @@ -1745,7 +1744,7 @@ tpp = XFS_BMAP_BROOT_PTR_ADDR(rblock, 1, rblocklen); dmxr = be16_to_cpu(dblock->bb_numrecs); memcpy(tkp, fkp, sizeof(*fkp) * dmxr); - memcpy(tpp, fpp, sizeof(*fpp) * dmxr); /* INT_: direct copy */ + memcpy(tpp, fpp, sizeof(*fpp) * dmxr); } /* @@ -1805,7 +1804,7 @@ tp = cur->bc_tp; mp = cur->bc_mp; for (block = xfs_bmbt_get_block(cur, lev, &bp); lev > level; ) { - fsbno = INT_GET(*XFS_BMAP_PTR_IADDR(block, cur->bc_ptrs[lev], cur), ARCH_CONVERT); + fsbno = be64_to_cpu(*XFS_BMAP_PTR_IADDR(block, cur->bc_ptrs[lev], cur)); if ((error = xfs_btree_read_bufl(mp, tp, fsbno, 0, &bp, XFS_BMAP_BTREE_REF))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); @@ -2135,7 +2134,7 @@ tp = cur->bc_tp; mp = cur->bc_mp; for (block = xfs_bmbt_get_block(cur, lev, &bp); lev > level; ) { - fsbno = INT_GET(*XFS_BMAP_PTR_IADDR(block, cur->bc_ptrs[lev], cur), ARCH_CONVERT); + fsbno = be64_to_cpu(*XFS_BMAP_PTR_IADDR(block, cur->bc_ptrs[lev], cur)); if ((error = xfs_btree_read_bufl(mp, tp, fsbno, 0, &bp, XFS_BMAP_BTREE_REF))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); @@ -2361,7 +2360,7 @@ return error; } #endif - args.fsbno = INT_GET(*pp, ARCH_CONVERT); + args.fsbno = be64_to_cpu(*pp); args.type = XFS_ALLOCTYPE_START_BNO; } else args.type = XFS_ALLOCTYPE_NEAR_BNO; @@ -2401,13 +2400,12 @@ #endif memcpy(cpp, pp, be16_to_cpu(cblock->bb_numrecs) * sizeof(*pp)); #ifdef DEBUG - if ((error = xfs_btree_check_lptr(cur, (xfs_bmbt_ptr_t)args.fsbno, - level))) { + if ((error = xfs_btree_check_lptr(cur, args.fsbno, level))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } #endif - INT_SET(*pp, ARCH_CONVERT, args.fsbno); + *pp = cpu_to_be64(args.fsbno); xfs_iroot_realloc(cur->bc_private.b.ip, 1 - be16_to_cpu(cblock->bb_numrecs), cur->bc_private.b.whichfork); xfs_btree_setbuf(cur, level, bp); @@ -2681,9 +2679,9 @@ { int dmxr; xfs_bmbt_key_t *fkp; - xfs_bmbt_ptr_t *fpp; + __be64 *fpp; xfs_bmbt_key_t *tkp; - xfs_bmbt_ptr_t *tpp; + __be64 *tpp; ASSERT(be32_to_cpu(rblock->bb_magic) == XFS_BMAP_MAGIC); ASSERT(be64_to_cpu(rblock->bb_leftsib) == NULLDFSBNO); @@ -2698,7 +2696,7 @@ tpp = XFS_BTREE_PTR_ADDR(dblocklen, xfs_bmdr, dblock, 1, dmxr); dmxr = be16_to_cpu(dblock->bb_numrecs); memcpy(tkp, fkp, sizeof(*fkp) * dmxr); - memcpy(tpp, fpp, sizeof(*fpp) * dmxr); /* INT_: direct copy */ + memcpy(tpp, fpp, sizeof(*fpp) * dmxr); } /* Index: xfs-2.6.x/fs/xfs/xfs_btree.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_btree.h 2006-07-09 19:37:01.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_btree.h 2006-07-09 19:37:17.000000000 +0200 @@ -244,7 +244,7 @@ int level); /* btree block level */ #define xfs_btree_check_lptr_disk(cur, ptr, level) \ - xfs_btree_check_lptr(cur, INT_GET(ptr, ARCH_CONVERT), level) + xfs_btree_check_lptr(cur, be64_to_cpu(ptr), level) /* * Checking routine: check that short form block header is ok. From owner-xfs@oss.sgi.com Mon Jul 10 11:04:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:52 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDi021824 for ; Mon, 10 Jul 2006 11:04:24 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH4PRT027046 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:04:26 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH4PYP027044; Mon, 10 Jul 2006 19:04:25 +0200 Date: Mon, 10 Jul 2006 19:04:25 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH 5/7] xfs: endianess annotations for xfs_bmbt_ptr_t/xfs_bmdr_ptr_t Message-ID: <20060710170425.GE26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8188 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 838 Lines: 23 There were already handled correctly, so only switch to __be64. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/xfs_bmap_btree.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap_btree.h 2006-02-18 15:45:01.000000000 +0100 +++ xfs-2.6.x/fs/xfs/xfs_bmap_btree.h 2006-02-21 20:44:57.000000000 +0100 @@ -168,8 +168,10 @@ xfs_dfiloff_t br_startoff; /* starting file offset */ } xfs_bmbt_key_t, xfs_bmdr_key_t; -typedef xfs_dfsbno_t xfs_bmbt_ptr_t, xfs_bmdr_ptr_t; /* btree pointer type */ - /* btree block header type */ +/* btree pointer type */ +typedef __be64 xfs_bmbt_ptr_t, xfs_bmdr_ptr_t; + +/* btree block header type */ typedef struct xfs_btree_lblock xfs_bmbt_block_t; #define XFS_BUF_TO_BMBT_BLOCK(bp) ((xfs_bmbt_block_t *)XFS_BUF_PTR(bp)) From owner-xfs@oss.sgi.com Mon Jul 10 11:04:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:50 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDk021824 for ; Mon, 10 Jul 2006 11:04:26 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH4ART026996 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:04:10 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH4ASJ026994; Mon, 10 Jul 2006 19:04:10 +0200 Date: Mon, 10 Jul 2006 19:04:10 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH 2/7] xfs: endianess annotations for xfs_inobt_rec_t / xfs_inobt_key_t Message-ID: <20060710170410.GB26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8187 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 11421 Lines: 322 There's some incore users of xfs_inobt_rec, so introduce an _incore variant. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/xfs_btree.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_btree.h 2006-02-21 20:45:07.000000000 +0100 +++ xfs-2.6.x/fs/xfs/xfs_btree.h 2006-07-09 19:34:52.000000000 +0200 @@ -145,7 +145,7 @@ union { xfs_alloc_rec_incore_t a; xfs_bmbt_irec_t b; - xfs_inobt_rec_t i; + xfs_inobt_rec_incore_t i; } bc_rec; /* current insert/search record value */ struct xfs_buf *bc_bufs[XFS_BTREE_MAXLEVELS]; /* buf ptr per level */ int bc_ptrs[XFS_BTREE_MAXLEVELS]; /* key/record # */ Index: xfs-2.6.x/fs/xfs/xfs_ialloc_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_ialloc_btree.c 2006-07-09 19:28:17.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_ialloc_btree.c 2006-07-09 19:34:52.000000000 +0200 @@ -568,7 +568,7 @@ /* * Make a key out of the record data to be inserted, and save it. */ - key.ir_startino = recp->ir_startino; /* INT_: direct copy */ + key.ir_startino = recp->ir_startino; optr = ptr = cur->bc_ptrs[level]; /* * If we're off the left edge, return failure. @@ -641,7 +641,7 @@ return error; #endif ptr = cur->bc_ptrs[level]; - nrec.ir_startino = nkey.ir_startino; /* INT_: direct copy */ + nrec.ir_startino = nkey.ir_startino; } else { /* * Otherwise the insert fails. @@ -950,12 +950,12 @@ xfs_inobt_key_t *kkp; kkp = kkbase + keyno - 1; - startino = INT_GET(kkp->ir_startino, ARCH_CONVERT); + startino = be32_to_cpu(kkp->ir_startino); } else { xfs_inobt_rec_t *krp; krp = krbase + keyno - 1; - startino = INT_GET(krp->ir_startino, ARCH_CONVERT); + startino = be32_to_cpu(krp->ir_startino); } /* * Compute difference to get next direction. @@ -1160,7 +1160,7 @@ } else { memmove(rrp, rrp + 1, be16_to_cpu(right->bb_numrecs) * sizeof(*rrp)); xfs_inobt_log_recs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs)); - key.ir_startino = rrp->ir_startino; /* INT_: direct copy */ + key.ir_startino = rrp->ir_startino; rkp = &key; } /* @@ -1301,9 +1301,9 @@ kp[1] = *XFS_INOBT_KEY_ADDR(right, 1, cur); /* INT_: struct copy */ } else { rp = XFS_INOBT_REC_ADDR(left, 1, cur); - INT_COPY(kp[0].ir_startino, rp->ir_startino, ARCH_CONVERT); + kp[0].ir_startino = rp->ir_startino; rp = XFS_INOBT_REC_ADDR(right, 1, cur); - INT_COPY(kp[1].ir_startino, rp->ir_startino, ARCH_CONVERT); + kp[1].ir_startino = rp->ir_startino; } xfs_inobt_log_keys(cur, nbp, 1, 2); /* @@ -1420,7 +1420,7 @@ memmove(rrp + 1, rrp, be16_to_cpu(right->bb_numrecs) * sizeof(*rrp)); *rrp = *lrp; xfs_inobt_log_recs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs) + 1); - key.ir_startino = rrp->ir_startino; /* INT_: direct copy */ + key.ir_startino = rrp->ir_startino; rkp = &key; } /* @@ -1559,7 +1559,7 @@ rrp = XFS_INOBT_REC_ADDR(right, 1, cur); memcpy(rrp, lrp, be16_to_cpu(right->bb_numrecs) * sizeof(*rrp)); xfs_inobt_log_recs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs)); - keyp->ir_startino = rrp->ir_startino; /* INT_: direct copy */ + keyp->ir_startino = rrp->ir_startino; } /* * Find the left block number by looking in the buffer. @@ -1813,9 +1813,9 @@ * Point to the record and extract its data. */ rec = XFS_INOBT_REC_ADDR(block, ptr, cur); - *ino = INT_GET(rec->ir_startino, ARCH_CONVERT); - *fcnt = INT_GET(rec->ir_freecount, ARCH_CONVERT); - *free = INT_GET(rec->ir_free, ARCH_CONVERT); + *ino = be32_to_cpu(rec->ir_startino); + *fcnt = be32_to_cpu(rec->ir_freecount); + *free = be64_to_cpu(rec->ir_free); *stat = 1; return 0; } @@ -1930,9 +1930,9 @@ level = 0; nbno = NULLAGBLOCK; - INT_SET(nrec.ir_startino, ARCH_CONVERT, cur->bc_rec.i.ir_startino); - INT_SET(nrec.ir_freecount, ARCH_CONVERT, cur->bc_rec.i.ir_freecount); - INT_SET(nrec.ir_free, ARCH_CONVERT, cur->bc_rec.i.ir_free); + nrec.ir_startino = cpu_to_be32(cur->bc_rec.i.ir_startino); + nrec.ir_freecount = cpu_to_be32(cur->bc_rec.i.ir_freecount); + nrec.ir_free = cpu_to_be64(cur->bc_rec.i.ir_free); ncur = (xfs_btree_cur_t *)0; pcur = cur; /* @@ -2060,9 +2060,9 @@ /* * Fill in the new contents and log them. */ - INT_SET(rp->ir_startino, ARCH_CONVERT, ino); - INT_SET(rp->ir_freecount, ARCH_CONVERT, fcnt); - INT_SET(rp->ir_free, ARCH_CONVERT, free); + rp->ir_startino = cpu_to_be32(ino); + rp->ir_freecount = cpu_to_be32(fcnt); + rp->ir_free = cpu_to_be64(free); xfs_inobt_log_recs(cur, bp, ptr, ptr); /* * Updating first record in leaf. Pass new key value up to our parent. @@ -2070,7 +2070,7 @@ if (ptr == 1) { xfs_inobt_key_t key; /* key containing [ino] */ - INT_SET(key.ir_startino, ARCH_CONVERT, ino); + key.ir_startino = cpu_to_be32(ino); if ((error = xfs_inobt_updkey(cur, &key, 1))) return error; } Index: xfs-2.6.x/fs/xfs/xfs_ialloc_btree.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_ialloc_btree.h 2006-02-21 20:45:07.000000000 +0100 +++ xfs-2.6.x/fs/xfs/xfs_ialloc_btree.h 2006-07-09 19:34:52.000000000 +0200 @@ -47,19 +47,24 @@ /* * Data record structure */ -typedef struct xfs_inobt_rec -{ +typedef struct xfs_inobt_rec { + __be32 ir_startino; /* starting inode number */ + __be32 ir_freecount; /* count of free inodes (set bits) */ + __be64 ir_free; /* free inode mask */ +} xfs_inobt_rec_t; + +typedef struct xfs_inobt_rec_incore { xfs_agino_t ir_startino; /* starting inode number */ __int32_t ir_freecount; /* count of free inodes (set bits) */ xfs_inofree_t ir_free; /* free inode mask */ -} xfs_inobt_rec_t; +} xfs_inobt_rec_incore_t; + /* * Key structure */ -typedef struct xfs_inobt_key -{ - xfs_agino_t ir_startino; /* starting inode number */ +typedef struct xfs_inobt_key { + __be32 ir_startino; /* starting inode number */ } xfs_inobt_key_t; /* btree pointer type */ @@ -77,7 +82,7 @@ #define XFS_INOBT_IS_FREE(rp,i) \ (((rp)->ir_free & XFS_INOBT_MASK(i)) != 0) #define XFS_INOBT_IS_FREE_DISK(rp,i) \ - ((INT_GET((rp)->ir_free,ARCH_CONVERT) & XFS_INOBT_MASK(i)) != 0) + ((be64_to_cpu((rp)->ir_free) & XFS_INOBT_MASK(i)) != 0) #define XFS_INOBT_SET_FREE(rp,i) ((rp)->ir_free |= XFS_INOBT_MASK(i)) #define XFS_INOBT_CLR_FREE(rp,i) ((rp)->ir_free &= ~XFS_INOBT_MASK(i)) Index: xfs-2.6.x/fs/xfs/xfs_itable.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_itable.c 2006-07-09 19:28:17.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_itable.c 2006-07-09 19:34:52.000000000 +0200 @@ -395,9 +395,9 @@ gcnt++; } gfree |= XFS_INOBT_MASKN(0, chunkidx); - INT_SET(irbp->ir_startino, ARCH_CONVERT, gino); - INT_SET(irbp->ir_freecount, ARCH_CONVERT, gcnt); - INT_SET(irbp->ir_free, ARCH_CONVERT, gfree); + irbp->ir_startino = cpu_to_be32(gino); + irbp->ir_freecount = cpu_to_be32(gcnt); + irbp->ir_free = cpu_to_be64(gfree); irbp++; agino = gino + XFS_INODES_PER_CHUNK; icount = XFS_INODES_PER_CHUNK - gcnt; @@ -453,9 +453,9 @@ * If this chunk has any allocated inodes, save it. */ if (gcnt < XFS_INODES_PER_CHUNK) { - INT_SET(irbp->ir_startino, ARCH_CONVERT, gino); - INT_SET(irbp->ir_freecount, ARCH_CONVERT, gcnt); - INT_SET(irbp->ir_free, ARCH_CONVERT, gfree); + irbp->ir_startino = cpu_to_be32(gino); + irbp->ir_freecount = cpu_to_be32(gcnt); + irbp->ir_free = cpu_to_be64(gfree); irbp++; icount += XFS_INODES_PER_CHUNK - gcnt; } @@ -488,14 +488,14 @@ * inodes in that cluster. */ for (agbno = XFS_AGINO_TO_AGBNO(mp, - INT_GET(irbp[1].ir_startino, ARCH_CONVERT)), + be32_to_cpu(irbp[1].ir_startino)), chunkidx = 0; chunkidx < XFS_INODES_PER_CHUNK; chunkidx += nicluster, agbno += nbcluster) { if (XFS_INOBT_MASKN(chunkidx, nicluster) & - ~(INT_GET(irbp[1].ir_free, ARCH_CONVERT))) + ~(be64_to_cpu(irbp[1].ir_free))) xfs_btree_reada_bufs(mp, agno, agbno, nbcluster); } @@ -503,9 +503,9 @@ /* * Now process this chunk of inodes. */ - for (agino = INT_GET(irbp->ir_startino, ARCH_CONVERT), chunkidx = 0, clustidx = 0; + for (agino = be32_to_cpu(irbp->ir_startino), chunkidx = 0, clustidx = 0; ubleft > 0 && - INT_GET(irbp->ir_freecount, ARCH_CONVERT) < XFS_INODES_PER_CHUNK; + be32_to_cpu(irbp->ir_freecount) < XFS_INODES_PER_CHUNK; chunkidx++, clustidx++, agino++) { ASSERT(chunkidx < XFS_INODES_PER_CHUNK); /* @@ -525,7 +525,7 @@ */ if ((chunkidx & (nicluster - 1)) == 0) { agbno = XFS_AGINO_TO_AGBNO(mp, - INT_GET(irbp->ir_startino, ARCH_CONVERT)) + + be32_to_cpu(irbp->ir_startino)) + ((chunkidx & nimask) >> mp->m_sb.sb_inopblog); @@ -564,13 +564,13 @@ /* * Skip if this inode is free. */ - if (XFS_INOBT_MASK(chunkidx) & INT_GET(irbp->ir_free, ARCH_CONVERT)) + if (XFS_INOBT_MASK(chunkidx) & be64_to_cpu(irbp->ir_free)) continue; /* * Count used inodes as free so we can tell * when the chunk is used up. */ - INT_MOD(irbp->ir_freecount, ARCH_CONVERT, +1); + be32_add(&irbp->ir_freecount, 1); ino = XFS_AGINO_TO_INO(mp, agno, agino); bno = XFS_AGB_TO_DADDR(mp, agno, agbno); if (flags & BULKSTAT_FG_QUICK) { Index: xfs-2.6.x/fs/xfs/xfs_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_btree.c 2006-07-09 19:28:16.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_btree.c 2006-07-09 19:34:52.000000000 +0200 @@ -170,7 +170,7 @@ k1 = ak1; k2 = ak2; - ASSERT(INT_GET(k1->ir_startino, ARCH_CONVERT) < INT_GET(k2->ir_startino, ARCH_CONVERT)); + ASSERT(be32_to_cpu(k1->ir_startino) < be32_to_cpu(k2->ir_startino)); break; } default: @@ -285,8 +285,8 @@ r1 = ar1; r2 = ar2; - ASSERT(INT_GET(r1->ir_startino, ARCH_CONVERT) + XFS_INODES_PER_CHUNK <= - INT_GET(r2->ir_startino, ARCH_CONVERT)); + ASSERT(be32_to_cpu(r1->ir_startino) + XFS_INODES_PER_CHUNK <= + be32_to_cpu(r2->ir_startino)); break; } default: Index: xfs-2.6.x/fs/xfs/xfs_ialloc.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_ialloc.c 2006-07-09 19:28:17.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_ialloc.c 2006-07-09 19:34:52.000000000 +0200 @@ -529,10 +529,10 @@ int offset; /* index of inode in chunk */ xfs_agino_t pagino; /* parent's a.g. relative inode # */ xfs_agnumber_t pagno; /* parent's allocation group number */ - xfs_inobt_rec_t rec; /* inode allocation record */ + xfs_inobt_rec_incore_t rec; /* inode allocation record */ xfs_agnumber_t tagno; /* testing allocation group number */ xfs_btree_cur_t *tcur; /* temp cursor */ - xfs_inobt_rec_t trec; /* temp inode allocation record */ + xfs_inobt_rec_incore_t trec; /* temp inode allocation record */ if (*IO_agbp == NULL) { @@ -945,7 +945,7 @@ int ilen; /* inodes in an inode cluster */ xfs_mount_t *mp; /* mount structure for filesystem */ int off; /* offset of inode in inode chunk */ - xfs_inobt_rec_t rec; /* btree record */ + xfs_inobt_rec_incore_t rec; /* btree record */ mp = tp->t_mountp; From owner-xfs@oss.sgi.com Mon Jul 10 11:04:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:04:45 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AI4EDc021824 for ; Mon, 10 Jul 2006 11:04:20 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AH4bRT027074 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 19:04:37 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AH4bjB027072; Mon, 10 Jul 2006 19:04:37 +0200 Date: Mon, 10 Jul 2006 19:04:37 +0200 From: Christoph Hellwig To: nathans@sgi.com Cc: xfs@oss.sgi.com Subject: [PATCH 7/7] xfs: endianess annotations for xfs_bmbt_key Message-ID: <20060710170437.GG26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8186 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 7973 Lines: 228 Trivial as there are no incore users. Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/xfs_bmap.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap.c 2006-07-09 19:38:02.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_bmap.c 2006-07-09 19:38:18.000000000 +0200 @@ -3512,7 +3512,7 @@ */ kp = XFS_BMAP_KEY_IADDR(block, 1, cur); arp = XFS_BMAP_REC_IADDR(ablock, 1, cur); - INT_SET(kp->br_startoff, ARCH_CONVERT, xfs_bmbt_disk_get_startoff(arp)); + kp->br_startoff = cpu_to_be64(xfs_bmbt_disk_get_startoff(arp)); pp = XFS_BMAP_PTR_IADDR(block, 1, cur); *pp = cpu_to_be64(args.fsbno); /* Index: xfs-2.6.x/fs/xfs/xfs_bmap_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:37:17.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:38:18.000000000 +0200 @@ -58,7 +58,7 @@ STATIC int xfs_bmbt_lshift(xfs_btree_cur_t *, int, int *); STATIC int xfs_bmbt_rshift(xfs_btree_cur_t *, int, int *); STATIC int xfs_bmbt_split(xfs_btree_cur_t *, int, xfs_fsblock_t *, - xfs_bmbt_key_t *, xfs_btree_cur_t **, int *); + __uint64_t *, xfs_btree_cur_t **, int *); STATIC int xfs_bmbt_updkey(xfs_btree_cur_t *, xfs_bmbt_key_t *, int); @@ -192,16 +192,11 @@ xfs_btree_cur_t *cur, int i, xfs_fsblock_t f, - xfs_bmbt_key_t *k, + xfs_dfiloff_t o, int line) { - xfs_dfsbno_t d; - xfs_dfiloff_t o; - - d = (xfs_dfsbno_t)f; - o = INT_GET(k->br_startoff, ARCH_CONVERT); xfs_bmbt_trace_enter(func, cur, ARGS, XFS_BMBT_KTRACE_ARGIFK, line, - i, d >> 32, (int)d, o >> 32, + i, (xfs_dfsbno_t)f >> 32, (int)f, o >> 32, (int)o, 0, 0, 0, 0, 0, 0); } @@ -248,7 +243,7 @@ { xfs_dfiloff_t o; - o = INT_GET(k->br_startoff, ARCH_CONVERT); + o = be64_to_cpu(k->br_startoff); xfs_bmbt_trace_enter(func, cur, ARGS, XFS_BMBT_KTRACE_ARGIFK, line, i, o >> 32, (int)o, 0, 0, 0, 0, 0, @@ -286,8 +281,8 @@ xfs_bmbt_trace_argfffi(fname, c, o, b, i, j, __LINE__) #define XFS_BMBT_TRACE_ARGI(c,i) \ xfs_bmbt_trace_argi(fname, c, i, __LINE__) -#define XFS_BMBT_TRACE_ARGIFK(c,i,f,k) \ - xfs_bmbt_trace_argifk(fname, c, i, f, k, __LINE__) +#define XFS_BMBT_TRACE_ARGIFK(c,i,f,s) \ + xfs_bmbt_trace_argifk(fname, c, i, f, s, __LINE__) #define XFS_BMBT_TRACE_ARGIFR(c,i,f,r) \ xfs_bmbt_trace_argifr(fname, c, i, f, r, __LINE__) #define XFS_BMBT_TRACE_ARGIK(c,i,k) \ @@ -299,7 +294,7 @@ #define XFS_BMBT_TRACE_ARGBII(c,b,i,j) #define XFS_BMBT_TRACE_ARGFFFI(c,o,b,i,j) #define XFS_BMBT_TRACE_ARGI(c,i) -#define XFS_BMBT_TRACE_ARGIFK(c,i,f,k) +#define XFS_BMBT_TRACE_ARGIFK(c,i,f,s) #define XFS_BMBT_TRACE_ARGIFR(c,i,f,r) #define XFS_BMBT_TRACE_ARGIK(c,i,k) #define XFS_BMBT_TRACE_CURSOR(c,s) @@ -404,7 +399,8 @@ xfs_bmbt_log_recs(cur, bp, ptr, numrecs - 1); } if (ptr == 1) { - INT_SET(key.br_startoff, ARCH_CONVERT, xfs_bmbt_disk_get_startoff(rp)); + key.br_startoff = + cpu_to_be64(xfs_bmbt_disk_get_startoff(rp)); kp = &key; } } @@ -748,7 +744,7 @@ int logflags; /* inode logging flags */ xfs_fsblock_t nbno; /* new block number */ struct xfs_btree_cur *ncur; /* new btree cursor */ - xfs_bmbt_key_t nkey; /* new btree key value */ + __uint64_t startoff; /* new btree key value */ xfs_bmbt_rec_t nrec; /* new record count */ int optr; /* old key/record index */ xfs_bmbt_ptr_t *pp; /* pointer to bmap block addr */ @@ -760,8 +756,7 @@ XFS_BMBT_TRACE_CURSOR(cur, ENTRY); XFS_BMBT_TRACE_ARGIFR(cur, level, *bnop, recp); ncur = (xfs_btree_cur_t *)0; - INT_SET(key.br_startoff, ARCH_CONVERT, - xfs_bmbt_disk_get_startoff(recp)); + key.br_startoff = cpu_to_be64(xfs_bmbt_disk_get_startoff(recp)); optr = ptr = cur->bc_ptrs[level]; if (ptr == 0) { XFS_BMBT_TRACE_CURSOR(cur, EXIT); @@ -820,7 +815,7 @@ optr = ptr = cur->bc_ptrs[level]; } else { if ((error = xfs_bmbt_split(cur, level, - &nbno, &nkey, &ncur, + &nbno, &startoff, &ncur, &i))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); @@ -840,7 +835,7 @@ #endif ptr = cur->bc_ptrs[level]; xfs_bmbt_disk_set_allf(&nrec, - nkey.br_startoff, 0, 0, + startoff, 0, 0, XFS_EXT_NORM); } else { XFS_BMBT_TRACE_CURSOR(cur, @@ -1169,7 +1164,7 @@ keyno = (low + high) >> 1; if (level > 0) { kkp = kkbase + keyno - 1; - startoff = INT_GET(kkp->br_startoff, ARCH_CONVERT); + startoff = be64_to_cpu(kkp->br_startoff); } else { krp = krbase + keyno - 1; startoff = xfs_bmbt_disk_get_startoff(krp); @@ -1353,8 +1348,7 @@ } else { memmove(rrp, rrp + 1, rrecs * sizeof(*rrp)); xfs_bmbt_log_recs(cur, rbp, 1, rrecs); - INT_SET(key.br_startoff, ARCH_CONVERT, - xfs_bmbt_disk_get_startoff(rrp)); + key.br_startoff = cpu_to_be64(xfs_bmbt_disk_get_startoff(rrp)); rkp = &key; } if ((error = xfs_bmbt_updkey(cur, rkp, level + 1))) { @@ -1468,8 +1462,7 @@ memmove(rrp + 1, rrp, be16_to_cpu(right->bb_numrecs) * sizeof(*rrp)); *rrp = *lrp; xfs_bmbt_log_recs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs) + 1); - INT_SET(key.br_startoff, ARCH_CONVERT, - xfs_bmbt_disk_get_startoff(rrp)); + key.br_startoff = cpu_to_be64(xfs_bmbt_disk_get_startoff(rrp)); rkp = &key; } be16_add(&left->bb_numrecs, -1); @@ -1534,7 +1527,7 @@ xfs_btree_cur_t *cur, int level, xfs_fsblock_t *bnop, - xfs_bmbt_key_t *keyp, + __uint64_t *startoff, xfs_btree_cur_t **curp, int *stat) /* success/failure */ { @@ -1559,7 +1552,7 @@ xfs_bmbt_rec_t *rrp; /* right record pointer */ XFS_BMBT_TRACE_CURSOR(cur, ENTRY); - XFS_BMBT_TRACE_ARGIFK(cur, level, *bnop, keyp); + XFS_BMBT_TRACE_ARGIFK(cur, level, *bnop, *startoff); args.tp = cur->bc_tp; args.mp = cur->bc_mp; lbp = cur->bc_bufs[level]; @@ -1628,13 +1621,13 @@ memcpy(rpp, lpp, be16_to_cpu(right->bb_numrecs) * sizeof(*rpp)); xfs_bmbt_log_keys(cur, rbp, 1, be16_to_cpu(right->bb_numrecs)); xfs_bmbt_log_ptrs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs)); - keyp->br_startoff = INT_GET(rkp->br_startoff, ARCH_CONVERT); + *startoff = be64_to_cpu(rkp->br_startoff); } else { lrp = XFS_BMAP_REC_IADDR(left, i, cur); rrp = XFS_BMAP_REC_IADDR(right, 1, cur); memcpy(rrp, lrp, be16_to_cpu(right->bb_numrecs) * sizeof(*rrp)); xfs_bmbt_log_recs(cur, rbp, 1, be16_to_cpu(right->bb_numrecs)); - keyp->br_startoff = xfs_bmbt_disk_get_startoff(rrp); + *startoff = xfs_bmbt_disk_get_startoff(rrp); } be16_add(&left->bb_numrecs, -(be16_to_cpu(right->bb_numrecs))); right->bb_rightsib = left->bb_rightsib; @@ -2738,7 +2731,7 @@ XFS_BMBT_TRACE_CURSOR(cur, EXIT); return 0; } - INT_SET(key.br_startoff, ARCH_CONVERT, off); + key.br_startoff = cpu_to_be64(off); if ((error = xfs_bmbt_updkey(cur, &key, 1))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; Index: xfs-2.6.x/fs/xfs/xfs_bmap_btree.h =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_bmap_btree.h 2006-07-09 19:37:06.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_bmap_btree.h 2006-07-09 19:38:18.000000000 +0200 @@ -163,9 +163,8 @@ /* * Key structure for non-leaf levels of the tree. */ -typedef struct xfs_bmbt_key -{ - xfs_dfiloff_t br_startoff; /* starting file offset */ +typedef struct xfs_bmbt_key { + __be64 br_startoff; /* starting file offset */ } xfs_bmbt_key_t, xfs_bmdr_key_t; /* btree pointer type */ Index: xfs-2.6.x/fs/xfs/xfs_btree.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/xfs_btree.c 2006-07-09 19:34:52.000000000 +0200 +++ xfs-2.6.x/fs/xfs/xfs_btree.c 2006-07-09 19:38:18.000000000 +0200 @@ -161,7 +161,7 @@ k1 = ak1; k2 = ak2; - ASSERT(INT_GET(k1->br_startoff, ARCH_CONVERT) < INT_GET(k2->br_startoff, ARCH_CONVERT)); + ASSERT(be64_to_cpu(k1->br_startoff) < be64_to_cpu(k2->br_startoff)); break; } case XFS_BTNUM_INO: { From owner-xfs@oss.sgi.com Mon Jul 10 11:11:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 11:11:35 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AIB9DW025855 for ; Mon, 10 Jul 2006 11:11:14 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6AGtdRT026725 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jul 2006 18:55:39 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6AGtdnc026723; Mon, 10 Jul 2006 18:55:39 +0200 Date: Mon, 10 Jul 2006 18:55:39 +0200 From: Christoph Hellwig To: nathans@sgi.com, xfs@oss.sgi.com Subject: [PATCH] xfs: fix brown paperbag quota-aware stafs bug Message-ID: <20060710165539.GA26673@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8189 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 1556 Lines: 44 All xfs_disk_dquot_t values are (as the name says) disk endian. Before putting them into struct statfs they should be endian-swapped. (I wish someone at SGI would run sparse once in a while..) Signed-off-by: Christoph Hellwig Index: xfs-2.6.x/fs/xfs/quota/xfs_qm_bhv.c =================================================================== --- xfs-2.6.x.orig/fs/xfs/quota/xfs_qm_bhv.c 2006-07-09 19:28:21.000000000 +0200 +++ xfs-2.6.x/fs/xfs/quota/xfs_qm_bhv.c 2006-07-09 20:04:56.000000000 +0200 @@ -217,17 +217,24 @@ return 0; dp = &dqp->q_core; - limit = dp->d_blk_softlimit ? dp->d_blk_softlimit : dp->d_blk_hardlimit; + limit = dp->d_blk_softlimit ? + be64_to_cpu(dp->d_blk_softlimit) : + be64_to_cpu(dp->d_blk_hardlimit); if (limit && statp->f_blocks > limit) { statp->f_blocks = limit; - statp->f_bfree = (statp->f_blocks > dp->d_bcount) ? - (statp->f_blocks - dp->d_bcount) : 0; + statp->f_bfree = + (statp->f_blocks > be64_to_cpu(dp->d_bcount)) ? + (statp->f_blocks - be64_to_cpu(dp->d_bcount)) : 0; } - limit = dp->d_ino_softlimit ? dp->d_ino_softlimit : dp->d_ino_hardlimit; + + limit = dp->d_ino_softlimit ? + be64_to_cpu(dp->d_ino_softlimit) : + be64_to_cpu(dp->d_ino_hardlimit); if (limit && statp->f_files > limit) { statp->f_files = limit; - statp->f_ffree = (statp->f_files > dp->d_icount) ? - (statp->f_ffree - dp->d_icount) : 0; + statp->f_ffree = + (statp->f_files > be64_to_cpu(dp->d_icount)) ? + (statp->f_ffree - be64_to_cpu(dp->d_icount)) : 0; } xfs_qm_dqput(dqp); From owner-xfs@oss.sgi.com Mon Jul 10 13:01:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 13:01:32 -0700 (PDT) Received: from postfix2-c.free.fr (postfix2-c.free.fr [213.228.0.80]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AK1GDW018729 for ; Mon, 10 Jul 2006 13:01:19 -0700 Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by postfix2-c.free.fr (Postfix) with ESMTP id 8E78F47BBEB4 for ; Mon, 10 Jul 2006 21:00:59 +0200 (CEST) Received: from inara.maison.net (lns-bzn-36-82-251-4-50.adsl.proxad.net [82.251.4.50]) by smtp2-g19.free.fr (Postfix) with ESMTP id A649175CF9 for ; Mon, 10 Jul 2006 22:00:55 +0200 (CEST) Received: by inara.maison.net (Postfix, from userid 32266) id 063225A69A; Mon, 10 Jul 2006 22:00:54 +0200 (CEST) Date: Mon, 10 Jul 2006 22:00:54 +0200 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: determining sunit Message-ID: <20060710200054.GC11802@inara.maison.net> Mail-Followup-To: xfs@oss.sgi.com 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 8190 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs Content-Length: 354 Lines: 13 * Joshua Baker-Lepain (jlb17@duke.edu) [20060704 11:29]: > -d sunit=64,swidth=448 -d su=32,sw=7 is more readable to me (2¢). Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Mon Jul 10 13:36:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 13:36:42 -0700 (PDT) Received: from smtp.funpic.de (smtp.funpic.de [213.202.225.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6AKaIDW024303 for ; Mon, 10 Jul 2006 13:36:23 -0700 Date: Mon, 10 Jul 2006 20:34:36 +0200 From: "A. Liemen" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Change internal to external log/journal Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20060710183437.BD681A0090E@smtp.funpic.de> X-archive-position: 8191 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: maillist@liemen.net Precedence: bulk X-list: xfs Content-Length: 150 Lines: 8 Hi, is there a way to change an internal log/journal to an external one on an existing volume? (without loosing data / runnning mkfs) Thanks Alex From owner-xfs@oss.sgi.com Mon Jul 10 17:19:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 17:20:08 -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 k6B0JHDW001468 for ; Mon, 10 Jul 2006 17:19:29 -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 KAA25000; Tue, 11 Jul 2006 10:18:30 +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 k6B0IOgw1703617; Tue, 11 Jul 2006 10:18:25 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6B0IIMY1702666; Tue, 11 Jul 2006 10:18:18 +1000 (EST) Date: Tue, 11 Jul 2006 10:18:17 +1000 From: Nathan Scott To: Stephane Doyon Cc: Christoph Hellwig , Suzuki , linux-fsdevel@vger.kernel.org, "linux-aio kvack.org" , lkml , suparna , akpm@osdl.org, xfs@oss.sgi.com Subject: Re: [RFC] Badness in __mutex_unlock_slowpath with XFS stress tests Message-ID: <20060711101817.B1702118@wobbly.melbourne.sgi.com> References: <440FDF3E.8060400@in.ibm.com> <20060309120306.GA26682@infradead.org> <20060309223042.GC1135@frodo> <20060309224219.GA6709@infradead.org> <20060309231422.GD1135@frodo> <20060310005020.GF1135@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sdoyon@max-t.com on Mon, Jul 10, 2006 at 12:46:23PM -0400 X-archive-position: 8192 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: 2391 Lines: 58 On Mon, Jul 10, 2006 at 12:46:23PM -0400, Stephane Doyon wrote: > Hi, Hi Stephane, > A few months back, a fix was introduced for a mutex double unlock warning > related to direct I/O in XFS. I believe that fix has a lock ordering > problem that can cause a deadlock. > > The problem was that __blockdev_direct_IO() would unlock the i_mutex in > the READ and DIO_OWN_LOCKING case, and the mutex would be unlocked again > in xfs_read() soon after returning from __generic_file_aio_read(). Because > there are lots of execution paths down from __generic_file_aio_read() that > do not consistently release the i_mutex, the safest fix was deemed to be > to reacquire the i_mutex before returning from __blockdev_direct_IO(). At > this point however, the reader is holding an xfs ilock, and AFAICT the > i_mutex is usually taken BEFORE the xfs ilock. That is correct, yes. Hmm. Subtle. Painful. Thanks for the detailed report and your analysis. > We are seeing a deadlock between a process writing and another process > reading the same file, when the reader is using direct I/O. (The writer Is that a direct writer or a buffered writer? > must apparently be growing the file, using either direct or buffered > I/O.) Something like this, on XFS: > (dd if=/dev/zero of=f bs=128K count=5000 & ) ; sleep 1 ; dd of=/dev/null > if=f iflag=direct bs=128K count=5000 > > Seen on kernels 2.6.16 and 2.6.17. > > The deadlock scenario appears to be this: > -The reader goes into xfs_read(), takes the i_mutex and then an xfs_ilock > XFS_IOLOCK_SHARED, then calls down to __generic_file_aio_read() which > eventually goes down to __blockdev_direct_IO(). In there it drops the > i_mutex. > -The writer goes into xfs_write() and obtains the i_mutex. It then tries > to get an xfs_ilock XFS_ILOCK_EXCL and must wait on it since it's held by > the reader. > -The reader, still in __blockdev_direct_IO(), executes directio_worker() > and then tries to reacquire the i_mutex, and must wait on it because the > writer has it. > > And so we have a deadlock. *nod*. This will require some thought, I'm not sure I like the sound of your suggested workaround there a whole lot, unfortunately, but maybe it is all we can do at this stage. Let me ponder further and get back to you (but if you want to prototype your fix further, that'd be most welcome, of course). cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 10 17:24:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 17:25:04 -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 k6B0ORDW002386 for ; Mon, 10 Jul 2006 17:24: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 KAA25192; Tue, 11 Jul 2006 10:23:48 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k6B0Nigw1701817; Tue, 11 Jul 2006 10:23:45 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6B0Ng5e1701986; Tue, 11 Jul 2006 10:23:42 +1000 (EST) Date: Tue, 11 Jul 2006 10:23:42 +1000 From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] xfs: fix brown paperbag quota-aware stafs bug Message-ID: <20060711102341.C1702118@wobbly.melbourne.sgi.com> References: <20060710165539.GA26673@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060710165539.GA26673@lst.de>; from hch@lst.de on Mon, Jul 10, 2006 at 06:55:39PM +0200 X-archive-position: 8193 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: 443 Lines: 16 On Mon, Jul 10, 2006 at 06:55:39PM +0200, Christoph Hellwig wrote: > All xfs_disk_dquot_t values are (as the name says) disk endian. Before > putting them into struct statfs they should be endian-swapped. Thanks Christoph (ugh, porting bug, looked such an "obvious" merge at the time). :| > (I wish someone at SGI would run sparse once in a while..) Indeed, my bad. I'm much more motivated to do so now, thanks. :) cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 10 19:02:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 19:02: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 k6B21oDW017937 for ; Mon, 10 Jul 2006 19:02: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 MAA29088; Tue, 11 Jul 2006 12:01:09 +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 k6B215gw1704905; Tue, 11 Jul 2006 12:01:05 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6B210xs1705475; Tue, 11 Jul 2006 12:01:00 +1000 (EST) Date: Tue, 11 Jul 2006 12:00:59 +1000 From: Nathan Scott To: Christoph Hellwig Cc: Alexey Dobriyan , Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060711120059.D1702118@wobbly.melbourne.sgi.com> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709125643.GA28769@infradead.org> <20060710081711.A1670244@wobbly.melbourne.sgi.com> <20060710165100.GA11567@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060710165100.GA11567@infradead.org>; from hch@infradead.org on Mon, Jul 10, 2006 at 05:51:00PM +0100 X-archive-position: 8195 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: 3849 Lines: 83 Hi Christoph, On Mon, Jul 10, 2006 at 05:51:00PM +0100, Christoph Hellwig wrote: > Sorry about the odd reference. No worries. > changes seem to not come with TAKE messages sometimes. So I have to Yeah, sometimes we have new folks coming on board learning the ropes, and sometimes email lists gets b0rked. We also have somewhat oddball processes here so stuff gets dropped; its the nature of the beast and unavoidable at times, unfortunately. > look at the changes between two linus releases to see changes. OK. I've still had zero expressions of interest from anyone else WRT sending out XFS git merge mail to wider audiences... *shrug*. And I know you're plenty handy with git, so you don't need it yourself. :) > Anyway, the odd changes from 2.6.17 to 2.6.18-rc are: > > - replacing PFLAGS_* with even more obsfucation Bah! They certainly look cleaner to me - less case SHOUTING, and this sort of thing is done in plenty of other places (e.g. see bio_flagged, bio_sync, etc...) > - the big renaming of the vnode/vfs thingies. I take this as an official > go-ahead that this cruft isn't for irix-compatibility anymore and remove > it. I have a nice patch pending that reduces xfs size big time with > this (unfortunatly needs a nasty rebase now) Heh, don't take it that way... take it more as "behaviours are useful within XFS, despite you not wanting them to be". ;) There is no way I can see those ever being removed, they are (for the Nth time) genuinely useful now and I see them becoming more and more useful. A more pragmatic approach for you might be to say: "I don't see how they can be even more useful, Nathan, you dill, and I'm itching to remove them!", at which point I'll point you to Dave, and say "Discuss amongst yourselves, but Dave is making wide use of them in his current project and says they're a perfect fit there too". So, stop hassling me about it and please don't send patches that have already been NACKd - I've my own work to get done too. Thanks. > - the VN_TRUNC looks interesting. I wish we had a public discussion about > this and could see whether or not to handle it at the VFS level Sure, please discuss. I was narrowing a window on a long standing XFS-specific issue there (the good old truncate vs. delalloc NULL files problem). If this can be done better in a generic way, I'm all for it. Personally, I thought it was a good use of the generic flush() infrastructure that we weren't using ... but I guess theres some scope for this to be more generic (generic inode flag? you sure? hmm, I dunno - would others use this?). > - adding a new inherit_nodfrg flag that's not actually used anywhere C'mon, you know better. Try inode allocation, in xfs_inode.c. > - addding a VFS_UMOUNT flag that isn't actually used anywhere and shouldn't > exist with Linux's unmount handling Hmm, yes, I really may have accidentally merged something there. That is used during xfssyncd shutdown on 2.4, do you recall why we don't need it on 2.6? (refresh my memory? I'm gettin' old). I'm half-tempted to fire back my own list - recent regressions introduced into XFS by, er, Christoph and (more importantly) fixed by myself and others @sgi... but thats not constructive (although our atime and dir2-corruption nightmares continue :). I'd _really, really_ like to see people so keen on doing cleanup work also participating in the bug fixing work (and regression fixing from their own handiwork, sometimes!) - I think that would go a long way to really improving XFS, rather than just prettying the code up at the edges. As always, I appreciate your input though Christoph (at least you look at the code, unlike the wc(1) jokers, and there's plenty of good with the bad). Plus, you buy me beers sometimes, so I really can't complain - thanks mate. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 10 18:58:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 18:58:23 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6B1voDW016779 for ; Mon, 10 Jul 2006 18:58:01 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k6B29XDu39806940 for ; Mon, 10 Jul 2006 19:09:33 -0700 (PDT) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k6B4McEc019383 for ; Mon, 10 Jul 2006 21:22:38 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k6B1ui8s20936663 for ; Mon, 10 Jul 2006 18:56:44 -0700 (PDT) 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 k6B4LtCv019367 for ; Mon, 10 Jul 2006 21:21:55 -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 k6B1txnB45510031; Mon, 10 Jul 2006 18:55:59 -0700 (PDT) Message-ID: <44B3052E.1050208@sgi.com> Date: Mon, 10 Jul 2006 20:55:58 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: "A. Liemen" CC: xfs@oss.sgi.com Subject: Re: Change internal to external log/journal References: <20060710183437.BD681A0090E@smtp.funpic.de> In-Reply-To: <20060710183437.BD681A0090E@smtp.funpic.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8194 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: 370 Lines: 17 A. Liemen wrote: > Hi, > > is there a way to change an internal log/journal to an external one on > an existing volume? (without loosing data / runnning mkfs) > > Thanks > Alex > No supported option, but if you search through the list archives you'll find -unsupported- instructions for doing it with xfs_db. If it breaks, you get both pieces, etc etc :) -Eric From owner-xfs@oss.sgi.com Mon Jul 10 23:35:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 23:35:24 -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 k6B6YmDW006392 for ; Mon, 10 Jul 2006 23:35:00 -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 QAA09110; Tue, 11 Jul 2006 16:34:13 +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 k6B6YAgw1712671; Tue, 11 Jul 2006 16:34:11 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6B6Y8p01709632; Tue, 11 Jul 2006 16:34:08 +1000 (EST) Date: Tue, 11 Jul 2006 16:34:08 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060711163408.B1710004@wobbly.melbourne.sgi.com> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> <20060710014001.GA15511@crodrigues.org> <20060710114919.C1675766@wobbly.melbourne.sgi.com> <20060710015159.GA16864@crodrigues.org> <20060710122119.D1675766@wobbly.melbourne.sgi.com> <20060711063248.GB63611@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060711063248.GB63611@crodrigues.org>; from rodrigc@crodrigues.org on Tue, Jul 11, 2006 at 02:32:48AM -0400 X-archive-position: 8197 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: 397 Lines: 20 On Tue, Jul 11, 2006 at 02:32:48AM -0400, Craig Rodrigues wrote: > On Mon, Jul 10, 2006 at 12:21:19PM +1000, Nathan Scott wrote: > > > % id -u root > > > 0 > > > > Oh. Ah, wait, what about group (-g)? (and exit code). > > % id -g root > 0 > % echo $? > 0 Hmm. So remind me again why we made the change to not install our make targets as root.root (user/group) anymore? thanks. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 10 23:33:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 23:33:37 -0700 (PDT) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [216.148.227.155] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6B6X8DW006126 for ; Mon, 10 Jul 2006 23:33:16 -0700 Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (rwcrmhc15) with ESMTP id <20060711063246m15004f9kje>; Tue, 11 Jul 2006 06:32:46 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k6B6WnVT063635; Tue, 11 Jul 2006 02:32:49 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k6B6Wm0Q063634; Tue, 11 Jul 2006 02:32:48 -0400 (EDT) (envelope-from rodrigc) Date: Tue, 11 Jul 2006 02:32:48 -0400 From: Craig Rodrigues To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060711063248.GB63611@crodrigues.org> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> <20060710014001.GA15511@crodrigues.org> <20060710114919.C1675766@wobbly.melbourne.sgi.com> <20060710015159.GA16864@crodrigues.org> <20060710122119.D1675766@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060710122119.D1675766@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8196 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 227 Lines: 15 On Mon, Jul 10, 2006 at 12:21:19PM +1000, Nathan Scott wrote: > > % id -u root > > 0 > > Oh. Ah, wait, what about group (-g)? (and exit code). % id -g root 0 % echo $? 0 -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Mon Jul 10 23:55:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Jul 2006 23:55:59 -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 k6B6tIDW011462 for ; Mon, 10 Jul 2006 23:55:29 -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 QAA09829; Tue, 11 Jul 2006 16:54:42 +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 k6B6segw1710258; Tue, 11 Jul 2006 16:54:41 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6B6sc1r1708260; Tue, 11 Jul 2006 16:54:38 +1000 (EST) Date: Tue, 11 Jul 2006 16:54:38 +1000 From: Nathan Scott To: Craig Rodrigues Cc: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060711165438.C1710004@wobbly.melbourne.sgi.com> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> <20060710014001.GA15511@crodrigues.org> <20060710114919.C1675766@wobbly.melbourne.sgi.com> <20060710015159.GA16864@crodrigues.org> <20060710122119.D1675766@wobbly.melbourne.sgi.com> <20060711063248.GB63611@crodrigues.org> <20060711163408.B1710004@wobbly.melbourne.sgi.com> <20060711064808.GA63743@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060711064808.GA63743@crodrigues.org>; from rodrigc@crodrigues.org on Tue, Jul 11, 2006 at 02:48:08AM -0400 X-archive-position: 8198 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: 666 Lines: 19 On Tue, Jul 11, 2006 at 02:48:08AM -0400, Craig Rodrigues wrote: > On Tue, Jul 11, 2006 at 04:34:08PM +1000, Nathan Scott wrote: > > Hmm. So remind me again why we made the change to not install > > our make targets as root.root (user/group) anymore? > > Because there is no "root" group in FreeBSD. Only "wheel". > You made the relevant change in version 1.3 of package_globals.m4 Oh, I see my mistake - "id -g root" is not looking for group root, its still refering to user root (the group of user root). Hmm, anyone know if theres a general Unix'y way to easily test if a given group _name_ is valid (i.e. group "root" exists or not?)? cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 11 00:01:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Jul 2006 00:01:50 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6B71TDW014831 for ; Tue, 11 Jul 2006 00:01:29 -0700 Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (rwcrmhc13) with ESMTP id <20060711064806m1300s92v0e>; Tue, 11 Jul 2006 06:48:06 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k6B6m8u0063759; Tue, 11 Jul 2006 02:48:08 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k6B6m8dS063758; Tue, 11 Jul 2006 02:48:08 -0400 (EDT) (envelope-from rodrigc) Date: Tue, 11 Jul 2006 02:48:08 -0400 From: Craig Rodrigues To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: xfsprogs 2.8.4 installs Polish locale message files? Message-ID: <20060711064808.GA63743@crodrigues.org> References: <20060707172251.GA65338@crodrigues.org> <20060709120837.B1648127@wobbly.melbourne.sgi.com> <20060710014001.GA15511@crodrigues.org> <20060710114919.C1675766@wobbly.melbourne.sgi.com> <20060710015159.GA16864@crodrigues.org> <20060710122119.D1675766@wobbly.melbourne.sgi.com> <20060711063248.GB63611@crodrigues.org> <20060711163408.B1710004@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060711163408.B1710004@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8199 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: xfs Content-Length: 361 Lines: 11 On Tue, Jul 11, 2006 at 04:34:08PM +1000, Nathan Scott wrote: > Hmm. So remind me again why we made the change to not install > our make targets as root.root (user/group) anymore? Because there is no "root" group in FreeBSD. Only "wheel". You made the relevant change in version 1.3 of package_globals.m4 -- Craig Rodrigues rodrigc@crodrigues.org From owner-xfs@oss.sgi.com Tue Jul 11 07:48:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Jul 2006 07:49:09 -0700 (PDT) Received: from mail.max-t.com (h216-18-124-229.gtcust.grouptelecom.net [216.18.124.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6BEmaDW017794 for ; Tue, 11 Jul 2006 07:48:38 -0700 Received: from madrid.max-t.internal ([192.168.1.189] ident=[U2FsdGVkX1+93dJHIPEniHvj8LRDZn96WmBfX5X0Xys=]) by mail.max-t.com with esmtp (Exim 4.43) id 1G0IVI-0001w8-PJ; Tue, 11 Jul 2006 09:42:21 -0400 Date: Tue, 11 Jul 2006 09:40:49 -0400 (EDT) From: Stephane Doyon X-X-Sender: sdoyon@madrid.max-t.internal To: Nathan Scott cc: Christoph Hellwig , Suzuki , linux-fsdevel@vger.kernel.org, "linux-aio kvack.org" , lkml , suparna , akpm@osdl.org, xfs@oss.sgi.com In-Reply-To: <20060711101817.B1702118@wobbly.melbourne.sgi.com> Message-ID: References: <440FDF3E.8060400@in.ibm.com> <20060309120306.GA26682@infradead.org> <20060309223042.GC1135@frodo> <20060309224219.GA6709@infradead.org> <20060309231422.GD1135@frodo> <20060310005020.GF1135@frodo> <20060711101817.B1702118@wobbly.melbourne.sgi.com> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.1.189 X-SA-Exim-Mail-From: sdoyon@max-t.com Subject: Re: [RFC] Badness in __mutex_unlock_slowpath with XFS stress tests Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Version: 4.1 (built Thu, 08 Sep 2005 14:17:48 -0500) X-SA-Exim-Scanned: Yes (on mail.max-t.com) X-archive-position: 8202 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sdoyon@max-t.com Precedence: bulk X-list: xfs Content-Length: 3879 Lines: 102 On Tue, 11 Jul 2006, Nathan Scott wrote: > On Mon, Jul 10, 2006 at 12:46:23PM -0400, Stephane Doyon wrote: >> Hi, > > Hi Stephane, > >> A few months back, a fix was introduced for a mutex double unlock warning >> related to direct I/O in XFS. I believe that fix has a lock ordering >> problem that can cause a deadlock. >> >> The problem was that __blockdev_direct_IO() would unlock the i_mutex in >> the READ and DIO_OWN_LOCKING case, and the mutex would be unlocked again >> in xfs_read() soon after returning from __generic_file_aio_read(). Because >> there are lots of execution paths down from __generic_file_aio_read() that >> do not consistently release the i_mutex, the safest fix was deemed to be >> to reacquire the i_mutex before returning from __blockdev_direct_IO(). At >> this point however, the reader is holding an xfs ilock, and AFAICT the >> i_mutex is usually taken BEFORE the xfs ilock. > > That is correct, yes. Hmm. Subtle. Painful. Thanks for the detailed > report and your analysis. > >> We are seeing a deadlock between a process writing and another process >> reading the same file, when the reader is using direct I/O. (The writer > > Is that a direct writer or a buffered writer? Whichever, both cases trigger the deadlock. >> must apparently be growing the file, using either direct or buffered >> I/O.) Something like this, on XFS: >> (dd if=/dev/zero of=f bs=128K count=5000 & ) ; sleep 1 ; dd of=/dev/null >> if=f iflag=direct bs=128K count=5000 >> >> Seen on kernels 2.6.16 and 2.6.17. >> >> The deadlock scenario appears to be this: >> -The reader goes into xfs_read(), takes the i_mutex and then an xfs_ilock >> XFS_IOLOCK_SHARED, then calls down to __generic_file_aio_read() which >> eventually goes down to __blockdev_direct_IO(). In there it drops the >> i_mutex. >> -The writer goes into xfs_write() and obtains the i_mutex. It then tries >> to get an xfs_ilock XFS_ILOCK_EXCL and must wait on it since it's held by >> the reader. >> -The reader, still in __blockdev_direct_IO(), executes directio_worker() >> and then tries to reacquire the i_mutex, and must wait on it because the >> writer has it. >> >> And so we have a deadlock. > > *nod*. This will require some thought, I'm not sure I like the sound of > your suggested workaround there a whole lot, unfortunately, but maybe it > is all we can do at this stage. Let me ponder further and get back to you Thank you. > (but if you want to prototype your fix further, that'd be most welcome, of > course). Sure, well it's not very subtle. The below patch is what I'm using for now. I haven't seen problems with it yet but it hasn't been seriously tested. I'm assuming that it's OK to keep holding the i_mutex during the call to direct_io_worker(), because in the DIO_LOCKING case, direct_io_worker() is called with the i_mutex held, and XFS touches i_mutex only in xfs_read() and xfs_write(), so opefully nothing will conflict. Signed-off-by: Stephane Doyon --- linux/fs/direct-io.c.orig 2006-07-11 09:23:20.000000000 -0400 +++ linux/fs/direct-io.c 2006-07-11 09:27:54.000000000 -0400 @@ -1191,7 +1191,6 @@ __blockdev_direct_IO(int rw, struct kioc loff_t end = offset; struct dio *dio; int release_i_mutex = 0; - int acquire_i_mutex = 0; if (rw & WRITE) current->flags |= PF_SYNCWRITE; @@ -1254,11 +1253,6 @@ __blockdev_direct_IO(int rw, struct kioc goto out; } - if (dio_lock_type == DIO_OWN_LOCKING) { - mutex_unlock(&inode->i_mutex); - acquire_i_mutex = 1; - } - } if (dio_lock_type == DIO_LOCKING) down_read(&inode->i_alloc_sem); @@ -1282,8 +1276,6 @@ __blockdev_direct_IO(int rw, struct kioc out: if (release_i_mutex) mutex_unlock(&inode->i_mutex); - else if (acquire_i_mutex) - mutex_lock(&inode->i_mutex); if (rw & WRITE) current->flags &= ~PF_SYNCWRITE; return retval; From owner-xfs@oss.sgi.com Tue Jul 11 09:04:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Jul 2006 09:04:30 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6BG4ADW001041 for ; Tue, 11 Jul 2006 09:04:12 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 9D31461012C6; Tue, 11 Jul 2006 12:03:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 99FCA16195E6B; Tue, 11 Jul 2006 12:03:46 -0400 (EDT) Date: Tue, 11 Jul 2006 12:03:46 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: linux-kernel@vger.kernel.org cc: linux-raid@vger.kernel.org, Neil Brown , xfs@oss.sgi.com Subject: Raid5 Reshape Status + xfs_growfs = Success! (2.6.17.3) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8203 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1729 Lines: 52 Neil, It worked, echo'ing the 600 > to the stripe width in /sys, however, how come /dev/md3 says it is 0 MB when I type fdisk -l? Is this normal? Disk /dev/md0 doesn't contain a valid partition table Disk /dev/md3: 0 MB, 0 bytes 2 heads, 4 sectors/track, 0 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/md3 doesn't contain a valid partition table Disk /dev/md2: 71.9 GB, 71954661376 bytes 2 heads, 4 sectors/track, 17567056 cylinders Units = cylinders of 8 * 512 = 4096 bytes Furthermore, the xfs_growfs worked beautifully! p34:~# df -h /dev/md3 2.2T 487G 1.8T 22% /raid5 p34:~# xfs_growfs /raid5 meta-data=/dev/md3 isize=256 agcount=32, agsize=18314368 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=586059776, imaxpct=25 = sunit=128 swidth=768 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks realtime =none extsz=3145728 blocks=0, rtextents=0 data blocks changed from 586059776 to 683740288 p34:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/md3 2.6T 487G 2.1T 19% /raid5 p34:~# umount /raid5 p34:~# mount /raid5 p34:~# dmesg | tail -5 [4354159.367000] disk 7, o:1, dev:sdc1 [4360850.548000] XFS mounting filesystem md3 [4360850.803000] Ending clean XFS mount for filesystem: md3 [4360868.121000] XFS mounting filesystem md3 [4360868.189000] Ending clean XFS mount for filesystem: md3 Very nice stuff. Thanks Neil & XFS team for the information and help! Justin. From owner-xfs@oss.sgi.com Tue Jul 11 17:50:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Jul 2006 17:50:57 -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 k6C0o8DW005674 for ; Tue, 11 Jul 2006 17:50:22 -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 KAA21988; Wed, 12 Jul 2006 10:49: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 k6C0nOgw1731459; Wed, 12 Jul 2006 10:49:24 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6C0nLW91733167; Wed, 12 Jul 2006 10:49:21 +1000 (EST) Date: Wed, 12 Jul 2006 10:49:21 +1000 From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH 4/7] xfs: add xfs_btree_check_lptr_disk Message-ID: <20060712104921.A1732817@wobbly.melbourne.sgi.com> References: <20060710170420.GD26786@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060710170420.GD26786@lst.de>; from hch@lst.de on Mon, Jul 10, 2006 at 07:04:20PM +0200 X-archive-position: 8205 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: 1124 Lines: 32 Hi Christoph, On Mon, Jul 10, 2006 at 07:04:20PM +0200, Christoph Hellwig wrote: > --- xfs-2.6.x.orig/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:28:16.000000000 +0200 > +++ xfs-2.6.x/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:37:01.000000000 +0200 > @@ -382,7 +382,7 @@ > pp = XFS_BMAP_PTR_IADDR(block, 1, cur); > #ifdef DEBUG > for (i = ptr; i < numrecs; i++) { > - if ((error = xfs_btree_check_lptr(cur, INT_GET(pp[i], ARCH_CONVERT), level))) { > + if ((error = xfs_btree_check_lptr_disk(cur, pp, level))) { This incorrectly changes the debug-only btree checking here, no? > --- xfs-2.6.x.orig/fs/xfs/xfs_btree.h 2006-07-09 19:34:52.000000000 +0200 > +++ xfs-2.6.x/fs/xfs/xfs_btree.h 2006-07-09 19:37:01.000000000 +0200 > @@ -243,6 +243,9 @@ > xfs_dfsbno_t ptr, /* btree block disk address */ > int level); /* btree block level */ > > +#define xfs_btree_check_lptr_disk(cur, ptr, level) \ > + xfs_btree_check_lptr(cur, INT_GET(ptr, ARCH_CONVERT), level) > + Shouldn't this be using be64_to_cpu() instead of the old school INT_GET? Maybe static inline here for type checking? *shrug*. thanks. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 11 18:25:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Jul 2006 18:25:29 -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 k6C1OqDW012819 for ; Tue, 11 Jul 2006 18:25: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 LAA23404; Wed, 12 Jul 2006 11:24: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 k6C1O2gw1733923; Wed, 12 Jul 2006 11:24:03 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6C1O0R31733154; Wed, 12 Jul 2006 11:24:00 +1000 (EST) Date: Wed, 12 Jul 2006 11:24:00 +1000 From: Nathan Scott To: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 4/7] xfs: add xfs_btree_check_lptr_disk Message-ID: <20060712112400.A1734462@wobbly.melbourne.sgi.com> References: <20060710170420.GD26786@lst.de> <20060712104921.A1732817@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060712104921.A1732817@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Jul 12, 2006 at 10:49:21AM +1000 X-archive-position: 8206 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: 749 Lines: 24 On Wed, Jul 12, 2006 at 10:49:21AM +1000, Nathan Scott wrote: > > --- xfs-2.6.x.orig/fs/xfs/xfs_btree.h 2006-07-09 19:34:52.000000000 +0200 > > +++ xfs-2.6.x/fs/xfs/xfs_btree.h 2006-07-09 19:37:01.000000000 +0200 > > @@ -243,6 +243,9 @@ > > xfs_dfsbno_t ptr, /* btree block disk address */ > > int level); /* btree block level */ > > > > +#define xfs_btree_check_lptr_disk(cur, ptr, level) \ > > + xfs_btree_check_lptr(cur, INT_GET(ptr, ARCH_CONVERT), level) > > + > > Shouldn't this be using be64_to_cpu() instead of the old school Ah, you do that in a later patch in the series. > INT_GET? Maybe static inline here for type checking? *shrug*. Just this question remains - any preference on inline or not here? cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jul 12 08:44:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Jul 2006 08:44:55 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6CFiYDW029787 for ; Wed, 12 Jul 2006 08:44:35 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6CFiERT021850 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jul 2006 17:44:14 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6CFiEud021848; Wed, 12 Jul 2006 17:44:14 +0200 Date: Wed, 12 Jul 2006 17:44:14 +0200 From: Christoph Hellwig To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: [PATCH 4/7] xfs: add xfs_btree_check_lptr_disk Message-ID: <20060712154414.GB21752@lst.de> References: <20060710170420.GD26786@lst.de> <20060712104921.A1732817@wobbly.melbourne.sgi.com> <20060712112400.A1734462@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060712112400.A1734462@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8210 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 330 Lines: 8 > > INT_GET? Maybe static inline here for type checking? *shrug*. > > Just this question remains - any preference on inline or not here? I'll try to make it an inline when respinning the patch. It's been a long time since I did the initial version of this patch and I can't remember if I had any reason to go for the macro. From owner-xfs@oss.sgi.com Wed Jul 12 08:43:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Jul 2006 08:44:04 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6CFhgDW029610 for ; Wed, 12 Jul 2006 08:43:43 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6CFhHRT021827 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jul 2006 17:43:17 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6CFhHKs021825; Wed, 12 Jul 2006 17:43:17 +0200 Date: Wed, 12 Jul 2006 17:43:17 +0200 From: Christoph Hellwig To: Nathan Scott Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH 4/7] xfs: add xfs_btree_check_lptr_disk Message-ID: <20060712154317.GA21752@lst.de> References: <20060710170420.GD26786@lst.de> <20060712104921.A1732817@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060712104921.A1732817@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8209 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 1638 Lines: 37 On Wed, Jul 12, 2006 at 10:49:21AM +1000, Nathan Scott wrote: > Hi Christoph, > > On Mon, Jul 10, 2006 at 07:04:20PM +0200, Christoph Hellwig wrote: > > --- xfs-2.6.x.orig/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:28:16.000000000 +0200 > > +++ xfs-2.6.x/fs/xfs/xfs_bmap_btree.c 2006-07-09 19:37:01.000000000 +0200 > > @@ -382,7 +382,7 @@ > > pp = XFS_BMAP_PTR_IADDR(block, 1, cur); > > #ifdef DEBUG > > for (i = ptr; i < numrecs; i++) { > > - if ((error = xfs_btree_check_lptr(cur, INT_GET(pp[i], ARCH_CONVERT), level))) { > > + if ((error = xfs_btree_check_lptr_disk(cur, pp, level))) { > > This incorrectly changes the debug-only btree checking here, no? Right, it should be pp[i], I'll resping the patch. I wonder why I didn't get any warning from the compiler, though as I'm always building with DEBUG enabled. > > --- xfs-2.6.x.orig/fs/xfs/xfs_btree.h 2006-07-09 19:34:52.000000000 +0200 > > +++ xfs-2.6.x/fs/xfs/xfs_btree.h 2006-07-09 19:37:01.000000000 +0200 > > @@ -243,6 +243,9 @@ > > xfs_dfsbno_t ptr, /* btree block disk address */ > > int level); /* btree block level */ > > > > +#define xfs_btree_check_lptr_disk(cur, ptr, level) \ > > + xfs_btree_check_lptr(cur, INT_GET(ptr, ARCH_CONVERT), level) > > + > > Shouldn't this be using be64_to_cpu() instead of the old school > INT_GET? Maybe static inline here for type checking? *shrug*. It's converted a patch or two later in the series. This patch only introduced the helper, the switch to be64_to_cpu() happens when the variables it's operating on are switched to the __be64 so we don't get sparse warnings and can verify the annotations better. From owner-xfs@oss.sgi.com Wed Jul 12 08:59:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Jul 2006 09:00:04 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6CFxmDW000536 for ; Wed, 12 Jul 2006 08:59:49 -0700 Received: by nz-out-0102.google.com with SMTP id v1so142899nzb for ; Wed, 12 Jul 2006 08:59:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=SCoZD2TU7lcdFWquQYR7+1chWPMSb2k47/NUkNvFAbb1VSJr3CuLVc72phUwNFRs6RkfBTD3dlRJ0xloN+OOatDMr/QiumMDPxpmmp9PwkEz7bTGHFxoed/0Vf5/hmhpiSeXeRyHHs8I82rCZuLoi0O610Fc6B8w4laU0JWPRcw= Received: by 10.36.47.14 with SMTP id u14mr933019nzu; Wed, 12 Jul 2006 07:22:24 -0700 (PDT) Received: from ?192.168.10.3? ( [221.219.119.87]) by mx.gmail.com with ESMTP id 17sm508395nzo.2006.07.12.07.22.03; Wed, 12 Jul 2006 07:22:13 -0700 (PDT) Message-ID: <44B50591.4060006@gmail.com> Date: Wed, 12 Jul 2006 22:22:09 +0800 From: "Michael Li (gmail)" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Delivered state of DMAPI Event Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8211 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 558 Lines: 18 Hi, all, As I know, DMAPI event can be in 2 states: 1) enqueued, undelivered 2) delivered and awaiting a response from the DM application. The 2nd state also know as outstanding state for synchronous event message. I'd like to know the exact meaning of "delivered", Does "delivered" means the DM application had call dm_get_event() on the event? Can an event message automatically change state from 1 to 2 when it is enqueued? Is there a list of the events that will always change state to delievered state after it is enqueued? Thanks a lot, Mikore From owner-xfs@oss.sgi.com Wed Jul 12 09:44:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Jul 2006 09:45:13 -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 k6CGikDW008001 for ; Wed, 12 Jul 2006 09:44:46 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G0gm7-0000Hz-Cq; Wed, 12 Jul 2006 16:37:19 +0100 Date: Wed, 12 Jul 2006 16:37:19 +0100 From: Christoph Hellwig To: Nathan Scott Cc: Christoph Hellwig , Alexey Dobriyan , Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060712153719.GA620@infradead.org> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709125643.GA28769@infradead.org> <20060710081711.A1670244@wobbly.melbourne.sgi.com> <20060710165100.GA11567@infradead.org> <20060711120059.D1702118@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060711120059.D1702118@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8212 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 3623 Lines: 70 > > changes seem to not come with TAKE messages sometimes. So I have to > > Yeah, sometimes we have new folks coming on board learning the ropes, > and sometimes email lists gets b0rked. We also have somewhat oddball > processes here so stuff gets dropped; its the nature of the beast and > unavoidable at times, unfortunately. Sure, this wasn't a complaint by itself. I happened to me more than often enough. It's just an explanation why it's hard to timely review xfs changes. What would be even more helpfull is of course if changes get sent to the xfs list for review before committing instead of just to an sgi-internal one.. > > - the big renaming of the vnode/vfs thingies. I take this as an official > > go-ahead that this cruft isn't for irix-compatibility anymore and remove > > it. I have a nice patch pending that reduces xfs size big time with > > this (unfortunatly needs a nasty rebase now) > > Heh, don't take it that way... take it more as "behaviours are useful within > XFS, despite you not wanting them to be". ;) There is no way I can see those > ever being removed, they are (for the Nth time) genuinely useful now and I see > them becoming more and more useful. A more pragmatic approach for you might > be to say: "I don't see how they can be even more useful, Nathan, you dill, > and I'm itching to remove them!", at which point I'll point you to Dave, and > say "Discuss amongst yourselves, but Dave is making wide use of them in his > current project and says they're a perfect fit there too". So, stop hassling > me about it and please don't send patches that have already been NACKd - I've > my own work to get done too. Thanks. Maybe Dave could explain what he's doing? (Hi Dave!). Generally these kinds of duplication of stackable filesystem infrastructure in a single filesystem is pretty much the last thing we want. If you want to keep it you need to bring up a very very good reason. This is comparable to the long as nasty reiser4 discussion. > issue there (the good old truncate vs. delalloc NULL files problem). If this > can be done better in a generic way, I'm all for it. Personally, I thought it > was a good use of the generic flush() infrastructure that we weren't using ... > but I guess theres some scope for this to be more generic (generic inode flag? > you sure? hmm, I dunno - would others use this?). Yes, a generic inode flag would be useful. Especially as killing this odd vmodified flag has been on my todo list for a long time. No need to have another flag word in the vnode when there's already one in the linux inode and one in xfs_inode. > > > - adding a new inherit_nodfrg flag that's not actually used anywhere > > C'mon, you know better. Try inode allocation, in xfs_inode.c. Look again. It's not used anywhere in fs/xfs/ in Linus' tree. > > - addding a VFS_UMOUNT flag that isn't actually used anywhere and shouldn't > > exist with Linux's unmount handling > > Hmm, yes, I really may have accidentally merged something there. That is used > during xfssyncd shutdown on 2.4, do you recall why we don't need it on 2.6? > (refresh my memory? I'm gettin' old). Because the kthread_ API handles all this. > I'm half-tempted to fire back my own list - recent regressions introduced into > XFS by, er, Christoph and (more importantly) fixed by myself and others @sgi... > but thats not constructive (although our atime and dir2-corruption nightmares > continue :). Hey, fixes for problems I introduced are 1st on my every growing todo list. But maybe you should tell me about things I'm supposed to help fixing? From owner-xfs@oss.sgi.com Wed Jul 12 11:40:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Jul 2006 11:40:49 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6CIeaDW025615 for ; Wed, 12 Jul 2006 11:40:36 -0700 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6CH7Odj017697 for ; Wed, 12 Jul 2006 11:07:24 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6CH7Oto009303 for ; Wed, 12 Jul 2006 11:07:24 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k6CH7OHw027149 for ; Wed, 12 Jul 2006 12:07:24 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k6CH7N2c027148 for xfs@oss.sgi.com; Wed, 12 Jul 2006 12:07:23 -0500 (CDT) Date: Wed, 12 Jul 2006 12:07:23 -0500 From: Dean Roehrich To: xfs@oss.sgi.com Subject: Re: Delivered state of DMAPI Event Message-ID: <20060712170723.GA26842@kickball-mn.Central.Sun.COM> References: <44B50591.4060006@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B50591.4060006@gmail.com> User-Agent: Mutt/1.5.9i X-archive-position: 8213 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 1458 Lines: 40 On Wed, Jul 12, 2006 at 10:22:09PM +0800, Michael Li (gmail) wrote: > Hi, all, > > As I know, DMAPI event can be in 2 states: > 1) enqueued, undelivered This is sitting on sn_newq. > 2) delivered and awaiting a response from the DM application. This is sitting on sn_delq. > The 2nd state also know as outstanding state for synchronous event > message. I'd like to know the exact meaning of "delivered", > Does "delivered" means the DM application had call dm_get_event() on the > event? Yes, delivered means the HSM has retrieved it with dm_get_events(). This is the only place you should see a dm_unlink_event(sn_newq) and a matching dm_link_event(sn_delq). It doesn't go onto sn_delq unless it's a sync event, as determined by looking at the ev_token field and you can see that's set in dm_enqueue() only for sync events. > Can an event message automatically change state from 1 to 2 when it is > enqueued? > Is there a list of the events that will always change state to > delievered state after it is enqueued? The "user" event, DM_EVENT_USER. Ug. This is how an HSM can drop a marker directly into the "delivered" queue. A user event never enters sn_newq. I supposed an HSM would have multiple sessions, and would be moving events around between sessions for something...er other. Don't ask me how this event is used. Of course, dm_move_event() can pull an event off one session's delq and add it to another session's delq. Dean From owner-xfs@oss.sgi.com Wed Jul 12 13:57:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Jul 2006 13:58:37 -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 k6CKvoDW017879 for ; Wed, 12 Jul 2006 13:57:59 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G0llr-00007f-TN; Wed, 12 Jul 2006 21:57:23 +0100 Date: Wed, 12 Jul 2006 21:57:23 +0100 From: Christoph Hellwig To: Nathan Scott Cc: Christoph Hellwig , Alexey Dobriyan , Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: remove unused locking flags Message-ID: <20060712205723.GA30880@infradead.org> References: <20060708215324.GA7522@martell.zuzino.mipt.ru> <20060709105454.D1640104@wobbly.melbourne.sgi.com> <20060709125643.GA28769@infradead.org> <20060710081711.A1670244@wobbly.melbourne.sgi.com> <20060710165100.GA11567@infradead.org> <20060711120059.D1702118@wobbly.melbourne.sgi.com> <20060712153719.GA620@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060712153719.GA620@infradead.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8214 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 500 Lines: 11 On Wed, Jul 12, 2006 at 04:37:19PM +0100, Christoph Hellwig wrote: > > > - adding a new inherit_nodfrg flag that's not actually used anywhere > > > > C'mon, you know better. Try inode allocation, in xfs_inode.c. > > Look again. It's not used anywhere in fs/xfs/ in Linus' tree. Actual the define with the xfs_ prefix and vowels in the identifier is used, sorry. The grepping kernel developer would be a lot happier if both identifiers were spelled either with or without the vowel, though :) From owner-xfs@oss.sgi.com Wed Jul 12 20:50:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Jul 2006 20:50:56 -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 k6D3oEDW016789 for ; Wed, 12 Jul 2006 20:50:26 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA00069; Thu, 13 Jul 2006 13:49:35 +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 k6D3nVgw1767352; Thu, 13 Jul 2006 13:49:32 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6D3nRF61761695; Thu, 13 Jul 2006 13:49:27 +1000 (EST) Date: Thu, 13 Jul 2006 13:49:27 +1000 From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: sparse (was Re: [PATCH] xfs: fix brown paperbag quota-aware stafs bug) Message-ID: <20060713134927.D1761066@wobbly.melbourne.sgi.com> References: <20060710165539.GA26673@lst.de> <20060711102341.C1702118@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060711102341.C1702118@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Tue, Jul 11, 2006 at 10:23:42AM +1000 X-archive-position: 8216 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: 609 Lines: 21 On Tue, Jul 11, 2006 at 10:23:42AM +1000, Nathan Scott wrote: > On Mon, Jul 10, 2006 at 06:55:39PM +0200, Christoph Hellwig wrote: > ... > > (I wish someone at SGI would run sparse once in a while..) > > Indeed, my bad. I'm much more motivated to do so now, thanks. :) Do you see this kind of warning from sparse, for debug builds? CHECK fs/xfs/xfs_ialloc_btree.c fs/xfs/xfs_alloc_btree.c:922:4: error: too long token expansion Looks like an assert (guess it expands to a fairly long string, after cpp-style expansion) - is there any way to make sparse not warn/error on these? thanks. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 13 01:22:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 01:22:28 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6D8M5DW026281 for ; Thu, 13 Jul 2006 01:22:06 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id k6D8LhRT009934 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Jul 2006 10:21:43 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id k6D8LhDN009932; Thu, 13 Jul 2006 10:21:43 +0200 Date: Thu, 13 Jul 2006 10:21:43 +0200 From: Christoph Hellwig To: Nathan Scott Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: sparse (was Re: [PATCH] xfs: fix brown paperbag quota-aware stafs bug) Message-ID: <20060713082143.GA9850@lst.de> References: <20060710165539.GA26673@lst.de> <20060711102341.C1702118@wobbly.melbourne.sgi.com> <20060713134927.D1761066@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060713134927.D1761066@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8217 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 1146 Lines: 25 On Thu, Jul 13, 2006 at 01:49:27PM +1000, Nathan Scott wrote: > On Tue, Jul 11, 2006 at 10:23:42AM +1000, Nathan Scott wrote: > > On Mon, Jul 10, 2006 at 06:55:39PM +0200, Christoph Hellwig wrote: > > ... > > > (I wish someone at SGI would run sparse once in a while..) > > > > Indeed, my bad. I'm much more motivated to do so now, thanks. :) > > Do you see this kind of warning from sparse, for debug builds? > > CHECK fs/xfs/xfs_ialloc_btree.c > fs/xfs/xfs_alloc_btree.c:922:4: error: too long token expansion > > Looks like an assert (guess it expands to a fairly long string, > after cpp-style expansion) - is there any way to make sparse not > warn/error on these? Yes, although I only see them with recent sparse versions. There's also a lot 'foo could be static' warnings with debug builds because STATIC is defined to nothing there. And quite a few warnings because of the uncmpleteted endianess annotations and the iovec mess.. So it's generally not so useful to look at all the warnings for now but only at the diff to a previous version, carefully looking at the changes and making sure the warnings get less, not more.. From owner-xfs@oss.sgi.com Thu Jul 13 10:36:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 10:36:27 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6DHaEDW017154 for ; Thu, 13 Jul 2006 10:36:14 -0700 Received: by nz-out-0102.google.com with SMTP id 13so101095nzn for ; Thu, 13 Jul 2006 10:35:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=jXu7eslVatntspmav5fM88vVWsyiYwN0Ayt9/9Iv5Zob91ojroLWruZCkV8PgxQV1zSkXMhcFvjg9InAyXgIDEmmp14ny8cs7dooHGy4mOaJI3hOJlfiwuF1Fer+TZIlLFHf0oZsPNQn0gb3pQE5wvn8UEgQcRN4r7gNz2xsias= Received: by 10.36.55.2 with SMTP id d2mr1664528nza; Thu, 13 Jul 2006 10:35:49 -0700 (PDT) Received: from ?192.168.10.3? ( [221.218.132.96]) by mx.gmail.com with ESMTP id 38sm86997nzk.2006.07.13.10.35.46; Thu, 13 Jul 2006 10:35:48 -0700 (PDT) Message-ID: <44B6847C.80102@gmail.com> Date: Fri, 14 Jul 2006 01:35:56 +0800 From: "Michael Li (gmail)" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com, dean.roehrich@sun.com Subject: Re:Re: Delivered state of DMAPI Event Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8220 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 2184 Lines: 67 Dean: It is a perfect answer for my questions, more than I have expected. However, we met a strange thing for our DM application: Our simple DM application running on Linux/XFS. Its task is to monitor the file read event. In the experience: 1.start the DM application. 2.set READ region for a file. 3.kill the DM application. 4.read that file. Then the system will hang, umount the xfs partition will fail too. In above exercise, after the DM app is killed, no thread will take the role doing dm_get_event(). So that the read event will not be in delivered state. But it does hang our read process. What's that, is there other issue result to this, like bad mount option... token related? Thanks, Michael On Wed, Jul 12, 2006 at 10:22:09PM +0800, Michael Li (gmail) wrote: > Hi, all, > > As I know, DMAPI event can be in 2 states: > 1) enqueued, undelivered This is sitting on sn_newq. > 2) delivered and awaiting a response from the DM application. This is sitting on sn_delq. > The 2nd state also know as outstanding state for synchronous event > message. I'd like to know the exact meaning of "delivered", > Does "delivered" means the DM application had call dm_get_event() on the > event? Yes, delivered means the HSM has retrieved it with dm_get_events(). This is the only place you should see a dm_unlink_event(sn_newq) and a matching dm_link_event(sn_delq). It doesn't go onto sn_delq unless it's a sync event, as determined by looking at the ev_token field and you can see that's set in dm_enqueue() only for sync events. > Can an event message automatically change state from 1 to 2 when it is > enqueued? > Is there a list of the events that will always change state to > delievered state after it is enqueued? The "user" event, DM_EVENT_USER. Ug. This is how an HSM can drop a marker directly into the "delivered" queue. A user event never enters sn_newq. I supposed an HSM would have multiple sessions, and would be moving events around between sessions for something...er other. Don't ask me how this event is used. Of course, dm_move_event() can pull an event off one session's delq and add it to another session's delq. Dean From owner-xfs@oss.sgi.com Thu Jul 13 10:58:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 10:58:41 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6DHwHDW021038 for ; Thu, 13 Jul 2006 10:58:19 -0700 Received: by nz-out-0102.google.com with SMTP id 13so103624nzn for ; Thu, 13 Jul 2006 10:57:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=K0iMu0RreeXqVPd5bAO4CIgVFLEeUtMA1Ty4aFb4kdh4LxvnQb6QI4mdTOkfYDtW2LyGaHNLaGbDqwVeZXBq++AM1eCAkYmtxc0kFejMxveXvOvAC14V8GFWK57AQzzcfoFpf9zB2/uPrkvYOLtDDdp0EIzSDc/zRPr6DBziTWg= Received: by 10.36.47.14 with SMTP id u14mr1694390nzu; Thu, 13 Jul 2006 10:57:56 -0700 (PDT) Received: from ?192.168.10.3? ( [221.218.132.96]) by mx.gmail.com with ESMTP id 36sm1210663nzk.2006.07.13.10.57.54; Thu, 13 Jul 2006 10:57:56 -0700 (PDT) Message-ID: <44B689AC.8030408@gmail.com> Date: Fri, 14 Jul 2006 01:58:04 +0800 From: "Michael Li (gmail)" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nathans@sgi.com, xfs@oss.sgi.com Subject: XFS bmap to disk lba question. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8221 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 1433 Lines: 35 Hi, Nathans and all, I am looking for the way to map bmap of file extent to disk physical LBA on IRIX/CXFS. Since here is the BEST place to get help about XFS, I send my confusion to you. We know that the command xfs_bmap can show us the file's extent range, for example [20 - 100], but how can we know the real physical secoter ID (or named as LBA) of file's first block(512Bytes) on a raw disk? I've read XVM admin for IRIX, it show us less clue for this mapping. We can get this mapping method on linux, as linux/xfs is open sourced, but IRIX is not, we don't know how to do it on IRIX, although the filesystem is the in the same name XFS. Furthermore, is it the same way to mapping the bmap/LBA in a striped volume. For example: a file on striped volume is in bmap range[20, 1000]. there are 3 physical disks(disk1/disk2/disk3) in the stripe, stripe unit is 128. each stripe unit has 32 512B-blocks. How can we map the first block in the file to one of disk's X sector? After read XVM document. the stripe chunksize should be 128*32 blocks, the stripe width is 3. In the special case, the file's first block must belong to disk1. But how can we know the real LBA on disk1? assume it is a very simple stripe group, not for log subvolume/realtime subvolume. Could you help me? Thanks very much! Michael BTW: If we should not talk about IRIX here, I will stop posting such a topic here. Sorry for the noise. From owner-xfs@oss.sgi.com Thu Jul 13 12:47:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 12:48:00 -0700 (PDT) Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6DJlfDW007349 for ; Thu, 13 Jul 2006 12:47:43 -0700 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6DITlxq010575 for ; Thu, 13 Jul 2006 11:29:47 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6DIR2NB002410 for ; Thu, 13 Jul 2006 12:27:02 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k6DITlpC005380 for ; Thu, 13 Jul 2006 13:29:47 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k6DITl9I005379 for xfs@oss.sgi.com; Thu, 13 Jul 2006 13:29:47 -0500 (CDT) Date: Thu, 13 Jul 2006 13:29:46 -0500 From: Dean Roehrich To: xfs@oss.sgi.com Subject: Re: Re: Delivered state of DMAPI Event Message-ID: <20060713182946.GA5313@kickball-mn.Central.Sun.COM> References: <44B6847C.80102@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B6847C.80102@gmail.com> User-Agent: Mutt/1.5.9i X-archive-position: 8222 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@Sun.COM Precedence: bulk X-list: xfs Content-Length: 1454 Lines: 47 On Fri, Jul 14, 2006 at 01:35:56AM +0800, Michael Li (gmail) wrote: > Dean: > > It is a perfect answer for my questions, more than I have expected. > However, we met a strange thing for our DM application: > Our simple DM application running on Linux/XFS. Its task is to monitor > the file read event. > In the experience: > > 1.start the DM application. > 2.set READ region for a file. So here you insert DMAPI into the I/O path for this file... > 3.kill the DM application. At this point you've disabled part of the I/O path for that file... > 4.read that file. And this is waiting for that I/O path to be restored. > Then the system will hang, umount the xfs partition will fail too. I don't believe that the entire system will hang--the only things hanging are reads on that file. I agree that the filesystem is busy and will not unmount. The read process is not holding any XFS locks or linux inode semaphores (unless there's a new bug), so it's not holding up anyone that way. > In above exercise, after the DM app is killed, no thread will take the role > doing dm_get_event(). So that the read event will not be in delivered > state. But it does hang our read process. > > What's that, is there other issue result to this, like bad mount option... > token related? Someone needs to process the DMAPI events. Restart your DM app. What did you want your read process to do? Did you want the read system call to fail? Dean From owner-xfs@oss.sgi.com Thu Jul 13 15:24:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 15:24:53 -0700 (PDT) Received: from web35705.mail.mud.yahoo.com (web35705.mail.mud.yahoo.com [66.163.179.159]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6DMOXDW029314 for ; Thu, 13 Jul 2006 15:24:34 -0700 Received: (qmail 60073 invoked by uid 60001); 13 Jul 2006 21:24:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pumSWIls/2XbwjKP5ls8o/z82BtIWrq7SHTkfQ12FfEVOdl53U0ra9pPojUBVgbSLPpREHvRCoKZyYCM+TvZfz7rr5D2+bZjpPpkD0zzf+rgWfgKzNIR2cQt1I7LlZ6KU+/ZTafYgT5mCjyIvF32h9gb8wpqGzuZWREjToQpzmg= ; Message-ID: <20060713212404.60071.qmail@web35705.mail.mud.yahoo.com> Received: from [71.134.42.129] by web35705.mail.mud.yahoo.com via HTTP; Thu, 13 Jul 2006 14:24:04 PDT Date: Thu, 13 Jul 2006 14:24:04 -0700 (PDT) From: Jeff Hardy Subject: dmapi support for xfs on fedora core 5? To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8223 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: linuxrlz@yahoo.com Precedence: bulk X-list: xfs Content-Length: 422 Lines: 15 Hello, is there any quick howto on how to setup dmapi support on the xfs on fc5? I have mounted xfs with no problem, but running a program calling dm_init_service fails. I can't seem to find any references to how to setup dmapi support. Thanks for your help -jeff __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Thu Jul 13 21:12:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 21:12:35 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6E4CCDW023994 for ; Thu, 13 Jul 2006 21:12:17 -0700 Received: by ug-out-1314.google.com with SMTP id m2so576048uge for ; Thu, 13 Jul 2006 21:11:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=LFQob0eIsUM0VlFn/ppyscnrKDxoNFMb4DuiOg9AUs9F7IsOz9hRHCbUx5gmo+18keaeEfxWzW6zGMYa+DO97t9ESgTfCB0L/q+/F94DZvdTMSILJiBk9PiYhrwYzS0iATskZtpW3/oeAnn3gb+s8QQBL4tcosv3950IMzTXdCs= Received: by 10.78.167.12 with SMTP id p12mr1436443hue; Thu, 13 Jul 2006 20:07:40 -0700 (PDT) Received: by 10.78.149.11 with HTTP; Thu, 13 Jul 2006 20:07:40 -0700 (PDT) Message-ID: Date: Fri, 14 Jul 2006 11:07:40 +0800 From: "Michael Li (Gmail)" To: dean.roehrich@Sun.COM, xfs@oss.sgi.com Subject: Re: Re: Re: Delivered state of DMAPI Event MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8224 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 2423 Lines: 87 Hi, Dean, You are right, system will not hang but only the read process, from my current knowlege of DMAPI The read process should not run in hang, since the dm_get_events() will not be called(dm app not exist), so that the read event message will not be delivered from nq to dq, from my understanding, it is the only reason that the read event message's state will be changed to outstanding, in which state, the read process will run in a hang. Am I wrong? From your point of view, can we say: when the read event is generated, it must be in outstanding state soon, or in other words: The sync event message must be get/response by dm app, if the dmapi is in the I/O path, otherwise the related laucher will be hang? Or: No matther the event is outstanding or not, if it is read event and DMAPI enabled, it will cause a read process hang although the event will not be in delivered state(outstanding state)? Thanks, Michael On Fri, Jul 14, 2006 at 01:35:56AM +0800, Michael Li (gmail) wrote: > Dean: > > It is a perfect answer for my questions, more than I have expected. > However, we met a strange thing for our DM application: > Our simple DM application running on Linux/XFS. Its task is to monitor > the file read event. > In the experience: > > 1.start the DM application. > 2.set READ region for a file. So here you insert DMAPI into the I/O path for this file... > 3.kill the DM application. At this point you've disabled part of the I/O path for that file... > 4.read that file. And this is waiting for that I/O path to be restored. > Then the system will hang, umount the xfs partition will fail too. I don't believe that the entire system will hang--the only things hanging are reads on that file. I agree that the filesystem is busy and will not unmount. The read process is not holding any XFS locks or linux inode semaphores (unless there's a new bug), so it's not holding up anyone that way. > In above exercise, after the DM app is killed, no thread will take the role > doing dm_get_event(). So that the read event will not be in delivered > state. But it does hang our read process. > > What's that, is there other issue result to this, like bad mount option... > token related? Someone needs to process the DMAPI events. Restart your DM app. What did you want your read process to do? Did you want the read system call to fail? Dean [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Jul 13 22:36:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 22:36:25 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6E5aADW002276 for ; Thu, 13 Jul 2006 22:36:11 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 8FF3318D48C7A; Thu, 13 Jul 2006 23:29:38 -0500 (CDT) Message-ID: <44B71DB1.3040801@sandeen.net> Date: Thu, 13 Jul 2006 23:29:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Jeff Hardy Cc: xfs@oss.sgi.com Subject: Re: dmapi support for xfs on fedora core 5? References: <20060713212404.60071.qmail@web35705.mail.mud.yahoo.com> In-Reply-To: <20060713212404.60071.qmail@web35705.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8226 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 427 Lines: 12 Jeff Hardy wrote: > Hello, is there any quick howto on how to setup dmapi > support on the xfs on fc5? I have mounted xfs with no > problem, but running a program calling dm_init_service > fails. I can't seem to find any references to how to > setup dmapi support. I don't think dmapi kernel support is in fc5.... you'd probably need to start w/ the cvs kernel from oss.sgi.com, or suse (or a custom fc5 kernel....) -Eric From owner-xfs@oss.sgi.com Thu Jul 13 22:32:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 22:32: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 k6E5VqDW001581 for ; Thu, 13 Jul 2006 22:32: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 PAA27977; Fri, 14 Jul 2006 15:31: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 k6E5V9gw1797831; Fri, 14 Jul 2006 15:31:09 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6E5V7aK1799533; Fri, 14 Jul 2006 15:31:07 +1000 (EST) Date: Fri, 14 Jul 2006 15:31:06 +1000 From: Nathan Scott To: "Michael Li (gmail)" Cc: xfs@oss.sgi.com Subject: Re: XFS bmap to disk lba question. Message-ID: <20060714153106.I1768738@wobbly.melbourne.sgi.com> References: <44B689AC.8030408@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44B689AC.8030408@gmail.com>; from mikore.li@gmail.com on Fri, Jul 14, 2006 at 01:58:04AM +0800 X-archive-position: 8225 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: 1900 Lines: 46 On Fri, Jul 14, 2006 at 01:58:04AM +0800, Michael Li (gmail) wrote: > We know that the command xfs_bmap can show us the file's extent range, > for example [20 - 100], but how can we know the real physical secoter ID > (or > named as LBA) of file's first block(512Bytes) on a raw disk? I've read > XVM admin for IRIX, it show us less clue for this mapping. For a single disk, its relatively simple. bmap gives you the starting offset for each extent in basic blocks (512 bytes) always, which maps directly to sectors on the logical device. You need to consider any partition table or volume manager header at the start of a physical device, and factor that into the calculation, they are not any one fixed size (I don't know how large an XVM label would be for example). > We can get this mapping method on linux, as linux/xfs is open sourced, > but IRIX is not, we don't know how to do it on IRIX, although the > filesystem is the in the same name XFS. The xfs_bmap command is basically the same between IRIX and Linux. > Furthermore, is it the same way to mapping the bmap/LBA in a striped > volume. ... > unit is 128. each stripe unit has 32 512B-blocks. How can we map the > first block in the file to one of disk's X sector? Well, it gets more complex now of course, bmap gives you one number (for the single logical address space presented by the raid or volume manager), and its an exercise for the reader to figure out which actual disk that corresponds to based on the raid geometry. Theres no tools for doing this that I know of, you just have to sit down and do the math... (well, thats how I've done it in the past anyway)... a bit of a pain, I know. > BTW: If we should not talk about IRIX here, I will stop posting such a > topic here. Sorry for the noise. Heh, yes, its more usual to speak to SGI customer support folks for this sort of topic. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 13 22:52:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Jul 2006 22:52:59 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6E5qZDW005208 for ; Thu, 13 Jul 2006 22:52:36 -0700 Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1G1Gau-0002HJ-00; Fri, 14 Jul 2006 07:52:08 +0200 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1G1Gau-0006wW-00; Fri, 14 Jul 2006 07:52:08 +0200 Received: from mapibe17.exchange.xchg ([172.23.1.54]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 07:52:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: XFS bmap to disk lba question. Date: Fri, 14 Jul 2006 07:52:00 +0200 Message-ID: <55EF1E5D5804A542A6CA37E446DDC2062D6068@mapibe17.exchange.xchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS bmap to disk lba question. Thread-Index: AcanBvBfIrLeFlpsTj2NKZ6dVgQIbgAAadag From: "Sebastian Brings" To: "Nathan Scott" , "Michael Li \(gmail\)" Cc: X-OriginalArrivalTime: 14 Jul 2006 05:52:07.0698 (UTC) FILETIME=[A4239F20:01C6A709] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k6E5qaDW005221 X-archive-position: 8227 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sebas@silexmedia.com Precedence: bulk X-list: xfs Content-Length: 2738 Lines: 75 For Irix I am aware of two ways. One is to do the math, using xvm show -verbose phys/* and so on to get the sizes of labels and volume header and figure out where the first data block starts. The other way is to use a program which does direct IO read on an existing file and run it under control of "par -k". This produces plenty of output, but holds information like "read from device X starting at offset Y number of bytes Z. You then can match it with your xfs_bmap -v list. Cheers Sebastian > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of > Nathan Scott > Sent: Freitag, 14. Juli 2006 07:31 > To: Michael Li (gmail) > Cc: xfs@oss.sgi.com > Subject: Re: XFS bmap to disk lba question. > > On Fri, Jul 14, 2006 at 01:58:04AM +0800, Michael Li (gmail) wrote: > > We know that the command xfs_bmap can show us the file's extent range, > > for example [20 - 100], but how can we know the real physical secoter ID > > (or > > named as LBA) of file's first block(512Bytes) on a raw disk? I've read > > XVM admin for IRIX, it show us less clue for this mapping. > > For a single disk, its relatively simple. bmap gives you the starting > offset for each extent in basic blocks (512 bytes) always, which maps > directly to sectors on the logical device. > > You need to consider any partition table or volume manager header at > the start of a physical device, and factor that into the calculation, > they are not any one fixed size (I don't know how large an XVM label > would be for example). > > > We can get this mapping method on linux, as linux/xfs is open sourced, > > but IRIX is not, we don't know how to do it on IRIX, although the > > filesystem is the in the same name XFS. > > The xfs_bmap command is basically the same between IRIX and Linux. > > > Furthermore, is it the same way to mapping the bmap/LBA in a striped > > volume. ... > > unit is 128. each stripe unit has 32 512B-blocks. How can we map the > > first block in the file to one of disk's X sector? > > Well, it gets more complex now of course, bmap gives you one number > (for the single logical address space presented by the raid or volume > manager), and its an exercise for the reader to figure out which > actual disk that corresponds to based on the raid geometry. Theres > no tools for doing this that I know of, you just have to sit down and > do the math... (well, thats how I've done it in the past anyway)... a > bit of a pain, I know. > > > BTW: If we should not talk about IRIX here, I will stop posting such a > > topic here. Sorry for the noise. > > Heh, yes, its more usual to speak to SGI customer support folks for > this sort of topic. > > cheers. > > -- > Nathan > From owner-xfs@oss.sgi.com Fri Jul 14 00:07:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Jul 2006 00:07:52 -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 k6E77EDW018408 for ; Fri, 14 Jul 2006 00:07:25 -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 RAA04542; Fri, 14 Jul 2006 17:06:35 +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 k6E76Vgw1798939; Fri, 14 Jul 2006 17:06:32 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6E76TGN1798773; Fri, 14 Jul 2006 17:06:29 +1000 (EST) Date: Fri, 14 Jul 2006 17:06:29 +1000 From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH 4/7] xfs: add xfs_btree_check_lptr_disk Message-ID: <20060714170628.B1797719@wobbly.melbourne.sgi.com> References: <20060710170420.GD26786@lst.de> <20060712104921.A1732817@wobbly.melbourne.sgi.com> <20060712154317.GA21752@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060712154317.GA21752@lst.de>; from hch@lst.de on Wed, Jul 12, 2006 at 05:43:17PM +0200 X-archive-position: 8228 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: 1185 Lines: 32 Hi Christoph, On Wed, Jul 12, 2006 at 05:43:17PM +0200, Christoph Hellwig wrote: > On Wed, Jul 12, 2006 at 10:49:21AM +1000, Nathan Scott wrote: > > > > > - if ((error = xfs_btree_check_lptr(cur, INT_GET(pp[i], ARCH_CONVERT), level))) { > > > + if ((error = xfs_btree_check_lptr_disk(cur, pp, level))) { > > > > This incorrectly changes the debug-only btree checking here, no? > > Right, it should be pp[i], I'll resping the patch. I wonder why I Don't worry about it - I've got it fixed here. I'm outta time for today, will merge it Monday - this and the rest look good. > > INT_GET? Maybe static inline here for type checking? *shrug*. Send an incremental on the rest of the previous series if you think this is better, and I'll merge it Monday too. BTW, the xfs_bulkstat annotations overlapped with a bunch of tuning work I'd done in there (probably merge that next week too), and I'd noticed that the endian swizzling in there is all pointless - it's only an incore buffer of inode clusters... I've got this fixed in a patch that applies after your series (so I'll apply the sparse work there, but in the end it'll come back out - no matter). cheers. -- Nathan From owner-xfs@oss.sgi.com Fri Jul 14 02:48:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Jul 2006 02:49:11 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6E9mlDW015318 for ; Fri, 14 Jul 2006 02:48:48 -0700 Received: by ug-out-1314.google.com with SMTP id s2so687814uge for ; Fri, 14 Jul 2006 02:48:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GnGoC1ylYvxLaCEYeA8+ETu9f4NNb1CIosXDm6XDKEG3eCskXilONbB5Y7KvhTZio0gf30KzrXP9gY2Imim2PxTjXaHM3wPZ3vxmKHq+yXMuRhlQwG8lF/v/KI/zOWIOAZFqvmOk/atokGPMlKVGlOuhD2bQlGSdDeQrQg3GANI= Received: by 10.78.166.7 with SMTP id o7mr1567518hue; Fri, 14 Jul 2006 02:46:48 -0700 (PDT) Received: by 10.78.149.11 with HTTP; Fri, 14 Jul 2006 02:46:48 -0700 (PDT) Message-ID: Date: Fri, 14 Jul 2006 17:46:48 +0800 From: "Michael Li (Gmail)" To: nathans@sgi.com, sebas@silexmedia.com, xfs@oss.sgi.com Subject: RE: XFS bmap to disk lba question MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8229 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 439 Lines: 16 Hi, Nathans and Sebas, Thanks for your help on my questions, we finally get the map on the simple stripe I mentioned above. It a simple caculation but I make mistake on the understanding of stripe unit size, it's in KB not Block. In my limited experience on CXFS, I always see the docs using #block on SGI :-) So... Thanks very much. More interesting questions will come later.:-) Thanks, Michael [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Jul 14 03:25:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Jul 2006 03:26:08 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6EAPjDW021156 for ; Fri, 14 Jul 2006 03:25:47 -0700 Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k6EAPIKv024510; Fri, 14 Jul 2006 19:25:18 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k6EAPIT17273; Fri, 14 Jul 2006 19:25:18 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k6EAPHX28991; Fri, 14 Jul 2006 19:25:17 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k6EAPH71006127; Fri, 14 Jul 2006 19:25:17 +0900 To: Nathan Scott Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xfs: i_state of inode is changed after the inode is freed In-reply-to: <20060710103740.B1674239@wobbly.melbourne.sgi.com> Message-Id: <20060714192520m-saito@mail.aom.tnes.nec.co.jp> References: <20060710103740.B1674239@wobbly.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Fri, 14 Jul 2006 19:25:20 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8230 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: 2113 Lines: 59 Hi, Nathan. >I'll leave it to Dave to comment more later (he's travelling at the >moment), since he's had his head deep in this area of the code most >recently - but my first thoughts on your patch are that its solving >the problem incorrectly. We should not be in the destroy_inode code >if the inode reference counting is correct everywhere - I would have >expected the fix to be a get/put style change, rather than adding an >inode lock and new lock/unlock semantics around an individual field; >... and if that cannot be done to fix this (eh?), then some comments >as to why refcounting didn't solve the problem here. On the basis of the above, I consider the get/put style fix which use i_count. This problem is that i_state of the inode is changed while the inode is freed in xfs filesystem. And the cause is that the inode release and xfs_iunpun() can run in parallel. To fix this problem, I added a pair of igrab()/iput() before and behind mark_inode_dirty_sync() at xfs_iunpin(). I think this can change it as follows. (1)The case that the inode release transaction runs after xfs_iunpin() is called. While mark_inode_dirty_sync() is running, igrab() promises that the inode is alive. (2)The case that xfs_iunpin() is called after iput() in the inode release transaction is called(i_count is 0). mark_inode_dirty_sync() is not called because the igrab() can not get the inode. I have made the following patch, but it is not yet tested. I would like to hear your comment, first. Signed-off-by: Masayuki Saito --- --- linux-2.6.17.4/fs/xfs/xfs_inode.c.orig 2006-07-14 09:44:44.187844139 +0900 +++ linux-2.6.17.4/fs/xfs/xfs_inode.c 2006-07-14 09:58:26.398486290 +0900 @@ -2751,8 +2751,14 @@ xfs_iunpin( if (vp) { struct inode *inode = vn_to_inode(vp); - if (!(inode->i_state & I_NEW)) - mark_inode_dirty_sync(inode); + if (!(inode->i_state & + (I_NEW|I_FREEING|I_CLEAR))) { + inode = igrab(inode); + if (inode != NULL) { + mark_inode_dirty_sync(inode); + iput(inode); + } + } } } wake_up(&ip->i_ipin_wait); From owner-xfs@oss.sgi.com Fri Jul 14 06:42:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Jul 2006 06:43:31 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6EDgnDW018141 for ; Fri, 14 Jul 2006 06:42:49 -0700 Received: by nz-out-0102.google.com with SMTP id r28so222724nza for ; Fri, 14 Jul 2006 06:42:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jf99VC8jlkIoASyx7V4HKo7BiTmsk7Z9DdJ6SWuMq1GCxCuzMe9A6Los4TUROfSj/JR3WShsSjn2GJQhA3XEYCkov4dEL2eEIjmcyylF7zEw33x0g/EGIFoR6mWN8Pdp5fEP5dUeMXykRjg0Rf/wkIpZN5l2b8UXGEXhmCVCNic= Received: by 10.36.178.19 with SMTP id a19mr3009483nzf; Fri, 14 Jul 2006 06:42:28 -0700 (PDT) Received: from ?192.168.10.3? ( [221.222.175.135]) by mx.gmail.com with ESMTP id 10sm1494887nzo.2006.07.14.06.42.24; Fri, 14 Jul 2006 06:42:27 -0700 (PDT) Message-ID: <44B79F4D.3060603@gmail.com> Date: Fri, 14 Jul 2006 21:42:37 +0800 From: "Michael Li (gmail)" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastian Brings , Nathan Scott , xfs@oss.sgi.com Subject: Re: XFS bmap to disk lba question. References: <55EF1E5D5804A542A6CA37E446DDC2062D6068@mapibe17.exchange.xchg> In-Reply-To: <55EF1E5D5804A542A6CA37E446DDC2062D6068@mapibe17.exchange.xchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8231 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 4418 Lines: 158 Hi, Nathan and Sebastian, I have drafted a formula for the bmap->LBA mapping for a simple stripe group(RAID0) on IRIX/CXFS. Maybe it is some roughness, If there is any mistake, correct me: For example: if a file is on [200, 1000]( shown from xfs_bmap). And the stripe unit is 128kB. stripe width is 3(totally 3 disks), xvm can told us the user data area begin after 4096 block.(This is changable by admin) stripe_unit_size = 128KB stripe_width = 3 sector_size = 512Btyes chuck_blocks = stripe_unit_size/sector_size = 128KB/512B = 256 blocks. stripe_line_blocks = chuck_block * stripe_width = 256 * 3 = 768 blocks data_offset_to_disk_block0 = 4096 blocks. file_sector_offset_in_stripe_line = BMAP % stripe_line_blocks = 200 % 768 = 200 disk_id = file_sector_offset_in_stripe_line / chunk_blocks = 200 / 256 = 0 stripe_high = BMAP / strip_line_blocks = 200 / 768 = 0 File_head_sector = stripe_high * chuck_blocks + data_offset_to_disk_block0 + file_sector_offset_in_stripe_line = 0*256 + 4096 + 200 = 4296 The LBA for the file's first block IS the above line: 4296. To ensure it, just dd back the raw data from the disk at the offset 4296 is ok. However, I am not sure the result if there is a plex layer is inserted or on the realtime volume... Could you or other interested persons refine the calculation for some variation or is there any outstanding issue on it? Thanks, Michael Sebastian Brings wrote: >For Irix I am aware of two ways. One is to do the math, using xvm show >-verbose phys/* and so on to get the sizes of labels and volume header >and figure out where the first data block starts. >The other way is to use a program which does direct IO read on an >existing file and run it under control of "par -k". This produces plenty >of output, but holds information like "read from device X starting at >offset Y number of bytes Z. You then can match it with your xfs_bmap -v >list. > >Cheers > >Sebastian > > > >>-----Original Message----- >>From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf >> >> >Of > > >>Nathan Scott >>Sent: Freitag, 14. Juli 2006 07:31 >>To: Michael Li (gmail) >>Cc: xfs@oss.sgi.com >>Subject: Re: XFS bmap to disk lba question. >> >>On Fri, Jul 14, 2006 at 01:58:04AM +0800, Michael Li (gmail) wrote: >> >> >>>We know that the command xfs_bmap can show us the file's extent >>> >>> >range, > > >>>for example [20 - 100], but how can we know the real physical >>> >>> >secoter ID > > >>>(or >>>named as LBA) of file's first block(512Bytes) on a raw disk? I've >>> >>> >read > > >>>XVM admin for IRIX, it show us less clue for this mapping. >>> >>> >>For a single disk, its relatively simple. bmap gives you the starting >>offset for each extent in basic blocks (512 bytes) always, which maps >>directly to sectors on the logical device. >> >>You need to consider any partition table or volume manager header at >>the start of a physical device, and factor that into the calculation, >>they are not any one fixed size (I don't know how large an XVM label >>would be for example). >> >> >> >>>We can get this mapping method on linux, as linux/xfs is open >>> >>> >sourced, > > >>>but IRIX is not, we don't know how to do it on IRIX, although the >>>filesystem is the in the same name XFS. >>> >>> >>The xfs_bmap command is basically the same between IRIX and Linux. >> >> >> >>>Furthermore, is it the same way to mapping the bmap/LBA in a striped >>>volume. ... >>>unit is 128. each stripe unit has 32 512B-blocks. How can we map the >>>first block in the file to one of disk's X sector? >>> >>> >>Well, it gets more complex now of course, bmap gives you one number >>(for the single logical address space presented by the raid or volume >>manager), and its an exercise for the reader to figure out which >>actual disk that corresponds to based on the raid geometry. Theres >>no tools for doing this that I know of, you just have to sit down and >>do the math... (well, thats how I've done it in the past anyway)... a >>bit of a pain, I know. >> >> >> >>>BTW: If we should not talk about IRIX here, I will stop posting such >>> >>> >a > > >>>topic here. Sorry for the noise. >>> >>> >>Heh, yes, its more usual to speak to SGI customer support folks for >>this sort of topic. >> >>cheers. >> >>-- >>Nathan >> >> >> > > > > From owner-xfs@oss.sgi.com Fri Jul 14 08:24:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Jul 2006 08:24:11 -0700 (PDT) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6EFO0DW004209 for ; Fri, 14 Jul 2006 08:24:00 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id EB7DBC07D9D7 for ; Fri, 14 Jul 2006 21:54:52 +0800 (PHT) Received: from musang.free.net.ph (gusi.leathercollection.ph [202.163.192.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id A2AA2C0001FF for ; Fri, 14 Jul 2006 21:54:48 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id CE49A2074BC5; Fri, 14 Jul 2006 21:54:44 +0800 (PHT) Date: Fri, 14 Jul 2006 21:54:44 +0800 From: Federico Sevilla III To: Linux XFS Mailing List Subject: Request Barriers and Software RAID Message-ID: <20060714135444.GB3307@free.net.ph> Mail-Followup-To: Linux XFS Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.11 X-archive-position: 8232 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: xfs Content-Length: 600 Lines: 21 Hi, I just upgraded to 2.6.17.4, and with request barriers in XFS enabled by default, am now discovering that request barriers do not work with my software RAID 1 configuration. Would anyone know if there's a way of safely allowing software RAID 1 together with XFS to support request barriers, so that I can safely enable write caching in my underlying IDE drives to squeeze out a little bit of additional performance? Thank you very much. Cheers! --> Jijo -- Federico Vicente C. Sevilla III Information Technology Consultant Q Software Research Corporation Website: http://jijo.free.net.ph From owner-xfs@oss.sgi.com Fri Jul 14 09:05:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Jul 2006 09:05:26 -0700 (PDT) Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6EG5BDW009339 for ; Fri, 14 Jul 2006 09:05:11 -0700 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6EG4oAV009000 for ; Fri, 14 Jul 2006 09:04:50 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6EG23n6022722 for ; Fri, 14 Jul 2006 10:02:03 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k6EG4otA007234 for ; Fri, 14 Jul 2006 11:04:50 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k6EG4oKZ007233 for xfs@oss.sgi.com; Fri, 14 Jul 2006 11:04:50 -0500 (CDT) Date: Fri, 14 Jul 2006 11:04:49 -0500 From: Dean Roehrich To: xfs@oss.sgi.com Subject: Re: Re: Re: Delivered state of DMAPI Event Message-ID: <20060714160449.GA7207@kickball-mn.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 8233 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 928 Lines: 20 On Fri, Jul 14, 2006 at 11:07:40AM +0800, Michael Li (Gmail) wrote: > Or: No matther the event is outstanding or not, if it is read event and > DMAPI enabled, it will cause a read process hang although the event will not > be in delivered state(outstanding state)? The state (new or delivered) doesn't matter. The file had a dmapi event set for that action so the filesystem deferred the thread to dmapi. That thread is now in the DMAPI module and, ultimately, the only mechanism to release it from DMAPI and allow it to return to the filesystem is a call to dm_respond_event. You don't have a usable filesystem if there's no DM app responding to events. You need to think in terms of making that app robust and keeping it running. The people writing that DM app also need to be aware that through DMAPI their app becomes a part of the filesystem's I/O path and they need to think appropriately, given that context. Dean From owner-xfs@oss.sgi.com Fri Jul 14 14:15:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Jul 2006 14:16:52 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6ELFeDW030821 for ; Fri, 14 Jul 2006 14:15:40 -0700 Received: from [82.41.152.154] (helo=vaio.housecafe.de) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G1U2J-0001Tl-CA for linux-xfs@oss.sgi.com; Fri, 14 Jul 2006 22:13:19 +0200 Date: Fri, 14 Jul 2006 21:13:05 +0100 (BST) From: christian X-X-Sender: evil@vaio.testbed.de To: linux-xfs@oss.sgi.com Subject: 2.6.18-rc1: XFS internal error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8234 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 994 Lines: 28 Hello xfs, today one of my xfs partitions has been shutdown with the folowing errors: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 1992 of file fs/xfs/xfs_da_btree.c. Caller 0xc02172f0 Filesystem "md0": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xc024b7c7 This fs has been running for quite a while now, it's xfs on top of a (soft)RAID-1 mounted with "noatime,nodev,nosuid". I noticed that I was getting strange io errors when ls'ing the mountpoint and then I saw the xfs errors in the kernel.log. I've unmounted the fs, mounted it again and can now access the fs again (although i suspect that I have more "free space" than yesterday) I've put together logs, the exact error message, xfs_check run output and more here: http://nerdbynature.de/bits/2.6.18-rc1/ The only thing I did was upgrading from 2.6.17.1 to 2.6.18-rc1... Thank you for your comments, Christian. -- BOFH excuse #179: multicasts on broken packets From owner-xfs@oss.sgi.com Sat Jul 15 03:08:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Jul 2006 03:08:43 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6FA8RDW014664 for ; Sat, 15 Jul 2006 03:08:28 -0700 Received: from [82.41.152.154] (helo=vaio.housecafe.de) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G1h4G-0008Sw-KR for linux-xfs@oss.sgi.com; Sat, 15 Jul 2006 12:08:12 +0200 Date: Sat, 15 Jul 2006 11:07:54 +0100 (BST) From: christian X-X-Sender: evil@vaio.testbed.de To: linux-xfs@oss.sgi.com Subject: Re: 2.6.18-rc1: XFS internal error In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8236 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 1222 Lines: 26 On Fri, 14 Jul 2006, christian wrote: > today one of my xfs partitions has been shutdown with the folowing errors: > > Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 1992 of file > fs/xfs/xfs_da_btree.c. Caller 0xc02172f0 > Filesystem "md0": XFS internal error xfs_trans_cancel at line 1138 of file > fs/xfs/xfs_trans.c. Caller 0xc024b7c7 well, it just happened again at approx. the same time when the backups are made and rsnapshot/rsync is hammering the fs: Jul 14 07:09:33 sheep kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 1992 of file fs/xfs/xfs_da_btree.c. Caller 0xc02172f0 Jul 14 07:09:33 sheep kernel: Filesystem "md0": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xc024b7c7 Jul 15 07:06:14 sheep kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 1992 of file fs/xfs/xfs_da_btree.c. Caller 0xc02172f0 Jul 15 07:06:14 sheep kernel: Filesystem "md0": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xc024b7c7 I'll downgrade to 2.6.17.4 now, please tell me it'll go away with 2.6.18-final ;) thanks, Christian. -- BOFH excuse #418: Sysadmins busy fighting SPAM. From owner-xfs@oss.sgi.com Sat Jul 15 03:49:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Jul 2006 03:49:40 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6FAnPDW020010 for ; Sat, 15 Jul 2006 03:49:26 -0700 Received: from localhost (dslb-084-056-076-199.pools.arcor-ip.net [84.56.76.199]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 85260FA510 for ; Sat, 15 Jul 2006 12:47:05 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: XFS and write barrier Date: Sat, 15 Jul 2006 12:48:56 +0200 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607151248.56603.Martin@lichtvoll.de> X-archive-position: 8237 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1970 Lines: 50 Hello, I am currently gathering information to write an article about journal filesystems with emphasis on write barrier functionality, how it works, why journalling filesystems need write barrier and the current implementation of write barrier support for different filesystems. I have quite good informations on XFS already, but some questions remain: 1) Is it safe to use write barriers with 2.6.16 or should one use 2.6.17 instead? This relates to: ----------------------------------------------------------------------- commit b04ed21a1fdbfe48ee0738519a4d1af09589dfea Author: Nathan Scott Date: Wed Jan 11 15:32:17 2006 +1100 [XFS] Disable write barriers for now till intermittent IO errors are understood. SGI-PV: 912426 SGI-Modid: xfs-linux-melb:xfs-kern:202962a Signed-off-by: Nathan Scott ----------------------------------------------------------------------- What are those intermittent IO errors? I googled but did not find a discussion of this change. 2) I experienced three XFS corruptions in one week on 2.6.16 with enabled write caches, but (by default) disabled write barriers, but on 2.6.15 - with enabled write cache as well - it only very rarely got corrupted. Does anyone have any hint as to why this may have been the case? Thing is that the system went down, the kernel crashed while it was in use. I am suspecting that the kernel went down due to other instabilities and then XFS got corrupted by out of order writes. But it may also been related to a different IO path and / or changes in the write barrier implementation in the block layer. Any ideas? No worries, if not, I simply write so. ;) It just would be nice to know why. I know its difficult to retrospect especially as I do not have the syslogs from those occasions anymore. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sat Jul 15 10:18:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Jul 2006 10:19:02 -0700 (PDT) Received: from smtp.funpic.de (smtp.funpic.de [213.202.225.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6FHInDW009042 for ; Sat, 15 Jul 2006 10:18:49 -0700 Date: Sat, 15 Jul 2006 19:18:32 +0200 From: "A. Liemen" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: Change internal to external log/journal References: <20060710183437.BD681A0090E@smtp.funpic.de> <20060711015629.DE3012008DE@smtp.funpic.de> In-Reply-To: <20060711015629.DE3012008DE@smtp.funpic.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20060715171824.2F8C1A00A89@smtp.funpic.de> X-archive-position: 8240 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: maillist@liemen.net Precedence: bulk X-list: xfs Content-Length: 529 Lines: 27 Just for reference: http://oss.sgi.com/archives/xfs/2001-07/msg00564.html Worked like a charm. Thanks Eric Alex Eric Sandeen schrieb: > A. Liemen wrote: >> Hi, >> >> is there a way to change an internal log/journal to an external one on >> an existing volume? (without loosing data / runnning mkfs) >> >> Thanks >> Alex >> > > No supported option, but if you search through the list archives you'll > find -unsupported- instructions for doing it with xfs_db. > > If it breaks, you get both pieces, etc etc :) > > -Eric From owner-xfs@oss.sgi.com Sat Jul 15 10:13:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Jul 2006 10:13:51 -0700 (PDT) Received: from smtp.funpic.de (smtp.funpic.de [213.202.225.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6FHDZDW008136 for ; Sat, 15 Jul 2006 10:13:39 -0700 Date: Sat, 15 Jul 2006 19:13:10 +0200 From: "A. Liemen" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Bonnie getc reading hitting exact 65536 kb/s Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20060715171304.59053A00A8A@smtp.funpic.de> X-archive-position: 8239 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: maillist@liemen.net Precedence: bulk X-list: xfs Content-Length: 1330 Lines: 51 Hi, during some xfs tuning tests I discovered the following phenomenon. Maybe someone can explain it to me: Bonnie++ Reading with getc()... hits exactly an almost constant 65536 kbyte/s with only ~15% IO usage. iostat and bonnie output can be found under: http://alexander.liemen.net/bonnie.txt sdb is a 14 disk RAID10 (128kb stripe) 2.8Tbyte XFS Volume with an external log (128Mb) on sda7 (Raid1) mount options are: noatime,nodiratime,logbufs=8,ihashsize=65536,logdev=/dev/sda7 mkfs: mkfs.xfs -f -d sunit=256,swidth=1792 -l version=2,size=128m,logdev=/dev/sda7 /dev/sdb scheduler: deadline system: - debian testing 2.6.15-1-amd64-k8-smp - dual opteron 275-285 (both tested) - 16gb ram - areca pci-x 1160 controller 1gb cache v1.41 firmware - WD400YR disks CPU usage is 100% (on one of the cpus) but i don't think that's the limiting factor since it hits that 16bit value absolut constantly. I have also tested it with exactly the same server but faster CPUs and it's hitting the same barrier + tested it with no mkfs.xfs options + no mount options on a second identical server. Same problem. Intelligent reading is way above with 350+ Mb/s (check bonnie.txt) Anyone got an idea why it is hitting that 16bit value / barrier? Also of interest would be why the random seeks are so bad. Thanks a lot Alex From owner-xfs@oss.sgi.com Sat Jul 15 12:29:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Jul 2006 12:29:47 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6FJTMDW026817 for ; Sat, 15 Jul 2006 12:29:26 -0700 Received: (qmail 70404 invoked from network); 15 Jul 2006 19:28:59 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 15 Jul 2006 19:28:59 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id BB35F1810227; Sat, 15 Jul 2006 12:28:57 -0700 (PDT) Date: Sat, 15 Jul 2006 12:28:57 -0700 From: Chris Wedgwood To: Martin Steigerwald Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Message-ID: <20060715192857.GA11034@tuatara.stupidest.org> References: <200607151248.56603.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607151248.56603.Martin@lichtvoll.de> X-archive-position: 8241 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: 829 Lines: 22 On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: > What are those intermittent IO errors? I googled but did not find a > discussion of this change. write barriers are enabled by default now, they have been for some months (since the end of March) > Does anyone have any hint as to why this may have been the case? > Thing is that the system went down, the kernel crashed while it was > in use. usually in the case of a kernel crash the disks are able to ti flush (unlike with power loss) so i wouldn't expect barriers or the lack of them to affect things here > I am suspecting that the kernel went down due to other instabilities > and then XFS got corrupted by out of order writes. yes, if writes are misordered and some are lost, then it's possible to have a corrupt filesystem when you come back up From owner-xfs@oss.sgi.com Sun Jul 16 02:54:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 02:54:14 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6G9s4DW005598 for ; Sun, 16 Jul 2006 02:54:04 -0700 Received: from localhost (dslb-084-056-110-224.pools.arcor-ip.net [84.56.110.224]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 6AABFFA4F3 for ; Sun, 16 Jul 2006 11:51:41 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Date: Sun, 16 Jul 2006 11:53:39 +0200 User-Agent: KMail/1.9.3 References: <200607151248.56603.Martin@lichtvoll.de> <20060715192857.GA11034@tuatara.stupidest.org> In-Reply-To: <20060715192857.GA11034@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607161153.40130.Martin@lichtvoll.de> X-archive-position: 8244 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1919 Lines: 59 Am Samstag 15 Juli 2006 21:28 schrieb Chris Wedgwood: > On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: > > What are those intermittent IO errors? I googled but did not find a > > discussion of this change. > > write barriers are enabled by default now, they have been for some > months (since the end of March) Hallo Chris, yes, but for 2.6.17 which was still in development. The stable release of it appeared kernel.org on 18-Jun-2006 02:10 according to the date in the file listing there! commit 3bbcc8e3976f8bba2fd607c8850d7dfe7e332fda Author: Nathan Scott Date: Fri Mar 31 13:04:56 2006 +1000 [XFS] Reenable write barriers by default. [...] They have been in enabled but then disabled again 5 minutes later for 2.6.16 which should still be widely in use: commit 4ef19dddbaf2f24e492c18112fd8a04ce116daca Author: Christoph Hellwig Date: Wed Jan 11 15:27:18 2006 +1100 [XFS] enable write barriers by default [...] commit b04ed21a1fdbfe48ee0738519a4d1af09589dfea Author: Nathan Scott Date: Wed Jan 11 15:32:17 2006 +1100 [XFS] Disable write barriers for now till intermittent IO errors are understood. [...] Thus for end users this write barrier support by default in XFS is rather new! What I would like to know whether its safe to use write barriers with 2.6.16 or even 2.6.15 (if it is possible at all) as well (I guess there are not many distributions that shipd with 2.6.17 already) or whether one might face those "intermittent IO errors" - whatever they are - when using them. If I do not find anything more on this I will recommend 2.6.17 for XFS with write barrier usages as I am pretty much convinced that it works stable from my own experience. (See my other post.) Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sun Jul 16 02:44:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 02:44:22 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6G9i6DW004897 for ; Sun, 16 Jul 2006 02:44:11 -0700 Received: from localhost (dslb-084-056-110-224.pools.arcor-ip.net [84.56.110.224]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 1D807FA4F3 for ; Sun, 16 Jul 2006 11:41:44 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: XFS now working stable with write caches - Thank you! Date: Sun, 16 Jul 2006 11:43:38 +0200 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607161143.38872.Martin@lichtvoll.de> X-archive-position: 8243 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 672 Lines: 29 Hello, okay, I am pretty much convinced. See http://bugzilla.kernel.org/show_bug.cgi?id=6380 Thank you, guys! Running an automated test case simulating switching the power off while writing data for a thousand times might still be a good idea if it has not already been done yet and someone can fund it. Too bad that the XFS fix from http://bugzilla.kernel.org/show_bug.cgi?id=6757 still did not make it into a stable kernel release for 2.6.17! I stronly recommend to apply it if you want to use 2.6.17 and probably 2.6.16 as well! Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sun Jul 16 08:51:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 08:52:21 -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 k6GFpaDW008577 for ; Sun, 16 Jul 2006 08:51:48 -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 BAA18050; Mon, 17 Jul 2006 01:50:56 +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 k6GFoWEo27695439; Mon, 17 Jul 2006 01:50:32 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6GFoTrJ30494394; Mon, 17 Jul 2006 01:50:29 +1000 (AEST) Date: Mon, 17 Jul 2006 01:50:29 +1000 From: David Chinner To: "A. Liemen" Cc: xfs@oss.sgi.com Subject: Re: Bonnie getc reading hitting exact 65536 kb/s Message-ID: <20060716155029.GR15160733@melbourne.sgi.com> References: <20060715171304.59053A00A8A@smtp.funpic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060715171304.59053A00A8A@smtp.funpic.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 8245 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: 1403 Lines: 43 On Sat, Jul 15, 2006 at 07:13:10PM +0200, A. Liemen wrote: > Hi, > > during some xfs tuning tests I discovered the following phenomenon. > Maybe someone can explain it to me: > > Bonnie++ Reading with getc()... hits exactly an almost constant > 65536 kbyte/s with only ~15% IO usage. > > iostat and bonnie output can be found under: > > http://alexander.liemen.net/bonnie.txt Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP storage4 40000M 64890 99 229195 39 105826 24 63895 98 350285 38 361.1 0 ^^^^^^^^^ ^^^^^^^^^ It's cpu bound, not I/O bound. It can't go any faster because it's a single threaded test.... > CPU usage is 100% (on one of the cpus) but i don't think that's the > limiting factor since it hits that 16bit value absolut constantly. What you are seeing is XFS issuing regular sized I/Os at a constant throughput. If you really think this is a 16bit ceiling, see what the block I/O tests report in iostat - you're getting ~230MB/s for write and 350MB/s for read, so if iostat is has a bug then you'll see it there. > Also of interest would be why the random seeks are so bad. Try creating more than 16 files for youre create/read/delete so that the runtime is somewhat greater than the timer resolution.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Jul 16 10:33:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 10:33:58 -0700 (PDT) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6GHXMDW015224 for ; Sun, 16 Jul 2006 10:33:22 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id C1F71C06F478 for ; Mon, 17 Jul 2006 01:32:49 +0800 (PHT) Received: from musang.free.net.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 54DE5C0001FD for ; Mon, 17 Jul 2006 01:32:42 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 708642014464; Mon, 17 Jul 2006 01:32:38 +0800 (PHT) Date: Mon, 17 Jul 2006 01:32:38 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Message-ID: <20060716173238.GD3417@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200607151248.56603.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607151248.56603.Martin@lichtvoll.de> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.11 X-archive-position: 8246 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: xfs Content-Length: 819 Lines: 22 On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: > I am currently gathering information to write an article about journal > filesystems with emphasis on write barrier functionality, how it > works, why journalling filesystems need write barrier and the current > implementation of write barrier support for different filesystems. Cool! Would you by any chance have information on the interaction between journal filesystems with write barrier functionality, and software RAID (md)? Based on my experience with 2.6.17, XFS detects that the underlying software RAID 1 device does not support barriers and therefore disables that functionality. Cheers! --> Jijo -- Federico Vicente C. Sevilla III Information Technology Consultant Q Software Research Corporation Website: http://jijo.free.net.ph From owner-xfs@oss.sgi.com Sun Jul 16 12:05:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 12:05:55 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6GJ5XDW021287 for ; Sun, 16 Jul 2006 12:05:34 -0700 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G2Bvg-00032Q-Vn for linux-xfs@oss.sgi.com; Sun, 16 Jul 2006 21:05:25 +0200 Date: Sun, 16 Jul 2006 20:04:57 +0100 (BST) From: christian X-X-Sender: evil@sheep.housecafe.de To: linux-xfs@oss.sgi.com Subject: Re: 2.6.18-rc1: XFS internal error In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8247 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 305 Lines: 13 On Sat, 15 Jul 2006, christian wrote: > I'll downgrade to 2.6.17.4 now, please tell me it'll go away with > 2.6.18-final ;) Well, downgrading to 2.6.17.5 helped, no error during the last backup run. Christian. -- BOFH excuse #137: User was distributing pornography on server; system seized by FBI. From owner-xfs@oss.sgi.com Sun Jul 16 15:47:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 15:47:49 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6GMlZDW007659 for ; Sun, 16 Jul 2006 15:47:35 -0700 Received: by py-out-1112.google.com with SMTP id c39so1267188pyd for ; Sun, 16 Jul 2006 15:47:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gVRz1+BRXq/8PPySECTDGdoaB/mDL/7Ob/s8QjDdQIuRMrug9Cvf8vyMTkVXH0DLLh+mLa/lMpHjNmdoUYSTQnEgZvJc6NeWt4G28A+PYDUFVkeYqBpJ8VmfiKATedqe9+KQfzRQkj4ZjQQD6DUIckOsUU0t9Uby9F1Ao+mvKPw= Received: by 10.35.91.10 with SMTP id t10mr2921443pyl; Sun, 16 Jul 2006 14:23:23 -0700 (PDT) Received: by 10.35.60.14 with HTTP; Sun, 16 Jul 2006 14:23:23 -0700 (PDT) Message-ID: Date: Sun, 16 Jul 2006 17:23:23 -0400 From: "Gregory Maxwell" To: xfs@oss.sgi.com Subject: Stripe alignment with RAID volumes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 8248 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gmaxwell@gmail.com Precedence: bulk X-list: xfs Content-Length: 1202 Lines: 25 I have a 12 disk HW raid 5 with 128K stripe size. I built my 4k block XFS volume with sunit=256,swidth=2816. Everything is peachy ... or is it? If I built my volume on a partitioned block device (i.e. /dev/sda2) it is quite likely that my partition will not start on a 128K boundary, so what XFS thinks is a single disk is actually two.. Worse, it's possible that the partition won't start on a 4K boundary... so every FS block read of a block on the 128K boundary will require hitting two disks (and potentially take an extra disk rotation if the disks are not spin aligned). This problem wouldn't be limited to XFS, but as one of the few FSes that pays a lot of attention to the underlying disk geometry I thought someone here might have given though to this issue. I' believe that I have avoided this problem on my own system by just putting the FS on the raw device.... which isn't so bad because msdos partition tables won't permit a 3TB partition in any case... but surely there must be a more general solution. Would it be possible to add a stripe start offset to XFS? I expect it would be fairly easy to make a disk benchmark tool which could estimate sunit, swidth, and start offset.. From owner-xfs@oss.sgi.com Sun Jul 16 17:44:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 17:44:41 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6H0iHDW019901 for ; Sun, 16 Jul 2006 17:44:23 -0700 Received: (qmail 50377 invoked from network); 17 Jul 2006 00:43:56 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 17 Jul 2006 00:43:55 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id B76201810229; Sun, 16 Jul 2006 17:43:54 -0700 (PDT) Date: Sun, 16 Jul 2006 17:43:54 -0700 From: Chris Wedgwood To: Martin Steigerwald Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Message-ID: <20060717004354.GA27193@tuatara.stupidest.org> References: <200607151248.56603.Martin@lichtvoll.de> <20060715192857.GA11034@tuatara.stupidest.org> <200607161153.40130.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607161153.40130.Martin@lichtvoll.de> X-archive-position: 8249 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: 1654 Lines: 38 On Sun, Jul 16, 2006 at 11:53:39AM +0200, Martin Steigerwald wrote: > yes, but for 2.6.17 which was still in development. The stable > release of it appeared kernel.org on 18-Jun-2006 02:10 according to > the date in the file listing there! well, i guess it depends how you look at it > What I would like to know whether its safe to use write barriers > with 2.6.16 or even 2.6.15 (if it is possible at all) as well (I > guess there are not many distributions that shipd with 2.6.17 > already) or whether one might face those "intermittent IO errors" - > whatever they are - when using them. some people (myself included) saw problems when write barriers were enabled, but that was quite some time ago and it wasn't clear if this was really an xfs, a write-barrier or some other coincidental problem at the time the problems never cause any significant on-disk damage (perhaps none at all, i don't recall the details other than it would crash often during large rsync jobs until i disabled it) write barrier support appear november last year, so a lot has changed since then fwiw, w/o write barries if your disks have write caching enabled (most will, they are horribly slow and worse some die without it) then you can trivially create corrupted volumes (do something like cp -Rl src dst and drop power or yank a hot-plug drive) > If I do not find anything more on this I will recommend 2.6.17 for > XFS with write barrier usages as I am pretty much convinced that it > works stable from my own experience. (See my other post.) you probably want 2.6.17.5+ as that has a fix for a very hard to hit bug (that seemingly a few people may have hit) From owner-xfs@oss.sgi.com Sun Jul 16 18:05:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 18:05:33 -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 k6H14wDW021761 for ; Sun, 16 Jul 2006 18:05:10 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA26007; Mon, 17 Jul 2006 11:04:18 +1000 Message-ID: <44BAE1C3.2030703@sgi.com> Date: Mon, 17 Jul 2006 11:02:59 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Liemen" CC: xfs@oss.sgi.com Subject: Re: Change internal to external log/journal References: <20060710183437.BD681A0090E@smtp.funpic.de> <20060711015629.DE3012008DE@smtp.funpic.de> <20060715171824.2F8C1A00A89@smtp.funpic.de> In-Reply-To: <20060715171824.2F8C1A00A89@smtp.funpic.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8250 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: 214 Lines: 13 A. Liemen wrote: > Just for reference: > > http://oss.sgi.com/archives/xfs/2001-07/msg00564.html But without the xfs_db endian issues from that time. Right? > > Worked like a charm. > > Thanks Eric > Alex > --Tim From owner-xfs@oss.sgi.com Sun Jul 16 18:15:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 18:15:42 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6H1FVDW023245 for ; Sun, 16 Jul 2006 18:15:32 -0700 Received: (qmail invoked by alias); 17 Jul 2006 00:15:09 -0000 Received: from dslb-084-056-121-229.pools.arcor-ip.net (EHLO [192.168.0.2]) [84.56.121.229] by mail.gmx.net (mp033) with SMTP; 17 Jul 2006 02:15:09 +0200 X-Authenticated: #395780 Message-ID: <44BAD692.8070402@gmx.de> Date: Mon, 17 Jul 2006 02:15:14 +0200 From: Michel User-Agent: Thunderbird 1.5.0.4 (X11/20060603) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: XFS failure X-Y-GMX-Trusted: 0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8251 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lomik@gmx.de Precedence: bulk X-list: xfs Content-Length: 2438 Lines: 71 Hello dear developer, almost every week on checking my fs i get * livecd root # xfs_check /dev/sda3 bad free block nused 2 should be 8 for dir ino 220115 block 16777216 bad free block nused 0 should be 6 for dir ino 34171444 block 16777216 bad free block nvalid/nused 5/-1 for dir ino 35644249 block 16777216 missing free index for data block 0 in dir ino 35644249 missing free index for data block 1 in dir ino 35644249 missing free index for data block 2 in dir ino 35644249 missing free index for data block 3 in dir ino 35644249 missing free index for data block 4 in dir ino 35644249* when i run xfs_repair ... here is the output *livecd / # xfs_repair /dev/sda3 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... free block 16777216 for directory inode 35644249 bad nused rebuilding directory inode 35644249 free block 16777216 for directory inode 34171444 bad nused rebuilding directory inode 34171444 free block 16777216 for directory inode 220115 bad nused rebuilding directory inode 220115 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done* After repairing, xfs_check reports no more errors. I always unmounting my devices cleanly ... and i never had any power failure! But every week i get the same errors. My HDD is 1 month old and i already tested it for bad sectors. Regards Michel [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Jul 16 18:24:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Jul 2006 18:25:06 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6H1OsDW024287 for ; Sun, 16 Jul 2006 18:24:54 -0700 Received: (qmail 80281 invoked from network); 17 Jul 2006 01:24:33 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 17 Jul 2006 01:24:32 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 934CA1810227; Sun, 16 Jul 2006 18:24:31 -0700 (PDT) Date: Sun, 16 Jul 2006 18:24:31 -0700 From: Chris Wedgwood To: Martin Steigerwald Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Message-ID: <20060717012431.GA27925@tuatara.stupidest.org> References: <200607151248.56603.Martin@lichtvoll.de> <20060715192857.GA11034@tuatara.stupidest.org> <200607161153.40130.Martin@lichtvoll.de> <20060717004354.GA27193@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060717004354.GA27193@tuatara.stupidest.org> X-archive-position: 8252 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: 284 Lines: 8 On Sun, Jul 16, 2006 at 05:43:54PM -0700, Chris Wedgwood wrote: > you probably want 2.6.17.5+ as that has a fix for a very hard to hit > bug (that seemingly a few people may have hit) actually, it turns out i'm a retard and can't drive git so that fix might not be in there either From owner-xfs@oss.sgi.com Mon Jul 17 01:36:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 01:36:29 -0700 (PDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6H8aJDW008544 for ; Mon, 17 Jul 2006 01:36:19 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G2NeD-0005Eb-9j for linux-xfs@oss.sgi.com; Mon, 17 Jul 2006 00:36:09 -0700 Message-ID: <5356806.post@talk.nabble.com> Date: Mon, 17 Jul 2006 00:36:09 -0700 (PDT) From: Cosmo Nova To: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation In-Reply-To: <43311567.3060208@tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: cs_mcc98@hotmail.com X-Nabble-From: Cosmo Nova References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> <43311567.3060208@tlinx.org> X-archive-position: 8253 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cs_mcc98@hotmail.com Precedence: bulk X-list: xfs Content-Length: 756 Lines: 17 Hi, you mentioned delayed allocation. What is the size of the buffer holding the data, before they're actually written to disk? How can it tackle growing files? If I have a DVR system of 16 channels. They keep writing data to the disk in pieces of video files. I read some spec of xfs. Apart from extend-based allocation, there're allocaiton groups in xfs. I would like to ask, does XFS's allocation groups work similar as JFS's, which would lock an allocation group for individual file write? How does the allocation group in XFS work? And how would it help the fragmentation problem? Thankyou! -- View this message in context: http://www.nabble.com/file-system-defragmentation-tf255485.html#a5356806 Sent from the Xfs - General forum at Nabble.com. From owner-xfs@oss.sgi.com Mon Jul 17 01:41:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 01:41:55 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6H8fiDW009177 for ; Mon, 17 Jul 2006 01:41:44 -0700 Received: from deepdance.of.teamix.net (blackhole.teamix.net [194.150.191.251]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 0D191FA6B3 for ; Mon, 17 Jul 2006 10:39:07 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: XFS failure Date: Mon, 17 Jul 2006 10:41:14 +0200 User-Agent: KMail/1.9.3 References: <44BAD692.8070402@gmx.de> In-Reply-To: <44BAD692.8070402@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607171041.14806.Martin@lichtvoll.de> X-archive-position: 8254 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 431 Lines: 20 Am Montag 17 Juli 2006 02:15 schrieb Michel: > Hello dear developer, > > almost every week on checking my fs i get Hello, known and already fixed bug, see: http://bugzilla.kernel.org/show_bug.cgi?id=6757 You need to apply this patch to get it fixed: http://bugzilla.kernel.org/show_bug.cgi?id=6757#c8 Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Mon Jul 17 03:07:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 03:07:43 -0700 (PDT) Received: from rproxy.teamix.net (team.teamix.net [194.150.191.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6HA7FDW017712 for ; Mon, 17 Jul 2006 03:07:28 -0700 Received: from mango.of.teamix.net (unknown [172.21.123.1]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by rproxy.teamix.net (Postfix) with ESMTP id AD04447E2B for ; Mon, 17 Jul 2006 09:05:48 +0000 (UTC) From: Martin Steigerwald Organization: team(ix) GmbH To: linux-xfs@oss.sgi.com Subject: Unfixable XFS defect - fatal error -- can't read block 16777216 Date: Mon, 17 Jul 2006 11:05:46 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607171105.46445.ms@teamix.de> X-archive-position: 8255 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ms@teamix.de Precedence: bulk X-list: xfs Content-Length: 3847 Lines: 92 Hello, today I got a "E: Bus error" on my workstation and KDE went down as well as no files were accessible anymore. Like trying to run "bash" gives "Input/Output error". I have no idea what this was, why it happened and found no mention of it in the syslog. I booted into Knoppix 5 and did an XFS check on the partition just to make sure it is okay. Well the root partition has some problems: root@1[~]# xfs_check /dev/sda6 agi unlinked bucket 1 is 100033 in ag 0 (inode=100033) [... some more of these ...] bad free block nused 3 should be 8 for dir ino 58973313 block 16777216 [... I thought things like this shouldn't happen anymore) missing free index for data block 0 in dir ino 100884318 missing free index for data block 1 in dir ino 100884318 missing free index for data block 2 in dir ino 100884318 missing free index for data block 3 in dir ino 100884318 missing free index for data block 4 in dir ino 100884318 missing free index for data block 5 in dir ino 100884318 missing free index for data block 6 in dir ino 100884318 missing free index for data block 7 in dir ino 100884318 missing free index for data block 8 in dir ino 100884318 missing free index for data block 9 in dir ino 100884318 missing free index for data block 10 in dir ino 100884318 missing free index for data block 11 in dir ino 100884318 missing free index for data block 12 in dir ino 100884318 missing free index for data block 13 in dir ino 100884318 missing free index for data block 14 in dir ino 100884318 missing free index for data block 32 in dir ino 100884318 agi unlinked bucket 2 is 964930 in ag 13 (inode=110016834) allocated inode 207228 has 0 link count [... some more of these ...] Does not seem to be a big problem, but xfs_repair cannot repair it: Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... fatal error -- can't read block 16777216 for directory inode 100884318 I darkly recall having read about this problem here before, but I do not find the relevant mail anymore. Can anyone give me a pointer on where to look? I am using kernel: mango:~# uname -a Linux mango 2.6.17.3-workstation-sws2-2.2.6-xfs-fix #1 PREEMPT Thu Jul 6 12:50:38 CEST 2006 i686 GNU/Linux which has the fix from http://bugzilla.kernel.org/show_bug.cgi?id=6757 on a Dell Dimension 5100 with SATA controller: mango:/home_lokal/ms# lspci 0000:00:00.0 Host bridge: Intel Corporation 945G/P Memory Controller Hub (rev 02) 0000:00:01.0 PCI bridge: Intel Corporation 945G/P PCI Express Graphics Port (rev 02) 0000:00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 0000:00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 0000:00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) [... some more of these ...] 0000:00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 0000:00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 0000:00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 0000:00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controllers cc=IDE (rev 01) 0000:00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] 0000:01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] 0000:03:08.0 Ethernet controller: Intel Corporation 82801G (ICH7 Family) LAN Controller (rev 01) Regards, -- Martin Steigerwald - team(ix) GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 From owner-xfs@oss.sgi.com Mon Jul 17 03:24:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 03:24:38 -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 k6HANwDW019747 for ; Mon, 17 Jul 2006 03:24:09 -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 UAA04818; Mon, 17 Jul 2006 20:23:18 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id C536858C4C01; Mon, 17 Jul 2006 20:23:18 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954580 - sparse fixes and annotations Message-Id: <20060717102318.C536858C4C01@chook.melbourne.sgi.com> Date: Mon, 17 Jul 2006 20:23:18 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8256 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: 8090 Lines: 221 All xfs_disk_dquot_t values are (as the name says) disk endian. Before putting them into struct statfs they should be endian-swapped. Signed-off-by: Christoph Hellwig Date: Mon Jul 17 16:50:36 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Christoph Hellwig The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26550a quota/xfs_qm_bhv.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h - All xfs_disk_dquot_t values are (as the name says) disk endian. Before putting them into struct statfs they should be endian-swapped. Fix rounding bug in xfs_free_file_space found by sparse checking. Date: Mon Jul 17 16:52:20 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26551a xfs_vnodeops.c - 1.681 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.681&r2=text&tr2=1.680&f=h Fix sparse warning found when page tracing enabled, due to overloaded gfp_t param. Date: Mon Jul 17 16:53:45 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26552a xfsidbg.c - 1.305 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.305&r2=text&tr2=1.304&f=h linux-2.6/xfs_aops.c - 1.132 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h linux-2.4/xfs_aops.c - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h endianess annotation for xfs_agfl_t. Trivial, xfs_agfl_t is always used for ondisk values. Signed-off-by: Christoph Hellwig Date: Mon Jul 17 16:59:13 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26553a xfs_ag.h - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ag.h.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h xfs_alloc.c - 1.182 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.182&r2=text&tr2=1.181&f=h - endianess annotation for xfs_agfl_t. endianess annotations for xfs_inobt_rec_t / xfs_inobt_key_t Signed-off-by: Christoph Hellwig Date: Mon Jul 17 20:05:30 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26556a xfs_ialloc.c - 1.190 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.190&r2=text&tr2=1.189&f=h xfs_itable.c - 1.140 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.140&r2=text&tr2=1.139&f=h xfs_ialloc_btree.h - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h xfs_ialloc_btree.c - 1.84 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h xfs_btree.c - 1.115 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.c.diff?r1=text&tr1=1.115&r2=text&tr2=1.114&f=h xfs_btree.h - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h - endianess annotations for xfs_inobt_rec_t / xfs_inobt_key_t remove left over INT_ comments in *alloc*.c We can verify endianess handling with sparse now, no need for comments. Signed-off-by: Christoph Hellwig Date: Mon Jul 17 20:06:58 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26557a xfs_ialloc_btree.c - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h xfs_alloc_btree.c - 1.88 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.c.diff?r1=text&tr1=1.88&r2=text&tr2=1.87&f=h - remove left over INT_ comments add xfs_btree_check_lptr_disk variant which handles endian conversion Signed-off-by: Christoph Hellwig Date: Mon Jul 17 20:10:12 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26558a xfs_bmap_btree.c - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h xfs_btree.h - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h xfs_bmap.c - 1.354 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.354&r2=text&tr2=1.353&f=h - add xfs_btree_check_lptr_disk variant which handles endian conversion endianess annotations for xfs_bmbt_ptr_t/xfs_bmdr_ptr_t Signed-off-by: Christoph Hellwig Date: Mon Jul 17 20:12:13 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26559a xfs_bmap_btree.h - 1.73 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h - endianess annotations for xfs_bmbt_ptr_t/xfs_bmdr_ptr_t endianess annotate XFS_BMAP_BROOT_PTR_ADDR Make sure it returns a __be64 and let the callers use the proper macros. Signed-off-by: Christoph Hellwig Date: Mon Jul 17 20:14:07 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26560a xfs_bmap_btree.c - 1.155 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.155&r2=text&tr2=1.154&f=h xfs_btree.h - 1.64 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h xfs_bmap.c - 1.355 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.355&r2=text&tr2=1.354&f=h - endianess annotate XFS_BMAP_BROOT_PTR_ADDR Make sure it returns a __be64 and let the callers use the proper macros. endianess annotations for xfs_bmbt_key Trivial as there are no incore users. Signed-off-by: Christoph Hellwig Date: Mon Jul 17 20:21:16 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26561a xfs_bmap_btree.h - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h xfs_bmap_btree.c - 1.156 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.156&r2=text&tr2=1.155&f=h xfs_btree.c - 1.116 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.c.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h xfs_bmap.c - 1.356 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.356&r2=text&tr2=1.355&f=h - endianess annotations for xfs_bmbt_key From owner-xfs@oss.sgi.com Mon Jul 17 03:36:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 03:36: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 k6HAa2DW020958 for ; Mon, 17 Jul 2006 03:36:14 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA03957; Mon, 17 Jul 2006 19:32:36 +1000 Message-ID: <44BB592E.1040400@melbourne.sgi.com> Date: Mon, 17 Jul 2006 19:32:30 +1000 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cosmo Nova CC: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> <43311567.3060208@tlinx.org> <5356806.post@talk.nabble.com> In-Reply-To: <5356806.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8257 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1423 Lines: 36 Cosmo Nova wrote: > Hi, you mentioned delayed allocation. What is the size of the buffer holding > the data, before they're actually written to disk? How can it tackle growing > files? I'll leave the details for Nathan/Dave... > > If I have a DVR system of 16 channels. They keep writing data to the disk in > pieces of video files. I read some spec of xfs. Apart from extend-based > allocation, there're allocaiton groups in xfs. I would like to ask, does > XFS's allocation groups work similar as JFS's, which would lock an > allocation group for individual file write? How does the allocation group in > XFS work? And how would it help the fragmentation problem? > Locking down an allocation group is part of what a new "filestream" mount option will provide. This feature is already in use at a number of IRIX sites with media apps (mainly in conjunction with CXFS since you have more writers in a clustered filesystem and more need to lock down contiguous space), and is coming to Linux XFS soon. The best way to tackle fragementation with streaming data is to preallocate space for the files. This allows the allocator to try to find the space you require using as large contiguous chunks as it can find. See xfsctl(3). David -- David Chatterton Phone: +61 3 9963 1934 XFS Engineering Manager Mobile: +61 409 154 121 SGI Australia http://www.sgi.com/products/storage From owner-xfs@oss.sgi.com Mon Jul 17 03:41:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 03:41: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 k6HAfHDW021644 for ; Mon, 17 Jul 2006 03:41:29 -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 UAA05087 for ; Mon, 17 Jul 2006 20:40:45 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id E87C958C4C01; Mon, 17 Jul 2006 20:40:44 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 954580 - cleanups Message-Id: <20060717104044.E87C958C4C01@chook.melbourne.sgi.com> Date: Mon, 17 Jul 2006 20:40:44 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8258 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: 3017 Lines: 70 use NULL for pointer initialisation instead of zero-cast-to-ptr Date: Mon Jul 17 20:31:23 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sjv The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26562a xfs_ialloc.c - 1.191 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.191&r2=text&tr2=1.190&f=h xfs_ialloc_btree.c - 1.86 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h xfs_bmap_btree.c - 1.157 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h xfs_alloc_btree.c - 1.89 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.c.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h remove bhv_lookup, _range version works aswell and has more useful semantics. Signed-off-by: Christoph Hellwig Date: Mon Jul 17 20:34:49 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26563a xfs_mount.h - 1.226 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.226&r2=text&tr2=1.225&f=h xfs_behavior.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_behavior.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfs_behavior.h - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_behavior.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h linux-2.6/xfs_vnode.h - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h linux-2.4/xfs_vnode.h - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h linux-2.6/xfs_ksyms.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h linux-2.4/xfs_ksyms.c - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h dmapi/xfs_dm.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - remove bhv_lookup, _range version works aswell and has more useful semantics. remove accidentally reintroduced vfs unmount flag, unneeded in current kernels Date: Mon Jul 17 20:40:14 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26564a linux-2.6/xfs_vfs.h - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h From owner-xfs@oss.sgi.com Mon Jul 17 03:47:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 03:48: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 k6HAlTDW022559 for ; Mon, 17 Jul 2006 03:47: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 UAA05281; Mon, 17 Jul 2006 20:46:52 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 0489158C4C01; Mon, 17 Jul 2006 20:46:51 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954366 - prep for i_blksize removal Message-Id: <20060717104652.0489158C4C01@chook.melbourne.sgi.com> Date: Mon, 17 Jul 2006 20:46:51 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8259 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: 476 Lines: 15 Update XFS for i_blksize removal from generic inode structure Date: Mon Jul 17 20:46:05 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26565a linux-2.6/xfs_iops.c - 1.254 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.254&r2=text&tr2=1.253&f=h From owner-xfs@oss.sgi.com Mon Jul 17 04:06:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 04:06: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 k6HB66DW024654 for ; Mon, 17 Jul 2006 04:06:20 -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 VAA05609; Mon, 17 Jul 2006 21:05:16 +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 k6HB5Bgw1893033; Mon, 17 Jul 2006 21:05:13 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6HB52nw1895867; Mon, 17 Jul 2006 21:05:02 +1000 (EST) Date: Mon, 17 Jul 2006 21:05:01 +1000 From: Nathan Scott To: Masayuki Saito Cc: David Chinner , 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: <20060717210501.A1895298@wobbly.melbourne.sgi.com> References: <20060710103740.B1674239@wobbly.melbourne.sgi.com> <20060714192520m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060714192520m-saito@mail.aom.tnes.nec.co.jp>; from m-saito@tnes.nec.co.jp on Fri, Jul 14, 2006 at 07:25:20PM +0900 X-archive-position: 8260 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: 1974 Lines: 49 On Fri, Jul 14, 2006 at 07:25:20PM +0900, Masayuki Saito wrote: > Hi, Nathan. > > >I'll leave it to Dave to comment more later (he's travelling at the > >moment), since he's had his head deep in this area of the code most > >recently - but my first thoughts on your patch are that its solving > >the problem incorrectly. We should not be in the destroy_inode code > >if the inode reference counting is correct everywhere - I would have > >expected the fix to be a get/put style change, rather than adding an > >inode lock and new lock/unlock semantics around an individual field; > >... and if that cannot be done to fix this (eh?), then some comments > >as to why refcounting didn't solve the problem here. > > On the basis of the above, I consider the get/put style fix which use > i_count. > > This problem is that i_state of the inode is changed while the inode > is freed in xfs filesystem. And the cause is that the inode release > and xfs_iunpun() can run in parallel. > > To fix this problem, I added a pair of igrab()/iput() before and behind > mark_inode_dirty_sync() at xfs_iunpin(). I think this can change it as > follows. > > (1)The case that the inode release transaction runs after xfs_iunpin() > is called. > While mark_inode_dirty_sync() is running, igrab() promises that the > inode is alive. > > (2)The case that xfs_iunpin() is called after iput() in the inode > release transaction is called(i_count is 0). > mark_inode_dirty_sync() is not called because the igrab() can not get > the inode. > > I have made the following patch, but it is not yet tested. > I would like to hear your comment, first. If this fixes your test case, then I like the look of it. ;-) It does seem much simpler and less invasive than the earlier fix using a spinlock. I'll run with this in my testing for awhile, let me know how your own testing goes too, please (I especially would like to hear if it fixes that reproducible failure case). thanks! -- Nathan From owner-xfs@oss.sgi.com Mon Jul 17 06:20:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 06:21:03 -0700 (PDT) Received: from rproxy.teamix.net (team.teamix.net [194.150.191.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6HDKmDW011776 for ; Mon, 17 Jul 2006 06:20:48 -0700 Received: from mango.of.teamix.net (unknown [172.21.123.1]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by rproxy.teamix.net (Postfix) with ESMTP id E0A7C47E0B for ; Mon, 17 Jul 2006 13:20:27 +0000 (UTC) From: Martin Steigerwald Organization: team(ix) GmbH To: linux-xfs@oss.sgi.com Subject: Re: Unfixable XFS defect - fatal error -- can't read block 16777216 Date: Mon, 17 Jul 2006 15:20:24 +0200 User-Agent: KMail/1.9.1 References: <200607171105.46445.ms@teamix.de> In-Reply-To: <200607171105.46445.ms@teamix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607171520.25067.ms@teamix.de> X-archive-position: 8261 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ms@teamix.de Precedence: bulk X-list: xfs Content-Length: 1206 Lines: 34 Am Montag, 17. Juli 2006 11:05 schrieben Sie: > I darkly recall having read about this problem here before, but I do not > find the relevant mail anymore. Can anyone give me a pointer on where to > look? Hello, I found it: http://oss.sgi.com/bugzilla/show_bug.cgi?id=631 Mailing list thread: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable I read that using xfs_repair 2.7.18 might help. I didnt found this in the ftp area thus I compiled xfsprogs 2.8.4 under Knoppix 5 and tried with that. Unfortunately it isn't able to fix the defect. It shows the same error message as the older xfs_repair in Knoppix 5. The partition in question is 20 gigs. I can create a backup of it, but only with partimage which can compress, as I have no 20gig in one place free on that harddisk. Tell me when you are interested. I like to know how I can fix this in place however - the manual way of fixing it which is described in the mailing list thread I mentioned above did not work according to what I read there. If nothing else helps I will replay a backup. Regards, -- Martin Steigerwald - team(ix) GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 From owner-xfs@oss.sgi.com Mon Jul 17 07:09:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 07:09:51 -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 k6HE98DW018987 for ; Mon, 17 Jul 2006 07:09:19 -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 AAA09138; Tue, 18 Jul 2006 00:08:22 +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 k6HE7uEo30882264; Tue, 18 Jul 2006 00:07:57 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6HE7pjn30879382; Tue, 18 Jul 2006 00:07:51 +1000 (AEST) Date: Tue, 18 Jul 2006 00:07:51 +1000 From: David Chinner To: Nathan Scott Cc: Masayuki Saito , David Chinner , 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: <20060717140751.GW2114946@melbourne.sgi.com> References: <20060710103740.B1674239@wobbly.melbourne.sgi.com> <20060714192520m-saito@mail.aom.tnes.nec.co.jp> <20060717210501.A1895298@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060717210501.A1895298@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8262 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: 3799 Lines: 89 On Mon, Jul 17, 2006 at 09:05:01PM +1000, Nathan Scott wrote: > On Fri, Jul 14, 2006 at 07:25:20PM +0900, Masayuki Saito wrote: > > Hi, Nathan. > > > > >I'll leave it to Dave to comment more later (he's travelling at the > > >moment), since he's had his head deep in this area of the code most > > >recently - but my first thoughts on your patch are that its solving > > >the problem incorrectly. We should not be in the destroy_inode code > > >if the inode reference counting is correct everywhere - I would have > > >expected the fix to be a get/put style change, rather than adding an > > >inode lock and new lock/unlock semantics around an individual field; > > >... and if that cannot be done to fix this (eh?), then some comments > > >as to why refcounting didn't solve the problem here. Looking at this a bit deeper, I think the reference counting is correct and the problem is that we are not breaking the link between the linux inode and the xfs inode atomically w.r.t xfs_iunpin() usage.... > > On the basis of the above, I consider the get/put style fix which use > > i_count. > > > > This problem is that i_state of the inode is changed while the inode > > is freed in xfs filesystem. And the cause is that the inode release > > and xfs_iunpun() can run in parallel. > > > > To fix this problem, I added a pair of igrab()/iput() before and behind > > mark_inode_dirty_sync() at xfs_iunpin(). I think this can change it as > > follows. > > > > (1)The case that the inode release transaction runs after xfs_iunpin() > > is called. > > While mark_inode_dirty_sync() is running, igrab() promises that the > > inode is alive. > > > > (2)The case that xfs_iunpin() is called after iput() in the inode > > release transaction is called(i_count is 0). > > mark_inode_dirty_sync() is not called because the igrab() can not get > > the inode. > > > > I have made the following patch, but it is not yet tested. > > I would like to hear your comment, first. > > If this fixes your test case, then I like the look of it. ;-) I don't think it fixes the problem because igrab() fails to handle the case we are hitting where I_CLEAR is set on the inode when we mark it dirty. There's nothing in this patch preventing us from sleeping after the !(I_NEW|I_FREEING|I_CLEAR) check is done and then racing with generic_drop_inode() before the igrab() can take a reference on the inode. ATM, I think the real problem is the use of the XFS_IRECLAIMABLE flag and the locking involved. Nathan, the inode hash lock is used to sync that flag between xfs_iget_core() and xfs_finish_reclaim(), but no lock is used when setting it or (now) checking in xfs_iunpin()..... Worse, the i_flags field does not use atomic bitops and there is no consistent locking protecting i_flags so updates and reads of this filed can race or even get lost.... Also, I think that xfs_iunpin() must execute atomically w.r.t xfs_reclaim(), otherwise we cannot ever safely do the checks we are doing in xfs_iunpin(). > It does seem much simpler and less invasive than the earlier fix > using a spinlock. I'll run with this in my testing for awhile, > let me know how your own testing goes too, please (I especially > would like to hear if it fixes that reproducible failure case). I think a fix is going to be much more invasive than just adding reference as my fixes appear to have only narrowed the race window and not solved it. The addition of the lock in the original patch solves the atomic xfs_iunpin()/xfs_reclaim() execution problem, but it does not solve the problems with the i_flags field. Adding a new lock may be our only option here. This will have to wait until after OLS before I get a chance to look at this further... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jul 17 07:47:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 07:48:06 -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 k6HElRDW023391 for ; Mon, 17 Jul 2006 07:47:39 -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 AAA09984; Tue, 18 Jul 2006 00:46:49 +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 k6HEkPEo31138327; Tue, 18 Jul 2006 00:46:26 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6HEkNFC31155432; Tue, 18 Jul 2006 00:46:23 +1000 (AEST) Date: Tue, 18 Jul 2006 00:46:23 +1000 From: David Chinner To: Gregory Maxwell Cc: xfs@oss.sgi.com Subject: Re: Stripe alignment with RAID volumes Message-ID: <20060717144623.GA2114946@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 8263 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: 2719 Lines: 74 On Sun, Jul 16, 2006 at 05:23:23PM -0400, Gregory Maxwell wrote: > I have a 12 disk HW raid 5 with 128K stripe size. I built my 4k block > XFS volume with sunit=256,swidth=2816. Everything is peachy ... or is > it? > > If I built my volume on a partitioned block device (i.e. /dev/sda2) it > is quite likely that my partition will not start on a 128K boundary, > so what XFS thinks is a single disk is actually two.. RAID performance trap for the unwary #21. ;) > Worse, it's > possible that the partition won't start on a 4K boundary... so every > FS block read of a block on the 128K boundary will require hitting two > disks (and potentially take an extra disk rotation if the disks are > not spin aligned). *nod* IIRC from investigations done years ago on Irix, this misalignment typically results in the filesystem being 3-4x slower on bandwidth loads than a correctly aligned filesystem.... > This problem wouldn't be limited to XFS, but as one of the few FSes > that pays a lot of attention to the underlying disk geometry I thought > someone here might have given though to this issue. Plenty ;) For example, see the Data Layout section of the Irix GRIOv2 man page: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat5/grio2.z&srch=grio2 We probably should encapsulate some form of this example in a FAQ entry, because that's exactly what it is... > I' believe that I have avoided this problem on my own system by just > putting the FS on the raw device.... which isn't so bad because msdos > partition tables won't permit a 3TB partition in any case... but > surely there must be a more general solution. Device mapper is your friend - you can offset the start of the volume on each device you use. We've done this in the past to allow multiple volume managers to coexist on the same luns. e.g. first volume manager exists in 0-4MiB of each lun, so we tell dm that each device starts at offset 4MiB rather than at 0.... > Would it be possible to add a stripe start offset to XFS? Maybe, but I can't see how it would be a simple thing to do because it would require on-disk format changes... Anyway, if you were configuring an XFS filesystem to do this, you still need to understand the underlying geometry to get it right. You may as well get your volume manager configuration correct, and then we don't have to worry about it in XFS. > I expect > it would be fairly easy to make a disk benchmark tool which could > estimate sunit, swidth, and start offset.. Not as easy as you would expect. But if you've got a patch, then we'll happily consider it. ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jul 17 08:21:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 08:21:42 -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 k6HFL2DW031551 for ; Mon, 17 Jul 2006 08:21:15 -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 AAA09464; Tue, 18 Jul 2006 00:19:42 +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 k6HEJJEo30991408; Tue, 18 Jul 2006 00:19:19 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6HEJH2x29532191; Tue, 18 Jul 2006 00:19:17 +1000 (AEST) Date: Tue, 18 Jul 2006 00:19:17 +1000 From: David Chinner To: Cosmo Nova Cc: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation Message-ID: <20060717141917.GY2114946@melbourne.sgi.com> References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> <43311567.3060208@tlinx.org> <5356806.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5356806.post@talk.nabble.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8265 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: 692 Lines: 20 On Mon, Jul 17, 2006 at 12:36:09AM -0700, Cosmo Nova wrote: > > Hi, you mentioned delayed allocation. What is the size of the buffer holding > the data, before they're actually written to disk? How can it tackle growing > files? No special buffering is needed in XFS as the page cache does it all for us. delalloc means that XFS does not allocate until the data gets written to disk (i.e. flushed from the cache). The size of the allocation is dependent on the amount of contiguous dirty data in the file. That is, The more sequential dirty pages in the page cache for a file, the larger the allocation... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jul 17 08:30:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 08:31:08 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6HFUtDW000892 for ; Mon, 17 Jul 2006 08:30:56 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6HFUTBk020772 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 Jul 2006 11:30:29 -0400 Subject: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Mon, 17 Jul 2006 11:30:23 -0400 Message-Id: <1153150223.4532.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8266 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 307 Lines: 13 Hi All We want to use XFS in all of our production servers but feel a little scary about the corruption problems seen in this list. I wonder which 2.6.16+ kernel we can use in order to get a stable XFS? Thanks! ps, one friend mentioned that XFS has some issue with LVM+MD under it. Is this true? Ming From owner-xfs@oss.sgi.com Mon Jul 17 08:52:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 08:53:00 -0700 (PDT) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6HFqLDW003183 for ; Mon, 17 Jul 2006 08:52:26 -0700 Received: (qmail 6635 invoked by uid 10); 17 Jul 2006 14:51:59 -0000 Received: from planetzork.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 17 Jul 2006 14:51:59 -0000 Received: (qmail 863 invoked by uid 1000); 17 Jul 2006 16:48:31 +0200 Date: Mon, 17 Jul 2006 16:48:31 +0200 From: Jochen Heuer To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Ingo Molnar , nathans@sgi.com, xfs@oss.sgi.com Subject: Re: BUG: soft lockup detected on CPU#1! Message-ID: <20060717144831.GA28284@planetzork.ping.de> References: <20060717125216.GA15481@planetzork.ping.de> <1153146608.1218.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153146608.1218.9.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 X-archive-position: 8267 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jogi-kernel@planetzork.ping.de Precedence: bulk X-list: xfs Content-Length: 302 Lines: 14 On Mon, Jul 17, 2006 at 10:30:08AM -0400, Steven Rostedt wrote: > > Jochen, you didn't say whether or not the 2.6.18-rc2 locked up. I'm > assuming it did. But did it? Hi Steven, no, it did not lock up yet but I did not do any "serious" webbrowsing with 2.6.18-rc2 so far. Best regards, Jochen From owner-xfs@oss.sgi.com Mon Jul 17 11:51:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 11:52:01 -0700 (PDT) Received: from service.eng.exegy.net (68-191-203-42.static.stls.mo.charter.com [68.191.203.42]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6HIphDW020875 for ; Mon, 17 Jul 2006 11:51:43 -0700 Received: from HANAFORD.eng.exegy.net (hanaford.eng.exegy.net [10.19.1.4]) by service.eng.exegy.net (8.13.1/8.13.1) with ESMTP id k6HHQFj7010524 for ; Mon, 17 Jul 2006 12:26:15 -0500 Received: from [10.19.4.98] ([10.19.4.98]) by HANAFORD.eng.exegy.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 12:26:15 -0500 Message-ID: <44BBC836.7020503@exegy.com> Date: Mon, 17 Jul 2006 12:26:14 -0500 From: Dave Lloyd User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: Stripe alignment with RAID volumes References: <20060717144623.GA2114946@melbourne.sgi.com> In-Reply-To: <20060717144623.GA2114946@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2006 17:26:15.0033 (UTC) FILETIME=[1B1FDE90:01C6A9C6] X-archive-position: 8268 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dlloyd@exegy.com Precedence: bulk X-list: xfs Content-Length: 1077 Lines: 33 David Chinner wrote: > > Device mapper is your friend - you can offset the start of the volume > on each device you use. > > We've done this in the past to allow multiple volume managers to coexist > on the same luns. e.g. first volume manager exists in 0-4MiB of each > lun, so we tell dm that each device starts at offset 4MiB rather than > at 0.... Device Mapper? I haven't heard about this. >> Would it be possible to add a stripe start offset to XFS? > > Maybe, but I can't see how it would be a simple thing to do because > it would require on-disk format changes... > > Anyway, if you were configuring an XFS filesystem to do this, you > still need to understand the underlying geometry to get it right. > You may as well get your volume manager configuration correct, and > then we don't have to worry about it in XFS. The latest parted will let you use bytes to size the partitions. Stripe aligning the begining and the end of the partition does give better performance. -- Dave Lloyd Test Engineer, Exegy, Inc. 314.450.5342 dlloyd@exegy.com From owner-xfs@oss.sgi.com Mon Jul 17 12:08:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 12:09:03 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6HJ8oDW023164 for ; Mon, 17 Jul 2006 12:08:50 -0700 Received: (qmail 41851 invoked from network); 17 Jul 2006 19:08:28 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 17 Jul 2006 19:08:28 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 819891810227; Mon, 17 Jul 2006 12:08:27 -0700 (PDT) Date: Mon, 17 Jul 2006 12:08:27 -0700 From: Chris Wedgwood To: Cosmo Nova Cc: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation Message-ID: <20060717190827.GA7845@tuatara.stupidest.org> References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> <43311567.3060208@tlinx.org> <5356806.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5356806.post@talk.nabble.com> X-archive-position: 8269 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: 700 Lines: 17 On Mon, Jul 17, 2006 at 12:36:09AM -0700, Cosmo Nova wrote: > If I have a DVR system of 16 channels. They keep writing data to the > disk in pieces of video files. I did some work for someone who does a similar thing (they write 96 channels in parallel and have to be able to do read back up to 32 of them at the same time of something). By default concurrent writes into the same directory will cause the files to get badly interleaved, and trying to get one file per-ag doesn't work so well if the agcount < n-files. I ended up getting them to change their code to preallocate and AFAIK it works very well now (you can throw away any space you over allocate when you're closing the file too). From owner-xfs@oss.sgi.com Mon Jul 17 19:07:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Jul 2006 19:07:29 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6I27CDW021471 for ; Mon, 17 Jul 2006 19:07:12 -0700 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 3E69B1EC08; Tue, 18 Jul 2006 02:48:43 +0200 (CEST) From: Neil Brown To: Justin Piszcz Date: Tue, 18 Jul 2006 10:48:07 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17596.12231.468729.199881@cse.unsw.edu.au> Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Raid5 Reshape Status + xfs_growfs = Success! (2.6.17.3) In-Reply-To: message from Justin Piszcz on Tuesday July 11 References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-face: v[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D Neil, > > It worked, echo'ing the 600 > to the stripe width in /sys, however, how > come /dev/md3 says it is 0 MB when I type fdisk -l? > > Is this normal? Yes. The 'cylinders' number is limited to 16bits. For you 2.2TB array, the number of 'cylinders' (given 2 heads and 4 sectors) would be about 500,000 which doesn't fit into 16 bits. > > Furthermore, the xfs_growfs worked beautifully! > Excellent! NeilBrown From owner-xfs@oss.sgi.com Tue Jul 18 00:32:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 00:32:44 -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 k6I7W2DW005962 for ; Tue, 18 Jul 2006 00:32:14 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28622; Tue, 18 Jul 2006 17:31:28 +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 k6I7VOgw1920919; Tue, 18 Jul 2006 17:31:25 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6I7VMkH1918590; Tue, 18 Jul 2006 17:31:22 +1000 (EST) Date: Tue, 18 Jul 2006 17:31:22 +1000 From: Nathan Scott To: xfs@oss.sgi.com Cc: Neil Brown , linux-raid@vger.kernel.org Subject: Re: XFS and write barrier Message-ID: <20060718173122.B1914501@wobbly.melbourne.sgi.com> References: <200607151248.56603.Martin@lichtvoll.de> <20060716173238.GD3417@free.net.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060716173238.GD3417@free.net.ph>; from jijo@free.net.ph on Mon, Jul 17, 2006 at 01:32:38AM +0800 X-archive-position: 8271 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: 912 Lines: 21 On Mon, Jul 17, 2006 at 01:32:38AM +0800, Federico Sevilla III wrote: > On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: > > I am currently gathering information to write an article about journal > > filesystems with emphasis on write barrier functionality, how it > > works, why journalling filesystems need write barrier and the current > > implementation of write barrier support for different filesystems. > > Cool! Would you by any chance have information on the interaction > between journal filesystems with write barrier functionality, and > software RAID (md)? Based on my experience with 2.6.17, XFS detects that > the underlying software RAID 1 device does not support barriers and > therefore disables that functionality. Noone here seems to know, maybe Neil &| the other folks on linux-raid can help us out with details on status of MD and write barriers? cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 18 00:56:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 00:57:16 -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 k6I7uaDW009051 for ; Tue, 18 Jul 2006 00:56:50 -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 RAA28982; Tue, 18 Jul 2006 17:55:58 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 3EF0858C4C03; Tue, 18 Jul 2006 17:55:58 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954577 - log/rt-as-file Message-Id: <20060718075558.3EF0858C4C03@chook.melbourne.sgi.com> Date: Tue, 18 Jul 2006 17:55:58 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8272 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: 484 Lines: 14 Fix use of realtime/log subvols as-a-file, like data subvol, for testing. Date: Tue Jul 18 17:55:36 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26575a xfsprogs/mkfs/xfs_mkfs.c - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h From owner-xfs@oss.sgi.com Tue Jul 18 01:00:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 01:00:14 -0700 (PDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6I802DW009575 for ; Tue, 18 Jul 2006 01:00:03 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G2kUV-00065A-8K for linux-xfs@oss.sgi.com; Tue, 18 Jul 2006 00:59:39 -0700 Message-ID: <5374022.post@talk.nabble.com> Date: Tue, 18 Jul 2006 00:59:39 -0700 (PDT) From: Cosmo Nova To: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation In-Reply-To: <20060717141917.GY2114946@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: cs_mcc98@hotmail.com X-Nabble-From: Cosmo Nova References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> <43311567.3060208@tlinx.org> <5356806.post@talk.nabble.com> <20060717141917.GY2114946@melbourne.sgi.com> X-archive-position: 8273 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cs_mcc98@hotmail.com Precedence: bulk X-list: xfs Content-Length: 952 Lines: 20 Hi, can I summarize by saying that, XFS still partition the volume into different allocation groups, but there is NO locking. Two files may write in the same allocation group and introduce fragments? What is the maximum and typical number of allocation groups please? I can't find the numbers in the source code... And for the buffer, Is preallocation the same as delayed allocation? page cache, as I remember belongs to Linux VFS. What are the memory / disk requirement and sizing for the cache please? If a file space allocation is delayed, what is the upper bound of the delayed size? Can files of MBs, GBs being delayed allocate, and multiple channels/threads files all store in memory?? How XFS's allocation works (with number please if possible) to help tackle fragmentation? Thankyou! -- View this message in context: http://www.nabble.com/file-system-defragmentation-tf255485.html#a5374022 Sent from the Xfs - General forum at Nabble.com. From owner-xfs@oss.sgi.com Tue Jul 18 01:16:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 01:17:24 -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 k6I8GdDW012181 for ; Tue, 18 Jul 2006 01:16:53 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA29374; Tue, 18 Jul 2006 18:15:57 +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 k6I8Frgw1920360; Tue, 18 Jul 2006 18:15:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6I8FoNP1888995; Tue, 18 Jul 2006 18:15:50 +1000 (EST) Date: Tue, 18 Jul 2006 18:15:49 +1000 From: Nathan Scott To: Ingo Molnar Cc: xfs@oss.sgi.com Subject: Re: Annotating xfs_lock_inodes Message-ID: <20060718181549.D1914501@wobbly.melbourne.sgi.com> References: <20060706091535.B1548326@wobbly.melbourne.sgi.com> <20060706100712.GA6439@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: <20060706100712.GA6439@elte.hu>; from mingo@elte.hu on Thu, Jul 06, 2006 at 12:07:12PM +0200 X-archive-position: 8274 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: 2980 Lines: 97 Hi Ingo, On Thu, Jul 06, 2006 at 12:07:12PM +0200, Ingo Molnar wrote: > ... > you can do a subclass++ in the inode locking loop in xfs_lock_inodes(), > and pass that subclass index into a new function: > > xfs_ilock_nested(..., subclass) > > or something like that. I have something like that working now, and on to investigating the next issue reported (unrelated to xfs_lock_inodes). I found that I needed to have the rwsem trylock variants available with a subclass argument too though (like the non-trylock variants are currently) in order to get that part of xfs_lock_inodes to play ball. Could you look over this change for me, and queue it up for lockdep checking in mainline (no rush) if it looks OK? thanks! -- Nathan diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h index 658afb3..d6d7d47 100644 --- a/include/linux/rwsem.h +++ b/include/linux/rwsem.h @@ -64,7 +64,9 @@ #ifdef CONFIG_DEBUG_LOCK_ALLOC * nested locking: */ extern void down_read_nested(struct rw_semaphore *sem, int subclass); +extern int down_read_trylock_nested(struct rw_semaphore *sem, int subclass); extern void down_write_nested(struct rw_semaphore *sem, int subclass); +extern int down_write_trylock_nested(struct rw_semaphore *sem, int subclass); /* * Take/release a lock when not the owner will release it: */ @@ -72,9 +74,11 @@ extern void down_read_non_owner(struct r extern void up_read_non_owner(struct rw_semaphore *sem); #else # define down_read_nested(sem, subclass) down_read(sem) -# define down_write_nested(sem, subclass) down_write(sem) -# define down_read_non_owner(sem) down_read(sem) -# define up_read_non_owner(sem) up_read(sem) +# define down_read_trylock_nested(sem, subclass) down_read_trylock(sem) +# define down_write_nested(sem, subclass) down_write(sem) +# define down_write_trylock_nested(sem, subclass) down_write_trylock(sem) +# define down_read_non_owner(sem) down_read(sem) +# define up_read_non_owner(sem) up_read(sem) #endif #endif /* __KERNEL__ */ diff --git a/kernel/rwsem.c b/kernel/rwsem.c index 291ded5..4b7eb74 100644 --- a/kernel/rwsem.c +++ b/kernel/rwsem.c @@ -116,6 +116,17 @@ void down_read_nested(struct rw_semaphor EXPORT_SYMBOL(down_read_nested); +int down_read_trylock_nested(struct rw_semaphore *sem, int subclass) +{ + int ret = __down_read_trylock(sem); + + if (ret == 1) + rwsem_acquire_read(&sem->dep_map, subclass, 1, _RET_IP_); + return ret; +} + +EXPORT_SYMBOL(down_read_trylock_nested); + void down_read_non_owner(struct rw_semaphore *sem) { might_sleep(); @@ -135,6 +146,17 @@ void down_write_nested(struct rw_semapho EXPORT_SYMBOL(down_write_nested); +int down_write_trylock_nested(struct rw_semaphore *sem, int subclass) +{ + int ret = __down_write_trylock(sem); + + if (ret == 1) + rwsem_acquire(&sem->dep_map, subclass, 0, _RET_IP_); + return ret; +} + +EXPORT_SYMBOL(down_write_trylock_nested); + void up_read_non_owner(struct rw_semaphore *sem) { __up_read(sem); From owner-xfs@oss.sgi.com Tue Jul 18 02:00:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 02:00:24 -0700 (PDT) Received: from mx1.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6I8xxDW017752 for ; Tue, 18 Jul 2006 02:00:00 -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 4EA6BEED8; Tue, 18 Jul 2006 10:59:32 +0200 (CEST) From: Neil Brown To: Nathan Scott Date: Tue, 18 Jul 2006 18:58:56 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17596.41680.124148.595601@cse.unsw.edu.au> Cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: XFS and write barrier In-Reply-To: message from Nathan Scott on Tuesday July 18 References: <200607151248.56603.Martin@lichtvoll.de> <20060716173238.GD3417@free.net.ph> <20060718173122.B1914501@wobbly.melbourne.sgi.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-face: v[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D On Mon, Jul 17, 2006 at 01:32:38AM +0800, Federico Sevilla III wrote: > > On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: > > > I am currently gathering information to write an article about journal > > > filesystems with emphasis on write barrier functionality, how it > > > works, why journalling filesystems need write barrier and the current > > > implementation of write barrier support for different filesystems. "Journalling filesystems need write barrier" isn't really accurate. They can make good use of write barrier if it is supported, and where it isn't supported, they should use blkdev_issue_flush in combination with regular submit/wait. > > > > Cool! Would you by any chance have information on the interaction > > between journal filesystems with write barrier functionality, and > > software RAID (md)? Based on my experience with 2.6.17, XFS detects that > > the underlying software RAID 1 device does not support barriers and > > therefore disables that functionality. > > Noone here seems to know, maybe Neil &| the other folks on linux-raid > can help us out with details on status of MD and write barriers? In 2.6.17, md/raid1 will detect if the underlying devices support barriers and if they all do, it will accept barrier requests from the filesystem and pass those requests down to all devices. Other raid levels will reject all barrier requests. Filesystems should notice this and submit regular writes and wait for them to complete (which they do) and call blk_issue_flush after the commit block has been written (which I think few do). At least, that is my understanding. NeilBrown From owner-xfs@oss.sgi.com Tue Jul 18 03:28:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 03:28:33 -0700 (PDT) Received: from e450.epcc.ed.ac.uk (e450.epcc.ed.ac.uk [129.215.56.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6IASFDW029044 for ; Tue, 18 Jul 2006 03:28:16 -0700 Received: from localhost (garnet.epcc.ed.ac.uk [129.215.56.56]) by e450.epcc.ed.ac.uk (8.13.6/8.13.6) with ESMTP id k6I9StVV004004; Tue, 18 Jul 2006 10:28:55 +0100 (BST) Subject: oops with CentOS 4.3 / xfs / nfsd From: Andrew Elwell To: linux-xfs@oss.sgi.com Cc: maciej@epcc.ed.ac.uk Content-Type: multipart/mixed; boundary="=-3KPuxqhFz7DVasZxaYzI" Date: Tue, 18 Jul 2006 10:29:21 +0100 Message-Id: <1153214961.6793.15.camel@x41ade> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) X-Edinburgh-Scanned: at mailhost.epcc.ed.ac.uk X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) X-archive-position: 8276 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrewe@epcc.ed.ac.uk Precedence: bulk X-list: xfs Content-Length: 20410 Lines: 485 --=-3KPuxqhFz7DVasZxaYzI Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Folks, We've migrated some of our storage servers to CentOS 4.3 and are seeing lockups. It *could* be hardware I know, and I'm scheduling downtime to run memtest86+ ASAP. Overview: 2* LPFC HBA's connecting to our SAN, dm setup for multipath to see 4*1.6TB trays each tray as a PV in lvm2 sanvg xfs on a 3T lv NFS exported out as /export/work using the 2.6.9-34 centosplus SMP kernel (3GHz P4 with hyperthreading enabled) what we normally (~once a day) is simply do_IRQ: stack overflow: 416 [] on the console and nothing else. (needs a cold reboot) Having installed netdump (nice tool btw) we got a different error yesterday that looks xfs / nfsd related... (attached) any help in progressing this would be much appreciated - Andrew --=-3KPuxqhFz7DVasZxaYzI Content-Disposition: attachment; filename=log Content-Type: text/plain; name=log; charset=UTF-8 Content-Transfer-Encoding: 7bit IP 172.20.0.224 SysRq : HELP : loglevel0-8 reBoot Crash tErm kIll saK showMem powerOff showPc unRaw Sync showTasks Unmount shoWcpus nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] kmem_alloc+0x50/0x96 [xfs] [] kmem_realloc+0x17/0x52 [xfs] [] xfs_iext_realloc+0xc9/0xdc [xfs] [] xfs_bmap_insert_exlist+0x22/0x77 [xfs] [] xfs_bmap_add_extent_hole_delay+0x43c/0x492 [xfs] [] xfs_bmap_add_extent+0x146/0x399 [xfs] [] xfs_bmapi+0xb03/0x12cc [xfs] [] do_IRQ+0x123/0x1b8 [] xfs_bmapi+0x329/0x12cc [xfs] [] autoremove_wake_function+0x0/0x2d [] xfs_iomap_write_delay+0x630/0x70a [xfs] [] xfs_bmap_do_search_extents+0x378/0x384 [xfs] [] xfs_iomap+0x23a/0x3ec [xfs] [] xfs_iomap+0x2e4/0x3ec [xfs] [] xfs_bmap+0x1a/0x1e [xfs] [] linvfs_get_block_core+0x6b/0x257 [xfs] [] set_bh_page+0x2c/0x34 [] linvfs_get_block+0x13/0x17 [xfs] [] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] [] linvfs_prepare_write+0x12/0x16 [xfs] [] linvfs_get_block+0x0/0x17 [xfs] [] generic_file_buffered_write+0x186/0x47c [] xfs_zero_eof+0x167/0x275 [xfs] [] xfs_write+0x61d/0x97d [xfs] [] linvfs_writev+0xc4/0xe3 [xfs] [] activate_task+0x88/0x95 [] svc_expkey_lookup+0x1f0/0x322 [nfsd] [] autoremove_wake_function+0x0/0x2d [] linvfs_writev+0x0/0xe3 [xfs] [] do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] [] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc] [] nfsd+0x1cc/0x339 [nfsd] [] nfsd+0x0/0x339 [nfsd] [] kernel_thread_helper+0x5/0xb Mem-info: DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 cpu 1 hot: low 2, high 6, batch 1 cpu 1 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu: empty Free pages: 2244kB (0kB HighMem) Active:2887 inactive:114284 dirty:14642 writeback:0 unstable:0 free:561 slab:5084 mapped:2796 pagetables:195 DMA free:172kB min:20kB low:40kB high:60kB active:476kB inactive:11204kB present:16384kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 Normal free:2072kB min:688kB low:1376kB high:2064kB active:11072kB inactive:445932kB present:490684kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 DMA: 33*4kB 5*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 172kB Normal: 226*4kB 122*8kB 2*16kB 5*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2072kB HighMem: empty Swap cache: add 55, delete 55, find 3/4, race 0+0 0 bounce buffer pages Free swap: 2048100kB 126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33708 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] kmem_alloc+0x50/0x96 [xfs] [] kmem_realloc+0x17/0x52 [xfs] [] xfs_iext_realloc+0xc9/0xdc [xfs] [] xfs_bmap_insert_exlist+0x22/0x77 [xfs] [] xfs_bmap_add_extent_hole_delay+0x43c/0x492 [xfs] [] xfs_bmap_add_extent+0x146/0x399 [xfs] [] xfs_bmapi+0xb03/0x12cc [xfs] [] do_IRQ+0x123/0x1b8 [] xfs_bmapi+0x329/0x12cc [xfs] [] autoremove_wake_function+0x0/0x2d [] xfs_iomap_write_delay+0x630/0x70a [xfs] [] xfs_bmap_do_search_extents+0x378/0x384 [xfs] [] xfs_iomap+0x23a/0x3ec [xfs] [] xfs_iomap+0x2e4/0x3ec [xfs] [] xfs_bmap+0x1a/0x1e [xfs] [] linvfs_get_block_core+0x6b/0x257 [xfs] [] set_bh_page+0x2c/0x34 [] linvfs_get_block+0x13/0x17 [xfs] [] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] [] linvfs_prepare_write+0x12/0x16 [xfs] [] linvfs_get_block+0x0/0x17 [xfs] [] generic_file_buffered_write+0x186/0x47c [] xfs_zero_eof+0x167/0x275 [xfs] [] xfs_write+0x61d/0x97d [xfs] [] linvfs_writev+0xc4/0xe3 [xfs] [] activate_task+0x88/0x95 [] svc_expkey_lookup+0x1f0/0x322 [nfsd] [] autoremove_wake_function+0x0/0x2d [] linvfs_writev+0x0/0xe3 [xfs] [] do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] [] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc] [] nfsd+0x1cc/0x339 [nfsd] [] nfsd+0x0/0x339 [nfsd] [] kernel_thread_helper+0x5/0xb Mem-info: DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 cpu 1 hot: low 2, high 6, batch 1 cpu 1 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu: empty Free pages: 2372kB (0kB HighMem) Active:2887 inactive:114252 dirty:14642 writeback:0 unstable:0 free:593 slab:5084 mapped:2796 pagetables:195 DMA free:172kB min:20kB low:40kB high:60kB active:476kB inactive:11204kB present:16384kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 Normal free:2200kB min:688kB low:1376kB high:2064kB active:11072kB inactive:445804kB present:490684kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 DMA: 33*4kB 5*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 172kB Normal: 234*4kB 134*8kB 2*16kB 5*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2200kB HighMem: empty Swap cache: add 55, delete 55, find 3/4, race 0+0 0 bounce buffer pages Free swap: 2048100kB 126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33678 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] kmem_alloc+0x50/0x96 [xfs] [] kmem_realloc+0x17/0x52 [xfs] [] xfs_iext_realloc+0xc9/0xdc [xfs] [] xfs_bmap_insert_exlist+0x22/0x77 [xfs] [] xfs_bmap_add_extent_hole_delay+0x43c/0x492 [xfs] [] xfs_bmap_add_extent+0x146/0x399 [xfs] [] xfs_bmapi+0xb03/0x12cc [xfs] [] do_IRQ+0x123/0x1b8 [] xfs_bmapi+0x329/0x12cc [xfs] [] autoremove_wake_function+0x0/0x2d [] xfs_iomap_write_delay+0x630/0x70a [xfs] [] xfs_bmap_do_search_extents+0x378/0x384 [xfs] [] xfs_iomap+0x23a/0x3ec [xfs] [] xfs_iomap+0x2e4/0x3ec [xfs] set_bh_page+0x2c/0x34 [] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] generic_file_buffered_write+0x186/0x47c activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc]cpu 0 hot: low 2, high 6, batch 1 126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33644 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] do_IRQ+0x123/0x1b8 autoremove_wake_function+0x0/0x2d set_bh_page+0x2c/0x34 [] linvfs_get_block+0x13/0x17 [xfs] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] generic_file_buffered_write+0x186/0x47c activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] []Active:2893 inactive:114163 dirty:14644 writeback:0 unstable:0 free:673 slab:5085 mapped:2796 pagetables:195 DMA free:300kB min:20kB low:40kB high:60kB active:476kB inactive:11076kB present:16384kB pages_scanned:0 all_unreclaimable? no protections[]:126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33625 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 do_IRQ+0x123/0x1b8 autoremove_wake_function+0x0/0x2d set_bh_page+0x2c/0x34 [] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] generic_file_buffered_write+0x186/0x47c linvfs_writev+0xc4/0xe3 [xfs] activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc] 126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33598 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] do_IRQ+0x123/0x1b8 autoremove_wake_function+0x0/0x2d set_bh_page+0x2c/0x34 [] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] generic_file_buffered_write+0x186/0x47c [] activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] [] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc]Free pages: 2820kB (0kB HighMem) Active:2894 inactive:114130 dirty:14646 writeback:1 unstable:0 free:705 slab:5085 mapped:2796 pagetables:195 DMA free:300kB min:20kB low:40kB high:60kB active:476kB inactive:11076kB present:16384kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 protections[]: 0 0 0 126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33586 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] autoremove_wake_function+0x0/0x2d set_bh_page+0x2c/0x34 [] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] generic_file_buffered_write+0x186/0x47c activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc]126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33574 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] xfs_bmap_add_extent_hole_delay+0x43c/0x492 [xfs] autoremove_wake_function+0x0/0x2d set_bh_page+0x2c/0x34 [] linvfs_get_block+0x13/0x17 [xfs] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] generic_file_buffered_write+0x186/0x47c [] activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] [] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc]cpu 0 hot: low 2, high 6, batch 1 empty Free pages: 2948kB (0kB HighMem) HighMem: empty 126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33560 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d [] cache_alloc_refill+0x14f/0x187 __kmalloc+0x71/0x83 [] xfs_bmapi+0xb03/0x12cc [xfs] autoremove_wake_function+0x0/0x2d set_bh_page+0x2c/0x34 [] linvfs_get_block+0x13/0x17 [xfs] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] generic_file_buffered_write+0x186/0x47c [] activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc] DMA: 65*4kB 5*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 300kB 126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33546 pages shared 0 pages swap cached nfsd: page allocation failure. order:4, mode:0x50 [] __alloc_pages+0x2d6/0x2ee [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x16/0xaf [] cache_grow+0x99/0x11d cache_alloc_refill+0x14f/0x187 [] __kmalloc+0x71/0x83 [] do_IRQ+0x123/0x1b8 autoremove_wake_function+0x0/0x2d set_bh_page+0x2c/0x34 [] linvfs_get_block+0x13/0x17 [xfs] __block_prepare_write+0x165/0x3e7 [] block_prepare_write+0x16/0x23 [] linvfs_get_block+0x0/0x17 [xfs] generic_file_buffered_write+0x186/0x47c [] activate_task+0x88/0x95 autoremove_wake_function+0x0/0x2d do_readv_writev+0x1c0/0x240 [] do_sync_write+0x0/0xc9 [] __dentry_open+0x105/0x1cf [] dentry_open+0x49/0x4e [] vfs_writev+0x3e/0x43 [] nfsd_write+0xeb/0x284 [nfsd] common_interrupt+0x18/0x20 [] svcauth_unix_set_client+0x7d/0xb5 [sunrpc] [] nfsd3_proc_write+0xbf/0xd5 [nfsd] [] nfs3svc_decode_writeargs+0x0/0x243 [nfsd] [] nfsd_dispatch+0xba/0x16d [nfsd] [] svc_process+0x432/0x6d7 [sunrpc] cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu:126767 pages of RAM 0 pages of HIGHMEM 2103 reserved pages 33534 pages shared 0 pages swap cached possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) possible deadlock in kmem_alloc (mode:0x50) do_IRQ: stack overflow: 416 [] --=-3KPuxqhFz7DVasZxaYzI-- From owner-xfs@oss.sgi.com Tue Jul 18 04:36:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 04:37:08 -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 k6IBarDW010742 for ; Tue, 18 Jul 2006 04:36:56 -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 k6IBaLvO022779; Tue, 18 Jul 2006 07:36:21 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.13.1/8.13.1/Submit) with ESMTP id k6IBaLpH022776; Tue, 18 Jul 2006 07:36:21 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 18 Jul 2006 07:36:21 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Andrew Elwell cc: linux-xfs@oss.sgi.com, maciej@epcc.ed.ac.uk Subject: Re: oops with CentOS 4.3 / xfs / nfsd In-Reply-To: <1153214961.6793.15.camel@x41ade> Message-ID: References: <1153214961.6793.15.camel@x41ade> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8278 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: 545 Lines: 22 On Tue, 18 Jul 2006 at 10:29am, Andrew Elwell wrote > using the 2.6.9-34 centosplus SMP kernel (3GHz P4 with hyperthreading > enabled) > > what we normally (~once a day) is simply > > do_IRQ: stack overflow: 416 > [] You don't want to use the XFS in the centosplus kernel. It has major known issues with 4K stacks (leading to overflows). Use the kernel-module-xfs (or somesuch) RPM instead, and you should have better luck. Or move to x86_64... ;) -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-xfs@oss.sgi.com Tue Jul 18 05:02:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 05:02:46 -0700 (PDT) Received: from mx0.intradot.com (ns21611.ovh.net [213.251.178.110]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6IC2UDW014830 for ; Tue, 18 Jul 2006 05:02:30 -0700 Received: from vev69-1-82-232-218-63.fbx.proxad.net ([82.232.218.63] helo=[192.168.2.60]) by mx0.intradot.com with esmtp (Exim 4.50) id 1G2mQd-0007AP-J6 for xfs@oss.sgi.com; Tue, 18 Jul 2006 12:03:47 +0200 Message-ID: <44BCB1F8.1030705@amakuru.net> Date: Tue, 18 Jul 2006 12:03:36 +0200 From: David Morel User-Agent: Mozilla Thunderbird 1.0.6-7.6.20060mdk (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: restore previous FAT ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8280 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmorel@amakuru.net Precedence: bulk X-list: xfs Content-Length: 252 Lines: 10 Hi, a client of mine (I SWEAR it is not me) accidentally formated one of their HDs, and they shouldn't have :) Kind of a mixup, and they end up having no data. Is there some miraculous way of restoring the previous FAT ? Thanks a million D.Morel From owner-xfs@oss.sgi.com Tue Jul 18 10:02:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 10:02:10 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6IH1tDW001362 for ; Tue, 18 Jul 2006 10:01:59 -0700 Received: (qmail 10714 invoked from network); 18 Jul 2006 17:01:31 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 18 Jul 2006 17:01:30 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id E984F184BF12; Tue, 18 Jul 2006 10:01:29 -0700 (PDT) Date: Tue, 18 Jul 2006 10:01:29 -0700 From: Chris Wedgwood To: David Morel Cc: xfs@oss.sgi.com Subject: Re: restore previous FAT ? Message-ID: <20060718170129.GB24508@tuatara.stupidest.org> References: <44BCB1F8.1030705@amakuru.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44BCB1F8.1030705@amakuru.net> X-archive-position: 8282 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: 457 Lines: 11 On Tue, Jul 18, 2006 at 12:03:36PM +0200, David Morel wrote: > a client of mine (I SWEAR it is not me) accidentally formated one of > their HDs, and they shouldn't have :) Kind of a mixup, and they end > up having no data. Is there some miraculous way of restoring the > previous FAT ? probably not easily, the critical data for FAT filesystems were likely clobbered by SB0 and the metadata associated with that AG (like thr root inode, directory, etc). From owner-xfs@oss.sgi.com Tue Jul 18 10:05:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 10:05:59 -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 k6IH5FDW001745 for ; Tue, 18 Jul 2006 10:05:27 -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 DAA09529; Wed, 19 Jul 2006 03:04:36 +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 k6IH4AEo31913079; Wed, 19 Jul 2006 03:04:10 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6IH46Jo32154457; Wed, 19 Jul 2006 03:04:06 +1000 (AEST) Date: Wed, 19 Jul 2006 03:04:06 +1000 From: David Chinner To: Neil Brown Cc: Nathan Scott , xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: XFS and write barrier Message-ID: <20060718170406.GT15160733@melbourne.sgi.com> References: <200607151248.56603.Martin@lichtvoll.de> <20060716173238.GD3417@free.net.ph> <20060718173122.B1914501@wobbly.melbourne.sgi.com> <17596.41680.124148.595601@cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17596.41680.124148.595601@cse.unsw.edu.au> User-Agent: Mutt/1.4.2.1i X-archive-position: 8283 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: 2053 Lines: 48 On Tue, Jul 18, 2006 at 06:58:56PM +1000, Neil Brown wrote: > On Tuesday July 18, nathans@sgi.com wrote: > > On Mon, Jul 17, 2006 at 01:32:38AM +0800, Federico Sevilla III wrote: > > > On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: > > > > I am currently gathering information to write an article about journal > > > > filesystems with emphasis on write barrier functionality, how it > > > > works, why journalling filesystems need write barrier and the current > > > > implementation of write barrier support for different filesystems. > > "Journalling filesystems need write barrier" isn't really accurate. > They can make good use of write barrier if it is supported, and where > it isn't supported, they should use blkdev_issue_flush in combination > with regular submit/wait. blkdev_issue_flush() causes a write cache flush - just like a barrier typically causes a write cache flush up to the I/O with the barrier in it. Both of these mechanisms provide the same thing - an I/O barrier that enforces ordering of I/Os to disk. Given that filesystems already indicate to the block layer when they want a barrier, wouldn't it be better to get the block layer to issue this cache flush if the underlying device doesn't support barriers and it receives a barrier request? FWIW, Only XFS and Reiser3 use this function, and only then when issuing a fsync when barriers are disabled to make sure a common test (fsync then power cycle) doesn't result in data loss... > > Noone here seems to know, maybe Neil &| the other folks on linux-raid > > can help us out with details on status of MD and write barriers? > > In 2.6.17, md/raid1 will detect if the underlying devices support > barriers and if they all do, it will accept barrier requests from the > filesystem and pass those requests down to all devices. > > Other raid levels will reject all barrier requests. Any particular reason for not supporting barriers on the other types of RAID? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jul 18 11:28:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 11:28:48 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6IISXDW011729 for ; Tue, 18 Jul 2006 11:28:34 -0700 Received: from localhost (dslb-084-056-120-082.pools.arcor-ip.net [84.56.120.82]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 7D5F6FA68B for ; Tue, 18 Jul 2006 20:25:40 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Date: Tue, 18 Jul 2006 20:27:48 +0200 User-Agent: KMail/1.9.3 References: <200607151248.56603.Martin@lichtvoll.de> <17596.41680.124148.595601@cse.unsw.edu.au> <20060718170406.GT15160733@melbourne.sgi.com> In-Reply-To: <20060718170406.GT15160733@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607182027.49648.Martin@lichtvoll.de> X-archive-position: 8284 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 2020 Lines: 47 Am Dienstag 18 Juli 2006 19:04 schrieb David Chinner: > > "Journalling filesystems need write barrier" isn't really accurate. > > They can make good use of write barrier if it is supported, and where > > it isn't supported, they should use blkdev_issue_flush in combination > > with regular submit/wait. > > blkdev_issue_flush() causes a write cache flush - just like a > barrier typically causes a write cache flush up to the I/O with the > barrier in it. Both of these mechanisms provide the same thing - an > I/O barrier that enforces ordering of I/Os to disk. Hello David, well now it gets interesting. If both provide the same thing, whats the difference? > Given that filesystems already indicate to the block layer when they > want a barrier, wouldn't it be better to get the block layer to issue > this cache flush if the underlying device doesn't support barriers > and it receives a barrier request? Does a device need to support more than this cache flush in order to support barriers? Up to know I thought that when a device supports cache flushes the kernel can provide barrier functinality for it. I see in boot output that my notebook harddisk supports cache flushes. But not in dmesg nor in syslog. I don't know yet how to actually determine whether barrier functionality is really usable on a certain system. > FWIW, Only XFS and Reiser3 use this function, and only then when > issuing a fsync when barriers are disabled to make sure a common > test (fsync then power cycle) doesn't result in data loss... So will XFS be safe even without write barriers? What will it do when it cannot do write barriers but write barriers are requested by the user or the inbuilt default setting of the filesystem? Will it work unsafely or will mount readonly or disable write caches in that case? I think I need to read / learn even more to get a complete picture of this. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Jul 18 12:23:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 12:24:08 -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 k6IJNSDW021820 for ; Tue, 18 Jul 2006 12:23:40 -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 FAA12615; Wed, 19 Jul 2006 05:22:03 +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 k6IJLdEo32195120; Wed, 19 Jul 2006 05:21:40 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6IJLaOA32242673; Wed, 19 Jul 2006 05:21:36 +1000 (AEST) Date: Wed, 19 Jul 2006 05:21:35 +1000 From: David Chinner To: Martin Steigerwald Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Message-ID: <20060718192135.GV15160733@melbourne.sgi.com> References: <200607151248.56603.Martin@lichtvoll.de> <17596.41680.124148.595601@cse.unsw.edu.au> <20060718170406.GT15160733@melbourne.sgi.com> <200607182027.49648.Martin@lichtvoll.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607182027.49648.Martin@lichtvoll.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 8285 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: 2898 Lines: 71 On Tue, Jul 18, 2006 at 08:27:48PM +0200, Martin Steigerwald wrote: > Am Dienstag 18 Juli 2006 19:04 schrieb David Chinner: > > > > "Journalling filesystems need write barrier" isn't really accurate. > > > They can make good use of write barrier if it is supported, and where > > > it isn't supported, they should use blkdev_issue_flush in combination > > > with regular submit/wait. > > > > blkdev_issue_flush() causes a write cache flush - just like a > > barrier typically causes a write cache flush up to the I/O with the > > barrier in it. Both of these mechanisms provide the same thing - an > > I/O barrier that enforces ordering of I/Os to disk. > > Hello David, > > well now it gets interesting. If both provide the same thing, whats the > difference? A WRITE_BARRIER I/O can be optimised by smart drivers, protocols and hardware to minimise the adverse effects of the barrier, whereas a cache flush is a brute force cache cleaning mechanism that cannot be optimised.... > > Given that filesystems already indicate to the block layer when they > > want a barrier, wouldn't it be better to get the block layer to issue > > this cache flush if the underlying device doesn't support barriers > > and it receives a barrier request? > > Does a device need to support more than this cache flush in order to > support barriers? Up to know I thought that when a device supports cache > flushes the kernel can provide barrier functinality for it. Not necessarily as different device/protocol commands are used. > I see in boot output that my notebook harddisk supports cache flushes. But > not in dmesg nor in syslog. I don't know yet how to actually determine > whether barrier functionality is really usable on a certain system. My test is to mount an XFS filesystem using barriers on the device and look at the syslog message. ;) > > FWIW, Only XFS and Reiser3 use this function, and only then when > > issuing a fsync when barriers are disabled to make sure a common > > test (fsync then power cycle) doesn't result in data loss... > > So will XFS be safe even without write barriers? XFS is only safe when you have: a) no write caching on the drive (barrier or nobarrier) b) non-volatile write caching on the drive (barrier or nobarrier) c) volatile write caching and barriers supported and enabled The same conditions hold true for any filesystem that requires I/O ordering guarantees to maintain filesystem consistency... > What will it do when it > cannot do write barriers but write barriers are requested by the user or > the inbuilt default setting of the filesystem? Will it work unsafely or > will mount readonly or disable write caches in that case? XFS will log a warning to the syslog and dmesg saying write barriers are disabled and continue onwards without barriers. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jul 18 14:17:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 14:17:21 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6ILHADW004971 for ; Tue, 18 Jul 2006 14:17:11 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G2Vpg-0003Av-Ty for ; Mon, 17 Jul 2006 17:20:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17595.47312.720883.451573@base.ty.sabi.co.UK> Date: Mon, 17 Jul 2006 17:20:32 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <1153150223.4532.24.camel@localhost.localdomain> References: <1153150223.4532.24.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 8287 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 431 Lines: 11 >>> On Mon, 17 Jul 2006 11:30:23 -0400, Ming Zhang >>> said: mingz> Hi All We want to use XFS in all of our production mingz> servers but feel a little scary about the corruption mingz> problems seen in this list. [ ... ] XFS is complex but quite stable code. Most of the reports about ''corruption'' are consequences of not being aware of what it was designed for, how it works and how it should be used... From owner-xfs@oss.sgi.com Tue Jul 18 14:33:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 14:33:54 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6ILXaDW006481 for ; Tue, 18 Jul 2006 14:33:39 -0700 Received: (qmail 94457 invoked from network); 18 Jul 2006 21:33:06 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 18 Jul 2006 21:33:05 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 621B1184DA25; Tue, 18 Jul 2006 14:33:04 -0700 (PDT) Date: Tue, 18 Jul 2006 14:33:04 -0700 From: Chris Wedgwood To: Cosmo Nova Cc: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation Message-ID: <20060718213304.GA27287@tuatara.stupidest.org> References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> <43311567.3060208@tlinx.org> <5356806.post@talk.nabble.com> <20060717141917.GY2114946@melbourne.sgi.com> <5374022.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5374022.post@talk.nabble.com> X-archive-position: 8288 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: 1463 Lines: 39 On Tue, Jul 18, 2006 at 12:59:39AM -0700, Cosmo Nova wrote: > Hi, can I summarize by saying that, XFS still partition the volume > into different allocation groups, but there is NO locking. the allocator has per-AG locks > Two files may write in the same allocation group and introduce > fragments? i'm not sure what you mean, but any number of files can be writing to a single AG at once, the degree of fragmentation you will see depends on the IO patterns and where there are writing in the case of writing multiple large files in parallel in the same directory the blocks do tend to interleave > What is the maximum and typical number of allocation groups please? > I can't find the numbers in the source code... It's a 32-bit value, I'm not sure how practical very large values are though. > And for the buffer, Is preallocation the same as delayed allocation? No, preallocation allocates space a head of time on disk so that later when it's written the allocation process is simpler (or not needed) and ideally also to reduce fragmentation by doing as much allocation as possible at once. Delayed allocation is simply the idea of doing the allocation as late as possible so when you do have to flush the data to disk you can try to make better decisions about where to place the blocks. > If a file space allocation is delayed, what is the upper bound of > the delayed size? It depends on the platform and how often data is flushed from the OS. From owner-xfs@oss.sgi.com Tue Jul 18 15:27:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 15:28:34 -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 k6IMQpDW011252 for ; Tue, 18 Jul 2006 15:27: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 IAA16341; Wed, 19 Jul 2006 08:25:41 +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 k6IMPQgw1934942; Wed, 19 Jul 2006 08:25:28 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6IMOxU91936544; Wed, 19 Jul 2006 08:24:59 +1000 (EST) Date: Wed, 19 Jul 2006 08:24:59 +1000 From: Nathan Scott To: Jan Engelhardt Cc: Greg KH , linux-kernel@vger.kernel.org, stable@kernel.org, Justin Forbes , Zwane Mwaikambo , "Theodore Ts'o" , Randy Dunlap , Dave Jones , Chuck Wolber , Chris Wedgwood , torvalds@osdl.org, akpm@osdl.org, alan@lxorguk.ukuu.org.uk, Mandy Kirkconnell , Chris Wright , xfs@oss.sgi.com Subject: Re: [patch 01/45] XFS: corruption fix Message-ID: <20060719082458.A1935136@wobbly.melbourne.sgi.com> References: <20060717160652.408007000@blue.kroah.org> <20060717162518.GB4829@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jengelh@linux01.gwdg.de on Tue, Jul 18, 2006 at 03:27:37PM +0200 X-archive-position: 8289 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: 1012 Lines: 24 On Tue, Jul 18, 2006 at 03:27:37PM +0200, Jan Engelhardt wrote: > > > >Fix nused counter. It's currently getting set to -1 rather than getting > >decremented by 1. Since nused never reaches 0, the "if (!free->hdr.nused)" > >check in xfs_dir2_leafn_remove() fails every time and xfs_dir2_shrink_inode() > >doesn't get called when it should. This causes extra blocks to be left on > >an empty directory and the directory in unable to be converted back to > >inline extent mode. > > > Is there a utility to fix such directories or will they autoshrink once the fs > is run with a 2.6.17.7? An xfs_repair is required. There is a remaining issue with repair where it cannot resolve some particular types of directory trashing, but for the most part I believe xfs_repair will resolve this (please report if not). We're working on improving the way xfs_repair deals with dir2 corruption atm, so this remaining problem (that funky dir2 offset problem, iow) I expect will shortly be resolved. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 18 15:31:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 15:31:40 -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 k6IMV1DW011707 for ; Tue, 18 Jul 2006 15:31:12 -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 IAA16499; Wed, 19 Jul 2006 08:30:20 +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 k6IMUHgw1934679; Wed, 19 Jul 2006 08:30:18 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6IMUEth1901959; Wed, 19 Jul 2006 08:30:14 +1000 (EST) Date: Wed, 19 Jul 2006 08:30:14 +1000 From: Nathan Scott To: Andrew Elwell Cc: xfs@oss.sgi.com, maciej@epcc.ed.ac.uk Subject: Re: oops with CentOS 4.3 / xfs / nfsd Message-ID: <20060719083014.B1935136@wobbly.melbourne.sgi.com> References: <1153214961.6793.15.camel@x41ade> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1153214961.6793.15.camel@x41ade>; from andrewe@epcc.ed.ac.uk on Tue, Jul 18, 2006 at 10:29:21AM +0100 X-archive-position: 8290 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: 908 Lines: 26 On Tue, Jul 18, 2006 at 10:29:21AM +0100, Andrew Elwell wrote: > Hi Folks, > > We've migrated some of our storage servers to CentOS 4.3 and are seeing > lockups. It *could* be hardware I know, and I'm scheduling downtime to > run memtest86+ ASAP. > ... > IP 172.20.0.224 > SysRq : HELP : loglevel0-8 reBoot Crash tErm kIll saK showMem powerOff showPc unRaw Sync showTasks Unmount shoWcpus > nfsd: page allocation failure. order:4, mode:0x50 This is very likely to be due to the way older versions of XFS managed incore inode extent lists. So, you've likely got a very fragmented file/files here, and XFS used to require large amounts of contiguous memory to deal with that. Your options are to take steps to combat inode extent fragmentation (like fsr), or use a more recent kernel (2.6.17+ IIRC). Oh yes, and like Joshua said, those old kernels also had 4Kstack related issues. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 18 15:36:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 15:36:54 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6IMacDW012775 for ; Tue, 18 Jul 2006 15:36:39 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6IMaCFR001957 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Jul 2006 18:36:12 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Peter Grandi Cc: Linux XFS In-Reply-To: <17595.47312.720883.451573@base.ty.sabi.co.UK> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> Content-Type: text/plain Date: Tue, 18 Jul 2006 18:36:06 -0400 Message-Id: <1153262166.2669.267.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8291 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 607 Lines: 20 Thanks for your response. But could you give me an example on what is an improper use? Ming On Mon, 2006-07-17 at 17:20 +0100, Peter Grandi wrote: > >>> On Mon, 17 Jul 2006 11:30:23 -0400, Ming Zhang > >>> said: > > mingz> Hi All We want to use XFS in all of our production > mingz> servers but feel a little scary about the corruption > mingz> problems seen in this list. [ ... ] > > XFS is complex but quite stable code. Most of the reports about > ''corruption'' are consequences of not being aware of what it > was designed for, how it works and how it should be used... > > From owner-xfs@oss.sgi.com Tue Jul 18 15:58:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 15:59:02 -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 k6IMwJDW014951 for ; Tue, 18 Jul 2006 15:58:31 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17004; Wed, 19 Jul 2006 08:57:39 +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 k6IMvXgw1938968; Wed, 19 Jul 2006 08:57:34 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6IMvVVh1939416; Wed, 19 Jul 2006 08:57:31 +1000 (EST) Date: Wed, 19 Jul 2006 08:57:31 +1000 From: Nathan Scott To: Torsten Landschoff Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060719085731.C1935136@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060718222941.GA3801@stargate.galaxy>; from torsten@debian.org on Wed, Jul 19, 2006 at 12:29:41AM +0200 X-archive-position: 8292 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: 983 Lines: 29 On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > Hi friends, Hi Torsten, > I upgraded to 2.6.18-rc1 on sunday, with the following results (taken > from my /var/log/kern.log), which ultimately led me to reinstall my > system: > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 I suspect you had some residual directory corruption from using the 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, fixed in the latest -stable point release). > of programs fail in mysterious ways. I tried to recover using xfs_repair > but I feel that my partition is thorougly borked. Of course no data was > lost due to backups but still I'd like this bug to be fixed ;-) 2.6.18-rc1 should be fine (contains the corruption fix). Did you mkfs and restore? Or at least get a full repair run? If you did, and you still see issues in .18-rc1, please let me know asap. thanks. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 18 16:11:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 16:12:02 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6INBlDW016495 for ; Tue, 18 Jul 2006 16:11:48 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G2ylm-0005Md-Ir for ; Wed, 19 Jul 2006 00:14:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17597.27469.834961.186850@base.ty.sabi.co.UK> Date: Wed, 19 Jul 2006 00:14:21 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <1153262166.2669.267.camel@localhost.localdomain> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 8293 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 1548 Lines: 37 >>> On Tue, 18 Jul 2006 18:36:06 -0400, Ming Zhang >>> said: mingz> [ .. ] example on what is an improper use? Well, this mailing list is full of them :-). However it is easier to say what is an optimal use: * A 64 bit system. * With a large, parallel storage system. * The block IO system handles all storage errors. * With backups of the contents of the storage system. In other words, an Altix in an enterprise computing room... :-) Something like 64 bit systems running a UNIX-like OS, one system production and one for backup, each with some TiB of RAID10 storage, both with UPSes giving a significant amount of uptime, and extensive hot swapping abilities. If you got that, XFS can give really good performance quite safely. My impression is that the design of XFS was based on a focus on performance, at the file system level, via on-disk layout, massive ''transactions'', and parallel IO requests, assuming that the block IO subsystem handles every storage error issue both transparently and gracefully. It is _possible_, and may even be appropriate after carefully thinking it through, to use XFS in a 32 bit system without UPS, and with no storage system redundancy, and with device errors not handled by the block IO system, and with little parallelism in the storage subsystem; e.g. a SOHO desktop or server. But then I have seen people building RAIDs stuffing in a couple dozen drives from the same shipping box, so improper use of XFS is definitely a second order issue at that kind of level :-). From owner-xfs@oss.sgi.com Tue Jul 18 16:55:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 16:55:29 -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 k6INslDW025447 for ; Tue, 18 Jul 2006 16:55:01 -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 JAA18121; Wed, 19 Jul 2006 09:54:06 +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 k6INs3gw1937229; Wed, 19 Jul 2006 09:54:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6INs00Q1937319; Wed, 19 Jul 2006 09:54:00 +1000 (EST) Date: Wed, 19 Jul 2006 09:54:00 +1000 From: Nathan Scott To: Ming Zhang Cc: xfs@oss.sgi.com Subject: Re: stable xfs Message-ID: <20060719095400.A1936041@wobbly.melbourne.sgi.com> References: <1153150223.4532.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1153150223.4532.24.camel@localhost.localdomain>; from mingz@ele.uri.edu on Mon, Jul 17, 2006 at 11:30:23AM -0400 X-archive-position: 8294 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: 1083 Lines: 31 On Mon, Jul 17, 2006 at 11:30:23AM -0400, Ming Zhang wrote: > Hi All > > We want to use XFS in all of our production servers but feel a little > scary about the corruption problems seen in this list. I wonder which > 2.6.16+ kernel we can use in order to get a stable XFS? Thanks! Use the latest 2.6.17 -stable release, or a vendor kernel (SLES is particularly good with XFS, as SGI works closely with SUSE). The current batch of corruption reports is due to one unfortunate bug that has slipped through our QA testing net, which happily is a fairly rare occurence (it was a very subtle bug). XFS also tends to get a bad rap (IMO) from the way it reports on-disk corruption and I/O errors in critical data structures, which is quite different to many other filesystems - it dumps a stack trace into the system log (alot of people mistake that for a panic) and "shuts down" the filesystem, with subsequent accesses returning errors until the problem is resolved. > ps, one friend mentioned that XFS has some issue with LVM+MD under it. > Is this true? No. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 18 18:21:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 18:21:28 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6J1LCDW001010 for ; Tue, 18 Jul 2006 18:21:13 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6J1Kn7C003917 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Jul 2006 21:20:50 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Peter Grandi Cc: Linux XFS In-Reply-To: <17597.27469.834961.186850@base.ty.sabi.co.UK> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> Content-Type: text/plain Date: Tue, 18 Jul 2006 21:20:44 -0400 Message-Id: <1153272044.2669.282.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8295 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 2118 Lines: 58 On Wed, 2006-07-19 at 00:14 +0100, Peter Grandi wrote: > >>> On Tue, 18 Jul 2006 18:36:06 -0400, Ming Zhang > >>> said: > > mingz> [ .. ] example on what is an improper use? > > Well, this mailing list is full of them :-). However it is > easier to say what is an optimal use: > > * A 64 bit system. > * With a large, parallel storage system. when u say large parallel storage system, you mean independent spindles right? but most people will have all disks configured in one RAID5/6 and thus it is not parallel any more. > * The block IO system handles all storage errors. so current MD/LVM/SATA/SCSI layers are not good enough? > * With backups of the contents of the storage system. > > In other words, an Altix in an enterprise computing room... :-) just kidding, are you a SGI sales? ;) > > Something like 64 bit systems running a UNIX-like OS, one system > production and one for backup, each with some TiB of RAID10 > storage, both with UPSes giving a significant amount of uptime, > and extensive hot swapping abilities. If you got that, XFS can > give really good performance quite safely. > > My impression is that the design of XFS was based on a focus on > performance, at the file system level, via on-disk layout, > massive ''transactions'', and parallel IO requests, assuming > that the block IO subsystem handles every storage error issue > both transparently and gracefully. > > It is _possible_, and may even be appropriate after carefully > thinking it through, to use XFS in a 32 bit system without UPS, > and with no storage system redundancy, and with device errors > not handled by the block IO system, and with little parallelism > in the storage subsystem; e.g. a SOHO desktop or server. i think with write barrier support, system without UPS should be ok. considering even u have UPS, kernel oops in other parts still can take the FS down. > > But then I have seen people building RAIDs stuffing in a couple > dozen drives from the same shipping box, so improper use of XFS > is definitely a second order issue at that kind of level :-). > > From owner-xfs@oss.sgi.com Tue Jul 18 19:23:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 19:23:31 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6J2NADW007736 for ; Tue, 18 Jul 2006 19:23:10 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6J1FxFE001149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Jul 2006 21:15:59 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Nathan Scott Cc: xfs@oss.sgi.com In-Reply-To: <20060719095400.A1936041@wobbly.melbourne.sgi.com> References: <1153150223.4532.24.camel@localhost.localdomain> <20060719095400.A1936041@wobbly.melbourne.sgi.com> Content-Type: text/plain Date: Tue, 18 Jul 2006 21:15:53 -0400 Message-Id: <1153271753.2669.276.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8296 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1336 Lines: 37 thanks a lot for this detail explanation! i will check both 2.6.17 -stable release and sles kernel. unfortunately, i only play with RHEL so far. Ming On Wed, 2006-07-19 at 09:54 +1000, Nathan Scott wrote: > On Mon, Jul 17, 2006 at 11:30:23AM -0400, Ming Zhang wrote: > > Hi All > > > > We want to use XFS in all of our production servers but feel a little > > scary about the corruption problems seen in this list. I wonder which > > 2.6.16+ kernel we can use in order to get a stable XFS? Thanks! > > Use the latest 2.6.17 -stable release, or a vendor kernel (SLES is > particularly good with XFS, as SGI works closely with SUSE). > > The current batch of corruption reports is due to one unfortunate > bug that has slipped through our QA testing net, which happily is > a fairly rare occurence (it was a very subtle bug). > > XFS also tends to get a bad rap (IMO) from the way it reports on-disk > corruption and I/O errors in critical data structures, which is quite > different to many other filesystems - it dumps a stack trace into the > system log (alot of people mistake that for a panic) and "shuts down" > the filesystem, with subsequent accesses returning errors until the > problem is resolved. > > > ps, one friend mentioned that XFS has some issue with LVM+MD under it. > > Is this true? > > No. > > cheers. > From owner-xfs@oss.sgi.com Tue Jul 18 22:56:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Jul 2006 22:56:57 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6J5ujDW001004 for ; Tue, 18 Jul 2006 22:56:46 -0700 Received: (qmail 78497 invoked from network); 19 Jul 2006 05:56:24 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 19 Jul 2006 05:56:23 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id BE290184DA45; Tue, 18 Jul 2006 22:56:21 -0700 (PDT) Date: Tue, 18 Jul 2006 22:56:21 -0700 From: Chris Wedgwood To: Ming Zhang Cc: Peter Grandi , Linux XFS Subject: Re: stable xfs Message-ID: <20060719055621.GA1491@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153272044.2669.282.camel@localhost.localdomain> X-archive-position: 8297 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: 980 Lines: 26 On Tue, Jul 18, 2006 at 09:20:44PM -0400, Ming Zhang wrote: > when u say large parallel storage system, you mean independent > spindles right? but most people will have all disks configured in > one RAID5/6 and thus it is not parallel any more. it depends, you might have 100s of spindles in groups, you don't make a giant raid5/6 array with that many disks, you make a number of smaller arrays > i think with write barrier support, system without UPS should be ok. with barrier support a UPS shouldn't be necessary > considering even u have UPS, kernel oops in other parts still can > take the FS down. but a crash won't cause writes to be 'reordered' reordering is bad because the fs pushes writes down in a manner that means when it comes back it will be able to make it self consistent, so if you have a number of writes pending and some of them are lost, and those that are lost are not the most recent writes because of reordering, you can end up with a corrupt fs From owner-xfs@oss.sgi.com Wed Jul 19 01:43:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 01:44:16 -0700 (PDT) Received: from e450.epcc.ed.ac.uk (e450.epcc.ed.ac.uk [129.215.56.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6J8hUDW028947 for ; Wed, 19 Jul 2006 01:43:33 -0700 Received: from garnet.epcc.ed.ac.uk (garnet.epcc.ed.ac.uk [129.215.56.56]) by e450.epcc.ed.ac.uk (8.13.6/8.13.6) with ESMTP id k6J7bTFX008826; Wed, 19 Jul 2006 08:37:29 +0100 (BST) Received: from garnet.epcc.ed.ac.uk (localhost [127.0.0.1]) by garnet.epcc.ed.ac.uk (8.13.6+Sun/8.12.10) with ESMTP id k6J7bSbm014771; Wed, 19 Jul 2006 08:37:28 +0100 (BST) Received: (from andrewe@localhost) by garnet.epcc.ed.ac.uk (8.13.6+Sun/8.13.6/Submit) id k6J7bSCf014770; Wed, 19 Jul 2006 08:37:28 +0100 (BST) Date: Wed, 19 Jul 2006 08:37:28 +0100 From: Andrew Elwell To: Nathan Scott Cc: xfs@oss.sgi.com, maciej@epcc.ed.ac.uk Subject: Re: oops with CentOS 4.3 / xfs / nfsd Message-ID: <20060719073728.GA14530@garnet.epcc.ed.ac.uk> References: <1153214961.6793.15.camel@x41ade> <20060719083014.B1935136@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060719083014.B1935136@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-Edinburgh-Scanned: at mailhost.epcc.ed.ac.uk X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) X-archive-position: 8298 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrewe@epcc.ed.ac.uk Precedence: bulk X-list: xfs Content-Length: 934 Lines: 27 > This is very likely to be due to the way older versions of XFS > managed incore inode extent lists. So, you've likely got a very > fragmented file/files here, and XFS used to require large amounts > of contiguous memory to deal with that. More than likely - the filesystem is exported to our Blue Gene rack so gets hammered by parallel IO constantly. Oh, and the server also exports a chunk of SATA raid out (3ware controller) as pvfs2... I guess our priority should be to try and "source" some more memory than the 512M we have in at the moment. > Your options are to take > steps to combat inode extent fragmentation (like fsr), or use a > more recent kernel (2.6.17+ IIRC). OK - we were trying to stay reasonably simple by using vendor kernels but I guess it's time for a quick "make menuconfig" Ta Andrew -- Andrew Elwell, System Administrator EPCC Tel 0131 445 7833 (ACF Building) Tel 0131 650 5023 (Rm 3309, JCMB) From owner-xfs@oss.sgi.com Wed Jul 19 02:03:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 02:04:22 -0700 (PDT) Received: from rproxy.teamix.net (team.teamix.net [194.150.191.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6J93uDW031519 for ; Wed, 19 Jul 2006 02:03:58 -0700 Received: from mango.of.teamix.net (unknown [172.21.123.1]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by rproxy.teamix.net (Postfix) with ESMTP id CF58247E1C; Wed, 19 Jul 2006 07:40:07 +0000 (UTC) From: Martin Steigerwald Organization: team(ix) GmbH To: Nathan Scott Subject: Re: stable xfs Date: Wed, 19 Jul 2006 09:40:05 +0200 User-Agent: KMail/1.9.1 Cc: Ming Zhang , xfs@oss.sgi.com References: <1153150223.4532.24.camel@localhost.localdomain> <20060719095400.A1936041@wobbly.melbourne.sgi.com> In-Reply-To: <20060719095400.A1936041@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607190940.05596.ms@teamix.de> X-archive-position: 8299 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ms@teamix.de Precedence: bulk X-list: xfs Content-Length: 960 Lines: 26 Am Mittwoch, 19. Juli 2006 01:54 schrieb Nathan Scott: > On Mon, Jul 17, 2006 at 11:30:23AM -0400, Ming Zhang wrote: > > Hi All > > > > We want to use XFS in all of our production servers but feel a little > > scary about the corruption problems seen in this list. I wonder which > > 2.6.16+ kernel we can use in order to get a stable XFS? Thanks! > > Use the latest 2.6.17 -stable release, or a vendor kernel (SLES is > particularly good with XFS, as SGI works closely with SUSE). Hello Nathan, as far as I can see the fix for kernel bug #6757 has not yet made it in a stable kernel release upto 2.6.17.6 and thus should manually be applied: http://bugzilla.kernel.org/show_bug.cgi?id=6757 It probably doesn't happen for lots of people but I would still apply that patch unless it is finally put into a stable point release. Regards, -- Martin Steigerwald - team(ix) GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 From owner-xfs@oss.sgi.com Wed Jul 19 02:13:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 02:13:52 -0700 (PDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6J9DLDW032657 for ; Wed, 19 Jul 2006 02:13:22 -0700 Received: from [192.168.1.63] (195-112-44-96.dyn.gotadsl.co.uk [195.112.44.96]) by smtp.nildram.co.uk (Postfix) with ESMTP id 380B823716E; Wed, 19 Jul 2006 09:08:00 +0100 (BST) From: Alistair John Strachan To: Nathan Scott Subject: Re: XFS breakage in 2.6.18-rc1 Date: Wed, 19 Jul 2006 09:08:30 +0100 User-Agent: KMail/1.9.3 Cc: Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> In-Reply-To: <20060719085731.C1935136@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607190908.30727.s0348365@sms.ed.ac.uk> X-archive-position: 8300 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: s0348365@sms.ed.ac.uk Precedence: bulk X-list: xfs Content-Length: 954 Lines: 25 On Tuesday 18 July 2006 23:57, Nathan Scott wrote: [snip] > > of programs fail in mysterious ways. I tried to recover using xfs_repair > > but I feel that my partition is thorougly borked. Of course no data was > > lost due to backups but still I'd like this bug to be fixed ;-) > > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > mkfs and restore? Or at least get a full repair run? If you did, > and you still see issues in .18-rc1, please let me know asap. Just out of interest, I've got a few XFS volumes that were created 24 months ago on a machine that I upgraded to 2.6.17 about a month ago. I haven't seen any crashes so far. Assuming I get the newest XFS repair tools on there, what's the disadvantage of repairing versus creating a new filesystem? What special circumstances are required to cause a crash? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. From owner-xfs@oss.sgi.com Wed Jul 19 02:26:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 02:26:55 -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 k6J9QDDW002077 for ; Wed, 19 Jul 2006 02:26:26 -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 TAA29477; Wed, 19 Jul 2006 19:25:39 +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 k6J9PGEo32451774; Wed, 19 Jul 2006 19:25:17 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6J9PErG32441978; Wed, 19 Jul 2006 19:25:14 +1000 (AEST) Date: Wed, 19 Jul 2006 19:25:14 +1000 (AEST) From: Timothy Shimmin Message-Id: <200607190925.k6J9PErG32441978@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 954372 - xfs EA list callback functionality + namespace abstractions X-archive-position: 8301 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1328 Lines: 35 Add EA list callbacks for xfs kernel use. Cleanup some namespace code. Date: Wed Jul 19 19:19:40 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-linux Inspected by: nathans@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26583a xfs_attr_leaf.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h - Some namespace macros and additional fields for the EA list context. xfs_attr_leaf.c - 1.103 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h - Add calls to EA list callback. Allow callback to be given a value as well as a name. Allow callback to indicate that the list iteration should finish early allowing to be used for searching. Abstract some namespace operations to simplify code for additions of more namespaces if needed. xfs_attr.c - 1.139 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.139&r2=text&tr2=1.138&f=h - Add EA list callbacks. xfs_attr.h - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h - Some prototype additions. From owner-xfs@oss.sgi.com Wed Jul 19 03:21:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 03:22:08 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JALcDW008804 for ; Wed, 19 Jul 2006 03:21:53 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G39E3-0000Pz-UN for ; Wed, 19 Jul 2006 11:24:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17598.2129.999932.67127@base.ty.sabi.co.UK> Date: Wed, 19 Jul 2006 11:24:17 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <1153272044.2669.282.camel@localhost.localdomain> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 8302 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 1025 Lines: 36 >>> On Tue, 18 Jul 2006 21:20:44 -0400, Ming Zhang said: [ ... ] mingz> when u say large parallel storage system, you mean mingz> independent spindles right? but most people will have all mingz> disks configured in one RAID5/6 and thus it is not mingz> parallel any more. As I was saying... pg> Most of the reports about ''corruption'' are consequences pg> of not being aware of what it was designed for, how it pg> works and how it should be used... mingz> [ .. ] example on what is an improper use? pg> Well, this mailing list is full of them :-). pg> But then I have seen people building RAIDs stuffing in a pg> couple dozen drives from the same shipping box, [ ... ] :-) BTW as to these: * A 64 bit system. * With a large, parallel storage system. * The block IO system handles all storage errors. * With backups of the contents of the storage system. I forgot a very essential one: * With lots of RAM, size proportional to that of the largest filesystem. [ ... ] From owner-xfs@oss.sgi.com Wed Jul 19 03:33:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 03:33:57 -0700 (PDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JAXfDW010519 for ; Wed, 19 Jul 2006 03:33:41 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G39Mg-000399-3V for linux-xfs@oss.sgi.com; Wed, 19 Jul 2006 03:33:14 -0700 Message-ID: <5393901.post@talk.nabble.com> Date: Wed, 19 Jul 2006 03:33:13 -0700 (PDT) From: Cosmo Nova To: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation In-Reply-To: <20060718213304.GA27287@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: cs_mcc98@hotmail.com X-Nabble-From: Cosmo Nova References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> <43311567.3060208@tlinx.org> <5356806.post@talk.nabble.com> <20060717141917.GY2114946@melbourne.sgi.com> <5374022.post@talk.nabble.com> <20060718213304.GA27287@tuatara.stupidest.org> X-archive-position: 8303 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cs_mcc98@hotmail.com Precedence: bulk X-list: xfs Content-Length: 904 Lines: 18 If there are AG locks, but multiple files can write in the same AG, how "AG lock" is interpreted by XFS then? What does it really do? For pre-allocation and delayed allocation, do they belong to the feature set of XFS? Or are they application dependant? I am trying to compare filesystems, especially xfs vs jfs. I found that jfs's per AG locking would only allow one file to be written per AG, which helps a lot to prevent fragmentation (according to experiment results). There're no pre-allocation and delayed allocation in JFS though. Comparing the experiment results, XFS is doing a good job, giving 6-10 fragments (compare to majority of single fragment in JFS...). So answers of the above questions with numbers would help a lot. Thanks! -- View this message in context: http://www.nabble.com/file-system-defragmentation-tf255485.html#a5393901 Sent from the Xfs - General forum at Nabble.com. From owner-xfs@oss.sgi.com Wed Jul 19 03:51:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 03:51:55 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JApiDW012911 for ; Wed, 19 Jul 2006 03:51:45 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G39gC-0000zR-Vx for ; Wed, 19 Jul 2006 11:53:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <17598.3876.565887.172598@base.ty.sabi.co.UK> Date: Wed, 19 Jul 2006 11:53:24 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <20060719055621.GA1491@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <20060719055621.GA1491@tuatara.stupidest.org> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k6JApjDW012917 X-archive-position: 8304 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 2877 Lines: 73 [ ... ] mingz> when u say large parallel storage system, you mean mingz> independent spindles right? but most people will have all mingz> disks configured in one RAID5/6 and thus it is not parallel mingz> any more. cw> it depends, you might have 100s of spindles in groups, you cw> don't make a giant raid5/6 array with that many disks, you cw> make a number of smaller arrays Perhaps you are undestimating the ''if it can be done'' mindset... Also, if one does a number of smaller RAID5s, is each one a separate filesystem or they get aggregated, for example with LVM with ''concat''? Either way, how likely is is that the consequences have been thought through? I would personally hesitate to recommend either, especially a two-level arrangement where the base level is a RAID5. [I am making an effort in this discussion to use euphemisms] mingz> i think with write barrier support, system without UPS mingz> should be ok. cw> with barrier support a UPS shouldn't be necessary Sure, «should» and «shouldn't» are nice hopeful concepts. But write barriers are difficult to achieve, and when achieved they are often unreliable, except on enterprise level hardware, because many disks/host adapters/... simply lie as to whether they have actually started writing (never mind finished writing, or written correctly) stuff. To get reliable write barrier often one has to source special cards or disks with custom firmware; or leave system integration to the big expensive guys and buy an Altix or equivalent system from Sun or IBM. Besides I have seen many reports of ''corruption'' that cannot be fixed by write barriers: many have the expectation that *data* should not be lost, even if no 'fsync' is done, *as if* 'mount -o sync' or 'mount -o data=ordered'. Of course that is a bit of an inflated expectation, but all that the vast majority of sysadms care about is whether it ''just works'', without ''wasting time'' figuring things out. mingz> considering even u have UPS, kernel oops in other parts mingz> still can take the FS down. cw> but a crash won't cause writes to be 'reordered' [ ... ] The metadata will be consistent, but metadata and data may well will be lost. So the filesystem is still ''corrupted'', at least from the point of view of a sysadm who just wants the filesystem to be effortlessly foolproof. Anyhow, if a crash happens all bets are off, because who knows *what* gets written. Look at it from the point of view of a ''practitioner'' sysadm: ''who cares if the metadata is consistent, if my 3TiB application database is unusable (and I don't do backups because after all it is a concat of RAID5s, backups are not necessary) as there is a huge gap in some data file, and my users are yelling at me, and it is not my fault'' The tradeoff in XFS is that if you know exactly what you are doing you get extra performance... From owner-xfs@oss.sgi.com Wed Jul 19 04:23:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 04:23:42 -0700 (PDT) Received: from pqueuea.post.tele.dk (pqueuea.post.tele.dk [193.162.153.9]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JBN7DW022094 for ; Wed, 19 Jul 2006 04:23:08 -0700 Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by pqueuea.post.tele.dk (Postfix) with ESMTP id 1A39537601E for ; Wed, 19 Jul 2006 12:21:13 +0200 (CEST) Received: from redeeman.kaspersandberg.com (kaspersandberg.com [80.164.32.14]) by pfepc.post.tele.dk (Postfix) with ESMTP id AC72A8A0052; Wed, 19 Jul 2006 12:21:05 +0200 (CEST) Subject: Re: XFS breakage in 2.6.18-rc1 From: Kasper Sandberg To: Nathan Scott Cc: Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060719085731.C1935136@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> Content-Type: text/plain Date: Wed, 19 Jul 2006 12:21:08 +0200 Message-Id: <1153304468.3706.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-archive-position: 8305 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lkml@metanurb.dk Precedence: bulk X-list: xfs Content-Length: 1278 Lines: 35 On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > Hi friends, > > Hi Torsten, > > > I upgraded to 2.6.18-rc1 on sunday, with the following results (taken > > from my /var/log/kern.log), which ultimately led me to reinstall my > > system: > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > I suspect you had some residual directory corruption from using the > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > fixed in the latest -stable point release). This has me very worried. i just upgraded to .18-rc1-git5 when it came out, i used .17-rc3 before. does this mean my .17-rc3 may have corrupted my filesystem? what action do you suggest i do now? > > > of programs fail in mysterious ways. I tried to recover using xfs_repair > > but I feel that my partition is thorougly borked. Of course no data was > > lost due to backups but still I'd like this bug to be fixed ;-) > > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > mkfs and restore? Or at least get a full repair run? If you did, > and you still see issues in .18-rc1, please let me know asap. > > thanks. > From owner-xfs@oss.sgi.com Wed Jul 19 06:11:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 06:11:51 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JDBcDW001709 for ; Wed, 19 Jul 2006 06:11:38 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6JDBFr2015169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Jul 2006 09:11:16 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Peter Grandi Cc: Linux XFS In-Reply-To: <17598.2129.999932.67127@base.ty.sabi.co.UK> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> Content-Type: text/plain Date: Wed, 19 Jul 2006 09:11:10 -0400 Message-Id: <1153314670.2691.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8306 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1280 Lines: 47 On Wed, 2006-07-19 at 11:24 +0100, Peter Grandi wrote: > >>> On Tue, 18 Jul 2006 21:20:44 -0400, Ming Zhang said: > > [ ... ] > > mingz> when u say large parallel storage system, you mean > mingz> independent spindles right? but most people will have all > mingz> disks configured in one RAID5/6 and thus it is not > mingz> parallel any more. > > As I was saying... > > pg> Most of the reports about ''corruption'' are consequences > pg> of not being aware of what it was designed for, how it > pg> works and how it should be used... > > mingz> [ .. ] example on what is an improper use? > pg> Well, this mailing list is full of them :-). > > pg> But then I have seen people building RAIDs stuffing in a > pg> couple dozen drives from the same shipping box, [ ... ] > > :-) > > BTW as to these: > > * A 64 bit system. > * With a large, parallel storage system. > * The block IO system handles all storage errors. > * With backups of the contents of the storage system. > > I forgot a very essential one: > > * With lots of RAM, size proportional to that of the largest filesystem. > > [ ... ] > what kind of "ram vs fs" size ratio here will be a safe/good/proper one? any rule of thumb? thanks! hope not 1:1. :) Ming From owner-xfs@oss.sgi.com Wed Jul 19 06:43:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 06:43:49 -0700 (PDT) Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JDhHDW006279 for ; Wed, 19 Jul 2006 06:43:18 -0700 Received: from [10.0.0.6] (84-51-141-144.itis099.adsl.metronet.co.uk [84.51.141.144]) by mail.metronet.co.uk (MetroNet Mail) with ESMTP id C2B1074AAE; Wed, 19 Jul 2006 13:43:24 +0100 (BST) From: Alistair John Strachan To: Kasper Sandberg Subject: Re: XFS breakage in 2.6.18-rc1 Date: Wed, 19 Jul 2006 13:43:33 +0100 User-Agent: KMail/1.9.3 Cc: Nathan Scott , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> In-Reply-To: <1153304468.3706.4.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607191343.33502.s0348365@sms.ed.ac.uk> X-archive-position: 8308 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: s0348365@sms.ed.ac.uk Precedence: bulk X-list: xfs Content-Length: 1931 Lines: 51 On Wednesday 19 July 2006 11:21, Kasper Sandberg wrote: > On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > > Hi friends, > > > > Hi Torsten, > > > > > I upgraded to 2.6.18-rc1 on sunday, with the following results (taken > > > from my /var/log/kern.log), which ultimately led me to reinstall my > > > system: > > > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > > > I suspect you had some residual directory corruption from using the > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > fixed in the latest -stable point release). > > This has me very worried. > > i just upgraded to .18-rc1-git5 when it came out, i used .17-rc3 before. > does this mean my .17-rc3 may have corrupted my filesystem? > > what action do you suggest i do now? > > > > of programs fail in mysterious ways. I tried to recover using > > > xfs_repair but I feel that my partition is thorougly borked. Of course > > > no data was lost due to backups but still I'd like this bug to be fixed > > > ;-) > > > > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > > mkfs and restore? Or at least get a full repair run? If you did, > > and you still see issues in .18-rc1, please let me know asap. > > > > thanks. According to another thread Nathan just responded to, it sounds like we need to wait for a new version of the xfsprogs package, and then run xfs_repair on the affected filesystems. I wouldn't worry about it too much if you've not had any crashes. The damage can be repaired, just not right now. I'm still waiting for a crash on a machine that has been under heavy load for 28 days, so it's obviously not _that_ easy to trigger. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. From owner-xfs@oss.sgi.com Wed Jul 19 07:11:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 07:12:19 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JEBwDW009644 for ; Wed, 19 Jul 2006 07:11:58 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6JEBZaq012390 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Jul 2006 10:11:36 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Martin Steigerwald Cc: Nathan Scott , xfs@oss.sgi.com In-Reply-To: <200607190940.05596.ms@teamix.de> References: <1153150223.4532.24.camel@localhost.localdomain> <20060719095400.A1936041@wobbly.melbourne.sgi.com> <200607190940.05596.ms@teamix.de> Content-Type: text/plain Date: Wed, 19 Jul 2006 10:11:30 -0400 Message-Id: <1153318290.2691.46.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8310 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 979 Lines: 28 yes. thx for reminding. Ming On Wed, 2006-07-19 at 09:40 +0200, Martin Steigerwald wrote: > Am Mittwoch, 19. Juli 2006 01:54 schrieb Nathan Scott: > > On Mon, Jul 17, 2006 at 11:30:23AM -0400, Ming Zhang wrote: > > > Hi All > > > > > > We want to use XFS in all of our production servers but feel a little > > > scary about the corruption problems seen in this list. I wonder which > > > 2.6.16+ kernel we can use in order to get a stable XFS? Thanks! > > > > Use the latest 2.6.17 -stable release, or a vendor kernel (SLES is > > particularly good with XFS, as SGI works closely with SUSE). > > Hello Nathan, > > as far as I can see the fix for kernel bug #6757 has not yet made it in a > stable kernel release upto 2.6.17.6 and thus should manually be applied: > > http://bugzilla.kernel.org/show_bug.cgi?id=6757 > > It probably doesn't happen for lots of people but I would still apply that > patch unless it is finally put into a stable point release. > > Regards, From owner-xfs@oss.sgi.com Wed Jul 19 07:11:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 07:11:26 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JEB7DW009520 for ; Wed, 19 Jul 2006 07:11:07 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6JEAB0Z011607 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Jul 2006 10:10:12 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Chris Wedgwood Cc: Peter Grandi , Linux XFS In-Reply-To: <20060719055621.GA1491@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <20060719055621.GA1491@tuatara.stupidest.org> Content-Type: text/plain Date: Wed, 19 Jul 2006 10:10:06 -0400 Message-Id: <1153318206.2691.43.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8309 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1157 Lines: 33 On Tue, 2006-07-18 at 22:56 -0700, Chris Wedgwood wrote: > On Tue, Jul 18, 2006 at 09:20:44PM -0400, Ming Zhang wrote: > > > when u say large parallel storage system, you mean independent > > spindles right? but most people will have all disks configured in > > one RAID5/6 and thus it is not parallel any more. > > it depends, you might have 100s of spindles in groups, you don't make > a giant raid5/6 array with that many disks, you make a number of > smaller arrays right > > > i think with write barrier support, system without UPS should be ok. > > with barrier support a UPS shouldn't be necessary > > > considering even u have UPS, kernel oops in other parts still can > > take the FS down. > i mean with UPS and huge write cache, but no write barrier. > but a crash won't cause writes to be 'reordered' > > > reordering is bad because the fs pushes writes down in a manner that > means when it comes back it will be able to make it self consistent, > so if you have a number of writes pending and some of them are lost, > and those that are lost are not the most recent writes because of > reordering, you can end up with a corrupt fs From owner-xfs@oss.sgi.com Wed Jul 19 07:45:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 07:45:43 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JEjWDW013834 for ; Wed, 19 Jul 2006 07:45:33 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6JEjAw4030781 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Jul 2006 10:45:10 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Peter Grandi Cc: Linux XFS In-Reply-To: <17598.3876.565887.172598@base.ty.sabi.co.UK> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <20060719055621.GA1491@tuatara.stupidest.org> <17598.3876.565887.172598@base.ty.sabi.co.UK> Content-Type: text/plain; charset=utf-8 Date: Wed, 19 Jul 2006 10:45:04 -0400 Message-Id: <1153320304.2691.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8311 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 3397 Lines: 90 On Wed, 2006-07-19 at 11:53 +0100, Peter Grandi wrote: > [ ... ] > > mingz> when u say large parallel storage system, you mean > mingz> independent spindles right? but most people will have all > mingz> disks configured in one RAID5/6 and thus it is not parallel > mingz> any more. > > cw> it depends, you might have 100s of spindles in groups, you > cw> don't make a giant raid5/6 array with that many disks, you > cw> make a number of smaller arrays > > Perhaps you are undestimating the ''if it can be done'' > mindset... > > Also, if one does a number of smaller RAID5s, is each one a > separate filesystem or they get aggregated, for example with > LVM with ''concat''? Either way, how likely is is that the > consequences have been thought through? > > I would personally hesitate to recommend either, especially a > two-level arrangement where the base level is a RAID5. could u give us some hints on this? since it is really popular to have a FS/LV/MD structure and I believe LVM is designed for this purpose. > > [I am making an effort in this discussion to use euphemisms] > > mingz> i think with write barrier support, system without UPS > mingz> should be ok. > > cw> with barrier support a UPS shouldn't be necessary > > Sure, «should» and «shouldn't» are nice hopeful concepts. > > But write barriers are difficult to achieve, and when achieved > they are often unreliable, except on enterprise level hardware, > because many disks/host adapters/... simply lie as to whether > they have actually started writing (never mind finished writing, > or written correctly) stuff. > > To get reliable write barrier often one has to source special > cards or disks with custom firmware; or leave system integration > to the big expensive guys and buy an Altix or equivalent system > from Sun or IBM. > > Besides I have seen many reports of ''corruption'' that cannot > be fixed by write barriers: many have the expectation that > *data* should not be lost, even if no 'fsync' is done, *as if* > 'mount -o sync' or 'mount -o data=ordered'. > > Of course that is a bit of an inflated expectation, but all that > the vast majority of sysadms care about is whether it ''just > works'', without ''wasting time'' figuring things out. > > mingz> considering even u have UPS, kernel oops in other parts > mingz> still can take the FS down. > > cw> but a crash won't cause writes to be 'reordered' [ ... ] > > The metadata will be consistent, but metadata and data may well > will be lost. So the filesystem is still ''corrupted'', at least > from the point of view of a sysadm who just wants the filesystem > to be effortlessly foolproof. Anyhow, if a crash happens all > bets are off, because who knows *what* gets written. > > Look at it from the point of view of a ''practitioner'' sysadm: > > ''who cares if the metadata is consistent, if my 3TiB > application database is unusable (and I don't do backups > because after all it is a concat of RAID5s, backups are not > necessary) as there is a huge gap in some data file, and my > users are yelling at me, and it is not my fault'' > > The tradeoff in XFS is that if you know exactly what you are > doing you get extra performance... then i think unless you disable all write cache, none of the file system can achieve this goal. or maybe ext3 with both data and metadata into log might do this? Ming From owner-xfs@oss.sgi.com Wed Jul 19 08:25:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 08:26:29 -0700 (PDT) Received: from pqueueb.post.tele.dk (pqueueb.post.tele.dk [193.162.153.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JFPuDW022291 for ; Wed, 19 Jul 2006 08:25:58 -0700 Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by pqueueb.post.tele.dk (Postfix) with ESMTP id 43F603DE238 for ; Wed, 19 Jul 2006 17:25:34 +0200 (CEST) Received: from redeeman.kaspersandberg.com (kaspersandberg.com [80.164.32.14]) by pfepb.post.tele.dk (Postfix) with ESMTP id 06347A5000E; Wed, 19 Jul 2006 17:25:26 +0200 (CEST) Subject: Re: XFS breakage in 2.6.18-rc1 From: Kasper Sandberg To: Alistair John Strachan Cc: Nathan Scott , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <200607191343.33502.s0348365@sms.ed.ac.uk> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <200607191343.33502.s0348365@sms.ed.ac.uk> Content-Type: text/plain Date: Wed, 19 Jul 2006 17:25:26 +0200 Message-Id: <1153322726.25089.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-archive-position: 8312 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lkml@metanurb.dk Precedence: bulk X-list: xfs Content-Length: 2235 Lines: 53 On Wed, 2006-07-19 at 13:43 +0100, Alistair John Strachan wrote: > On Wednesday 19 July 2006 11:21, Kasper Sandberg wrote: > > On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > > > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > > > Hi friends, > > > > > > Hi Torsten, > > > > > > > I upgraded to 2.6.18-rc1 on sunday, with the following results (taken > > > > from my /var/log/kern.log), which ultimately led me to reinstall my > > > > system: > > > > > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > > > > > I suspect you had some residual directory corruption from using the > > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > > fixed in the latest -stable point release). > > > > This has me very worried. > > > > i just upgraded to .18-rc1-git5 when it came out, i used .17-rc3 before. > > does this mean my .17-rc3 may have corrupted my filesystem? > > > > what action do you suggest i do now? > > > > > > of programs fail in mysterious ways. I tried to recover using > > > > xfs_repair but I feel that my partition is thorougly borked. Of course > > > > no data was lost due to backups but still I'd like this bug to be fixed > > > > ;-) > > > > > > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > > > mkfs and restore? Or at least get a full repair run? If you did, > > > and you still see issues in .18-rc1, please let me know asap. > > > > > > thanks. > > According to another thread Nathan just responded to, it sounds like we need > to wait for a new version of the xfsprogs package, and then run xfs_repair on > the affected filesystems. I wouldn't worry about it too much if you've not > had any crashes. The damage can be repaired, just not right now. without ANY loss? because even though it would be abit painful for me to do, i do have the option of smashing in a new drive, copy everything, and reinitialize my filesystem. > > I'm still waiting for a crash on a machine that has been under heavy load for > 28 days, so it's obviously not _that_ easy to trigger. so basically if i upgrade to a safe kernel before i do get these errors, im good? > From owner-xfs@oss.sgi.com Wed Jul 19 13:42:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 13:42:20 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JKg6DW027068 for ; Wed, 19 Jul 2006 13:42:06 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 8946E607BFA9; Wed, 19 Jul 2006 16:41:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 835E716172EC3 for ; Wed, 19 Jul 2006 16:41:41 -0400 (EDT) Date: Wed, 19 Jul 2006 16:41:41 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com Subject: The XFS bug of death 16777216. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8314 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 143 Lines: 5 Anyone have an FAQ for this? I am currently running 2.6.17.3 and am not [yet] affected, what triggers this bug? Will it be fixed in 2.6.18? From owner-xfs@oss.sgi.com Wed Jul 19 15:21:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 15:22:48 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JMLpDW003991 for ; Wed, 19 Jul 2006 15:21:51 -0700 Received: from [84.141.41.232] (helo=stargate.galaxy) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1G3JMp1zEv-00021I; Wed, 19 Jul 2006 23:14:03 +0200 Received: by stargate.galaxy (Postfix, from userid 1000) id C8ED218074; Wed, 19 Jul 2006 23:14:02 +0200 (CEST) Date: Wed, 19 Jul 2006 23:14:02 +0200 From: Torsten Landschoff To: Nathan Scott Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060719211402.GA1133@stargate.galaxy> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20060719085731.C1935136@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:d638a0eb9c9fbc21c426336ab6dfa19b X-archive-position: 8315 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: torsten@debian.org Precedence: bulk X-list: xfs Content-Length: 1201 Lines: 42 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Nathan,=20 On Wed, Jul 19, 2006 at 08:57:31AM +1000, Nathan Scott wrote: =20 > I suspect you had some residual directory corruption from using the > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > fixed in the latest -stable point release). That probably the cause of my problem. Thanks for the info! BTW: I think there was nothing important on the broken filesystems, but I'd like to keep what's still there anyway just in case... How would you suggest should I copy that data? I fear, just mounting and using cp=20 might break and shutdown the FS again, would xfsdump be more appropriate? Thanks for XFS, I am using it for years in production servers! Greetings Torsten --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEvqCadQgHtVUb5EcRAoJLAJ4jJaYRxbnNVCEZBJuki2kTz2VtQwCfd2Mq 9BasGncq2cRLpRTp5wU9EMM= =NS5n -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-xfs@oss.sgi.com Wed Jul 19 15:57:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 15:58:09 -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 k6JMvPDW007576 for ; Wed, 19 Jul 2006 15:57:39 -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 IAA14853; Thu, 20 Jul 2006 08:56:47 +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 k6JMuggw1967081; Thu, 20 Jul 2006 08:56:43 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6JMuaXN1960691; Thu, 20 Jul 2006 08:56:36 +1000 (EST) Date: Thu, 20 Jul 2006 08:56:36 +1000 From: Nathan Scott To: Alistair John Strachan Cc: Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060720085636.D1947140@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <200607190908.30727.s0348365@sms.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200607190908.30727.s0348365@sms.ed.ac.uk>; from s0348365@sms.ed.ac.uk on Wed, Jul 19, 2006 at 09:08:30AM +0100 X-archive-position: 8316 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: 1171 Lines: 28 On Wed, Jul 19, 2006 at 09:08:30AM +0100, Alistair John Strachan wrote: > On Tuesday 18 July 2006 23:57, Nathan Scott wrote: > [snip] > > > of programs fail in mysterious ways. I tried to recover using xfs_repair > > > but I feel that my partition is thorougly borked. Of course no data was > > > lost due to backups but still I'd like this bug to be fixed ;-) > > > > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > > mkfs and restore? Or at least get a full repair run? If you did, > > and you still see issues in .18-rc1, please let me know asap. > > Just out of interest, I've got a few XFS volumes that were created 24 months > ago on a machine that I upgraded to 2.6.17 about a month ago. I haven't seen > any crashes so far. > > Assuming I get the newest XFS repair tools on there, what's the disadvantage > of repairing versus creating a new filesystem? What special circumstances are > required to cause a crash? There should be no disadvantage to repairing. I will update the FAQ shortly to describe all the details of the problem, recommendations on how to address it, which kernel version is affected, etc. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jul 19 16:00:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 16:00:29 -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 k6JMxmDW007848 for ; Wed, 19 Jul 2006 15:59:59 -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 IAA14907; Thu, 20 Jul 2006 08:59: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 k6JMx8gw1960385; Thu, 20 Jul 2006 08:59:09 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6JMx4t71963640; Thu, 20 Jul 2006 08:59:04 +1000 (EST) Date: Thu, 20 Jul 2006 08:59:04 +1000 From: Nathan Scott To: Kasper Sandberg Cc: Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060720085904.E1947140@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1153304468.3706.4.camel@localhost>; from lkml@metanurb.dk on Wed, Jul 19, 2006 at 12:21:08PM +0200 X-archive-position: 8317 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: 1155 Lines: 33 On Wed, Jul 19, 2006 at 12:21:08PM +0200, Kasper Sandberg wrote: > On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > > Hi friends, > > > > Hi Torsten, > > > > > I upgraded to 2.6.18-rc1 on sunday, with the following results (taken > > > from my /var/log/kern.log), which ultimately led me to reinstall my > > > system: > > > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > > > I suspect you had some residual directory corruption from using the > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > fixed in the latest -stable point release). > This has me very worried. > > i just upgraded to .18-rc1-git5 when it came out, i used .17-rc3 before. > does this mean my .17-rc3 may have corrupted my filesystem? > > what action do you suggest i do now? The odds are decent that you're unaffected. You can check your filesystem using xfs_check or xfs_repair -n and these will give you a good indication as to whether further action is required. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jul 19 16:02:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 16:02:37 -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 k6JN1nDW008261 for ; Wed, 19 Jul 2006 16:02:00 -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 JAA15050; Thu, 20 Jul 2006 09:01: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 k6JN1Dgw1966121; Thu, 20 Jul 2006 09:01:14 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6JN19uO1967055; Thu, 20 Jul 2006 09:01:09 +1000 (EST) Date: Thu, 20 Jul 2006 09:01:09 +1000 From: Nathan Scott To: "Jeffrey E. Hundstad" Cc: Mattias Hedenskog , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060720090109.F1947140@wobbly.melbourne.sgi.com> References: <67dc30140607190717r57ed2fe5w719dcca896110d8@mail.gmail.com> <44BE48D5.7020107@mnsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44BE48D5.7020107@mnsu.edu>; from jeffrey.hundstad@mnsu.edu on Wed, Jul 19, 2006 at 09:59:33AM -0500 X-archive-position: 8318 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: 446 Lines: 14 On Wed, Jul 19, 2006 at 09:59:33AM -0500, Jeffrey E. Hundstad wrote: > I did try the xfs_repair 2.8.4 for a volume running on 2.6.17.4 and it > annihilated the volume. This volume was not showing signs of crashing. > So... I guess I would certainly not run xfs_repair unless there is good > reason. Erm, wha..? Can you expand on "annihilated" a bit? (please send me the full xfs_repair output if you still have it). thanks. -- Nathan From owner-xfs@oss.sgi.com Wed Jul 19 16:10:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 16:11:12 -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 k6JNAUDW010450 for ; Wed, 19 Jul 2006 16:10:44 -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 JAA15215; Thu, 20 Jul 2006 09:09:51 +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 k6JN9lgw1966491; Thu, 20 Jul 2006 09:09:48 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6JN9j6X1964133; Thu, 20 Jul 2006 09:09:45 +1000 (EST) Date: Thu, 20 Jul 2006 09:09:45 +1000 From: Nathan Scott To: Torsten Landschoff Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060720090945.G1947140@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <20060719211402.GA1133@stargate.galaxy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060719211402.GA1133@stargate.galaxy>; from torsten@debian.org on Wed, Jul 19, 2006 at 11:14:02PM +0200 X-archive-position: 8319 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: 1162 Lines: 30 On Wed, Jul 19, 2006 at 11:14:02PM +0200, Torsten Landschoff wrote: > On Wed, Jul 19, 2006 at 08:57:31AM +1000, Nathan Scott wrote: > > I suspect you had some residual directory corruption from using the > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > fixed in the latest -stable point release). > > That probably the cause of my problem. Thanks for the info! > > BTW: I think there was nothing important on the broken filesystems, but > I'd like to keep what's still there anyway just in case... How would you > suggest should I copy that data? I fear, just mounting and using cp > might break and shutdown the FS again, would xfsdump be more > appropriate? Yeah, xfsdumps not a bad idea, the interfaces it uses may well be able to avoid the cases that trigger shutdown. Otherwise it is a case of identifying the problem directory inode (the inum is reported in the shutdown trace) and avoiding that path when cp'ing - you can match inum to path via xfs_ncheck. > Thanks for XFS, I am using it for years in production servers! Thanks for the kind words, they're much appreciated at times like these. :-] cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jul 19 16:41:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 16:41:56 -0700 (PDT) Received: from mx2.suse.de (ns2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6JNfXDW018737 for ; Wed, 19 Jul 2006 16:41:35 -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 mx2.suse.de (Postfix) with ESMTP id 3D34E1F0FE; Thu, 20 Jul 2006 01:41:05 +0200 (CEST) From: Neil Brown To: David Chinner Date: Wed, 19 Jul 2006 09:41:31 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17597.29099.110370.121220@cse.unsw.edu.au> Cc: Nathan Scott , xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: XFS and write barrier In-Reply-To: message from David Chinner on Wednesday July 19 References: <200607151248.56603.Martin@lichtvoll.de> <20060716173238.GD3417@free.net.ph> <20060718173122.B1914501@wobbly.melbourne.sgi.com> <17596.41680.124148.595601@cse.unsw.edu.au> <20060718170406.GT15160733@melbourne.sgi.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-face: v[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D On Tue, Jul 18, 2006 at 06:58:56PM +1000, Neil Brown wrote: > > On Tuesday July 18, nathans@sgi.com wrote: > > > On Mon, Jul 17, 2006 at 01:32:38AM +0800, Federico Sevilla III wrote: > > > > On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: > > > > > I am currently gathering information to write an article about journal > > > > > filesystems with emphasis on write barrier functionality, how it > > > > > works, why journalling filesystems need write barrier and the current > > > > > implementation of write barrier support for different filesystems. > > > > "Journalling filesystems need write barrier" isn't really accurate. > > They can make good use of write barrier if it is supported, and where > > it isn't supported, they should use blkdev_issue_flush in combination > > with regular submit/wait. > > blkdev_issue_flush() causes a write cache flush - just like a > barrier typically causes a write cache flush up to the I/O with the > barrier in it. Both of these mechanisms provide the same thing - an > I/O barrier that enforces ordering of I/Os to disk. > > Given that filesystems already indicate to the block layer when they > want a barrier, wouldn't it be better to get the block layer to issue > this cache flush if the underlying device doesn't support barriers > and it receives a barrier request? A barrier means a lot more than just a flush. It means wait for all proceeding requests to commit flush write this request flush Any block device that uses the io scheduler could probably manage this. Other block devices might not find it so easy. > > Any particular reason for not supporting barriers on the other types > of RAID? > Imagine trying to implement barriers for raid0 (or any level with striping). You would need to block new requests wait for all requests to all devices to complete issue a flush to all devices issue the barrier request to the target device issue a flush to the target device permit new requests. This means raid0 would need to keep track of all pending requests, which it doesn't do. As the filesystem does, it is just as efficient to let the filesystem to the work. I guess raid0 could - block new requests - submit a no-op barrier to all devices - wait for the no-op to complete - submit the write/barrier request - permit new requests. This would avoid needing to keep track of all requests. However I don't think the Linux block layer supports a no-op barrer, and I don't think this would actually be better than not supporting barriers. The real value of barriers (as far as I can see) is that the target device can understand them so you don't need to stall the queue of requests flying over the buss to the device. If you need to stall the flow of requests and wait at the OS level, then the value of barriers disappears and you may as well wait in the filesystem code. At least, that is my understanding. I am happy to be educated. NeilBrown From owner-xfs@oss.sgi.com Wed Jul 19 17:19:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 17:20:15 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6K0JvDW022620 for ; Wed, 19 Jul 2006 17:19:58 -0700 Received: by ug-out-1314.google.com with SMTP id h2so544207ugf for ; Wed, 19 Jul 2006 17:19:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=lmYAyL6sjx45AF3mVeiYG2LTmT2L3pd0xUTJF7ntIn5y4Ub40TL9A8pNQvX217BDaQcGLq8Gv+YGXwuGV9tiIPIfWREm1cybVPMiQjMx9eGR7BxFwqfQL0Zc2Eb6MddBr1wqLLhNhybqozSqJ3Hh5QgESsZcCJ17+I8v1cP/NL8= Received: by 10.78.167.12 with SMTP id p12mr719570hue; Wed, 19 Jul 2006 14:31:15 -0700 (PDT) Received: by 10.78.159.14 with HTTP; Wed, 19 Jul 2006 14:31:14 -0700 (PDT) Message-ID: <68559cef0607191431m4b59e142v51e1c1dc12e60dc0@mail.gmail.com> Date: Wed, 19 Jul 2006 23:31:15 +0200 From: "Luca Maranzano" To: xfs@oss.sgi.com Subject: XFS: possible memory allocation deadlock in _pagebuf_lookup_pages (mode:0x250) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 8321 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liuk001@gmail.com Precedence: bulk X-list: xfs Content-Length: 950 Lines: 31 Hello all, we have a CentOS 4.3 Server on an HP DL 380G3, 1 Xeon 2,8 Ghz (no hyperthreading). Kernel: 2.6.9-34.0.2.EL Xfs: xfsprogs-2.7.3-1 kernel-module-xfs-2.6.9-34.EL-0.1-3 modinfo xfs: filename: /lib/modules/2.6.9-34.0.2.EL/extra/xfs.ko author: Silicon Graphics, Inc. description: SGI-XFS CVS-2004-10-17_05:00_UTC with ACLs, security attributes, realtime, large block numbers, no debug enabled license: GPL vermagic: 2.6.9-34.EL 686 REGPARM 4KSTACKS gcc-3.4 depends: The server has 1 Emulex Lp9002 with 3 LUNs of our SAN. 2 LUNs are forming a Striped LVM2 volume of 2,7 TB. 1 LUN is an LVM2 volume of 1,5 TB. The message appeared during moderately heavy load copying 700GB from one LVM to the other LVM (serveral thousands of I/O on the HBA). Apparently it's still working fine, but we are a bit worried about this message. Do you suggest some upgrade of the Kernel or the xfs modules? TIA. Kind regards, Luca From owner-xfs@oss.sgi.com Wed Jul 19 18:57:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 18:57:34 -0700 (PDT) Received: from avalanche.hickorytech.net (smtp.hickorytech.net [216.114.192.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6K1v7DW031656 for ; Wed, 19 Jul 2006 18:57:12 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by avalanche.hickorytech.net (Postfix) with ESMTP id 31048204FA4; Wed, 19 Jul 2006 19:48:20 -0500 (CDT) Received: from avalanche.hickorytech.net ([216.114.192.16]) by localhost (avalanche.hickorytech.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNoc-GjM3nVY; Wed, 19 Jul 2006 19:48:20 -0500 (CDT) Received: from [10.0.0.7] (mn-10k-dhcp2-220.dsl.hickorytech.net [216.114.240.220]) by avalanche.hickorytech.net (Postfix) with ESMTP id E4EF3204F9F; Wed, 19 Jul 2006 19:48:19 -0500 (CDT) Message-ID: <44BF19DA.9060403@mnsu.edu> Date: Thu, 20 Jul 2006 00:51:22 -0500 From: Jeffrey Hundstad User-Agent: Thunderbird 1.5.0.4 (X11/20060713) MIME-Version: 1.0 To: Nathan Scott Cc: Mattias Hedenskog , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 References: <67dc30140607190717r57ed2fe5w719dcca896110d8@mail.gmail.com> <44BE48D5.7020107@mnsu.edu> <20060720090109.F1947140@wobbly.melbourne.sgi.com> In-Reply-To: <20060720090109.F1947140@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8322 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: xfs Content-Length: 1068 Lines: 29 Nathan Scott wrote: > On Wed, Jul 19, 2006 at 09:59:33AM -0500, Jeffrey E. Hundstad wrote: > >> I did try the xfs_repair 2.8.4 for a volume running on 2.6.17.4 and it >> annihilated the volume. This volume was not showing signs of crashing. >> So... I guess I would certainly not run xfs_repair unless there is good >> reason. >> > > Erm, wha..? Can you expand on "annihilated" a bit? (please send > me the full xfs_repair output if you still have it). > Nathan Scott, I'm very sorry; I don't have the output anymore. By annihilated I mean that there were several directories trees that /didn't work/. If you tried to cd into the directory or take a directory listing... or used a file that you knew was in these certain directories then you'd get pages of debug message to the console; and no usable data. I re-ran xfs_repair and retried several times but the condition never seemed to improve or get worse for that matter. I /incorrectly/ figured it was a known issue or I'd have saved the output. Sorry again. -- Jeffrey Hundstad From owner-xfs@oss.sgi.com Wed Jul 19 21:24:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 21:24:17 -0700 (PDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6K4O3DW018069 for ; Wed, 19 Jul 2006 21:24:04 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G3Q4c-0003Il-2P for linux-xfs@oss.sgi.com; Wed, 19 Jul 2006 21:23:42 -0700 Message-ID: <5408752.post@talk.nabble.com> Date: Wed, 19 Jul 2006 21:23:42 -0700 (PDT) From: Cosmo Nova To: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation In-Reply-To: <20050828034108.73921.qmail@web34103.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: cs_mcc98@hotmail.com X-Nabble-From: Cosmo Nova References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43112C5D.8090202@sgi.com> <20050828034108.73921.qmail@web34103.mail.mud.yahoo.com> X-archive-position: 8324 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cs_mcc98@hotmail.com Precedence: bulk X-list: xfs Content-Length: 295 Lines: 7 what is the maximum tolerance for the delayed allocations pls? I guess it's not possible to buf a GB size file and delay its allocation? -- View this message in context: http://www.nabble.com/file-system-defragmentation-tf255485.html#a5408752 Sent from the Xfs - General forum at Nabble.com. From owner-xfs@oss.sgi.com Wed Jul 19 21:22:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 21:22:37 -0700 (PDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6K4MMDW017793 for ; Wed, 19 Jul 2006 21:22:22 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G3Q2y-0003Gz-5K for linux-xfs@oss.sgi.com; Wed, 19 Jul 2006 21:22:00 -0700 Message-ID: <5408744.post@talk.nabble.com> Date: Wed, 19 Jul 2006 21:22:00 -0700 (PDT) From: Cosmo Nova To: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation In-Reply-To: <20050829001723.GA10587@xiao.rsnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: cs_mcc98@hotmail.com X-Nabble-From: Cosmo Nova References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43112C5D.8090202@sgi.com> <20050829001723.GA10587@xiao.rsnet> X-archive-position: 8323 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cs_mcc98@hotmail.com Precedence: bulk X-list: xfs Content-Length: 250 Lines: 7 does the preallocation belong to xfs layer? or it's a "suggested feature" for applications? -- View this message in context: http://www.nabble.com/file-system-defragmentation-tf255485.html#a5408744 Sent from the Xfs - General forum at Nabble.com. From owner-xfs@oss.sgi.com Wed Jul 19 23:03:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 23:03:50 -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 k6K63LDW029805 for ; Wed, 19 Jul 2006 23:03:32 -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 QAA23106 for ; Thu, 20 Jul 2006 16:02:48 +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 k6K62MEo32327937 for ; Thu, 20 Jul 2006 16:02:22 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6K62Lsp32974694 for linux-xfs@oss.sgi.com; Thu, 20 Jul 2006 16:02:21 +1000 (AEST) Date: Thu, 20 Jul 2006 16:02:21 +1000 (AEST) From: Timothy Shimmin Message-Id: <200607200602.k6K62Lsp32974694@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: xfs FAQ update for write cache X-archive-position: 8325 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 203 Lines: 8 Modid: current:xfs-website:212892a faq.html - 1.88 - changed - Update info about write cache. Mention persistent write cache, external logs, checking it was actually enabled in xfs msgs. --Tim From owner-xfs@oss.sgi.com Wed Jul 19 23:12:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 23:12:43 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6K6CXDW031260 for ; Wed, 19 Jul 2006 23:12:33 -0700 Received: (qmail 13838 invoked from network); 20 Jul 2006 06:12:10 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2006 06:12:10 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 6A69A184DA2D; Wed, 19 Jul 2006 23:12:09 -0700 (PDT) Date: Wed, 19 Jul 2006 23:12:09 -0700 From: Chris Wedgwood To: Peter Grandi Cc: Linux XFS Subject: Re: stable xfs Message-ID: <20060720061209.GA18135@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <20060719055621.GA1491@tuatara.stupidest.org> <17598.3876.565887.172598@base.ty.sabi.co.UK> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17598.3876.565887.172598@base.ty.sabi.co.UK> X-archive-position: 8326 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: 1351 Lines: 35 On Wed, Jul 19, 2006 at 11:53:24AM +0100, Peter Grandi wrote: > But write barriers are difficult to achieve, and when achieved they > are often unreliable, except on enterprise level hardware, because > many disks/host adapters/... simply lie as to whether they have > actually started writing (never mind finished writing, or written > correctly) stuff. IDE/SATA doesn't have barrier to lie about (the kernel has to flush and wait in those cases). > The metadata will be consistent, but metadata and data may well will > be lost. So the filesystem is still ''corrupted'', at least from the > point of view of a sysadm who just wants the filesystem to be > effortlessly foolproof. Sanely written applications shouldn't lose data. > Look at it from the point of view of a ''practitioner'' sysadm: > > ''who cares if the metadata is consistent, if my 3TiB > application database is unusable (and I don't do backups any sane database should be safe, it will fsync or similar as needed this is also true for sane MTAs i've actually tested sitations where transactions were in flight and i've dropped power on a rack of disks and verified that when it came up all transactions that we claimed to have completed really did i've also done lesser things will SATA disks and email and it usually turns out to also be reliable for the most part From owner-xfs@oss.sgi.com Wed Jul 19 23:15:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Jul 2006 23:16:05 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6K6FsDW032196 for ; Wed, 19 Jul 2006 23:15:54 -0700 Received: (qmail 44245 invoked from network); 20 Jul 2006 06:15:29 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2006 06:15:28 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id EDFF7184DA2D; Wed, 19 Jul 2006 23:15:27 -0700 (PDT) Date: Wed, 19 Jul 2006 23:15:27 -0700 From: Chris Wedgwood To: Ming Zhang Cc: Peter Grandi , Linux XFS Subject: Re: stable xfs Message-ID: <20060720061527.GB18135@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153314670.2691.14.camel@localhost.localdomain> X-archive-position: 8327 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: 618 Lines: 20 On Wed, Jul 19, 2006 at 09:11:10AM -0400, Ming Zhang wrote: > what kind of "ram vs fs" size ratio here will be a safe/good/proper > one? it depends very much on what you are doing > any rule of thumb? thanks! > > hope not 1:1. :) i recent dealt with a corrupted filesystem that xfs_repair needed over 1GB to deal with --- the kicker is the filesystem was only 20GB, so that's 20:1 for xfs_repair i suspect that was anomalous though and that some bug or quirk of their fs cause xfs_repair to behave badly (that said, i'd had to have to repair an 8TB fs fill of maildir email boxes, which i know some people have) From owner-xfs@oss.sgi.com Thu Jul 20 00:14:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 00:14:45 -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 k6K7E0DW008069 for ; Thu, 20 Jul 2006 00:14:12 -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 RAA24219; Thu, 20 Jul 2006 17:13:21 +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 k6K7DHgw1975966; Thu, 20 Jul 2006 17:13:17 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6K7DAM11977042; Thu, 20 Jul 2006 17:13:10 +1000 (EST) Date: Thu, 20 Jul 2006 17:13:10 +1000 From: Nathan Scott To: Kasper Sandberg , Justin Piszcz , Torsten Landschoff Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: FAQ updated (was Re: XFS breakage...) Message-ID: <20060720171310.B1970528@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1153304468.3706.4.camel@localhost>; from lkml@metanurb.dk on Wed, Jul 19, 2006 at 12:21:08PM +0200 X-archive-position: 8328 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: 840 Lines: 27 On Wed, Jul 19, 2006 at 12:21:08PM +0200, Kasper Sandberg wrote: > On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > > > I suspect you had some residual directory corruption from using the > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > fixed in the latest -stable point release). Correction there - no -stable exists with this yet, I guess that'll be 2.6.17.7 once its out though. > what action do you suggest i do now? I've captured the state of this issue here, with options and ways to correct the problem: http://oss.sgi.com/projects/xfs/faq.html#dir2 Hope this helps. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 00:50:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 00:50:15 -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 k6K7njDW016633 for ; Thu, 20 Jul 2006 00:49:59 -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 QAA23891 for ; Thu, 20 Jul 2006 16:48:54 +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 k6K6mSEo31699685 for ; Thu, 20 Jul 2006 16:48:29 +1000 (AEST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6K6mSUg33101176 for linux-xfs@oss.sgi.com; Thu, 20 Jul 2006 16:48:28 +1000 (AEST) Date: Thu, 20 Jul 2006 16:48:28 +1000 (AEST) From: Nathan Scott Message-Id: <200607200648.k6K6mSUg33101176@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - faq.html X-archive-position: 8329 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 440 Lines: 14 Update the FAQ regarding dir2 corruption in 2.6.17. Date: Wed Jul 19 23:48:34 PDT 2006 Workarea: snort.melbourne.sgi.com:/home/nathans/isms/us-xfs-website Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-website/current Modid: current:xfs-website:212893a faq.html - 1.89 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/faq.html.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h From owner-xfs@oss.sgi.com Thu Jul 20 00:56:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 00:56:26 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6K7u6DW017449 for ; Thu, 20 Jul 2006 00:56:12 -0700 Received: from localhost (dslb-084-056-078-084.pools.arcor-ip.net [84.56.78.84]) by mondschein.lichtvoll.de (Postfix) with ESMTP id D040CFA8A6 for ; Thu, 20 Jul 2006 09:53:05 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: xfs FAQ update for write cache Date: Thu, 20 Jul 2006 09:55:35 +0200 User-Agent: KMail/1.9.3 References: <200607200602.k6K62Lsp32974694@snort.melbourne.sgi.com> In-Reply-To: <200607200602.k6K62Lsp32974694@snort.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607200955.36136.Martin@lichtvoll.de> X-archive-position: 8330 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 2031 Lines: 49 Am Donnerstag 20 Juli 2006 08:02 schrieb Timothy Shimmin: > Modid: current:xfs-website:212892a > faq.html - 1.88 - changed > - Update info about write cache. > Mention persistent write cache, external logs, > checking it was actually enabled in xfs msgs. Hello Thimothy, thanks a lot... thats awesome... I have that directory corruption problem also mentioned in the FAQ on a workstation at work. When you have a new xfs_check available I can test it. (I know how to compile it under Knoppix 5 ;-). A little feedback: lines are not wrapped in either Firefox or Konqueror (http://oss.sgi.com/projects/xfs/faq.html). This is for the complete FAQ. It makes reading it difficult. It might make sense to include the log messages when barriers are disabled at the approbiate places of the FAQ: root@deepdance:/usr/src/linux/fs/xfs -> grep -ir "barrier" * linux-2.6/xfs_super.c:xfs_mountfs_check_barriers(xfs_mount_t *mp) linux-2.6/xfs_super.c: "Disabling barriers, not supported with external log device"); linux-2.6/xfs_super.c: mp->m_flags &= ~XFS_MOUNT_BARRIER; linux-2.6/xfs_super.c: "Disabling barriers, not supported by the underlying device"); linux-2.6/xfs_super.c: mp->m_flags &= ~XFS_MOUNT_BARRIER; linux-2.6/xfs_super.c: error = xfs_barrier_test(mp); linux-2.6/xfs_super.c: "Disabling barriers, trial barrier write failed"); linux-2.6/xfs_super.c: mp->m_flags &= ~XFS_MOUNT_BARRIER; While they are quite self-explanatory it might still help to make it absolutely clear what each log message mean. Is the last one "Disabling barriers, trial barrier write failed" issued when the underlying device does not support write barriers? It would be good to know which drivers do and which don't but thats more of a kernel FAQ regarding write barrier support. Its probably best to test for oneself and use the logs ;-) Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Jul 20 00:58:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 00:58:42 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6K7wVDW017906 for ; Thu, 20 Jul 2006 00:58:32 -0700 Received: from localhost (dslb-084-056-078-084.pools.arcor-ip.net [84.56.78.84]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 78DC8FA8A6 for ; Thu, 20 Jul 2006 09:55:36 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: FAQ updated (was Re: XFS breakage...) Date: Thu, 20 Jul 2006 09:58:07 +0200 User-Agent: KMail/1.9.3 References: <20060718222941.GA3801@stargate.galaxy> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> In-Reply-To: <20060720171310.B1970528@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607200958.07706.Martin@lichtvoll.de> X-archive-position: 8331 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 658 Lines: 25 Am Donnerstag 20 Juli 2006 09:13 schrieb Nathan Scott: > > what action do you suggest i do now? > > I've captured the state of this issue here, with options and ways > to correct the problem: > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > Hope this helps. Hello Nathan, thanks a lot. If you need anyone to test a new xfs_repair let me know. I have a partition which that kind of corruption at hand and can compile a new xfs_repair under Knoppix 5. If you do not need any additional testers I will fix it the manual way. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Jul 20 02:44:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 02:44:19 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms1.lichtvoll.de [194.150.191.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6K9i6DW030403 for ; Thu, 20 Jul 2006 02:44:09 -0700 Received: from localhost (dslb-084-056-078-084.pools.arcor-ip.net [84.56.78.84]) by mondschein.lichtvoll.de (Postfix) with ESMTP id B6A0EFA8A6 for ; Thu, 20 Jul 2006 11:41:10 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: How does XFS handle file data with regards to journaling? Date: Thu, 20 Jul 2006 11:43:40 +0200 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607201143.40984.Martin@lichtvoll.de> X-archive-position: 8332 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 684 Lines: 21 Hello, AFAIK XFS does not support real data journaling. But when does it write changes to file data? Does ist write it before or after it updates the journal? IOW does it support ordered writes as ext3 does? data=ordered (*) All data are forced directly out to the main file system prior to its metadata being committed to the journal. Or does it work in writeback mode? data=writeback Data ordering is not preserved, data may be written into the main file system after its metadata has been committed to the journal. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Jul 20 03:06:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 03:06:17 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KA61DW001318 for ; Thu, 20 Jul 2006 03:06:01 -0700 Received: from localhost (dslb-084-056-078-084.pools.arcor-ip.net [84.56.78.84]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 705A5FA8A6 for ; Thu, 20 Jul 2006 12:03:03 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Question on the WriteCache / WriteBarrier FAQ entry Date: Thu, 20 Jul 2006 12:05:34 +0200 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607201205.34750.Martin@lichtvoll.de> X-archive-position: 8333 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1912 Lines: 45 Hello, I try to fully understand this entry: "Many drives use a write back cache in order to speed up the performance of writes. However, there are conditions such as power failure when the write cache memory is never flushed to the actual disk. This causes problems for XFS and journaled filesystems in general because they rely on knowing when a write has completed to the disk. They need to know that the log information has made it to disk before allowing metadata to go to disk. When the metadata makes it to disk then the tail of the log can move. So if the writes never make it to the physical disk, then the ordering is violated and the log and metadata can be lost, resulting in filesystem corruption." I have problems with: "When the metadata makes it to disk then the tail of the log can move". What does that mean exactly? What I imagine is this: XFS write transaction to its log and the log grows. When writing the meta data changes of a complete transaction XFS removes it from the log. Now when the metadata changes of a transaction has been written completely but the transaction itself has not, it may happen that a transaction is removed from the on disk log before it has been written. But even when this does not happen there are metadata changes on disk that the log doesn't know about. So there are two situations where unordered writes can make a journalling filesystem corrupt: 1) Metadata make it to disk before the transaction that belongs to them => There are metadata changes that XFS doesn't know about. 2) A transaction might be deleted from the log before it has been written => This leads to a corrupted log. Is that correct and complete? Please give feedback. You may use any of my text here to update / clarify the FAQ ;-) Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Jul 20 03:29:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 03:30:16 -0700 (PDT) Received: from pqueuea.post.tele.dk (pqueuea.post.tele.dk [193.162.153.9]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KATXDW004620 for ; Thu, 20 Jul 2006 03:29:34 -0700 Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by pqueuea.post.tele.dk (Postfix) with ESMTP id DEE17375DDA for ; Thu, 20 Jul 2006 12:29:08 +0200 (CEST) Received: from redeeman.kaspersandberg.com (kaspersandberg.com [80.164.32.14]) by pfepb.post.tele.dk (Postfix) with ESMTP id 78392A5002F; Thu, 20 Jul 2006 12:29:03 +0200 (CEST) Subject: Re: XFS breakage in 2.6.18-rc1 From: Kasper Sandberg To: Nathan Scott Cc: Alistair John Strachan , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060720085636.D1947140@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <200607190908.30727.s0348365@sms.ed.ac.uk> <20060720085636.D1947140@wobbly.melbourne.sgi.com> Content-Type: text/plain Date: Thu, 20 Jul 2006 12:29:02 +0200 Message-Id: <1153391342.31822.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-archive-position: 8334 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lkml@metanurb.dk Precedence: bulk X-list: xfs Content-Length: 1494 Lines: 33 On Thu, 2006-07-20 at 08:56 +1000, Nathan Scott wrote: > On Wed, Jul 19, 2006 at 09:08:30AM +0100, Alistair John Strachan wrote: > > On Tuesday 18 July 2006 23:57, Nathan Scott wrote: > > [snip] > > > > of programs fail in mysterious ways. I tried to recover using xfs_repair > > > > but I feel that my partition is thorougly borked. Of course no data was > > > > lost due to backups but still I'd like this bug to be fixed ;-) > > > > > > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > > > mkfs and restore? Or at least get a full repair run? If you did, > > > and you still see issues in .18-rc1, please let me know asap. > > > > Just out of interest, I've got a few XFS volumes that were created 24 months > > ago on a machine that I upgraded to 2.6.17 about a month ago. I haven't seen > > any crashes so far. > > > > Assuming I get the newest XFS repair tools on there, what's the disadvantage > > of repairing versus creating a new filesystem? What special circumstances are > > required to cause a crash? > > There should be no disadvantage to repairing. I will update the FAQ > shortly to describe all the details of the problem, recommendations > on how to address it, which kernel version is affected, etc. this FAQ, is it this: http://oss.sgi.com/projects/xfs/faq.html#dir2 ? (btw, it seems that while only in the TOC once, you have the same about 2.6.17 twice..).. which version of xfsprogs should i use while doing the xfs_check ? > > cheers. > From owner-xfs@oss.sgi.com Thu Jul 20 03:35:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 03:35:22 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms1.lichtvoll.de [194.150.191.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KAZ7DW005487 for ; Thu, 20 Jul 2006 03:35:11 -0700 Received: from localhost (dslb-084-056-078-084.pools.arcor-ip.net [84.56.78.84]) by mondschein.lichtvoll.de (Postfix) with ESMTP id D4E9FFA8A6 for ; Thu, 20 Jul 2006 12:32:10 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Date: Thu, 20 Jul 2006 12:34:41 +0200 User-Agent: KMail/1.9.3 References: <200607151248.56603.Martin@lichtvoll.de> <200607182027.49648.Martin@lichtvoll.de> <20060718192135.GV15160733@melbourne.sgi.com> In-Reply-To: <20060718192135.GV15160733@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607201234.42293.Martin@lichtvoll.de> X-archive-position: 8335 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 2459 Lines: 66 Am Dienstag 18 Juli 2006 21:21 schrieb David Chinner: > > Hello David, > > > > well now it gets interesting. If both provide the same thing, whats > > the difference? > > A WRITE_BARRIER I/O can be optimised by smart drivers, protocols and > hardware to minimise the adverse effects of the barrier, whereas a > cache flush is a brute force cache cleaning mechanism that cannot be > optimised.... Hello David, Thanks for your answer. I think now I understand it: The driver and the drive does a cache flush immediately, but they can delay a write barrier related cache flush as long as they make sure that they has completed all of the io requests before the write barrier and none of the io requests after the write barrier. The smart driver of a smart drive that supports ordered requests may additionally offload request ordering from the operating system to the drive. > > Does a device need to support more than this cache flush in order to > > support barriers? Up to know I thought that when a device supports > > cache flushes the kernel can provide barrier functinality for it. > > Not necessarily as different device/protocol commands are used. Do you have any specific information link about this one? AFAIK it should be possible to implement barrier functionality in the driver as soon as the drive supports cache flushes. According to what I understand from Documentation/block/barriers.txt, this is this case. That would be "iii. Devices which have queue depth of 1. This is a degenerate case of ii. Just keeping issue order suffices. Ancient SCSI controllers/drives and IDE drives are in this category." in combination with this one: "iii. Write-back cache and flush operation but no FUA (forced unit access). We need two cache flushes - before and after the barrier request." The number of cache flushes can be reduced to one if FUA is used: "iv. Write-back cache, flush operation and FUA. We still need one flush to make sure requests preceding a barrier are written to medium, but post-barrier flush can be avoided by using FUA write on the barrier itself." And then there are drives with queue depth greater 1 with support or do not support ordered requests. Ah, I think I finally got all of this and have a complete picture. Lets see whether I can put that into a diagram or what ;-). Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Jul 20 06:52:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 06:52:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KDpxDW003138 for ; Thu, 20 Jul 2006 06:52:00 -0700 Received: from [84.169.81.65] (helo=lisa) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1G3Xrz3X2h-0005YW; Thu, 20 Jul 2006 14:43:12 +0200 Received: from localhost (localhost [127.0.0.1]) by tyrex.lisa.loc (Postfix) with ESMTP id 75266F06CFFC; Thu, 20 Jul 2006 14:43:11 +0200 (CEST) From: Hans-Peter Jansen To: Nathan Scott Subject: Re: FAQ updated (was Re: XFS breakage...) Date: Thu, 20 Jul 2006 14:42:57 +0200 User-Agent: KMail/1.9.3 Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20060718222941.GA3801@stargate.galaxy> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> In-Reply-To: <20060720171310.B1970528@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607201442.58416.hpj@urpla.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:18d01dd0a2a377f0376b761557b5e99a X-archive-position: 8337 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hpj@urpla.net Precedence: bulk X-list: xfs Content-Length: 578 Lines: 16 Hi Nathan, Am Donnerstag, 20. Juli 2006 09:13 schrieb Nathan Scott: > > I've captured the state of this issue here, with options and ways > to correct the problem: > http://oss.sgi.com/projects/xfs/faq.html#dir2 Thanks for the pointer. I think, it is valuable for all XFS users, but reading the FAQ with a decent webbrowser on linux (konqueror 3.5.3 and firefox 1.5.0.4 in my case) is very painful, due to the overlong lines, not to speak of printing such texts. Try yourself: load that page into konqueror, hit print, select preview and 'have fun', hmm, suffer.. Pete From owner-xfs@oss.sgi.com Thu Jul 20 07:09:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 07:09:18 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KE8xDW005151 for ; Thu, 20 Jul 2006 07:08:59 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6KE8S4j003325 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Jul 2006 10:08:28 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Chris Wedgwood Cc: Peter Grandi , Linux XFS In-Reply-To: <20060720061527.GB18135@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> Content-Type: text/plain Date: Thu, 20 Jul 2006 10:08:22 -0400 Message-Id: <1153404502.2768.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8338 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1305 Lines: 44 On Wed, 2006-07-19 at 23:15 -0700, Chris Wedgwood wrote: > On Wed, Jul 19, 2006 at 09:11:10AM -0400, Ming Zhang wrote: > > > what kind of "ram vs fs" size ratio here will be a safe/good/proper > > one? > > it depends very much on what you are doing we mainly handle large media files like 20-50GB. so file number is not too much. but file size is large. hope i never need to run repair, but i do need to defrag from time to time. > > > any rule of thumb? thanks! > > > > hope not 1:1. :) > > i recent dealt with a corrupted filesystem that xfs_repair needed over > 1GB to deal with --- the kicker is the filesystem was only 20GB, so > that's 20:1 for xfs_repair hope this does not hold true for a 15x750GB SATA raid5. ;) > > i suspect that was anomalous though and that some bug or quirk of > their fs cause xfs_repair to behave badly (that said, i'd had to have > to repair an 8TB fs fill of maildir email boxes, which i know some > people have) ps, also another question brought up while reading this thread. say XFS can make use of parallel storage by using multiple allocation groups. but XFS need to be built over one block device. so if i have 4 smaller raid, i have to use LVM to glue them before i create XFS over it right? but then u said XFS over LVM or N MD is not good? Ming From owner-xfs@oss.sgi.com Thu Jul 20 07:51:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 07:52:27 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KEptDW009819 for ; Thu, 20 Jul 2006 07:51:57 -0700 Received: from localhost.localdomain (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 4EE2AE70A1; Thu, 20 Jul 2006 14:25:10 +0100 (BST) Received: from [10.0.0.90] (helo=[10.0.0.90]) by localhost.localdomain with esmtp (Exim 4.50) id 1G3YZs-0000wT-CD; Thu, 20 Jul 2006 14:28:32 +0100 Message-ID: <44BF8500.1010708@dgreaves.com> Date: Thu, 20 Jul 2006 14:28:32 +0100 From: David Greaves User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Nathan Scott Cc: Kasper Sandberg , Justin Piszcz , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, cw@f00f.org, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> In-Reply-To: <20060720171310.B1970528@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8339 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Content-Length: 1821 Lines: 67 Nathan Scott wrote: > Correction there - no -stable exists with this yet, I guess that'll > be 2.6.17.7 once its out though. > >> what action do you suggest i do now? > > I've captured the state of this issue here, with options and ways > to correct the problem: > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > Hope this helps. It does, thanks :) Does this problem exist in 2.16.6.x?? From various comments like: Unless 2.6.16.x is a dead-end could we please also have this patch put into there? and a result (I believe) of the corruption bug that was in 2.6.16/17. and I just want to confirm this bug as well and unfortunately it was my system disk too who had to take the hit. Im running 2.6.16 I assume it does. But the FAQ says: Q: What is the issue with directory corruption in Linux 2.6.17? In the Linux kernel 2.6.17 release a subtle bug... which implies it's not... HELP So given this is from 2.6.16.9: /* * One less used entry in the free table. */ INT_MOD(free->hdr.nused, ARCH_CONVERT, -1); xfs_dir2_free_log_header(tp, fbp); and it looks awfully similar to the patch which says: --- linux-2.6.17.2.orig/fs/xfs/xfs_dir2_node.c +++ linux-2.6.17.2/fs/xfs/xfs_dir2_node.c @@ -970,7 +970,7 @@ xfs_dir2_leafn_remove( /* * One less used entry in the free table. */ - free->hdr.nused = cpu_to_be32(-1); + be32_add(&free->hdr.nused, -1); xfs_dir2_free_log_header(tp, fbp); Should 2.6.16.x replace INT_MOD(free->hdr.nused, ARCH_CONVERT, -1); with be32_add(&free->hdr.nused, -1); I hope so because I assumed there simply wasn't a patch for 2.6.16 and applied this 'best guess' to my servers and rebooted/remounted successfully. David -- From owner-xfs@oss.sgi.com Thu Jul 20 08:38:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 08:38:43 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KFcVDW019140 for ; Thu, 20 Jul 2006 08:38:32 -0700 Received: by nf-out-0910.google.com with SMTP id a27so484580nfc for ; Thu, 20 Jul 2006 08:38:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=UZwpRfSNY1UHuh1ssHVFrQM5gNMAE01PfK099j/qoLb8+6B91zHjF9aGFPmNHB28FDSYYFi+YrHQFOxf8BKqyhxqAZgufIV/Y2Y+H1UOIm5HIDp62W9/51XXI/rxS0WJ717jJGOsZECOrellJRqzojrFBSCpLH/ubcATFJ6jXTA= Received: by 10.48.162.15 with SMTP id k15mr665545nfe; Thu, 20 Jul 2006 07:38:30 -0700 (PDT) Received: by 10.49.57.8 with HTTP; Thu, 20 Jul 2006 07:38:27 -0700 (PDT) Message-ID: Date: Thu, 20 Jul 2006 15:38:27 +0100 From: "Roger Willcocks" To: linux-xfs@oss.sgi.com Subject: preallocate near a specified block MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_44296_19539042.1153406307636" X-archive-position: 8340 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: willcor@gmail.com Precedence: bulk X-list: xfs Content-Length: 8361 Lines: 161 ------=_Part_44296_19539042.1153406307636 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi folks, I've put together a 'preallocate near' ioctl, which I've been using in anger for several months now. The changes are pretty minimal, and boil down to making xfs_bmap think it's extending a file instead of doing an initial allocation. From a user perspective it's a simple extension of the existing RESVSP ioctl, with the flag bits (allocate near, allocate contiguous) hidden in the 'whence' parameter. xfs_flock64_t flck; memset(&flck, 0, sizeof(flck)); flck.l_whence = SEEK_SET; flck.l_start = 0LL; flck.l_len = (off64_t)extent; if (nearToBlock != 0) { flck.l_whence |= RESV_NEAR | RESV_CONTIG; /* if possible */ flck.l_near = nearToBlock; } int status = ioctl(fd, XFS_IOC_RESVSP64, &flck); Any interest? -- Roger ------=_Part_44296_19539042.1153406307636 Content-Type: application/octet-stream; name="xfs_near.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xfs_near.patch" X-Attachment-Id: file0 ZGlmZiAtdXJiIGxpbnV4LTIuNi4xNi4xNi5vcmlnL2ZzL3hmcy94ZnNfYm1h cC5jIGxpbnV4LTIuNi4xNi4xNi9mcy94ZnMveGZzX2JtYXAuYwotLS0gbGlu dXgtMi42LjE2LjE2Lm9yaWcvZnMveGZzL3hmc19ibWFwLmMJMjAwNi0wNS0x MSAwMjo1NjoyNC4wMDAwMDAwMDAgKzAxMDAKKysrIGxpbnV4LTIuNi4xNi4x Ni9mcy94ZnMveGZzX2JtYXAuYwkyMDA2LTA3LTIwIDE0OjM5OjQzLjAwMDAw MDAwMCArMDEwMApAQCAtMjY4OCwxMiArMjY4OCwxMyBAQAogCQkgKiB1bmRl cmx5aW5nIGxvZ2ljYWwgdm9sdW1lIG1hbmFnZXIgaXMgYSBzdHJpcGUsIGFu ZAogCQkgKiB0aGUgZmlsZSBvZmZzZXQgaXMgemVybyB0aGVuIHRyeSB0byBh bGxvY2F0ZSBkYXRhCiAJCSAqIGJsb2NrcyBvbiBzdHJpcGUgdW5pdCBib3Vu ZGFyeS4KLQkJICogTk9URTogYXAtPmFlb2YgaXMgb25seSBzZXQgaWYgdGhl IGFsbG9jYXRpb24gbGVuZ3RoCisJCSAqIE5PVEU6IGFwLT5hZW9mID09IDEg aWYgdGhlIGFsbG9jYXRpb24gbGVuZ3RoCiAJCSAqIGlzID49IHRoZSBzdHJp cGUgdW5pdCBhbmQgdGhlIGFsbG9jYXRpb24gb2Zmc2V0IGlzCi0JCSAqIGF0 IHRoZSBlbmQgb2YgZmlsZS4KKwkJICogYXQgdGhlIGVuZCBvZiBmaWxlLiBh cC0+YWVvZiA9PSAyIGlmIHdlIHdhbnQgdG8KKwkJICogZm9yY2UgYW4gYWxs b2NhdGlvbiBhdCBhIHNwZWNpZmljIGJsb2NrLgogCQkgKi8KIAkJaWYgKCFh cC0+bG93ICYmIGFwLT5hZW9mKSB7Ci0JCQlpZiAoIWFwLT5vZmYpIHsKKwkJ CWlmICghYXAtPm9mZiAmJiBhcC0+YWVvZiA9PSAxKSB7CiAJCQkJYXJncy5h bGlnbm1lbnQgPSBtcC0+bV9kYWxpZ247CiAJCQkJYXR5cGUgPSBhcmdzLnR5 cGU7CiAJCQkJaXNhbGlnbmVkID0gMTsKQEAgLTQ3NjQsNyArNDc2NSw3IEBA CiAJCQkJZmlyc3RibG9jaywgdG90YWwsICZsb2dmbGFncywgd2hpY2hmb3Jr KSkpCiAJCQlnb3RvIGVycm9yMDsKIAl9Ci0JaWYgKHdyICYmICpmaXJzdGJs b2NrID09IE5VTExGU0JMT0NLKSB7CisJaWYgKHdyICYmICgqZmlyc3RibG9j ayA9PSBOVUxMRlNCTE9DSyB8fCAoZmxhZ3MgJiBYRlNfQk1BUElfTkVBUikg IT0gMCkpIHsKIAkJaWYgKFhGU19JRk9SS19GT1JNQVQoaXAsIHdoaWNoZm9y aykgPT0gWEZTX0RJTk9ERV9GTVRfQlRSRUUpCiAJCQltaW5sZWZ0ID0gYmUx Nl90b19jcHUoaWZwLT5pZl9icm9vdC0+YmJfbGV2ZWwpICsgMTsKIAkJZWxz ZQpAQCAtNDk0Nyw3ICs0OTQ4LDEwIEBACiAJCQkJICogZW9mIGlmIGl0IGlz IHVzZXJkYXRhIGFuZCBhbGxvY2F0aW9uIGxlbmd0aAogCQkJCSAqIGlzIGxh cmdlciB0aGFuIGEgc3RyaXBlIHVuaXQuCiAJCQkJICovCi0JCQkJaWYgKG1w LT5tX2RhbGlnbiAmJiBhbGVuID49IG1wLT5tX2RhbGlnbiAmJgorCQkJCWlm ICgoZmxhZ3MgJiBYRlNfQk1BUElfTkVBUikgIT0gMCkgeworCQkJCQlibWEu YWVvZiA9IDI7CisJCQkJfQorCQkJCWVsc2UgaWYgKG1wLT5tX2RhbGlnbiAm JiBhbGVuID49IG1wLT5tX2RhbGlnbiAmJgogCQkJCSAgICB1c2VyZGF0YSAm JiB3aGljaGZvcmsgPT0gWEZTX0RBVEFfRk9SSykgewogCQkJCQlpZiAoKGVy cm9yID0geGZzX2JtYXBfaXNhZW9mKGlwLCBhb2ZmLAogCQkJCQkJCXdoaWNo Zm9yaywgJmJtYS5hZW9mKSkpCmRpZmYgLXVyYiBsaW51eC0yLjYuMTYuMTYu b3JpZy9mcy94ZnMveGZzX2JtYXAuaCBsaW51eC0yLjYuMTYuMTYvZnMveGZz L3hmc19ibWFwLmgKLS0tIGxpbnV4LTIuNi4xNi4xNi5vcmlnL2ZzL3hmcy94 ZnNfYm1hcC5oCTIwMDYtMDUtMTEgMDI6NTY6MjQuMDAwMDAwMDAwICswMTAw CisrKyBsaW51eC0yLjYuMTYuMTYvZnMveGZzL3hmc19ibWFwLmgJMjAwNi0w Ny0yMCAxNDoxNzo1NC4wMDAwMDAwMDAgKzAxMDAKQEAgLTY2LDYgKzY2LDcg QEAKICNkZWZpbmUgWEZTX0JNQVBJX0NPTlZFUlQJMHgxMDAwCS8qIHVud3Jp dHRlbiBleHRlbnQgY29udmVyc2lvbiAtICovCiAJCQkJCS8qIG5lZWQgd3Jp dGUgY2FjaGUgZmx1c2hpbmcgYW5kIG5vICovCiAJCQkJCS8qIGFkZGl0aW9u YWwgYWxsb2NhdGlvbiBhbGlnbm1lbnRzICovCisjZGVmaW5lIFhGU19CTUFQ SV9ORUFSCQkweDIwMDAJLyogYWxsb2NhdGUgbmVhciBoZXJlIGlmIHBvc3Np YmxlICovCiAKICNkZWZpbmUJWEZTX0JNQVBJX0FGTEFHKHcpCXhmc19ibWFw aV9hZmxhZyh3KQogc3RhdGljIGlubGluZSBpbnQgeGZzX2JtYXBpX2FmbGFn KGludCB3KQpkaWZmIC11cmIgbGludXgtMi42LjE2LjE2Lm9yaWcvZnMveGZz L3hmc19mcy5oIGxpbnV4LTIuNi4xNi4xNi9mcy94ZnMveGZzX2ZzLmgKLS0t IGxpbnV4LTIuNi4xNi4xNi5vcmlnL2ZzL3hmcy94ZnNfZnMuaAkyMDA2LTA1 LTExIDAyOjU2OjI0LjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjE2 LjE2L2ZzL3hmcy94ZnNfZnMuaAkyMDA2LTA3LTIwIDE0OjU0OjEzLjAwMDAw MDAwMCArMDEwMApAQCAtMTU2LDEwICsxNTYsMTcgQEAKIAlfX3M2NAkJbF9s ZW47CQkvKiBsZW4gPT0gMCBtZWFucyB1bnRpbCBlbmQgb2YgZmlsZSAqLwog CV9fczMyCQlsX3N5c2lkOwogCV9fdTMyCQlsX3BpZDsKLQlfX3MzMgkJbF9w YWRbNF07CS8qIHJlc2VydmUgYXJlYQkJCSAgICAqLworCV9fczY0CQlsX25l YXI7CQkvKiBkaXNrIGJsb2NrIHdlJ2QgbGlrZSB0byBhbGxvY2F0ZSBuZWFy ICovCisJX19zMzIJCWxfcGFkWzJdOwkvKiByZXNlcnZlIGFyZWEJCQkgICAg Ki8KIH0geGZzX2Zsb2NrNjRfdDsKIAogLyoKKyAqIGZsYWdzIGZvciB0aGUg bF93aGVuY2UgZmllbGQKKyAqLworI2RlZmluZSBSRVNWX05FQVIJNAorI2Rl ZmluZSBSRVNWX0NPTlRJRwk4CisKKy8qCiAgKiBPdXRwdXQgZm9yIFhGU19J T0NfRlNHRU9NRVRSWV9WMQogICovCiB0eXBlZGVmIHN0cnVjdCB4ZnNfZnNv cF9nZW9tX3YxIHsKZGlmZiAtdXJiIGxpbnV4LTIuNi4xNi4xNi5vcmlnL2Zz L3hmcy94ZnNfdm5vZGVvcHMuYyBsaW51eC0yLjYuMTYuMTYvZnMveGZzL3hm c192bm9kZW9wcy5jCi0tLSBsaW51eC0yLjYuMTYuMTYub3JpZy9mcy94ZnMv eGZzX3Zub2Rlb3BzLmMJMjAwNi0wNS0xMSAwMjo1NjoyNC4wMDAwMDAwMDAg KzAxMDAKKysrIGxpbnV4LTIuNi4xNi4xNi9mcy94ZnMveGZzX3Zub2Rlb3Bz LmMJMjAwNi0wNy0yMCAxNDo1NTowNS4wMDAwMDAwMDAgKzAxMDAKQEAgLTM5 ODQsNyArMzk4NCw4IEBACiAJeGZzX29mZl90CQlvZmZzZXQsCiAJeGZzX29m Zl90CQlsZW4sCiAJaW50CQkJYWxsb2NfdHlwZSwKLQlpbnQJCQlhdHRyX2Zs YWdzKQorCWludAkJCWF0dHJfZmxhZ3MsCisJeGZzX2ZzYmxvY2tfdAkJbmVh cl9ibG9jaykKIHsKIAl4ZnNfbW91bnRfdAkJKm1wID0gaXAtPmlfbW91bnQ7 CiAJeGZzX29mZl90CQljb3VudDsKQEAgLTQwMjcsNyArNDAyOCw3IEBACiAJ ZXJyb3IgPSAwOwogCWltYXBwID0gJmltYXBzWzBdOwogCW5pbWFwcyA9IDE7 Ci0JYm1hcGlfZmxhZyA9IFhGU19CTUFQSV9XUklURSB8IChhbGxvY190eXBl ID8gWEZTX0JNQVBJX1BSRUFMTE9DIDogMCk7CisJYm1hcGlfZmxhZyA9IFhG U19CTUFQSV9XUklURSB8IGFsbG9jX3R5cGU7CiAJc3RhcnRvZmZzZXRfZnNi CT0gWEZTX0JfVE9fRlNCVChtcCwgb2Zmc2V0KTsKIAlhbGxvY2F0ZXNpemVf ZnNiID0gWEZTX0JfVE9fRlNCKG1wLCBjb3VudCk7CiAKQEAgLTQxMTUsMTAg KzQxMTYsMTcgQEAKIAkJICogSXNzdWUgdGhlIHhmc19ibWFwaSgpIGNhbGwg dG8gYWxsb2NhdGUgdGhlIGJsb2NrcwogCQkgKi8KIAkJWEZTX0JNQVBfSU5J VCgmZnJlZV9saXN0LCAmZmlyc3Rmc2IpOworCisJCWlmICgoYm1hcGlfZmxh ZyAmIFhGU19CTUFQSV9ORUFSKSAhPSAwKQorCQkJZmlyc3Rmc2IgPSBuZWFy X2Jsb2NrOworCiAJCWVycm9yID0geGZzX2JtYXBpKHRwLCBpcCwgc3RhcnRv ZmZzZXRfZnNiLAogCQkJCSAgYWxsb2NhdGVzaXplX2ZzYiwgYm1hcGlfZmxh ZywKIAkJCQkgICZmaXJzdGZzYiwgMCwgaW1hcHAsICZuaW1hcHMsCiAJCQkJ ICAmZnJlZV9saXN0KTsKKworCQlibWFwaV9mbGFnICY9IH5YRlNfQk1BUElf TkVBUjsKKwogCQlpZiAoZXJyb3IpIHsKIAkJCWdvdG8gZXJyb3IwOwogCQl9 CkBAIC00NDg4LDEyICs0NDk2LDI0IEBACiAJdmF0dHJfdAkJdmE7CiAJdm5v ZGVfdAkJKnZwOwogCisJeGZzX2ZzYmxvY2tfdAluZWFyX2Jsb2NrID0gTlVM TEZTQkxPQ0s7CisJaW50CQlhbGxvY190eXBlID0gMDsKKwogCXZwID0gQkhW X1RPX1ZOT0RFKGJkcCk7CiAJdm5fdHJhY2VfZW50cnkodnAsIF9fRlVOQ1RJ T05fXywgKGluc3RfdCAqKV9fcmV0dXJuX2FkZHJlc3MpOwogCiAJaXAgPSBY RlNfQkhWVE9JKGJkcCk7CiAJbXAgPSBpcC0+aV9tb3VudDsKIAorCWlmIChj bWQgPT0gWEZTX0lPQ19SRVNWU1A2NCkgeworCSAgICAJYWxsb2NfdHlwZSB8 PSAoYmYtPmxfd2hlbmNlICYgUkVTVl9ORUFSKSA/IFhGU19CTUFQSV9ORUFS IDogMDsKKwkgICAgCWFsbG9jX3R5cGUgfD0gKGJmLT5sX3doZW5jZSAmIFJF U1ZfQ09OVElHKSA/IFhGU19CTUFQSV9DT05USUcgOiAwOworCQliZi0+bF93 aGVuY2UgJj0gfihSRVNWX05FQVIgfCBSRVNWX0NPTlRJRyk7CisKKwkJaWYg KChhbGxvY190eXBlICYgWEZTX0JNQVBJX05FQVIpICE9IDApCisJCQluZWFy X2Jsb2NrID0gWEZTX0RBRERSX1RPX0ZTQihtcCwgYmYtPmxfbmVhcik7CisJ fQorCiAJLyoKIAkgKiBtdXN0IGJlIGEgcmVndWxhciBmaWxlIGFuZCBoYXZl IHdyaXRlIHBlcm1pc3Npb24KIAkgKi8KQEAgLTQ1NTIsNyArNDU3Miw3IEBA CiAJY2FzZSBYRlNfSU9DX1JFU1ZTUDoKIAljYXNlIFhGU19JT0NfUkVTVlNQ NjQ6CiAJCWVycm9yID0geGZzX2FsbG9jX2ZpbGVfc3BhY2UoaXAsIHN0YXJ0 b2Zmc2V0LCBiZi0+bF9sZW4sCi0JCQkJCQkJCTEsIGF0dHJfZmxhZ3MpOwor CQkJCQkgICAgIGFsbG9jX3R5cGUgfCBYRlNfQk1BUElfUFJFQUxMT0MsIGF0 dHJfZmxhZ3MsIG5lYXJfYmxvY2spOwogCQlpZiAoZXJyb3IpCiAJCQlyZXR1 cm4gZXJyb3I7CiAJCXNldHByZWFsbG9jID0gMTsKQEAgLTQ1NzEsNyArNDU5 MSw3IEBACiAJY2FzZSBYRlNfSU9DX0ZSRUVTUDY0OgogCQlpZiAoc3RhcnRv ZmZzZXQgPiBmc2l6ZSkgewogCQkJZXJyb3IgPSB4ZnNfYWxsb2NfZmlsZV9z cGFjZShpcCwgZnNpemUsCi0JCQkJCXN0YXJ0b2Zmc2V0IC0gZnNpemUsIDAs IGF0dHJfZmxhZ3MpOworCQkJCQkJICAgICBzdGFydG9mZnNldCAtIGZzaXpl LCAwLCBhdHRyX2ZsYWdzLCBOVUxMRlNCTE9DSyk7CiAJCQlpZiAoZXJyb3Ip CiAJCQkJYnJlYWs7CiAJCX0K ------=_Part_44296_19539042.1153406307636-- From owner-xfs@oss.sgi.com Thu Jul 20 08:46:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 08:46:29 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KFkIDW020142 for ; Thu, 20 Jul 2006 08:46:18 -0700 Received: by nf-out-0910.google.com with SMTP id a27so487136nfc for ; Thu, 20 Jul 2006 08:45:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DJW6VM353oIHt9f6I2FJY5QttWCwvDdUV4sj6GcZddw8lGmIu20Ws1F6LeeZqI6cpcEIO/S64uAme86JzyWKntNLqM26ZmzLwBNZjJNWOjYD4UgCeaMpxK404vcWu7Pbg5SLprq7SJssxM8T4NGpP/5tG2Bn3NqVZ4iDLgCnEdQ= Received: by 10.48.202.19 with SMTP id z19mr565421nff; Thu, 20 Jul 2006 07:43:28 -0700 (PDT) Received: by 10.49.57.8 with HTTP; Thu, 20 Jul 2006 07:43:28 -0700 (PDT) Message-ID: Date: Thu, 20 Jul 2006 15:43:28 +0100 From: "Roger Willcocks" To: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown on full filesystem In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4401039B.9050700@sgi.com> X-archive-position: 8341 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: willcor@gmail.com Precedence: bulk X-list: xfs Content-Length: 485 Lines: 15 On 2/27/06, Roger Willcocks wrote: > On 2/27/06, Roger Willcocks wrote: > > > I've reproduced the problem on a clean checkout of linux-2.6-xfs from > > oss.sgi.com. > > I've narrowed this down to XFS_DIR_CREATENAME returning ENOSPC in > xfs_create. (resblks = 40, resblks - XFS_IALLOC_SPACE_RES(mp) = 35). For what it's worth, this eventually turned out to be a code generation error. Updating the compiler made the problem go away. -- Roger From owner-xfs@oss.sgi.com Thu Jul 20 09:11:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 09:12:17 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6KGBkDW022750 for ; Thu, 20 Jul 2006 09:11:52 -0700 Received: (qmail 54890 invoked from network); 20 Jul 2006 16:11:24 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2006 16:11:23 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id AF097184DA48; Thu, 20 Jul 2006 09:11:21 -0700 (PDT) Date: Thu, 20 Jul 2006 09:11:21 -0700 From: Chris Wedgwood To: David Greaves Cc: Nathan Scott , Kasper Sandberg , Justin Piszcz , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060720161121.GA26748@tuatara.stupidest.org> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44BF8500.1010708@dgreaves.com> X-archive-position: 8342 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: 445 Lines: 13 On Thu, Jul 20, 2006 at 02:28:32PM +0100, David Greaves wrote: > Does this problem exist in 2.16.6.x?? The change was merged after 2.6.16.x was branched, I was mistaken in how long I thought the bug has been about. > I hope so because I assumed there simply wasn't a patch for 2.6.16 and > applied this 'best guess' to my servers and rebooted/remounted successfully. Doing the correct change to 2.6.16.x won't hurt, but it's not necessary. From owner-xfs@oss.sgi.com Thu Jul 20 09:17:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 09:17:44 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6KGHVDW023580 for ; Thu, 20 Jul 2006 09:17:33 -0700 Received: (qmail 72133 invoked from network); 20 Jul 2006 16:17:09 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2006 16:17:09 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 08820184DA48; Thu, 20 Jul 2006 09:17:07 -0700 (PDT) Date: Thu, 20 Jul 2006 09:17:07 -0700 From: Chris Wedgwood To: Ming Zhang Cc: Peter Grandi , Linux XFS Subject: Re: stable xfs Message-ID: <20060720161707.GB26748@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153404502.2768.50.camel@localhost.localdomain> X-archive-position: 8343 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: 1296 Lines: 35 On Thu, Jul 20, 2006 at 10:08:22AM -0400, Ming Zhang wrote: > we mainly handle large media files like 20-50GB. so file number is > not too much. but file size is large. xfs_repair usually deals with that fairly well in reality (much better than lots of small files anyhow) > hope i never need to run repair, but i do need to defrag from time > to time. if you preallocate you can avoid that (this is what i do, i preallocate in the replication daemon) > hope this does not hold true for a 15x750GB SATA raid5. ;) that's ~10TB or so, my guess is that a repair there would take some GBs of ram it would be interesting to test it if you had the time there is a 'formular' for working out how much ram is needed roughly (steve lord posted it a long time ago, hopefully someone can find that and repost is) > say XFS can make use of parallel storage by using multiple > allocation groups. but XFS need to be built over one block > device. so if i have 4 smaller raid, i have to use LVM to glue them > before i create XFS over it right? but then u said XFS over LVM or N > MD is not good? with recent kernels it shouldn't be a problem, the recursive nature of the block layer changed so you no longer blow up as badly as people did in the past (also, XFS tends to use less stack these days) From owner-xfs@oss.sgi.com Thu Jul 20 09:32:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 09:32:35 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KGWADW025308 for ; Thu, 20 Jul 2006 09:32:10 -0700 Received: by nf-out-0910.google.com with SMTP id a27so501789nfc for ; Thu, 20 Jul 2006 09:31:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R67RVL4pytYpQXwWV/XXr40pKrvUijsKL0gN+c8T5dwMw21v136f9vV0PQpAdEgaIpWcyz4Go3MOD0Hgb/b3l4Zo4U1hBxU+tl9RdhGdO2ahjYFKPbVkNuYJheP6dG+DeNiO2a7w/5NpXBwMatGp6QY07/v1db3+rAFCdIc8ZiM= Received: by 10.78.159.7 with SMTP id h7mr471189hue; Thu, 20 Jul 2006 08:13:58 -0700 (PDT) Received: by 10.78.117.19 with HTTP; Thu, 20 Jul 2006 08:13:57 -0700 (PDT) Message-ID: <3b0ffc1f0607200813q39ba2303l7623baedd924a5a1@mail.gmail.com> Date: Thu, 20 Jul 2006 11:13:57 -0400 From: "Kevin Radloff" To: "Nathan Scott" Subject: Re: FAQ updated (was Re: XFS breakage...) Cc: "Kasper Sandberg" , "Justin Piszcz" , "Torsten Landschoff" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060720171310.B1970528@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> X-archive-position: 8344 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: radsaq@gmail.com Precedence: bulk X-list: xfs Content-Length: 1907 Lines: 44 On 7/20/06, Nathan Scott wrote: > On Wed, Jul 19, 2006 at 12:21:08PM +0200, Kasper Sandberg wrote: > > On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > > > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > > > > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > > > > > I suspect you had some residual directory corruption from using the > > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > > fixed in the latest -stable point release). > > Correction there - no -stable exists with this yet, I guess that'll > be 2.6.17.7 once its out though. > > > what action do you suggest i do now? > > I've captured the state of this issue here, with options and ways > to correct the problem: > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > Hope this helps. I actually tried the xfs_db method to fix my / filesystem (as you had outlined in http://marc.theaimsgroup.com/?l=linux-kernel&m=115070320401919&w=2), and while it's quite possible that I screwed it up, after a subsequent xfs_repair run (which completed successfully and moved lots of stuff to /lost+found, as I would expect), the XFS code had serious problems with various parts of my filesystem (like "ls /lost+found", which would cause lots of errors to be logged, although not a complete fs shutdown). After another run through xfs_repair resulted in a filesystem that would no longer even successfully boot. Unfortunately it was a mostly-full 74GB big-/ partition on my primary machine (a laptop), so I don't have a dump of it for you and my report is probably pretty useless. :( But on the bright side, virtually all of the filesystem was otherwise intact and I was able to get all my data off before rebuilding my system. -- Kevin 'radsaq' Radloff radsaq@gmail.com http://thesaq.com/ From owner-xfs@oss.sgi.com Thu Jul 20 09:38:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 09:38:56 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KGcbDW026142 for ; Thu, 20 Jul 2006 09:38:39 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6KGc60q028416 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Jul 2006 12:38:07 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Chris Wedgwood Cc: Peter Grandi , Linux XFS In-Reply-To: <20060720161707.GB26748@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> Content-Type: text/plain Date: Thu, 20 Jul 2006 12:38:01 -0400 Message-Id: <1153413481.2768.65.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8345 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1655 Lines: 52 On Thu, 2006-07-20 at 09:17 -0700, Chris Wedgwood wrote: > On Thu, Jul 20, 2006 at 10:08:22AM -0400, Ming Zhang wrote: > > > we mainly handle large media files like 20-50GB. so file number is > > not too much. but file size is large. > > xfs_repair usually deals with that fairly well in reality (much better > than lots of small files anyhow) sounds cool. yes, large # of small files are always painful. > > > hope i never need to run repair, but i do need to defrag from time > > to time. > > if you preallocate you can avoid that (this is what i do, i > preallocate in the replication daemon) i could not control my application. so i still need to do defrag some time. > > > hope this does not hold true for a 15x750GB SATA raid5. ;) > > that's ~10TB or so, my guess is that a repair there would take some > GBs of ram > > it would be interesting to test it if you had the time yes. i should find out. hope to force a repair? unplug my power cord? ;) > > there is a 'formular' for working out how much ram is needed roughly > (steve lord posted it a long time ago, hopefully someone can find that > and repost is) > > > say XFS can make use of parallel storage by using multiple > > allocation groups. but XFS need to be built over one block > > device. so if i have 4 smaller raid, i have to use LVM to glue them > > before i create XFS over it right? but then u said XFS over LVM or N > > MD is not good? > > with recent kernels it shouldn't be a problem, the recursive nature of > the block layer changed so you no longer blow up as badly as people > did in the past (also, XFS tends to use less stack these days) sounds cool. From owner-xfs@oss.sgi.com Thu Jul 20 10:17:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 10:18:08 -0700 (PDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KHHbDW030001 for ; Thu, 20 Jul 2006 10:17:38 -0700 Received: from [192.168.1.63] (195-112-44-96.dyn.gotadsl.co.uk [195.112.44.96]) by smtp.nildram.co.uk (Postfix) with ESMTP id BA10423862B; Thu, 20 Jul 2006 17:51:07 +0100 (BST) From: Alistair John Strachan To: "Kevin Radloff" Subject: Re: FAQ updated (was Re: XFS breakage...) Date: Thu, 20 Jul 2006 17:51:40 +0100 User-Agent: KMail/1.9.3 Cc: "Nathan Scott" , "Kasper Sandberg" , "Justin Piszcz" , "Torsten Landschoff" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20060718222941.GA3801@stargate.galaxy> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <3b0ffc1f0607200813q39ba2303l7623baedd924a5a1@mail.gmail.com> In-Reply-To: <3b0ffc1f0607200813q39ba2303l7623baedd924a5a1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607201751.40040.s0348365@sms.ed.ac.uk> X-archive-position: 8346 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: s0348365@sms.ed.ac.uk Precedence: bulk X-list: xfs Content-Length: 3080 Lines: 65 On Thursday 20 July 2006 16:13, Kevin Radloff wrote: > On 7/20/06, Nathan Scott wrote: > > On Wed, Jul 19, 2006 at 12:21:08PM +0200, Kasper Sandberg wrote: > > > On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > > > > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > > > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > > > > > > > I suspect you had some residual directory corruption from using the > > > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > > > fixed in the latest -stable point release). > > > > Correction there - no -stable exists with this yet, I guess that'll > > be 2.6.17.7 once its out though. > > > > > what action do you suggest i do now? > > > > I've captured the state of this issue here, with options and ways > > to correct the problem: > > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > > > Hope this helps. > > I actually tried the xfs_db method to fix my / filesystem (as you had > outlined in > http://marc.theaimsgroup.com/?l=linux-kernel&m=115070320401919&w=2), and > while it's quite possible that I screwed it up, after a subsequent > xfs_repair run (which completed successfully and moved lots of stuff to > /lost+found, as I would expect), the XFS code had serious problems with > various parts of my filesystem (like "ls /lost+found", which > would cause lots of errors to be logged, although not a complete fs > shutdown). After another run through xfs_repair resulted in a > filesystem that would no longer even successfully boot. > > Unfortunately it was a mostly-full 74GB big-/ partition on my primary > machine (a laptop), so I don't have a dump of it for you and my report > is probably pretty useless. :( But on the bright side, virtually all > of the filesystem was otherwise intact and I was able to get all my > data off before rebuilding my system. I've been hit by this on my root filesystem today, and when I followed the instructions, I was able to retrieve my data. It turned out that the only corrupted inode was /, which unfortunately meant I had to repair the filesystem with a boot-cd. However, it was obvious which inodes corresponded to which directories, and I was able to repair it. I'm not sure this advice is sound, but it seems to me that if you're running an affected 2.6.17 kernel (or ever have) on an XFS volume, it's not worth risking destruction if you haven't had any oopses. The filesystem will get worse, but hopefully in a non-fatal way, and the XFS guys will hopefully have an xfs_repair up that works, soon. Right now I'd highly recommend copying as much as possible from the corrupted filesystem )after following the instructions) to a new filesystem (with an unaffected kernel, of course) and destroying the old one. I still have inconsistencies on the filesystem I "repaired", and it was a fairly painful process. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. From owner-xfs@oss.sgi.com Thu Jul 20 12:04:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 12:04:45 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6KJ4UDW009367 for ; Thu, 20 Jul 2006 12:04:34 -0700 Received: (qmail 31940 invoked from network); 20 Jul 2006 19:04:05 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2006 19:04:05 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 872B1184DA48; Thu, 20 Jul 2006 12:04:01 -0700 (PDT) Date: Thu, 20 Jul 2006 12:04:01 -0700 From: Chris Wedgwood To: Ming Zhang Cc: Peter Grandi , Linux XFS Subject: Re: stable xfs Message-ID: <20060720190401.GA28836@tuatara.stupidest.org> References: <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153413481.2768.65.camel@localhost.localdomain> X-archive-position: 8347 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: 1039 Lines: 27 On Thu, Jul 20, 2006 at 12:38:01PM -0400, Ming Zhang wrote: > i could not control my application. so i still need to do defrag > some time. one thing that irks me about fsr is that unless it's given path elements it that the files created to replace the fragmented file are usually not allocated close the original file (they are openned by handle after a bulkstat pass) so you tend to scatter your files about if you're not careful also, fsr implies doing a lot more work on the whole, writing, reading and rewriting the files in most cases and because it uses dio it will invalidate the page-cache of any files that might be being read-from when it's running > yes. i should find out. hope to force a repair? umount cleanly and run xfs_repair, check to see how much memory it uses with ps/top/whatever as it's running > unplug my power cord? ;) raid protects against failed disks, it usually doesn't protect well against corruption from lost/bad writes as a result of dropping power so well, if you have backups, sure, go for it From owner-xfs@oss.sgi.com Thu Jul 20 15:18:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:18:58 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KMIdDW028469 for ; Thu, 20 Jul 2006 15:18:39 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 55E1F607BFA8; Thu, 20 Jul 2006 18:18:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 50B6216172EC3; Thu, 20 Jul 2006 18:18:14 -0400 (EDT) Date: Thu, 20 Jul 2006 18:18:14 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nathan Scott cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) In-Reply-To: <20060721081452.B1990742@wobbly.melbourne.sgi.com> Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8349 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1218 Lines: 41 Nathan, Does the bug only occur during a crash? I have been running 2.6.17.x for awhile now (multiple XFS filesystems, all on UPS) - no issue? Justin. On Fri, 21 Jul 2006, Nathan Scott wrote: > On Thu, Jul 20, 2006 at 09:11:21AM -0700, Chris Wedgwood wrote: >> On Thu, Jul 20, 2006 at 02:28:32PM +0100, David Greaves wrote: >> >>> Does this problem exist in 2.16.6.x?? >> >> The change was merged after 2.6.16.x was branched, I was mistaken >> in how long I thought the bug has been about. >> >>> I hope so because I assumed there simply wasn't a patch for 2.6.16 and >>> applied this 'best guess' to my servers and rebooted/remounted successfully. >> >> Doing the correct change to 2.6.16.x won't hurt, but it's not >> necessary. > > Yep. As Chris said, 2.6.17 is the only affected kernel. I've > fixed up the whacky html formatting and my merge error (thanks > to all for reporting those) so its a bit more readable now. > > cheers. > > -- > Nathan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-xfs@oss.sgi.com Thu Jul 20 15:16:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:17:07 -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 k6KMG7DW028254 for ; Thu, 20 Jul 2006 15:16:18 -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 IAA11214; Fri, 21 Jul 2006 08:15: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 k6KMF7gw1992721; Fri, 21 Jul 2006 08:15:08 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6KMEqOm1990603; Fri, 21 Jul 2006 08:14:52 +1000 (EST) Date: Fri, 21 Jul 2006 08:14:52 +1000 From: Nathan Scott To: Chris Wedgwood Cc: David Greaves , Kasper Sandberg , Justin Piszcz , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060721081452.B1990742@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060720161121.GA26748@tuatara.stupidest.org>; from cw@f00f.org on Thu, Jul 20, 2006 at 09:11:21AM -0700 X-archive-position: 8348 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: 741 Lines: 23 On Thu, Jul 20, 2006 at 09:11:21AM -0700, Chris Wedgwood wrote: > On Thu, Jul 20, 2006 at 02:28:32PM +0100, David Greaves wrote: > > > Does this problem exist in 2.16.6.x?? > > The change was merged after 2.6.16.x was branched, I was mistaken > in how long I thought the bug has been about. > > > I hope so because I assumed there simply wasn't a patch for 2.6.16 and > > applied this 'best guess' to my servers and rebooted/remounted successfully. > > Doing the correct change to 2.6.16.x won't hurt, but it's not > necessary. Yep. As Chris said, 2.6.17 is the only affected kernel. I've fixed up the whacky html formatting and my merge error (thanks to all for reporting those) so its a bit more readable now. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 15:26:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:26:36 -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 k6KMPqDW029306 for ; Thu, 20 Jul 2006 15:26: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 IAA11495; Fri, 21 Jul 2006 08:25:07 +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 k6KMOugw1992885; Fri, 21 Jul 2006 08:24:57 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6KMOnbQ1992506; Fri, 21 Jul 2006 08:24:49 +1000 (EST) Date: Fri, 21 Jul 2006 08:24:49 +1000 From: Nathan Scott To: Justin Piszcz Cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060721082448.C1990742@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jpiszcz@lucidpixels.com on Thu, Jul 20, 2006 at 06:18:14PM -0400 X-archive-position: 8350 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: 654 Lines: 22 On Thu, Jul 20, 2006 at 06:18:14PM -0400, Justin Piszcz wrote: > Nathan, > > Does the bug only occur during a crash? No, its unrelated to crashing. Only when adding/removing from a directory that is in a specific node/btree format (many entries), and only under a specific set of conditions (like what directory entry names were used, which blocks they've hashed to and how they ended up being allocated and in what order each block gets removed from the directory). > I have been running 2.6.17.x for awhile now (multiple XFS filesystems, all > on UPS) - no issue? Could be an issue, could be none. xfs_check it to be sure. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 15:43:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:44:43 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KMhuDW031350 for ; Thu, 20 Jul 2006 15:43:56 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 32673607BFAE; Thu, 20 Jul 2006 18:43:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 2E5EE16172ECA; Thu, 20 Jul 2006 18:43:34 -0400 (EDT) Date: Thu, 20 Jul 2006 18:43:34 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nathan Scott cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) In-Reply-To: <20060721082448.C1990742@wobbly.melbourne.sgi.com> Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8351 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 927 Lines: 38 On Fri, 21 Jul 2006, Nathan Scott wrote: > On Thu, Jul 20, 2006 at 06:18:14PM -0400, Justin Piszcz wrote: >> Nathan, >> >> Does the bug only occur during a crash? > > No, its unrelated to crashing. Only when adding/removing from a > directory that is in a specific node/btree format (many entries), > and only under a specific set of conditions (like what directory > entry names were used, which blocks they've hashed to and how they > ended up being allocated and in what order each block gets removed > from the directory). > >> I have been running 2.6.17.x for awhile now (multiple XFS filesystems, all >> on UPS) - no issue? > > Could be an issue, could be none. xfs_check it to be sure. > > cheers. > > -- > Nathan > > p34:~# xfs_check -v /dev/md3 xfs_check: out of memory p34:~# D'oh... 1GB ram, 2GB swap trying to check a 2.6T fs, no dice. As long as it mounted ok with the patched kernel, should one be ok? From owner-xfs@oss.sgi.com Thu Jul 20 15:45:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:46:18 -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 k6KMjcDW031499 for ; Thu, 20 Jul 2006 15:45:50 -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 IAA11937; Fri, 21 Jul 2006 08:44:57 +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 k6KMisgw1989901; Fri, 21 Jul 2006 08:44:55 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6KMiqEG1995406; Fri, 21 Jul 2006 08:44:52 +1000 (EST) Date: Fri, 21 Jul 2006 08:44:51 +1000 From: Nathan Scott To: Roger Willcocks Cc: xfs@oss.sgi.com Subject: Re: preallocate near a specified block Message-ID: <20060721084451.E1990742@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from willcor@gmail.com on Thu, Jul 20, 2006 at 03:38:27PM +0100 X-archive-position: 8352 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: 511 Lines: 20 On Thu, Jul 20, 2006 at 03:38:27PM +0100, Roger Willcocks wrote: > Hi folks, > > I've put together a 'preallocate near' ioctl, which I've been using in > anger for several months now. The changes are pretty minimal, and boil > down to making xfs_bmap think it's extending a file instead of doing > an initial allocation. > ... > Any interest? Definately. Have you tweaked xfs_io to be able to exercise this functionality too? (also describing it in the xfsctl man page would be good). cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 15:53:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:54:08 -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 k6KMrQDW000790 for ; Thu, 20 Jul 2006 15:53: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 IAA12211; Fri, 21 Jul 2006 08:52:44 +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 k6KMqbgw1973740; Fri, 21 Jul 2006 08:52:37 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6KMqUtW1995061; Fri, 21 Jul 2006 08:52:30 +1000 (EST) Date: Fri, 21 Jul 2006 08:52:30 +1000 From: Nathan Scott To: Justin Piszcz Cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060721085230.F1990742@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jpiszcz@lucidpixels.com on Thu, Jul 20, 2006 at 06:43:34PM -0400 X-archive-position: 8353 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: 390 Lines: 19 On Thu, Jul 20, 2006 at 06:43:34PM -0400, Justin Piszcz wrote: > p34:~# xfs_check -v /dev/md3 > xfs_check: out of memory > p34:~# > > D'oh... xfs_repair -n is another option, it has a cheaper (memory wise, usually) checking algorithm. > As long as it mounted ok with the patched kernel, should one be ok? Not necessarily, no - mount will only read the root inode. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 15:56:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:56:36 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KMuDDW001190 for ; Thu, 20 Jul 2006 15:56:14 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 34A57607BFAF; Thu, 20 Jul 2006 18:55:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 308A116172ECA; Thu, 20 Jul 2006 18:55:51 -0400 (EDT) Date: Thu, 20 Jul 2006 18:55:51 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nathan Scott cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) In-Reply-To: <20060721085230.F1990742@wobbly.melbourne.sgi.com> Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> <20060721085230.F1990742@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8354 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1317 Lines: 47 Nasty! - agno = 37 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... free block 16777216 for directory inode 2684356622 bad nused free block 16777216 for directory inode 2147485710 bad nused - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. p34:~# I applied the "one line fix" - I should be ok now? On Fri, 21 Jul 2006, Nathan Scott wrote: > On Thu, Jul 20, 2006 at 06:43:34PM -0400, Justin Piszcz wrote: >> p34:~# xfs_check -v /dev/md3 >> xfs_check: out of memory >> p34:~# >> >> D'oh... > > xfs_repair -n is another option, it has a cheaper (memory wise, > usually) checking algorithm. > >> As long as it mounted ok with the patched kernel, should one be ok? > > Not necessarily, no - mount will only read the root inode. > > cheers. > > -- > Nathan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-xfs@oss.sgi.com Thu Jul 20 15:57:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 15:57:57 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KMvXDW001463 for ; Thu, 20 Jul 2006 15:57:34 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id D420C607BFB0; Thu, 20 Jul 2006 18:57:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D06AE16172ECA; Thu, 20 Jul 2006 18:57:11 -0400 (EDT) Date: Thu, 20 Jul 2006 18:57:11 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nathan Scott cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) In-Reply-To: Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> <20060721085230.F1990742@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8355 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1566 Lines: 55 Erm, the xfs_repair -n only prints out what it needs to fix, I read somewhere that xfs_repair may make things worse? What is the 'correct' fix? On Thu, 20 Jul 2006, Justin Piszcz wrote: > Nasty! > > - agno = 37 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... > free block 16777216 for directory inode 2684356622 bad nused > free block 16777216 for directory inode 2147485710 bad nused > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify link counts... > No modify flag set, skipping filesystem flush and exiting. > p34:~# > > I applied the "one line fix" - I should be ok now? > > > > On Fri, 21 Jul 2006, Nathan Scott wrote: > >> On Thu, Jul 20, 2006 at 06:43:34PM -0400, Justin Piszcz wrote: >>> p34:~# xfs_check -v /dev/md3 >>> xfs_check: out of memory >>> p34:~# >>> >>> D'oh... >> >> xfs_repair -n is another option, it has a cheaper (memory wise, >> usually) checking algorithm. >> >>> As long as it mounted ok with the patched kernel, should one be ok? >> >> Not necessarily, no - mount will only read the root inode. >> >> cheers. >> >> -- >> Nathan >> - >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > From owner-xfs@oss.sgi.com Thu Jul 20 16:01:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 16:01:56 -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 k6KN1DDW002517 for ; Thu, 20 Jul 2006 16:01:26 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12582; Fri, 21 Jul 2006 09:00:30 +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 k6KN0Mgw1993651; Fri, 21 Jul 2006 09:00:23 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6KN0Gtg1991966; Fri, 21 Jul 2006 09:00:16 +1000 (EST) Date: Fri, 21 Jul 2006 09:00:15 +1000 From: Nathan Scott To: Justin Piszcz Cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060721090015.G1990742@wobbly.melbourne.sgi.com> References: <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> <20060721085230.F1990742@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jpiszcz@lucidpixels.com on Thu, Jul 20, 2006 at 06:55:51PM -0400 X-archive-position: 8356 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: 687 Lines: 21 On Thu, Jul 20, 2006 at 06:55:51PM -0400, Justin Piszcz wrote: > Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... > free block 16777216 for directory inode 2684356622 bad nused > free block 16777216 for directory inode 2147485710 bad nused > - traversal finished ... > ... > I applied the "one line fix" - I should be ok now? You have two corrupt directory inodes (caused by this bug, that is exactly the signature I'd expect - it was a nused field that was affected by the dodgey endian change). The two inodes need to be fixed - consult the FAQ for details. Once fixed, and with a patched kernel, you're set. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 16:11:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 16:11:34 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KNBDDW003982 for ; Thu, 20 Jul 2006 16:11:13 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id AE277607BFB1; Thu, 20 Jul 2006 19:10:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id AB23E16172ECA; Thu, 20 Jul 2006 19:10:46 -0400 (EDT) Date: Thu, 20 Jul 2006 19:10:46 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nathan Scott cc: Chris Wedgwood , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) In-Reply-To: <20060721090015.G1990742@wobbly.melbourne.sgi.com> Message-ID: References: <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> <20060721085230.F1990742@wobbly.melbourne.sgi.com> <20060721090015.G1990742@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8357 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 6094 Lines: 139 Nathan, Running xfs_repair multiple times (after following the FAQ for the write core.mode 0 fix), I get this: - agno = 3 - agno = 4 - agno = 5 - agno = 6 entry ".." at block 0 offset 1352 in directory inode 3221227534 references free inode 2112 clearing inode number in entry at offset 1352... no .. entry for directory 3221227534 - agno = 7 - agno = 8 - agno = 9 disconnected inode 2684386082, moving to lost+found disconnected inode 2684386083, moving to lost+found disconnected inode 2684386084, moving to lost+found disconnected inode 2684386085, moving to lost+found disconnected inode 2684386086, moving to lost+found disconnected inode 2684386087, moving to lost+found disconnected inode 2684386088, moving to lost+found disconnected inode 2684386089, moving to lost+found disconnected inode 2684386090, moving to lost+found disconnected inode 2684386091, moving to lost+found disconnected inode 2684386092, moving to lost+found disconnected inode 2684386093, moving to lost+found disconnected inode 2684386094, moving to lost+found disconnected inode 2684386095, moving to lost+found disconnected inode 2684386096, moving to lost+found disconnected inode 2684386097, moving to lost+found disconnected inode 2684386098, moving to lost+found disconnected inode 2684386099, moving to lost+found disconnected inode 2684386100, moving to lost+found disconnected inode 2684386101, moving to lost+found disconnected inode 2684386102, moving to lost+found disconnected inode 2684386103, moving to lost+found disconnected inode 2684386104, moving to lost+found disconnected inode 2684386105, moving to lost+found disconnected inode 2684386106, moving to lost+found disconnected inode 2684386107, moving to lost+found disconnected inode 2684386108, moving to lost+found disconnected inode 2684386109, moving to lost+found disconnected inode 2684386110, moving to lost+found disconnected inode 2684386111, moving to lost+found disconnected inode 2684386112, moving to lost+found disconnected inode 2684386113, moving to lost+found disconnected inode 2684386114, moving to lost+found disconnected inode 2684386115, moving to lost+found disconnected inode 2684386116, moving to lost+found disconnected inode 2684386117, moving to lost+found disconnected inode 2684386118, moving to lost+found disconnected inode 2684386119, moving to lost+found disconnected inode 2684386120, moving to lost+found disconnected inode 2684386121, moving to lost+found disconnected inode 2684386122, moving to lost+found disconnected inode 2684386123, moving to lost+found disconnected inode 2684386124, moving to lost+found disconnected inode 2684386125, moving to lost+found disconnected inode 2684386126, moving to lost+found disconnected inode 2684386127, moving to lost+found disconnected inode 2684386128, moving to lost+found disconnected inode 2684386129, moving to lost+found disconnected inode 2684386130, moving to lost+found disconnected inode 2684386131, moving to lost+found disconnected inode 2684386132, moving to lost+found disconnected inode 2684386133, moving to lost+found disconnected inode 2684386134, moving to lost+found disconnected inode 2684386135, moving to lost+found disconnected inode 2684386136, moving to lost+found disconnected inode 2684386137, moving to lost+found disconnected inode 2684386138, moving to lost+found disconnected inode 2684386139, moving to lost+found disconnected inode 2684386140, moving to lost+found disconnected inode 2684386141, moving to lost+found disconnected inode 2684386142, moving to lost+found disconnected inode 2684386143, moving to lost+found disconnected inode 2684386144, moving to lost+found disconnected inode 2684386145, moving to lost+found disconnected inode 2684386146, moving to lost+found disconnected inode 2684386147, moving to lost+found disconnected inode 2684386148, moving to lost+found disconnected inode 2684386149, moving to lost+found disconnected inode 2684386150, moving to lost+found disconnected inode 2684386151, moving to lost+found disconnected inode 2684386152, moving to lost+found disconnected inode 2684386153, moving to lost+found disconnected inode 2684386154, moving to lost+found disconnected inode 2684386155, moving to lost+found disconnected inode 2684386156, moving to lost+found disconnected inode 2684386157, moving to lost+found disconnected inode 2684386158, moving to lost+found disconnected inode 2684386159, moving to lost+found disconnected inode 2684386160, moving to lost+found disconnected inode 2684386161, moving to lost+found disconnected inode 2684386162, moving to lost+found disconnected inode 2684386163, moving to lost+found disconnected inode 2684386164, moving to lost+found disconnected inode 2684386165, moving to lost+found disconnected inode 2684653605, moving to lost+found disconnected dir inode 3221227534, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 3221227534 nlinks from 3 to 2 done p34:~# I can run this over and over, and the result is the same? On Fri, 21 Jul 2006, Nathan Scott wrote: > On Thu, Jul 20, 2006 at 06:55:51PM -0400, Justin Piszcz wrote: >> Phase 6 - check inode connectivity... >> - traversing filesystem starting at / ... >> free block 16777216 for directory inode 2684356622 bad nused >> free block 16777216 for directory inode 2147485710 bad nused >> - traversal finished ... >> ... >> I applied the "one line fix" - I should be ok now? > > You have two corrupt directory inodes (caused by this bug, that > is exactly the signature I'd expect - it was a nused field that > was affected by the dodgey endian change). The two inodes need > to be fixed - consult the FAQ for details. > > Once fixed, and with a patched kernel, you're set. > > cheers. > > -- > Nathan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-xfs@oss.sgi.com Thu Jul 20 16:13:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 16:13:46 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6KNDLDW004316 for ; Thu, 20 Jul 2006 16:13:22 -0700 Received: (qmail 28461 invoked from network); 20 Jul 2006 23:12:58 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 20 Jul 2006 23:12:58 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 1B6E21810F5D; Thu, 20 Jul 2006 16:12:46 -0700 (PDT) Date: Thu, 20 Jul 2006 16:12:46 -0700 From: Chris Wedgwood To: Justin Piszcz Cc: Nathan Scott , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060720231245.GA32195@tuatara.stupidest.org> References: <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> <20060721085230.F1990742@wobbly.melbourne.sgi.com> <20060721090015.G1990742@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 8358 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: 199 Lines: 7 On Thu, Jul 20, 2006 at 07:10:46PM -0400, Justin Piszcz wrote: > I can run this over and over, and the result is the same? lost+found is recreated every time, rename it and you'll get less output From owner-xfs@oss.sgi.com Thu Jul 20 16:15:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 16:15:54 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6KNFWDW004961 for ; Thu, 20 Jul 2006 16:15:33 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id CD508607BFB3; Thu, 20 Jul 2006 19:15:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id CA62A16172ECA; Thu, 20 Jul 2006 19:15:10 -0400 (EDT) Date: Thu, 20 Jul 2006 19:15:10 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Chris Wedgwood cc: Nathan Scott , David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) In-Reply-To: <20060720231245.GA32195@tuatara.stupidest.org> Message-ID: References: <44BF8500.1010708@dgreaves.com> <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> <20060721085230.F1990742@wobbly.melbourne.sgi.com> <20060721090015.G1990742@wobbly.melbourne.sgi.com> <20060720231245.GA32195@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8359 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 648 Lines: 19 Thanks, that was it, after removing the lost+found directory & re-running xfs_repair, I no longer have any errors, onthat device anyway. On Thu, 20 Jul 2006, Chris Wedgwood wrote: > On Thu, Jul 20, 2006 at 07:10:46PM -0400, Justin Piszcz wrote: > >> I can run this over and over, and the result is the same? > > lost+found is recreated every time, rename it and you'll get less > output > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-xfs@oss.sgi.com Thu Jul 20 16:20:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 16:21: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 k6KNKkDW010359 for ; Thu, 20 Jul 2006 16:20: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 JAA13076; Fri, 21 Jul 2006 09:20:00 +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 k6KNJqgw1993353; Fri, 21 Jul 2006 09:19:53 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6KNJjGr1994666; Fri, 21 Jul 2006 09:19:45 +1000 (EST) Date: Fri, 21 Jul 2006 09:19:45 +1000 From: Nathan Scott To: Justin Piszcz , Chris Wedgwood Cc: David Greaves , Kasper Sandberg , Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, ml@magog.se, radsaq@gmail.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060721091945.I1990742@wobbly.melbourne.sgi.com> References: <20060720161121.GA26748@tuatara.stupidest.org> <20060721081452.B1990742@wobbly.melbourne.sgi.com> <20060721082448.C1990742@wobbly.melbourne.sgi.com> <20060721085230.F1990742@wobbly.melbourne.sgi.com> <20060721090015.G1990742@wobbly.melbourne.sgi.com> <20060720231245.GA32195@tuatara.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060720231245.GA32195@tuatara.stupidest.org>; from cw@f00f.org on Thu, Jul 20, 2006 at 04:12:46PM -0700 X-archive-position: 8360 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: 611 Lines: 21 On Thu, Jul 20, 2006 at 04:12:46PM -0700, Chris Wedgwood wrote: > On Thu, Jul 20, 2006 at 07:10:46PM -0400, Justin Piszcz wrote: > > > I can run this over and over, and the result is the same? > > lost+found is recreated every time, rename it and you'll get less > output Yes this is the current xfs_repair behaviour (any previously unlinked inodes will be found as unlinked on each successive run, due to lost+found being recreated). This will likely be rethought soon (not far off), since it confuses everyone. So, its all good - xfs_repair has fixed things and you're all set now. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 17:20:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 17:20:30 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6L0KGDW015845 for ; Thu, 20 Jul 2006 17:20:16 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6L0Jhro020999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Jul 2006 20:19:44 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Chris Wedgwood Cc: Peter Grandi , Linux XFS In-Reply-To: <20060720190401.GA28836@tuatara.stupidest.org> References: <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> <20060720190401.GA28836@tuatara.stupidest.org> Content-Type: text/plain Date: Thu, 20 Jul 2006 20:19:38 -0400 Message-Id: <1153441178.2768.158.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8361 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1411 Lines: 40 On Thu, 2006-07-20 at 12:04 -0700, Chris Wedgwood wrote: > On Thu, Jul 20, 2006 at 12:38:01PM -0400, Ming Zhang wrote: > > > i could not control my application. so i still need to do defrag > > some time. > > one thing that irks me about fsr is that unless it's given path > elements it that the files created to replace the fragmented file are > usually not allocated close the original file (they are openned by > handle after a bulkstat pass) so you tend to scatter your files about > if you're not careful what will be the side effect about this scattering? you want particular file in particular place? > > also, fsr implies doing a lot more work on the whole, writing, reading > and rewriting the files in most cases and because it uses dio it will > invalidate the page-cache of any files that might be being read-from > when it's running one thing i worry about fsr is when do fsr and some power loss events happen, can xfs handle this well? i will backup before trying these. need some time. ;) > > > yes. i should find out. hope to force a repair? > > umount cleanly and run xfs_repair, check to see how much memory it > uses with ps/top/whatever as it's running > > > unplug my power cord? ;) > > raid protects against failed disks, it usually doesn't protect well > against corruption from lost/bad writes as a result of dropping power > so well, if you have backups, sure, go for it From owner-xfs@oss.sgi.com Thu Jul 20 20:27:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 20:27:14 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6L3QwDW009627 for ; Thu, 20 Jul 2006 20:27:03 -0700 Received: (qmail 32099 invoked from network); 21 Jul 2006 03:26:34 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2006 03:26:34 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 4677F182727F; Thu, 20 Jul 2006 20:26:32 -0700 (PDT) Date: Thu, 20 Jul 2006 20:26:32 -0700 From: Chris Wedgwood To: Ming Zhang Cc: Peter Grandi , Linux XFS Subject: Re: stable xfs Message-ID: <20060721032632.GA4138@tuatara.stupidest.org> References: <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> <20060720190401.GA28836@tuatara.stupidest.org> <1153441178.2768.158.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153441178.2768.158.camel@localhost.localdomain> X-archive-position: 8362 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: 455 Lines: 13 On Thu, Jul 20, 2006 at 08:19:38PM -0400, Ming Zhang wrote: > what will be the side effect about this scattering? there is a desire in some cases to have files in the same directory close to each other on disk > one thing i worry about fsr is when do fsr and some power loss > events happen, can xfs handle this well? yes, fsr create a temporary file, unlinks it, copies the extents over, and does an atomic swap-extents-if-nothing-changed operation From owner-xfs@oss.sgi.com Thu Jul 20 22:09:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 22:10:22 -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 k6L59eDW021005 for ; Thu, 20 Jul 2006 22:09:51 -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 PAA18774 for ; Fri, 21 Jul 2006 15:09:06 +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 k6L594gw2000622 for ; Fri, 21 Jul 2006 15:09:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6L592Cx2001537 for xfs@oss.sgi.com; Fri, 21 Jul 2006 15:09:02 +1000 (EST) Date: Fri, 21 Jul 2006 15:09:02 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: Patches and reviews Message-ID: <20060721150902.C1998769@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8363 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: 1249 Lines: 31 Hi all, We have an internal process here (@sgi) where all changes are reviewed by someone else in the team before we merge them into our local tree. This is good and effective, but it obviously isn't visible to people outside SGI. Christoph has suggested we try to change this, so we plan to start sending out patches here before they are merged into our local tree, in the hope that others outside SGI will also take some time and cast a critical eye over changes before they go in. So, this is just a heads up that there will now be occasional mail coming to the list with "review: ..." in the Subject line and you're encouraged to try spot the bugs I'll "purposefully" inject from time to time, just to check you're awake. ;-) A response like "Beaauutiful code, Tim" is also helpful (recall that our internal process requires an ACK). I also now plan to start CC'ing the list on the mails I send to Linus and Andrew, requesting our XFS updates be merged into the mainline kernel. Hopefully this will also increase visibility everyone has as to what's going on in XFS with each new kernel. If you have other suggestions, particularly of things that are not going to increase my current workload at all, I'm all ears. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 22:16:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 22:16:53 -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 k6L5GJDW022284 for ; Thu, 20 Jul 2006 22:16:33 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18825; Fri, 21 Jul 2006 15:15:39 +1000 Message-ID: <44C062A3.1090206@sgi.com> Date: Fri, 21 Jul 2006 15:14:11 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com Subject: Re: Question on the WriteCache / WriteBarrier FAQ entry References: <200607201205.34750.Martin@lichtvoll.de> In-Reply-To: <200607201205.34750.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8364 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: 3609 Lines: 84 Martin Steigerwald wrote: > Hello, > > I try to fully understand this entry: > > "Many drives use a write back cache in order to speed up the performance > of writes. However, there are conditions such as power failure when the > write cache memory is never flushed to the actual disk. This causes > problems for XFS and journaled filesystems in general because they rely > on knowing when a write has completed to the disk. They need to know that > the log information has made it to disk before allowing metadata to go to > disk. When the metadata makes it to disk then the tail of the log can > move. So if the writes never make it to the physical disk, then the > ordering is violated and the log and metadata can be lost, resulting in > filesystem corruption." > > I have problems with: "When the metadata makes it to disk then the tail of > the log can move". What does that mean exactly? > Too vague for you, was it? ;-)) http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/trans.pdf has a good description in its 7 steps of a transaction. > What I imagine is this: XFS write transaction to its log and the log > grows. When writing the meta data changes of a complete transaction XFS > removes it from the log. Pretty much. The log is a fixed size and it wraps around with each basic block (512 bytes) having an embedded wrap# (or cycle#). We consider the head of the log as the point where a new transaction can go and the tail of the log as the last transaction whose metadata is still outstanding. Between the tail and the head are the active items which need to be replayed on log recovery. When we get an io callback for a metadata write, we remove the metadata items from a list of active items (AIL) and the tail pointer is based on the minimum entry (by log sequence #) in the AIL. So the tail is effectively moved on so that we know we can write over these inactive items in the ondisk log and can reclaim some space for the new ones to come. Also we know that on recovery we will not look at this old transaction. > Now when the metadata changes of a transaction > has been written completely but the transaction itself has not, Which should not happen as we don't allow metadata to be written until the associated transaction has made it to disk (see the 7 steps). But if something went wrong and it did happen... > it may > happen that a transaction is removed from the on disk log before it has > been written. Things would get confused. I guess it might try to find the item which is not in the AIL as the AIL gets updated on transaction callback. > But even when this does not happen there are metadata > changes on disk that the log doesn't know about. Yep, it's not good when we expect log replay to do the right thing. > > So there are two situations where unordered writes can make a journalling > filesystem corrupt: > > 1) Metadata make it to disk before the transaction that belongs to them => > There are metadata changes that XFS doesn't know about. Well, that aren't reflected in the log. > > 2) A transaction might be deleted from the log before it has been written > => This leads to a corrupted log. A transaction deleted before its metadata has made it to disk, yes. A transaction might be deleted (tail# moved on) because we believe it's metadata has made it to disk when it really hasn't (was in the write cache) in which case we need the transaction if recovery is required and we don't have it. I don't know if I want to try to go thru all the bad things that can happen and see how the code would handle it. Cheers, Tim. From owner-xfs@oss.sgi.com Thu Jul 20 22:29:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 22:29: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 k6L5SjDW024481 for ; Thu, 20 Jul 2006 22:28:57 -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 PAA19052; Fri, 21 Jul 2006 15:28: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 k6L5SAgw2000452; Fri, 21 Jul 2006 15:28:10 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6L5S7kQ2002620; Fri, 21 Jul 2006 15:28:07 +1000 (EST) Date: Fri, 21 Jul 2006 15:28:07 +1000 From: Nathan Scott To: xfs@oss.sgi.com Cc: jeremy@sgi.com Subject: review: fix remount vs barrier options Message-ID: <20060721152807.D1998769@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8365 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: 1625 Lines: 48 Hi, Jeremy has had me scratching my head for a few days trying to figure out how the SCSI traces he's looking at can still show signs of write barriers being issued to the device, despite a "remount,nobarrier" having been done. It finally clicked that we are not clearing the buffer flag from a previously written log buffer, even though we'll no longer set a new flag into a buffer (due to the mount flag being cleared), so we _can_ still issue barrier writes when remounted without barriers. This was made more complicated by the way a freshly mounted filesystem with 8 log buffers wouldn't show up the problem, since we have to slowly cycle through the "clear" log buffers before we see the bug. This seems like the simplest fix... (Hmmm, actually, I wonder if this will also resolve the quota log I/O problem that was reported the other day too). -- Nathan Index: xfs-linux/xfs_log.c =================================================================== --- xfs-linux.orig/xfs_log.c 2006-07-21 08:55:24.520992250 +1000 +++ xfs-linux/xfs_log.c 2006-07-21 09:47:08.429216000 +1000 @@ -1471,6 +1471,8 @@ xlog_sync(xlog_t *log, */ if (log->l_mp->m_flags & XFS_MOUNT_BARRIER) XFS_BUF_ORDERED(bp); + else + XFS_BUF_UNORDERED(bp); ASSERT(XFS_BUF_ADDR(bp) <= log->l_logBBsize-1); ASSERT(XFS_BUF_ADDR(bp) + BTOBB(count) <= log->l_logBBsize); @@ -1503,6 +1505,8 @@ xlog_sync(xlog_t *log, XFS_BUF_ASYNC(bp); if (log->l_mp->m_flags & XFS_MOUNT_BARRIER) XFS_BUF_ORDERED(bp); + else + XFS_BUF_UNORDERED(bp); dptr = XFS_BUF_PTR(bp); /* * Bump the cycle numbers at the start of each block From owner-xfs@oss.sgi.com Thu Jul 20 22:38:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 22:38:51 -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 k6L5c4DW025905 for ; Thu, 20 Jul 2006 22:38:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19269; Fri, 21 Jul 2006 15:37:24 +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 k6L5bMgw2002832; Fri, 21 Jul 2006 15:37:22 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6L5bJB22002680; Fri, 21 Jul 2006 15:37:19 +1000 (EST) Date: Fri, 21 Jul 2006 15:37:19 +1000 From: Nathan Scott To: Jackson Jones Cc: xfs@oss.sgi.com Subject: Re: Problems cross compiling xfsprogs Message-ID: <20060721153719.E1998769@wobbly.melbourne.sgi.com> References: <20060720114406.0fdf557a@XEONBOX> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060720114406.0fdf557a@XEONBOX>; from jjones@2wire.com on Thu, Jul 20, 2006 at 11:44:06AM -0700 X-archive-position: 8366 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: 1604 Lines: 43 On Thu, Jul 20, 2006 at 11:44:06AM -0700, Jackson Jones wrote: > xfs@oss.sgi.com, Nathan, > > Hi, my name is Jackson Jones, I am working on an embedded linux project. We are > using XFS for our filesystem. I am updating our toolchain to a 2.6.12 kernel > (from a 2.4.25). > > We were using xfsprogs-2.6.25 (which did fine against the 2.4.25 kernel. When > compiling against the 2.6.12 kernel, I got the following error(the entire build > log is attached) >.... > fadvise.o: In function `fadvise_f': > /home/jjones/depot/mp/exp-perf/output/mipsel/build/debug/xfsprogs/io/fadvise.c:122: > undefined reference to `posix_fadvise64' This sounds like you have an ancient libc... is that possible? > I moved up to xfsprogs-2.7.11 and got (entire log is attached). > -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > --tag=gcc -c bit.c libtool: compile: unable to infer tagged configuration > libtool: compile: specify a tag with `--tag' gmake[2]: *** [bit.lo] Error 1 > make[1]: *** [default] Error 2 make[1]: Leaving directory Urgh, I have no idea - libtool Just Works (TM) for me, so I don't mess with it... if you need to pass more options in, bounce us a patch implementing that I guess. > Is there a version (of xfsprogs, which you recommend, or where in the build > script should I insert the --tag=gcc option after the mode=compile? I am Dunno. > guessing the libtool is confused since our compiler is called > mipsel-linux-gcc. Did setting CC in the environment before running configure have any effect? (not sure, I've not done it, but maybe..) cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 20 23:19:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 23:19: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 k6L6JJDW031772 for ; Thu, 20 Jul 2006 23:19:31 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA20034; Fri, 21 Jul 2006 16:18:40 +1000 Message-ID: <44C07168.60904@sgi.com> Date: Fri, 21 Jul 2006 16:17:12 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com Subject: Re: xfs FAQ update for write cache References: <200607200602.k6K62Lsp32974694@snort.melbourne.sgi.com> <200607200955.36136.Martin@lichtvoll.de> In-Reply-To: <200607200955.36136.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8367 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: 3074 Lines: 78 Hi Martin, Martin Steigerwald wrote: > Am Donnerstag 20 Juli 2006 08:02 schrieb Timothy Shimmin: >> Modid: current:xfs-website:212892a >> faq.html - 1.88 - changed >> - Update info about write cache. >> Mention persistent write cache, external logs, >> checking it was actually enabled in xfs msgs. > > Hello Timothy, > > thanks a lot... thats awesome... I have that directory corruption problem > also mentioned in the FAQ on a workstation at work. When you have a new > xfs_check available I can test it. (I know how to compile it under > Knoppix 5 ;-). > > A little feedback: lines are not wrapped in either Firefox or Konqueror > (http://oss.sgi.com/projects/xfs/faq.html). This is for the complete FAQ. > It makes reading it difficult. I believe Nathan has fixed this now. > > It might make sense to include the log messages when barriers are disabled > at the approbiate places of the FAQ: > Yeah, I was thinking of that - like Dave (dgc) did in his reply. If you think that is helpful. > root@deepdance:/usr/src/linux/fs/xfs -> grep -ir "barrier" * > linux-2.6/xfs_super.c:xfs_mountfs_check_barriers(xfs_mount_t *mp) > linux-2.6/xfs_super.c: "Disabling barriers, not supported with > external log device"); > linux-2.6/xfs_super.c: mp->m_flags &= ~XFS_MOUNT_BARRIER; > linux-2.6/xfs_super.c: "Disabling barriers, not supported by > the underlying device"); > linux-2.6/xfs_super.c: mp->m_flags &= ~XFS_MOUNT_BARRIER; > linux-2.6/xfs_super.c: error = xfs_barrier_test(mp); > linux-2.6/xfs_super.c: "Disabling barriers, trial barrier write > failed"); > linux-2.6/xfs_super.c: mp->m_flags &= ~XFS_MOUNT_BARRIER; > > While they are quite self-explanatory it might still help to make it > absolutely clear what each log message mean. Ok. > > Is the last one "Disabling barriers, trial barrier write failed" issued > when the underlying device does not support write barriers? You mean is it the same as the msg: "Disabling barriers, not supported by the underlying device" ;-) I guess the end result is pretty much the same but the test is different. I didn't write the code (Christoph could provide more info here) but looking at it now... The "trial barrier write" actually tries a barrier write on the superblock and sees if we get an error back. Whereas the "not supported by" case, we use the information set by the driver for the block layer - it sets one of the ordered modes as described in the doc you quoted Documentation/block/barrier.txt. We test for QUEUE_ORDERED_NONE to give this message. The doc says: QUEUE_ORDERED_NONE I/O barriers are not needed and/or supported. Looking at IDE case, it would set ordered mode to NONE if write cache was on and not supported by drive. But I guess perhaps the only definitive way to be sure is to try it out and hence the trial write. And as for the external log case, we _may_ end up changing the code to flush on the data device and log device and so not need this message and action. We'll see. Cheers, Tim. From owner-xfs@oss.sgi.com Thu Jul 20 23:28:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Jul 2006 23:28: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 k6L6S4DW000594 for ; Thu, 20 Jul 2006 23:28:16 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA20163; Fri, 21 Jul 2006 16:27:27 +1000 Message-ID: <44C07377.3060209@sgi.com> Date: Fri, 21 Jul 2006 16:25:59 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: xfs@oss.sgi.com, jeremy@sgi.com Subject: Re: review: fix remount vs barrier options References: <20060721152807.D1998769@wobbly.melbourne.sgi.com> In-Reply-To: <20060721152807.D1998769@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8368 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: 951 Lines: 26 Nathan Scott wrote: > Hi, > > Jeremy has had me scratching my head for a few days trying to > figure out how the SCSI traces he's looking at can still show > signs of write barriers being issued to the device, despite a > "remount,nobarrier" having been done. > > It finally clicked that we are not clearing the buffer flag > from a previously written log buffer, even though we'll no > longer set a new flag into a buffer (due to the mount flag > being cleared), so we _can_ still issue barrier writes when > remounted without barriers. > > This was made more complicated by the way a freshly mounted > filesystem with 8 log buffers wouldn't show up the problem, > since we have to slowly cycle through the "clear" log buffers > before we see the bug. This seems like the simplest fix... > > (Hmmm, actually, I wonder if this will also resolve the quota > log I/O problem that was reported the other day too). > Patch looks good to me. --Tim From owner-xfs@oss.sgi.com Fri Jul 21 01:06:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 01:06: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 k6L865DW020183 for ; Fri, 21 Jul 2006 01:06:16 -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 SAA21874 for ; Fri, 21 Jul 2006 18:05:30 +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 k6L854Eo33929511 for ; Fri, 21 Jul 2006 18:05:05 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6L853br33936230 for linux-xfs@oss.sgi.com; Fri, 21 Jul 2006 18:05:03 +1000 (AEST) Date: Fri, 21 Jul 2006 18:05:03 +1000 (AEST) From: Timothy Shimmin Message-Id: <200607210805.k6L853br33936230@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE faq.html - barrier disable msg clarification X-archive-position: 8369 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 472 Lines: 16 Date: Fri Jul 21 01:03:59 PDT 2006 Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-website/current Modid: current:xfs-website:212950a faq.html - 1.93 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/faq.html.diff?r1=text&tr1=1.93&r2=text&tr2=1.92&f=h - Give more info and list the msgs for disabling barrier support. Martin Steigerwald suggested that clarification would be useful here. --Tim From owner-xfs@oss.sgi.com Fri Jul 21 02:26:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 02:27:09 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6L9QvDW031347 for ; Fri, 21 Jul 2006 02:26:57 -0700 Received: from localhost (dslb-084-056-091-176.pools.arcor-ip.net [84.56.91.176]) by mondschein.lichtvoll.de (Postfix) with ESMTP id D7397FA6B5 for ; Fri, 21 Jul 2006 11:23:47 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: xfs FAQ update for write cache Date: Fri, 21 Jul 2006 11:26:26 +0200 User-Agent: KMail/1.9.3 References: <200607200602.k6K62Lsp32974694@snort.melbourne.sgi.com> <200607200955.36136.Martin@lichtvoll.de> <44C07168.60904@sgi.com> In-Reply-To: <44C07168.60904@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607211126.26833.Martin@lichtvoll.de> X-archive-position: 8370 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 953 Lines: 31 Am Freitag 21 Juli 2006 08:17 schrieb Timothy Shimmin: > > A little feedback: lines are not wrapped in either Firefox or > > Konqueror (http://oss.sgi.com/projects/xfs/faq.html). This is for the > > complete FAQ. It makes reading it difficult. > > I believe Nathan has fixed this now. Hello Timothy, yes. And it makes a huge difference in readability. > > While they are quite self-explanatory it might still help to make it > > absolutely clear what each log message mean. > > Ok. Thanks for updating the FAQ. The XFS FAQ has the best and the only coverage on write caching and write barrier! No mention of it in ext3, Reiser(fs) and JFS FAQs. BTW I can do a review of the complete FAQ. I have written lots of documentation and articles. Contact me when you are interested. But first I continue writing my article ;) Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Fri Jul 21 03:48:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 03:49:19 -0700 (PDT) Received: from rzcomm12.rz.tu-bs.de (rzcomm12.rz.tu-bs.de [134.169.9.59]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6LAmbDW009627 for ; Fri, 21 Jul 2006 03:48:43 -0700 Received: from [134.169.64.209] (imt81.imt.ing.tu-bs.de [134.169.64.209]) by rzcomm12.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id k6LAmE022302 for ; Fri, 21 Jul 2006 12:48:15 +0200 (METDST) Message-ID: <44C0B0E4.7020403@l4x.org> Date: Fri, 21 Jul 2006 12:48:04 +0200 From: Jan Dittmer User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Userspace cp and ls utility Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8371 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jdi@l4x.org Precedence: bulk X-list: xfs Content-Length: 245 Lines: 11 Are there utilities for xfs which are able to ls and cp from an _unmounted_ xfs volume? I fear that by mounting the volume - even ro - I would lose even more data. Or can I achieve such an effect with other xfs related utilities? Thanks, Jan From owner-xfs@oss.sgi.com Fri Jul 21 06:11:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 06:12:09 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6LDB5DW032181 for ; Fri, 21 Jul 2006 06:11:39 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6LDAbCk030521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 09:10:37 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Chris Wedgwood Cc: Peter Grandi , Linux XFS In-Reply-To: <20060721032632.GA4138@tuatara.stupidest.org> References: <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> <20060720190401.GA28836@tuatara.stupidest.org> <1153441178.2768.158.camel@localhost.localdomain> <20060721032632.GA4138@tuatara.stupidest.org> Content-Type: text/plain Date: Fri, 21 Jul 2006 09:10:31 -0400 Message-Id: <1153487431.2841.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8373 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 801 Lines: 26 On Thu, 2006-07-20 at 20:26 -0700, Chris Wedgwood wrote: > On Thu, Jul 20, 2006 at 08:19:38PM -0400, Ming Zhang wrote: > > > what will be the side effect about this scattering? > > there is a desire in some cases to have files in the same directory > close to each other on disk then what is the benefit? because files under same dir can be accessed with locality so put close will reduce disk head seek? other than this, what else benefit? > > > one thing i worry about fsr is when do fsr and some power loss > > events happen, can xfs handle this well? > > yes, fsr create a temporary file, unlinks it, copies the extents over, > and does an atomic swap-extents-if-nothing-changed operation so if i have 500GB file, will it be copied to another 500GB temp file? sounds scary for me. Ming From owner-xfs@oss.sgi.com Fri Jul 21 06:45:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 06:45:21 -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 k6LDj8DW004356 for ; Fri, 21 Jul 2006 06:45:10 -0700 Received: by nf-out-0910.google.com with SMTP id a27so784155nfc for ; Fri, 21 Jul 2006 06:44:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=T23jmPipy7qHt0cDp+nqze4MF2xGT7l2msSwhZwjgLmms6HbJQEjQMQkvy8Kbv2afLbty8qwh/wYcxqcivuzEwmf4N3ietoSevMG3umyUeecETFle8JA31k5NstKTf1gaiyCQxF81hZ/B5C2oRxtaY5XkJyPqelcjAq2r8tsWkM= Received: by 10.78.166.7 with SMTP id o7mr313533hue; Fri, 21 Jul 2006 05:19:34 -0700 (PDT) Received: by 10.78.159.14 with HTTP; Fri, 21 Jul 2006 05:19:34 -0700 (PDT) Message-ID: <68559cef0607210519q9f382c6n7104bef9cf9716f3@mail.gmail.com> Date: Fri, 21 Jul 2006 14:19:34 +0200 From: "Luca Maranzano" To: xfs@oss.sgi.com Subject: Page allocation failure writing to an XFS volume via NFS on CentOS 4.3 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 8374 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liuk001@gmail.com Precedence: bulk X-list: xfs Content-Length: 5301 Lines: 143 Hello all, we have a CentOS 4.3 Server on an HP DL 380G3, 1 Xeon 2,8 Ghz (no hyperthreading), 1GB RAM. Kernel: 2.6.9-34.0.2.EL Xfs: - xfsprogs-2.7.3-1 - kernel-module-xfs-2.6.9-34.EL-0.1-3 modinfo xfs: filename: /lib/modules/2.6.9-34.0.2.EL/extra/xfs.ko author: Silicon Graphics, Inc. description: SGI-XFS CVS-2004-10-17_05:00_UTC with ACLs, security attributes, realtime, large block numbers, no debug enabled license: GPL vermagic: 2.6.9-34.EL 686 REGPARM 4KSTACKS gcc-3.4 depends: The server has 1 Emulex Lp9002 with 3 LUNs of our SAN. 2 LUNs are forming a Striped LVM2 volume of 2,7 TB (/sansata/big) 1 LUN is an LVM2 volume of 1,5 TB (/sansata/medium) Both LVs are exported via NFS and are formatted with XFS. Today, while transfering data via NFS from another server to /sansata/medium, we got the following error: kswapd0: page allocation failure. order:0, mode:0xd0 [] __alloc_pages+0x2e1/0x2f7 [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x15/0x94 [] cache_grow+0x107/0x233 [] cache_alloc_refill+0x1f7/0x227 [] kmem_cache_alloc+0x46/0x4c [] mempool_alloc+0xb6/0x1f9 [] autoremove_wake_function+0x0/0x2d [] autoremove_wake_function+0x0/0x2d [] EmsPlatformCreateIo+0x2a/0x60 [emcp] [] allocPio+0x18/0x40 [emcp] [] emcp_pseudo_mrf+0x27/0x60 [emcp] [] generic_make_request+0x190/0x1a0 [] bio_clone+0x8b/0xa3 [] __map_bio+0x34/0xb4 [dm_mod] [] __clone_and_map+0xc3/0x2c9 [dm_mod] [] __alloc_pages+0x1b1/0x2f7 [] __split_bio+0xaa/0x108 [dm_mod] [] dm_request+0xde/0xf1 [dm_mod] [] generic_make_request+0x190/0x1a0 [] autoremove_wake_function+0x0/0x2d [] submit_bio+0xa4/0xac [] bio_alloc+0x100/0x168 [] submit_bh+0x13e/0x163 [] xfs_submit_page+0x84/0xa8 [xfs] [] xfs_convert_page+0x1e0/0x1f4 [xfs] [] xfs_cluster_write+0x39/0x43 [xfs] [] xfs_page_state_convert+0x4c0/0x50c [xfs] [] linvfs_writepage+0x91/0xc6 [xfs] [] pageout+0x88/0xc5 [] shrink_list+0x209/0x4ea [] shrink_cache+0x1ff/0x454 [] shrink_slab+0x7d/0x14c [] shrink_zone+0x8f/0x9e [] balance_pgdat+0x197/0x2cb [] kswapd+0xb9/0xbb [] autoremove_wake_function+0x0/0x2d [] ret_from_fork+0x6/0x14 [] autoremove_wake_function+0x0/0x2d [] kswapd+0x0/0xbb [] kernel_thread_helper+0x5/0xb Mem-info: DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 HighMem per-cpu: cpu 0 hot: low 14, high 42, batch 7 cpu 0 cold: low 0, high 14, batch 7 Free pages: 280kB (280kB HighMem) Active:3798 inactive:247509 dirty:671 writeback:14620 unstable:0 free:70 slab:4738 mapped:3512 pagetables:249 DMA free:0kB min:16kB low:32kB high:48kB active:40kB inactive:12344kB present:16384kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 Normal free:0kB min:936kB low:1872kB high:2808kB active:2236kB inactive:865676kB present:901120kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 HighMem free:280kB min:128kB low:256kB high:384kB active:12916kB inactive:112016kB present:131048kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB HighMem: 0*4kB 15*8kB 4*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 280kB Swap cache: add 35191, delete 34409, find 16993/22779, race 0+0 0 bounce buffer pages Free swap: 1040416kB 262138 pages of RAM 32762 pages of HIGHMEM 3180 reserved pages 48473 pages shared 782 pages swap cached Despite this, the data transfer has completed at a reasonable speed and the file seems to be correct (it is a gz file and "gzip -vt" reports OK). I can't say if this is a real XFS issue, but I'd like to share with you my doubts about the stability of this setup, since this server is used as a "disk library" to backup a lot of data which are then backed up to a LTO Library via Netbackup. I'm very happy about the performance of the XFS partitions (on the Striped LVM DBench reported about 209 MB/s for 16 clients, bonnie++ reported 60MB/s for sequential block writing) and I'm always been an XFS fan :-). I've some suspect about the 4KSTACKS issues and the 2.4.9-x kernel used by RedHat 4 or CentOS 4.3: are there any known problems with this version of kernel? Please see also my other post about "xfs: possible memory allocation deadlock in _pagebuf_lookup_pages" of some days ago. From what I've read searching the Net it seems that XFS and RedHat are not big friends, correct me if I'm wrong :-/. I'd like to try latest SuSE as an alternative, since I need certified support for our EMC SAN Storage, but I cannot go back and reinstall all at this point. Let me know if you need more info. Your considerations are welcome. Thanks in advance. Cheers, Luca From owner-xfs@oss.sgi.com Fri Jul 21 09:13:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 09:14:04 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6LGDoDW027855 for ; Fri, 21 Jul 2006 09:13:50 -0700 Received: (qmail 36834 invoked from network); 21 Jul 2006 16:13:28 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2006 16:13:27 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id CDB72182727F; Fri, 21 Jul 2006 09:13:26 -0700 (PDT) Date: Fri, 21 Jul 2006 09:13:26 -0700 From: Chris Wedgwood To: Luca Maranzano Cc: xfs@oss.sgi.com Subject: Re: Page allocation failure writing to an XFS volume via NFS on CentOS 4.3 Message-ID: <20060721161326.GE12347@tuatara.stupidest.org> References: <68559cef0607210519q9f382c6n7104bef9cf9716f3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68559cef0607210519q9f382c6n7104bef9cf9716f3@mail.gmail.com> X-archive-position: 8376 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: 170 Lines: 6 On Fri, Jul 21, 2006 at 02:19:34PM +0200, Luca Maranzano wrote: > kswapd0: page allocation failure. order:0, mode:0xd0 you're out of memory, see what's being so piggy From owner-xfs@oss.sgi.com Fri Jul 21 09:07:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 09:08:03 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6LG7ZDW027050 for ; Fri, 21 Jul 2006 09:07:39 -0700 Received: (qmail 62307 invoked from network); 21 Jul 2006 16:07:11 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2006 16:07:10 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 5BE1C182727F; Fri, 21 Jul 2006 09:07:09 -0700 (PDT) Date: Fri, 21 Jul 2006 09:07:09 -0700 From: Chris Wedgwood To: Ming Zhang Cc: Peter Grandi , Linux XFS Subject: Re: stable xfs Message-ID: <20060721160709.GB12347@tuatara.stupidest.org> References: <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> <20060720190401.GA28836@tuatara.stupidest.org> <1153441178.2768.158.camel@localhost.localdomain> <20060721032632.GA4138@tuatara.stupidest.org> <1153487431.2841.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153487431.2841.8.camel@localhost.localdomain> X-archive-position: 8375 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: 1416 Lines: 35 On Fri, Jul 21, 2006 at 09:10:31AM -0400, Ming Zhang wrote: > then what is the benefit? because files under same dir can be accessed > with locality so put close will reduce disk head seek? yes > other than this, what else benefit? that alone has a measurable benefit to me (i have an overlay filesystem over many smaller 400 to 500GB filesystems so i don't get the benefit of many spindles to reduce average seek times) > so if i have 500GB file, will it be copied to another 500GB temp > file? yes, which in many cases isn't always derisable because: * if the file had a small number of extents in the first place, reducing them slightly more isn't much of a gain (ie. going from say 11 to 10 is argubly pointless) (i have a patch to specifiy the miniumum gains before doing the copy somewhere) * if the file changes during the copy, then it will be skipped until next time, for larger files this is problematic, you could argue attemtping to fsr a file that is less than seconds old is pointless as it has a high chance of being active (i have a patch for that too)) * fsr has no global overview of what it's doing, so it never does things like 'move this file out of the way to make room for this one' (it can't do this w/o assistance right now), and of course it can't move inodes w/o changing them so there are limits to what can be done anyhow From owner-xfs@oss.sgi.com Fri Jul 21 10:01:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 10:01:32 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6LH1JDW002953 for ; Fri, 21 Jul 2006 10:01:20 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6LH0nh0023416 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 13:00:50 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Chris Wedgwood Cc: Peter Grandi , Linux XFS In-Reply-To: <20060721160709.GB12347@tuatara.stupidest.org> References: <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> <20060720190401.GA28836@tuatara.stupidest.org> <1153441178.2768.158.camel@localhost.localdomain> <20060721032632.GA4138@tuatara.stupidest.org> <1153487431.2841.8.camel@localhost.localdomain> <20060721160709.GB12347@tuatara.stupidest.org> Content-Type: text/plain Date: Fri, 21 Jul 2006 13:00:44 -0400 Message-Id: <1153501244.2841.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8377 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1849 Lines: 53 On Fri, 2006-07-21 at 09:07 -0700, Chris Wedgwood wrote: > On Fri, Jul 21, 2006 at 09:10:31AM -0400, Ming Zhang wrote: > > > then what is the benefit? because files under same dir can be accessed > > with locality so put close will reduce disk head seek? > > yes > > > other than this, what else benefit? > > that alone has a measurable benefit to me (i have an overlay > filesystem over many smaller 400 to 500GB filesystems so i don't get > the benefit of many spindles to reduce average seek times) what u mean overlay fs over small fs? like a unionfs? > > > so if i have 500GB file, will it be copied to another 500GB temp > > file? > but other than fsr. there is no better way for this right? of course, preallocate is always good. but i do not have control over applications. > yes, which in many cases isn't always derisable because: > > * if the file had a small number of extents in the first place, > reducing them slightly more isn't much of a gain (ie. going from > say 11 to 10 is argubly pointless) (i have a patch to specifiy > the miniumum gains before doing the copy somewhere) > > * if the file changes during the copy, then it will be skipped until > next time, for larger files this is problematic, you could > argue attemtping to fsr a file that is less than seconds old > is pointless as it has a high chance of being active (i have a > patch for that too)) sounds like a useful patch. :P will it be merged into fsr code? > > * fsr has no global overview of what it's doing, so it never does > things like 'move this file out of the way to make room for this > one' (it can't do this w/o assistance right now), and of course it > can't move inodes w/o changing them so there are limits to what > can be done anyhow what kind of assistance you mean? > From owner-xfs@oss.sgi.com Fri Jul 21 11:07:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 11:07:50 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6LI7VDW011398 for ; Fri, 21 Jul 2006 11:07:35 -0700 Received: (qmail 94302 invoked from network); 21 Jul 2006 18:07:08 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2006 18:07:08 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 50770182727F; Fri, 21 Jul 2006 11:07:07 -0700 (PDT) Date: Fri, 21 Jul 2006 11:07:07 -0700 From: Chris Wedgwood To: Ming Zhang Cc: Peter Grandi , Linux XFS Subject: Re: stable xfs Message-ID: <20060721180707.GB13892@tuatara.stupidest.org> References: <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> <20060720190401.GA28836@tuatara.stupidest.org> <1153441178.2768.158.camel@localhost.localdomain> <20060721032632.GA4138@tuatara.stupidest.org> <1153487431.2841.8.camel@localhost.localdomain> <20060721160709.GB12347@tuatara.stupidest.org> <1153501244.2841.50.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153501244.2841.50.camel@localhost.localdomain> X-archive-position: 8378 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: 3562 Lines: 85 On Fri, Jul 21, 2006 at 01:00:44PM -0400, Ming Zhang wrote: > what u mean overlay fs over small fs? like a unionfs? sorta not really, it's userspace libraries which create a virtual filesystem over real filesystems with some database (bezerkely db). it sorta evolved from an attempt to unify several filesystems spread over cheap PCs into something that pretended to be one larger fs > but other than fsr. there is no better way for this right? not publicly, you could patch fsr or nag me for my patches if that helps > of course, preallocate is always good. but i do not have control > over applications. well, in some cases you could use LD_PRELOAD and influence things, it depends on the application and what you need from it fwiw, most modern p2p applicaitons have terribly access patterns which cause cause horrible fragmentation (on all fs's, not just XFS) > sounds like a useful patch. :P will it be merged into fsr code? no, because it's ugly and i don't think i ever decoupled it from other changes and posted it > what kind of assistance you mean? [WARNING: lots of hand waving ahead, plenty of minor, but important, details ignored] if you wanted much smarter defragmentation semantics, it would probably make sense to * bulkstat the entire volume, this will give you the inode cluster locations and enough information to start building a tree of where all the files are (XFS_IOC_FSGEOMETRY details obviously) * opendir/read to build a full directory tree * use XFS_IOC_GETBMAP & XFS_IOC_GETBMAPA to figure out which blocks are occupied by which files you would now have a pretty good idea of what is using what parts of the disk, except of course it could be constantly changing underneath you to make things harder also, doing this using the existing interfaces is (when i tried it) really really painfully slow if you have a large filesystem with a lot of small files (even when you try to optimized you accesses for minimize seeking by sorting by inode number and submitting several requests in parallel to try and help the elevator merge accesses) one you have some overall picture of the disk, you can decide what you want to move to achieve your goal, typically this would be to reduce the fragmentation of the largest files, and this would be be relocating some of all of those blocks to another place if you want to allocate space in a given AG, you open/creat a temporary file in a directory in that AG (create multiple dirs as needed to ensure you have one or more of these), and preallocate the space --- there you can copy the file over we could also add ioctls to further bias XFSs allocation strategies, like telling it to never allocate in some AGs (needed for an online shrink if someone wanted to make such a thing) or simply bias strongly away from some places, then add other ioctls to allow you to specifically allocate space in those AGs so you can bias what is allocated where another useful ioctl would be a variation of XFS_IOC_SWAPEXT which would swap only some extents. there is no internal support for this now except we do have code for XFS_IOC_UNRESVSP64 and XFS_IOC_RESVSP64 so perhaps the idea would be to swap some (but not all) blocks of a file by creating a function that do the equivalent of 'punch a hole' where we want to replace the blocks, and then 'allocate new blocks given some i already have elsewhere' (however, making that all work as one transaction might be very very difficult) it's a lot of effort for what for many people wouldn't only have marginal gains From owner-xfs@oss.sgi.com Fri Jul 21 15:59:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 16:00:30 -0700 (PDT) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6LMxWDW012338 for ; Fri, 21 Jul 2006 15:59:39 -0700 Received: (qmail 22644 invoked by uid 10); 21 Jul 2006 22:59:00 -0000 Received: from planetzork.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 21 Jul 2006 22:59:00 -0000 Received: (qmail 12322 invoked by uid 1000); 22 Jul 2006 00:58:05 +0200 Date: Sat, 22 Jul 2006 00:58:05 +0200 From: Jochen Heuer To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Ingo Molnar , nathans@sgi.com, xfs@oss.sgi.com Subject: Re: BUG: soft lockup detected on CPU#1! Message-ID: <20060721225805.GB12184@planetzork.ping.de> References: <20060717125216.GA15481@planetzork.ping.de> <1153146608.1218.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153146608.1218.9.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 X-archive-position: 8379 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jogi-kernel@planetzork.ping.de Precedence: bulk X-list: xfs Content-Length: 3586 Lines: 68 Hi everyone. > > Jul 17 09:23:03 [kernel] [] crypt+0xee/0x1e0 > > Jul 17 09:23:03 [kernel] [] crypt_iv_unaligned+0x3f/0xc0 > > Jul 17 09:23:03 [kernel] [] cbc_decrypt_iv+0x3d/0x50 > > Jul 17 09:23:03 [kernel] [] crypt_convert_scatterlist+0x117/0x170 > > Jul 17 09:23:03 [kernel] [] crypt_convert+0x142/0x190 > > Jul 17 09:23:03 [kernel] [] kcryptd_do_work+0x42/0x60 > > Jul 17 09:23:03 [kernel] [] run_workqueue+0x6f/0xe0 > > Jul 17 09:23:03 [kernel] [] worker_thread+0x128/0x150 > > Jul 17 09:23:03 [kernel] [] kthread+0xa4/0xe0 > > Jul 17 09:23:03 [kernel] [] kernel_thread_helper+0x5/0x10 > > Jul 17 09:24:17 [kernel] ============================================= > > Jul 17 09:24:17 [kernel] [ INFO: possible recursive locking detected ] > > Jul 17 09:24:17 [kernel] --------------------------------------------- > > This looks like a separate issue, and something more about fixing > lockdep not to report it instead of an actual bug (and why I CC'd the > xfs folks and Ingo). > > Probably XFS needs to tell lockdep about it's nesting. But maybe there > is a bug that is lying in there somewhere. I have some more of these. Now they look like this every time I get them: Jul 19 18:43:15 [kernel] ============================================= Jul 19 18:43:15 [kernel] [ INFO: possible recursive locking detected ] Jul 19 18:43:15 [kernel] --------------------------------------------- Jul 19 18:43:15 [kernel] qmail-local/9368 is trying to acquire lock: Jul 19 18:43:15 [kernel] (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x60/0xb0 Jul 19 18:43:15 [kernel] but task is already holding lock: Jul 19 18:43:15 [kernel] (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x60/0xb0 Jul 19 18:43:15 [kernel] other info that might help us debug this: Jul 19 18:43:15 [kernel] 2 locks held by qmail-local/9368: Jul 19 18:43:15 [kernel] #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x30 Jul 19 18:43:15 [kernel] #1: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x60/0xb0 Jul 19 18:43:15 [kernel] stack backtrace: Jul 19 18:43:15 [kernel] [] show_trace+0x12/0x20 Jul 19 18:43:15 [kernel] [] dump_stack+0x19/0x20 Jul 19 18:43:15 [kernel] [] print_deadlock_bug+0xb9/0xd0 Jul 19 18:43:15 [kernel] [] check_deadlock+0x6b/0x80 Jul 19 18:43:15 [kernel] [] __lock_acquire+0x354/0x990 Jul 19 18:43:15 [kernel] [] lock_acquire+0x75/0xa0 Jul 19 18:43:15 [kernel] [] down_write+0x3f/0x60 Jul 19 18:43:15 [kernel] [] xfs_ilock+0x60/0xb0 Jul 19 18:43:15 [kernel] [] xfs_iget_core+0x2aa/0x5b0 Jul 19 18:43:15 [kernel] [] xfs_iget+0xcc/0x150 Jul 19 18:43:15 [kernel] [] xfs_trans_iget+0xa8/0x140 Jul 19 18:43:15 [kernel] [] xfs_ialloc+0xaf/0x4c0 Jul 19 18:43:15 [kernel] [] xfs_dir_ialloc+0x6d/0x280 Jul 19 18:43:15 [kernel] [] xfs_create+0x241/0x670 Jul 19 18:43:15 [kernel] [] xfs_vn_mknod+0x1ed/0x2e0 Jul 19 18:43:15 [kernel] [] xfs_vn_create+0x12/0x20 Jul 19 18:43:15 [kernel] [] vfs_create+0x7d/0xd0 Jul 19 18:43:15 [kernel] [] open_namei+0xbf/0x620 Jul 19 18:43:15 [kernel] [] do_filp_open+0x2c/0x60 Jul 19 18:43:15 [kernel] [] do_sys_open+0x50/0xe0 Jul 19 18:43:15 [kernel] [] sys_open+0x1c/0x20 Jul 19 18:43:15 [kernel] [] sysenter_past_esp+0x56/0x8d Best regards, Jochen From owner-xfs@oss.sgi.com Fri Jul 21 15:59:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 16:00:32 -0700 (PDT) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6LMxWDW012337 for ; Fri, 21 Jul 2006 15:59:39 -0700 Received: (qmail 22613 invoked by uid 10); 21 Jul 2006 22:59:00 -0000 Received: from planetzork.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 21 Jul 2006 22:59:00 -0000 Received: (qmail 12235 invoked by uid 1000); 22 Jul 2006 00:53:04 +0200 Date: Sat, 22 Jul 2006 00:53:04 +0200 From: Jochen Heuer To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Ingo Molnar , nathans@sgi.com, xfs@oss.sgi.com Subject: Re: BUG: soft lockup detected on CPU#1! Message-ID: <20060721225304.GA12184@planetzork.ping.de> References: <20060717125216.GA15481@planetzork.ping.de> <1153146608.1218.9.camel@localhost.localdomain> <20060717144831.GA28284@planetzork.ping.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060717144831.GA28284@planetzork.ping.de> User-Agent: Mutt/1.5.11 X-archive-position: 8380 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jogi-kernel@planetzork.ping.de Precedence: bulk X-list: xfs Content-Length: 1153 Lines: 31 On Mon, Jul 17, 2006 at 04:48:31PM +0200, Jochen Heuer wrote: > On Mon, Jul 17, 2006 at 10:30:08AM -0400, Steven Rostedt wrote: > > > > Jochen, you didn't say whether or not the 2.6.18-rc2 locked up. I'm > > assuming it did. But did it? > > Hi Steven, > > no, it did not lock up yet but I did not do any "serious" webbrowsing > with 2.6.18-rc2 so far. Hi, well, it locks up with 2.6.18-rc2 too. Three times today. And always during webbrowsing ... What's so special about it? Could it be because it accesses network and disk at the same time? The system has been pretty busy compiling the last days because I did setup a new Gentoo system in chroot environment. No problem whatsoever. I did run 2 x mprime for a day and also no problem. Is there anything I can test? Disable irq balancing? Disabling preemption did not help. Disabling IO-APIC? What can I do to help isolate the problem because it really is annoying and I don't like pushing the reset button. Because if the system locks up *really* nothing works. The screen is frozen, no mouse, no keyboard, no sys-rq, no network ... nothing. Thanks for your help and best regards, Jochen From owner-xfs@oss.sgi.com Fri Jul 21 18:36:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Jul 2006 18:36:52 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6M1agDW004171 for ; Fri, 21 Jul 2006 18:36:42 -0700 Received: from linux01.gwdg.de ([134.76.13.21]) by mailer.gwdg.de with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60) (envelope-from ) id 1G447P-0001IE-7k; Sat, 22 Jul 2006 01:09:16 +0200 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k6LN6cqP019292; Sat, 22 Jul 2006 01:06:40 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k6LN6cfd019282; Sat, 22 Jul 2006 01:06:38 +0200 Date: Sat, 22 Jul 2006 01:06:38 +0200 (MEST) From: Jan Engelhardt To: Justin Piszcz cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, Neil Brown , xfs@oss.sgi.com Subject: Re: Raid5 Reshape Status + xfs_growfs = Success! (2.6.17.3) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8381 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 192 Lines: 11 On Jul 11 2006 12:03, Justin Piszcz wrote: >Subject: Raid5 Reshape Status + xfs_growfs = Success! (2.6.17.3) Now we just need shrink-reshaping and xfs_shrinkfs... :) Jan Engelhardt -- From owner-xfs@oss.sgi.com Sat Jul 22 02:31:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 02:32:04 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6M9VlDW022775 for ; Sat, 22 Jul 2006 02:31:48 -0700 Received: from localhost (dslb-084-056-114-021.pools.arcor-ip.net [84.56.114.21]) by mondschein.lichtvoll.de (Postfix) with ESMTP id D61ABFA8A7 for ; Sat, 22 Jul 2006 11:28:29 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier Date: Sat, 22 Jul 2006 11:31:15 +0200 User-Agent: KMail/1.9.3 References: <200607151248.56603.Martin@lichtvoll.de> <200607182027.49648.Martin@lichtvoll.de> <20060718192135.GV15160733@melbourne.sgi.com> In-Reply-To: <20060718192135.GV15160733@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607221131.16238.Martin@lichtvoll.de> X-archive-position: 8382 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1937 Lines: 49 Am Dienstag 18 Juli 2006 21:21 schrieb David Chinner: > > > blkdev_issue_flush() causes a write cache flush - just like a > > > barrier typically causes a write cache flush up to the I/O with the > > > barrier in it. Both of these mechanisms provide the same thing - > > > an I/O barrier that enforces ordering of I/Os to disk. > > > > Hello David, > > > > well now it gets interesting. If both provide the same thing, whats > > the difference? > > A WRITE_BARRIER I/O can be optimised by smart drivers, protocols and > hardware to minimise the adverse effects of the barrier, whereas a > cache flush is a brute force cache cleaning mechanism that cannot be > optimised.... Hello David, I like to understand this difference a bit better. As far as I understand there are three important differences between blkdev_issue_flush() and using the new barrier functionality: 1) blkdev_issue_flush() issues a cache flush synchronously and the filesystem has to wait for it to return. OTOH a write barrier is like a asynchron cache flush: The filesystem sends a barrier request to the block layer and forgets about it then. It can handle other stuff in the meanwhile while block layer will take care of the correct order of the write requests. 2) Since the filesystem offloads the ordering of the requests to the block layer, block layer can support smart drivers, protocols and hardware to optimize request ordering (say TCQ devices for example). 3) A direct cache flush means that the cache flush has to happen immediately while with a barrier it can happen some time in the future given that it happens before the barrier request is issued. So the advantages of the barrier functionality that is that it provides request ordering at a lower cost for the filesystem. Anything to add or correct? Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sat Jul 22 05:18:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 05:18:49 -0700 (PDT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6MCIBDW012463 for ; Sat, 22 Jul 2006 05:18:15 -0700 Received: from [192.168.1.11] ([213.114.216.208] [213.114.216.208]) by mxfep02.bredband.com with ESMTP id <20060722103623.VVIK3659.mxfep02.bredband.com@[192.168.1.11]>; Sat, 22 Jul 2006 12:36:23 +0200 Message-ID: <44C1FFA3.1050805@stesmi.com> Date: Sat, 22 Jul 2006 12:36:19 +0200 From: Stefan Smietanowski User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com Subject: Re: XFS and write barrier References: <200607151248.56603.Martin@lichtvoll.de> <200607182027.49648.Martin@lichtvoll.de> <20060718192135.GV15160733@melbourne.sgi.com> <200607221131.16238.Martin@lichtvoll.de> In-Reply-To: <200607221131.16238.Martin@lichtvoll.de> X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig5AA663FDD0F88E9C46B816A2" X-archive-position: 8385 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Content-Length: 853 Lines: 28 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5AA663FDD0F88E9C46B816A2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit > immediately while with a barrier it can happen some time in the future > given that it happens before the barrier request is issued. Timetravel? // Stefan --------------enig5AA663FDD0F88E9C46B816A2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEwf+nBrn2kJu9P78RA4WoAJ9XmpyP156zjsy49tanoZQ8/IgVbACgl2CG hvmcUGtlQP3O4IFZDna8sLo= =bj9k -----END PGP SIGNATURE----- --------------enig5AA663FDD0F88E9C46B816A2-- From owner-xfs@oss.sgi.com Sat Jul 22 10:45:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 10:45:33 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6MHjLDW015192 for ; Sat, 22 Jul 2006 10:45:21 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G4LZj-00040s-3Z for ; Sat, 22 Jul 2006 18:47:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <17602.25786.352484.487632@base.ty.sabi.co.UK> Date: Sat, 22 Jul 2006 18:47:38 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <1153404502.2768.50.camel@localhost.localdomain> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k6MHjMDW015199 X-archive-position: 8391 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 1522 Lines: 43 >>> On Thu, 20 Jul 2006 10:08:22 -0400, Ming Zhang >>> said: [ ... ] mingz> hope i never need to run repair, A ''strategic'' attitude :-). mingz> but i do need to defrag from time to time. As to defrag, I reckon that defrag-in-place is a very bad idea, but I have to admit that contrary evidence exists, and I was rather surprised to read this: http://OSS.SGI.com/archives/xfs/2006-03/msg00110.html «> How many people defrag their filesystems using xfs_fsr > /dev/PARTITION if their fragmentation is > 50% etc? Does > anyone regularly defrag their production filesystems or > just defrag their filesystems on a regular basis? We have several hundred production filesystems defragmented every night.» Even so I think that defragment-by-copy is a much better option. mingz> [ ... ] we mainly handle large media files like 20-50GB. mingz> [ ....] hope this does not hold true for a 15x750GB SATA mingz> raid5. ;) mingz> [ ... ] say XFS can make use of parallel storage by using mingz> multiple allocation groups. but XFS need to be built over mingz> one block device. so if i have 4 smaller raid, i have to mingz> use LVM to glue them before i create XFS over it right? Well, I'll just hint that I cannot find euphemisms suitable for expressing what I think of this setup :-). mingz> but then u said XFS over LVM or N MD is not good? It was me saying that [euphemism alert!] I would not recommend a setup like that without understanding very well the consequences. From owner-xfs@oss.sgi.com Sat Jul 22 10:45:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 10:45:29 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6MHjHDW015160 for ; Sat, 22 Jul 2006 10:45:17 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G4L2h-0003z3-9k for ; Sat, 22 Jul 2006 18:13:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17602.23734.534732.678392@base.ty.sabi.co.UK> Date: Sat, 22 Jul 2006 18:13:26 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <1153320304.2691.56.camel@localhost.localdomain> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <20060719055621.GA1491@tuatara.stupidest.org> <17598.3876.565887.172598@base.ty.sabi.co.UK> <1153320304.2691.56.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 8389 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 3546 Lines: 89 >>> On Wed, 19 Jul 2006 10:45:04 -0400, Ming Zhang >>> said: [ ... ] >> Also, if one does a number of smaller RAID5s, is each one a >> separate filesystem or they get aggregated, for example with >> LVM with ''concat''? Either way, how likely is is that the >> consequences have been thought through? >> >> I would personally hesitate to recommend either, especially a >> two-level arrangement where the base level is a RAID5. mingz> could u give us some hints on this? Well, RAID5 itself is in general a very bad idea, as well argued here: and a LVM based concat (which is the slow version of RAID0) of RAID5 volumes has quite terrible performance and redundancy aspects that nicely match those of RAID5. Imagine a 4TB volume build as a concat/span of 4 RAID5 volumes, each done as a 1TB RAID5 of 4+1 250GB disks. Under which conditions do you lose the whole lot? Compare the same with a RAID0 of RAID1 pairs... mingz> since it is really popular to have a FS/LV/MD structure Sure, and it is also really popular to do 5+1 or 11+1 RAID5s and to stuff them all with disks of the same model, and even from the same shipping carton... mingz> and I believe LVM is designed for this purpose. Yes and no. LVM's main purpose, if any, is to outgrow the limitation on the number of partitions in most, and PC-based in particular, partitioning schemes. This means that LVM is of benefit only in very few cases, those where one needs a lot of partitions (as such, not as a cheap quota scheme). [ ... ] >> ''who cares if the metadata is consistent, if my 3TiB >> application database is unusable (and I don't do backups >> because after all it is a concat of RAID5s, backups are not >> necessary) as there is a huge gap in some data file, and my >> users are yelling at me, and it is not my fault'' >> The tradeoff in XFS is that if you know exactly what you are >> doing you get extra performance... mingz> then i think unless you disable all write cache, Not even then, because storage subsystems often do lie about that. Only very clever system integrators and usually only those with a big wallet can manage to build storage subsystems with reliable caching semantics (including write barriers). mingz> none of the file system can achieve this goal. Well, some people might want to argue that a filesystem *should not* be designed to achieve that goal, because it is a goal that does not make sense in an ideal world in which people know exactly what they are doing. mingz> or maybe ext3 with both data and metadata into log might mingz> do this? Well, 'data=ordered' and especially 'data=journal' (and the low default value of 'commit=5') most often give at a moderate cost the illusion that the file system and storage system ''just work'', when they don't. This creates issues when discussing the relative merits of 'ext3' vs. other filesystems which are less forgiving. Eventually the XFS and 'ext3' designers seem to have chosen very different assumptions about their user base: * the XFS designers probably assumed that their user based would be big iron people with a high degree of understanding of storage systems and optimal hardware conditions, and interested in maximally scalable performance (e.g. Altix customers in HPC); * the 'ext3' guys seem to have assumed their user base would be general users slamming together stuff on the cheap without much awareness or thought as to storage system engineering, and interested in ''just works, most of the time''. From owner-xfs@oss.sgi.com Sat Jul 22 10:45:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 10:45:31 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6MHjIDW015176 for ; Sat, 22 Jul 2006 10:45:19 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G4JY2-0003pG-6C for ; Sat, 22 Jul 2006 16:37:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <17602.17985.533632.85589@base.ty.sabi.co.UK> Date: Sat, 22 Jul 2006 16:37:37 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <1153314670.2691.14.camel@localhost.localdomain> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k6MHjKDW015185 X-archive-position: 8390 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 1732 Lines: 48 >>> On Wed, 19 Jul 2006 09:11:10 -0400, Ming Zhang >>> said: [ ... ] mingz> what kind of "ram vs fs" size ratio here will be a mingz> safe/good/proper one? any rule of thumb? thanks! hope mingz> not 1:1. :) This is driven mostly by the space required by check/repair (which can well be above 4GiB, so 64 bit systems are often required): http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html «e.g. it took 1.5GiB RAM for 32bit xfs_check and 2.7GiB RAM for a 64bit xfs_check on a 1.1TiB filesystem with 3million inodes in it.» It suggests that a 10TB filesystem might need from about 15 gigabytes of RAM (or swap, with corresponding slowdown), after all only less than 0.2% of its size. Anyhow, a system with lots of RAM to speedly check/repair an XFS filesystem also benefits from the same RAM for caching and delayed writing, so it is all for good (as long as one has a perfectly reliable block IO subsystem). Note that the 15 gigabytes in the example above are well above what a 32 bit process can address, thus for multi-terabyte filesystem one should really have a 64 bit system (from the same article mentioned above): http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html «> > Your filesystem (8TiB) may simply bee too large for your > > system to be able to repair. Try mounting it on a 64bit > > system with more RAM in it and repairing it from there. > > Sorry, but is this a joke? A joke? Absolutely not. Acheivable XFS filesystem sizes outgrew the capability of 32 bit Irix systems to repair them several years ago. Now that linux supports larger than 2TiB filesystems on 32 bit systems, this is true for Linux as well.» From owner-xfs@oss.sgi.com Sat Jul 22 10:44:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 10:45:11 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6MHidDW015086 for ; Sat, 22 Jul 2006 10:44:39 -0700 Received: from [82.41.152.154] (helo=prinz64.housecafe.de) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G4KK5-0007HW-Pt; Sat, 22 Jul 2006 18:27:25 +0200 Date: Sat, 22 Jul 2006 17:27:24 +0100 (BST) From: Christian Kujau X-X-Sender: evil@prinz64.housecafe.de To: Nathan Scott cc: Torsten Landschoff , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 In-Reply-To: <20060719085731.C1935136@wobbly.melbourne.sgi.com> Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8387 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evil@g-house.de Precedence: bulk X-list: xfs Content-Length: 933 Lines: 30 Hi folks, On Wed, 19 Jul 2006, Nathan Scott wrote: > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > mkfs and restore? Or at least get a full repair run? If you did, > and you still see issues in .18-rc1, please let me know asap. well, at least for me, corruption/errors *started* with 2.6.18-rc1: http://oss.sgi.com/archives/xfs/2006-07/msg00151.html I downgraded to 2.6.17.5 and the errors stopped. Now I've upgraded to 2.6.18-rc2 and see the same errors: xfs_da_do_buf: bno 16777216 dir: inode 24472381 Filesystem "md0": XFS internal error xfs_da_do_buf(1) at line 1992 of file fs/xfs/xfs_da_btree.c. Caller 0xc0219230 Filesystem "md0": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xc024d717 Please see the whole error/.config/logs here: http://nerdbynature.de/bits/2.6.18-rc2/ Thanks, Christian. -- BOFH excuse #38: secretary plugged hairdryer into UPS From owner-xfs@oss.sgi.com Sat Jul 22 10:45:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 10:45:28 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6MHj3DW015116 for ; Sat, 22 Jul 2006 10:45:16 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G4LJm-0003zp-Rg for ; Sat, 22 Jul 2006 18:31:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <17602.24798.454081.144575@base.ty.sabi.co.UK> Date: Sat, 22 Jul 2006 18:31:10 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <20060720061209.GA18135@tuatara.stupidest.org> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <20060719055621.GA1491@tuatara.stupidest.org> <17598.3876.565887.172598@base.ty.sabi.co.UK> <20060720061209.GA18135@tuatara.stupidest.org> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k6MHjGDW015159 X-archive-position: 8388 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 2550 Lines: 60 >>> On Wed, 19 Jul 2006 23:12:09 -0700, Chris Wedgwood >>> said: [ ... ] pg> But write barriers are difficult to achieve, and when pg> achieved they are often unreliable, except on enterprise pg> level hardware, because many disks/host adapters/... simply pg> lie as to whether they have actually started writing (never pg> mind finished writing, or written correctly) stuff. cw> IDE/SATA doesn't have barrier to lie about Actually a very few ATA/SATA do have write barriers, but that is a just a nitpick, because it is hard to get to them, and anyhow Linux does not take advantage much :-). cw> (the kernel has to flush and wait in those cases). But ATA/SATA flush and wait have the same problems as write barriers, except worse: disks and ATA/SATA cards do lie too as to cache flushing. Just getting an ATA/SATA driver or card manufacturer to tell whether completion of cache flush is reported when the command is received, or when writing has started, or when writing has ended, is pretty difficult. cw> [ ... ] Sanely written applications shouldn't lose data. [ cw> ... ] any sane database should be safe, it will fsync or cw> similar as needed this is also true for sane MTAs Sure, in optimal conditions where people running the system and writing applications know exactly what they are doing and the storage subsystem has the right semantics, then things are good. Problem is, ''sanity'' is not entirely common in IT, as the archives of this mailing list show abundantly. cw> i've actually tested sitations where transactions were in cw> flight and i've dropped power on a rack of disks and cw> verified that when it came up all transactions that we cw> claimed to have completed really did I hope that this was with an Altix or equivalently robustly and advisedly engineered system and storage subsystem... (and I don't get any commission from SGI :->). cw> i've also done lesser things will SATA disks and email and cw> it usually turns out to also be reliable for the most part Ehehehe here :-). I like the «usually» and «most part». But my argument is that I guess that is what the 'ext3' designers, but not the XFS ones, have targeted. The difference here between XFS and 'ext3' is that with 'ext3' (and similar) even a not very aware sysadm running on a not very well chosen system can get ''just works''. Just the 'commit=5' default of 'ext3' makes *a very large* difference. My overall message is that using XFS on a system that «usually» and for the «most part» ''just works'' is not very appropriate... From owner-xfs@oss.sgi.com Sat Jul 22 11:07:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 11:07:49 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6MI7aDW018671 for ; Sat, 22 Jul 2006 11:07:37 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1G4Lv3-00044x-28 for ; Sat, 22 Jul 2006 19:09:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17602.27108.555049.327996@base.ty.sabi.co.UK> Date: Sat, 22 Jul 2006 19:09:40 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: stable xfs In-Reply-To: <1153413481.2768.65.camel@localhost.localdomain> References: <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 8392 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 493 Lines: 18 >>> On Thu, 20 Jul 2006 12:38:01 -0400, Ming Zhang >>> said: [ ... ] >>> we mainly handle large media files like 20-50GB. so file >>> number is not too much. but file size is large. >> xfs_repair usually deals with that fairly well in reality >> (much better than lots of small files anyhow) > sounds cool. yes, large # of small files are always painful. It is not just number of inodes, it is also number of extents. That is total number of metadata items. [ ... ] From owner-xfs@oss.sgi.com Sat Jul 22 20:37:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 22 Jul 2006 20:37:18 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6N3b2DW009496 for ; Sat, 22 Jul 2006 20:37:02 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4EEF518DB2DAD; Sat, 22 Jul 2006 22:36:37 -0500 (CDT) Message-ID: <44C2EEC5.4020804@sandeen.net> Date: Sat, 22 Jul 2006 22:36:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Jan Dittmer Cc: xfs@oss.sgi.com Subject: Re: Userspace cp and ls utility References: <44C0B0E4.7020403@l4x.org> In-Reply-To: <44C0B0E4.7020403@l4x.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8394 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 682 Lines: 18 Jan Dittmer wrote: > Are there utilities for xfs which are able to ls and > cp from an _unmounted_ xfs volume? I fear that by > mounting the volume - even ro - I would lose even more > data. > Or can I achieve such an effect with other xfs related > utilities? Mounting ro should be fine - if you also mount with "norecovery" then truly no IO should happen. If you're really paranoid, find a utility to mark the block device itself as read-only, then you've taken it out of the filesystem's hands completely. You could also try xfs_copy, it makes a copy of the filesystem and works on the underlying device, with the filesystem unmounted. There's a man page for it. -Eric From owner-xfs@oss.sgi.com Sun Jul 23 02:25:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 02:26:00 -0700 (PDT) Received: from ds666.l4x.org (mail.trixing.net [87.230.125.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6N9PcDW012646 for ; Sun, 23 Jul 2006 02:25:38 -0700 Received: from [192.168.1.3] (helo=[192.168.182.10]) by ds666.l4x.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.62) (envelope-from ) id 1G4Z99-0000X6-D2; Sun, 23 Jul 2006 10:17:07 +0200 Message-ID: <44C33080.3060108@l4x.org> Date: Sun, 23 Jul 2006 10:17:04 +0200 From: Jan Dittmer User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com References: <44C0B0E4.7020403@l4x.org> <44C2EEC5.4020804@sandeen.net> In-Reply-To: <44C2EEC5.4020804@sandeen.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 192.168.1.3 X-SA-Exim-Mail-From: jdi@l4x.org Subject: Re: Userspace cp and ls utility X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on ds666.l4x.org) X-archive-position: 8395 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jdi@l4x.org Precedence: bulk X-list: xfs Content-Length: 1160 Lines: 33 Eric Sandeen schrieb: > Jan Dittmer wrote: > >> Are there utilities for xfs which are able to ls and >> cp from an _unmounted_ xfs volume? I fear that by >> mounting the volume - even ro - I would lose even more >> data. >> Or can I achieve such an effect with other xfs related >> utilities? > > > Mounting ro should be fine - if you also mount with "norecovery" then > truly no IO should happen. If you're really paranoid, find a utility to > mark the block device itself as read-only, then you've taken it out of > the filesystem's hands completely. Thanks for the suggestions. Meanwhile I found the norecovery option myself and got most of my data back. Strangely enough I had one top directory missing on one mount attempt (only ro option) and it appeared again on the next attempt (ro + norecovery). > You could also try xfs_copy, it makes a copy of the filesystem and works > on the underlying device, with the filesystem unmounted. There's a man > page for it. Is there any difference to using dd when the destination is no xfs filesystem? And if I read the description correctly it does not allow to copy individual files? Thanks, Jan From owner-xfs@oss.sgi.com Sun Jul 23 05:09:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 05:10:00 -0700 (PDT) Received: from web31705.mail.mud.yahoo.com (web31705.mail.mud.yahoo.com [68.142.201.185]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6NC9hDW030060 for ; Sun, 23 Jul 2006 05:09:43 -0700 Received: (qmail 79375 invoked by uid 60001); 23 Jul 2006 11:09:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sUBOZXobGsjjyIt2o8LinmyHSUeLB0ApL/fyce9UckDwdK1ADzH5yKP4u8tE6wAdP1o7gPnmVKbByDKOC9EJo1L6uHfT+0m1iDIEckNTxNMnBv7ryTMte0qGyH+j0QZW+HQMiHDJPPC0Cf+VZ4JChGxJYAaZGpvcnTyZW9DDqb0= ; Message-ID: <20060723110919.79373.qmail@web31705.mail.mud.yahoo.com> Received: from [80.178.93.94] by web31705.mail.mud.yahoo.com via HTTP; Sun, 23 Jul 2006 04:09:18 PDT Date: Sun, 23 Jul 2006 04:09:18 -0700 (PDT) From: Heilige Gheist Subject: XFS setting custom extent size: real-time section only? To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8396 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hgheist@yahoo.com Precedence: bulk X-list: xfs Content-Length: 926 Lines: 24 I'm trying to get custom extent size per file working, but XFS_IOC_FSSETXATTR ioctl returns with EINVAL, both from my code or from xfs_io. The environment is SLES9 SP2, 2.6.5-7.252 kernel, xfsprogs-2.6.25-0.6 After examining the kernel code in xfs_vnodeops.c we found out that custom extent size is supported on files in real-time section only. This is not mentioned anywhere else in the documentation, so I'm wondering whether this limitation is removed in further kernel versions. I've downloaded the recent xfsprogs-2.8.4, it uses a new flag XFS_XFLAG_EXTSIZE when setting the custom extent size. I'm not sure what kernel version do I need to work with 2.8.4, but it's certainly a sign that kernel support has changed. Can anyone shed a light on this? Thanks, Alan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Sun Jul 23 07:21:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 07:21:57 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6NELkDW012442 for ; Sun, 23 Jul 2006 07:21:46 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 8060E18DE2F33; Sun, 23 Jul 2006 09:21:18 -0500 (CDT) Message-ID: <44C385DE.100@sandeen.net> Date: Sun, 23 Jul 2006 09:21:18 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Jan Dittmer Cc: xfs@oss.sgi.com Subject: Re: Userspace cp and ls utility References: <44C0B0E4.7020403@l4x.org> <44C2EEC5.4020804@sandeen.net> <44C33080.3060108@l4x.org> In-Reply-To: <44C33080.3060108@l4x.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8397 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 672 Lines: 18 Jan Dittmer wrote: >> You could also try xfs_copy, it makes a copy of the filesystem and >> works on the underlying device, with the filesystem unmounted. >> There's a man page for it. > > Is there any difference to using dd when the destination is no xfs > filesystem? And if I read the description correctly it does not allow > to copy individual files? xfs_copy knows about the xfs format, so it only copies what it needs to. dd will copy every bit on the source disk. So, xfs_copy is more efficient. There is no option to copy individual files. Depending on the problem with your original filesystem, perhaps xfs_copy might not be the best choice. -Eric From owner-xfs@oss.sgi.com Sun Jul 23 08:34:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 08:35:02 -0700 (PDT) Received: from ds666.l4x.org (mail.trixing.net [87.230.125.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6NFYoDW025595 for ; Sun, 23 Jul 2006 08:34:51 -0700 Received: from [192.168.1.3] (helo=[192.168.182.2]) by ds666.l4x.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.62) (envelope-from ) id 1G4fyJ-0001ra-7q; Sun, 23 Jul 2006 17:34:23 +0200 Message-ID: <44C396FB.7050308@l4x.org> Date: Sun, 23 Jul 2006 17:34:19 +0200 From: Jan Dittmer User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com References: <44C0B0E4.7020403@l4x.org> <44C2EEC5.4020804@sandeen.net> <44C33080.3060108@l4x.org> <44C385DE.100@sandeen.net> In-Reply-To: <44C385DE.100@sandeen.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 192.168.1.3 X-SA-Exim-Mail-From: jdi@l4x.org Subject: Re: Userspace cp and ls utility X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on ds666.l4x.org) X-archive-position: 8400 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jdi@l4x.org Precedence: bulk X-list: xfs Content-Length: 1126 Lines: 31 Eric Sandeen schrieb: > Jan Dittmer wrote: > >>> You could also try xfs_copy, it makes a copy of the filesystem and >>> works on the underlying device, with the filesystem unmounted. >>> There's a man page for it. >> >> >> Is there any difference to using dd when the destination is no xfs >> filesystem? And if I read the description correctly it does not allow >> to copy individual files? > > > xfs_copy knows about the xfs format, so it only copies what it needs > to. dd will copy every bit on the source disk. So, xfs_copy is more > efficient. There is no option to copy individual files. > > Depending on the problem with your original filesystem, perhaps xfs_copy > might not be the best choice. Well I suffered from the 2.6.17 endian bug and had fun with dis- and re- appearing folders upon xfs_repair and mount runs. After all the 'only' thing I lost from my 600+gb volume are one or two mailing list folders and most of my inbox (for which I've backups). Seems to only affect folders which were open at the wrong moment. Now I reformated the whole volume and restore the data from other disks. Jan From owner-xfs@oss.sgi.com Sun Jul 23 12:17:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 12:17:31 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6NJHHDW019764 for ; Sun, 23 Jul 2006 12:17:17 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 6FA5861012B4; Sun, 23 Jul 2006 15:16:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 4964216172ECC for ; Sun, 23 Jul 2006 15:16:48 -0400 (EDT) Date: Sun, 23 Jul 2006 15:16:48 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com Subject: chattr +d dir Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8401 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 214 Lines: 8 I used the chattr +d option for no_dump for a certain directory, but it still appears xfsdump dumped the directory anyway? Is there some special usage/way to make xfsdump NOT dump a certain directory? Justin. From owner-xfs@oss.sgi.com Sun Jul 23 13:06:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 13:06:33 -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 k6NK68DW030214 for ; Sun, 23 Jul 2006 13:06:08 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G4jHu-0006DS-JN; Sun, 23 Jul 2006 20:06:50 +0100 Date: Sun, 23 Jul 2006 20:06:50 +0100 From: Christoph Hellwig To: Nathan Scott Cc: xfs@oss.sgi.com, jeremy@sgi.com Subject: Re: review: fix remount vs barrier options Message-ID: <20060723190650.GA22180@infradead.org> References: <20060721152807.D1998769@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060721152807.D1998769@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8402 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 808 Lines: 19 > It finally clicked that we are not clearing the buffer flag > from a previously written log buffer, even though we'll no > longer set a new flag into a buffer (due to the mount flag > being cleared), so we _can_ still issue barrier writes when > remounted without barriers. That's true. Ooops. > This was made more complicated by the way a freshly mounted > filesystem with 8 log buffers wouldn't show up the problem, > since we have to slowly cycle through the "clear" log buffers > before we see the bug. This seems like the simplest fix... > > (Hmmm, actually, I wonder if this will also resolve the quota > log I/O problem that was reported the other day too). Shouldn't we make sure we clear all flags when reusing a log buffer? Relying on clearing individual flags seems rather fragile to me. From owner-xfs@oss.sgi.com Sun Jul 23 16:02:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 16:03:05 -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 k6NN2SDW019715 for ; Sun, 23 Jul 2006 16:02:39 -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 JAA20344; Mon, 24 Jul 2006 09:01:46 +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 k6NN1ggw2065295; Mon, 24 Jul 2006 09:01:43 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6NN1cbi2082406; Mon, 24 Jul 2006 09:01:38 +1000 (EST) Date: Mon, 24 Jul 2006 09:01:38 +1000 From: Nathan Scott To: Christian Kujau Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060724090138.C2083275@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from evil@g-house.de on Sat, Jul 22, 2006 at 05:27:24PM +0100 X-archive-position: 8403 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: 987 Lines: 27 On Sat, Jul 22, 2006 at 05:27:24PM +0100, Christian Kujau wrote: > On Wed, 19 Jul 2006, Nathan Scott wrote: > > 2.6.18-rc1 should be fine (contains the corruption fix). Did you > > mkfs and restore? Or at least get a full repair run? If you did, > > and you still see issues in .18-rc1, please let me know asap. > > well, at least for me, corruption/errors *started* with 2.6.18-rc1: > ... > I downgraded to 2.6.17.5 and the errors stopped. Now I've upgraded to > 2.6.18-rc2 and see the same errors: > > xfs_da_do_buf: bno 16777216 > dir: inode 24472381 This is an ondisk corruption - downgrading the kernel will not resolve it. The problem must be triggered by a combination of operations on a directory; I'm certain that if you access inode 24472381 on your filesystem on 2.6.17, that it'll shutdown your filesystem too. See the FAQ entry for a description on how to translate inums to paths, and also the repair -n step to detect any corruption ondisk. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 23 17:01:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 17:01:55 -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 k6O01EDW030944 for ; Sun, 23 Jul 2006 17:01:25 -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 KAA21440; Mon, 24 Jul 2006 10:00:35 +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 k6O00Wgw2086302; Mon, 24 Jul 2006 10:00:33 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6O00UPY2087020; Mon, 24 Jul 2006 10:00:30 +1000 (EST) Date: Mon, 24 Jul 2006 10:00:30 +1000 From: Nathan Scott To: Heilige Gheist Cc: xfs@oss.sgi.com Subject: Re: XFS setting custom extent size: real-time section only? Message-ID: <20060724100030.E2083275@wobbly.melbourne.sgi.com> References: <20060723110919.79373.qmail@web31705.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060723110919.79373.qmail@web31705.mail.mud.yahoo.com>; from hgheist@yahoo.com on Sun, Jul 23, 2006 at 04:09:18AM -0700 X-archive-position: 8404 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: 1086 Lines: 25 On Sun, Jul 23, 2006 at 04:09:18AM -0700, Heilige Gheist wrote: > I'm trying to get custom extent size per file working, but > XFS_IOC_FSSETXATTR ioctl returns with EINVAL, > both from my code or from xfs_io. > The environment is SLES9 SP2, 2.6.5-7.252 kernel, xfsprogs-2.6.25-0.6 > After examining the kernel code in xfs_vnodeops.c we found out that > custom extent size is supported on files in real-time section only. > This is not mentioned anywhere else in the documentation, so I'm > wondering whether this limitation is removed in further kernel > versions. > I've downloaded the recent xfsprogs-2.8.4, it uses a new flag > XFS_XFLAG_EXTSIZE when setting the custom extent size. > I'm not sure what kernel version do I need to work with 2.8.4, but it's > certainly a sign that kernel support has changed. Indeed it has. I'm not sure which kernel version this was merged into, but the rough timeframe can be seen on http://oss.sgi.com/projects/xfs/ on the "recent changes" table. It wont be there in any SLES9, but IIRC SLES10 does now include that code. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 23 17:02:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 17:03:19 -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 k6O02YDW031087 for ; Sun, 23 Jul 2006 17:02:47 -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 KAA21451; Mon, 24 Jul 2006 10:01:52 +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 k6O01ogw2084676; Mon, 24 Jul 2006 10:01:51 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6O01mCw2084975; Mon, 24 Jul 2006 10:01:48 +1000 (EST) Date: Mon, 24 Jul 2006 10:01:48 +1000 From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com, jeremy@sgi.com Subject: Re: review: fix remount vs barrier options Message-ID: <20060724100147.F2083275@wobbly.melbourne.sgi.com> References: <20060721152807.D1998769@wobbly.melbourne.sgi.com> <20060723190650.GA22180@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060723190650.GA22180@infradead.org>; from hch@infradead.org on Sun, Jul 23, 2006 at 08:06:50PM +0100 X-archive-position: 8405 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: 994 Lines: 27 On Sun, Jul 23, 2006 at 08:06:50PM +0100, Christoph Hellwig wrote: > > It finally clicked that we are not clearing the buffer flag > > from a previously written log buffer, even though we'll no > > longer set a new flag into a buffer (due to the mount flag > > being cleared), so we _can_ still issue barrier writes when > > remounted without barriers. > > That's true. Ooops. > > > This was made more complicated by the way a freshly mounted > > filesystem with 8 log buffers wouldn't show up the problem, > > since we have to slowly cycle through the "clear" log buffers > > before we see the bug. This seems like the simplest fix... > > > > (Hmmm, actually, I wonder if this will also resolve the quota > > log I/O problem that was reported the other day too). > > Shouldn't we make sure we clear all flags when reusing a log buffer? > Relying on clearing individual flags seems rather fragile to me. *nod* - good idea. I'll rework xlog_sync, and resend later. thanks. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 23 17:25:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 17:25:36 -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 k6O0OoDW002141 for ; Sun, 23 Jul 2006 17:25:02 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA21885; Mon, 24 Jul 2006 10:24:08 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k6O0O4gw2085951; Mon, 24 Jul 2006 10:24:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6O0Nxo72086002; Mon, 24 Jul 2006 10:23:59 +1000 (EST) Date: Mon, 24 Jul 2006 10:23:59 +1000 From: Nathan Scott To: Adrian Bunk Cc: Arthur Corliss , xfs@oss.sgi.com Subject: Buglet in mount(8) with large page size Message-ID: <20060724102359.B2056114@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8406 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: 536 Lines: 21 Hi Adrian, We have had this XFS bug report... http://oss.sgi.com/bugzilla/show_bug.cgi?id=704 ...and Arthur has diagnosed the problem and proposed a fix. Its in some code we "lifted" from mount(8) to attempt to detect an existing filesystem/partition/... before overwriting it with mkfs.xfs. How do you want to fix this in mount_guess_fstype.c? Options would seem to be: - bump up the size of the "buf" array to cater for all current page sizes; or - malloc the read buffer taking into account the page size. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 23 18:24:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 18:24:53 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6O1OZDW009928 for ; Sun, 23 Jul 2006 18:24:37 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6O1Ef5x011557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 23 Jul 2006 21:14:41 -0400 Subject: Re: stable xfs From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Chris Wedgwood Cc: Peter Grandi , Linux XFS In-Reply-To: <20060721180707.GB13892@tuatara.stupidest.org> References: <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> <20060720190401.GA28836@tuatara.stupidest.org> <1153441178.2768.158.camel@localhost.localdomain> <20060721032632.GA4138@tuatara.stupidest.org> <1153487431.2841.8.camel@localhost.localdomain> <20060721160709.GB12347@tuatara.stupidest.org> <1153501244.2841.50.camel@localhost.localdomain> <20060721180707.GB13892@tuatara.stupidest.org> Content-Type: text/plain Date: Sun, 23 Jul 2006 21:14:36 -0400 Message-Id: <1153703676.6963.42.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8407 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 4341 Lines: 109 On Fri, 2006-07-21 at 11:07 -0700, Chris Wedgwood wrote: > On Fri, Jul 21, 2006 at 01:00:44PM -0400, Ming Zhang wrote: > > > what u mean overlay fs over small fs? like a unionfs? > > sorta not really, it's userspace libraries which create a virtual > filesystem over real filesystems with some database (bezerkely db). > it sorta evolved from an attempt to unify several filesystems spread > over cheap PCs into something that pretended to be one larger fs fancy word for this is NAS virtualization i guess. > > > but other than fsr. there is no better way for this right? > > not publicly, you could patch fsr or nag me for my patches if that > helps i will run some tests about fsr and see if i need to bug you about patches. > > > of course, preallocate is always good. but i do not have control > > over applications. > > well, in some cases you could use LD_PRELOAD and influence things, it > depends on the application and what you need from it > > fwiw, most modern p2p applicaitons have terribly access patterns which > cause cause horrible fragmentation (on all fs's, not just XFS) > > > sounds like a useful patch. :P will it be merged into fsr code? > > no, because it's ugly and i don't think i ever decoupled it from other > changes and posted it > > > what kind of assistance you mean? > > [WARNING: lots of hand waving ahead, plenty of minor, but important, > details ignored] > read about this and feel this will be VERY hard to be built, especially considering the transaction issue. can this be easier? * analyze the fs to find out which file(s) to be defrag; * create a temp file and begin to copy, preserve the space so it is continuous; * after first round of copy, for changed blocks have a trace table and a second round on changed blocks. * lock and switch the old file with new file. > if you wanted much smarter defragmentation semantics, it would > probably make sense to > > * bulkstat the entire volume, this will give you the inode cluster > locations and enough information to start building a tree of where > all the files are (XFS_IOC_FSGEOMETRY details obviously) > > * opendir/read to build a full directory tree > > * use XFS_IOC_GETBMAP & XFS_IOC_GETBMAPA to figure out which blocks > are occupied by which files > > you would now have a pretty good idea of what is using what parts of > the disk, except of course it could be constantly changing underneath > you to make things harder > > also, doing this using the existing interfaces is (when i tried it) > really really painfully slow if you have a large filesystem with a lot > of small files (even when you try to optimized you accesses for > minimize seeking by sorting by inode number and submitting several > requests in parallel to try and help the elevator merge accesses) > > > one you have some overall picture of the disk, you can decide what you > want to move to achieve your goal, typically this would be to reduce > the fragmentation of the largest files, and this would be be > relocating some of all of those blocks to another place > > if you want to allocate space in a given AG, you open/creat a > temporary file in a directory in that AG (create multiple dirs as > needed to ensure you have one or more of these), and preallocate the > space --- there you can copy the file over > > we could also add ioctls to further bias XFSs allocation strategies, > like telling it to never allocate in some AGs (needed for an online > shrink if someone wanted to make such a thing) or simply bias strongly > away from some places, then add other ioctls to allow you to > specifically allocate space in those AGs so you can bias what is > allocated where > > another useful ioctl would be a variation of XFS_IOC_SWAPEXT which > would swap only some extents. there is no internal support for this > now except we do have code for XFS_IOC_UNRESVSP64 and XFS_IOC_RESVSP64 > so perhaps the idea would be to swap some (but not all) blocks of a > file by creating a function that do the equivalent of 'punch a hole' > where we want to replace the blocks, and then 'allocate new blocks > given some i already have elsewhere' (however, making that all work as > one transaction might be very very difficult) > > it's a lot of effort for what for many people wouldn't only have > marginal gains From owner-xfs@oss.sgi.com Sun Jul 23 18:28:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 18:29:04 -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 k6O1SQDW010534 for ; Sun, 23 Jul 2006 18:28: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 LAA22813; Mon, 24 Jul 2006 11:27: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 k6O1Rfgw2088238; Mon, 24 Jul 2006 11:27:42 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6O1Rc0F2089090; Mon, 24 Jul 2006 11:27:38 +1000 (EST) Date: Mon, 24 Jul 2006 11:27:37 +1000 From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com, jeremy@sgi.com Subject: Re: review: fix remount vs barrier options Message-ID: <20060724112737.D2085715@wobbly.melbourne.sgi.com> References: <20060721152807.D1998769@wobbly.melbourne.sgi.com> <20060723190650.GA22180@infradead.org> <20060724100147.F2083275@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060724100147.F2083275@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Mon, Jul 24, 2006 at 10:01:48AM +1000 X-archive-position: 8408 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: 3387 Lines: 87 On Mon, Jul 24, 2006 at 10:01:48AM +1000, Nathan Scott wrote: > On Sun, Jul 23, 2006 at 08:06:50PM +0100, Christoph Hellwig wrote: > > Shouldn't we make sure we clear all flags when reusing a log buffer? > > Relying on clearing individual flags seems rather fragile to me. > > *nod* - good idea. I'll rework xlog_sync, and resend later. After looking more, I'm less convinced. There's some flags we wont want to touch - the "internal" flags like PAGE_CACHE, etc (that one is obviously not relevent here, but still, at some point a flag may be introduced that we accidentally break by clearing all flags). There is a ZEROFLAGS macro, I've added ORDERED to that and used it instead. I also fixed the double barrier issue for the split log write case - here's an updated patch... cheers. -- Nathan Index: xfs-linux/xfs_log.c =================================================================== --- xfs-linux.orig/xfs_log.c 2006-07-21 08:55:24.520992250 +1000 +++ xfs-linux/xfs_log.c 2006-07-24 11:13:22.743144500 +1000 @@ -1444,7 +1444,7 @@ xlog_sync(xlog_t *log, ops = iclog->ic_header.h_num_logops; INT_SET(iclog->ic_header.h_num_logops, ARCH_CONVERT, ops); - bp = iclog->ic_bp; + bp = iclog->ic_bp; ASSERT(XFS_BUF_FSPRIVATE2(bp, unsigned long) == (unsigned long)1); XFS_BUF_SET_FSPRIVATE2(bp, (unsigned long)2); XFS_BUF_SET_ADDR(bp, BLOCK_LSN(INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT))); @@ -1461,15 +1461,14 @@ xlog_sync(xlog_t *log, } XFS_BUF_SET_PTR(bp, (xfs_caddr_t) &(iclog->ic_header), count); XFS_BUF_SET_FSPRIVATE(bp, iclog); /* save for later */ + XFS_BUF_ZEROFLAGS(bp); XFS_BUF_BUSY(bp); XFS_BUF_ASYNC(bp); /* * Do an ordered write for the log block. - * - * It may not be needed to flush the first split block in the log wrap - * case, but do it anyways to be safe -AK + * Its unnecessary to flush the first split block in the log wrap case. */ - if (log->l_mp->m_flags & XFS_MOUNT_BARRIER) + if (!split && (log->l_mp->m_flags & XFS_MOUNT_BARRIER)) XFS_BUF_ORDERED(bp); ASSERT(XFS_BUF_ADDR(bp) <= log->l_logBBsize-1); @@ -1491,7 +1490,7 @@ xlog_sync(xlog_t *log, return error; } if (split) { - bp = iclog->ic_log->l_xbuf; + bp = iclog->ic_log->l_xbuf; ASSERT(XFS_BUF_FSPRIVATE2(bp, unsigned long) == (unsigned long)1); XFS_BUF_SET_FSPRIVATE2(bp, (unsigned long)2); @@ -1499,6 +1498,7 @@ xlog_sync(xlog_t *log, XFS_BUF_SET_PTR(bp, (xfs_caddr_t)((__psint_t)&(iclog->ic_header)+ (__psint_t)count), split); XFS_BUF_SET_FSPRIVATE(bp, iclog); + XFS_BUF_ZEROFLAGS(bp); XFS_BUF_BUSY(bp); XFS_BUF_ASYNC(bp); if (log->l_mp->m_flags & XFS_MOUNT_BARRIER) Index: xfs-linux/linux-2.6/xfs_buf.h =================================================================== --- xfs-linux.orig/linux-2.6/xfs_buf.h 2006-07-24 11:04:17.203179750 +1000 +++ xfs-linux/linux-2.6/xfs_buf.h 2006-07-24 11:09:29.652577250 +1000 @@ -247,8 +247,8 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define BUF_BUSY XBF_DONT_BLOCK #define XFS_BUF_BFLAGS(bp) ((bp)->b_flags) -#define XFS_BUF_ZEROFLAGS(bp) \ - ((bp)->b_flags &= ~(XBF_READ|XBF_WRITE|XBF_ASYNC|XBF_DELWRI)) +#define XFS_BUF_ZEROFLAGS(bp) ((bp)->b_flags &= \ + ~(XBF_READ|XBF_WRITE|XBF_ASYNC|XBF_DELWRI|XBF_ORDERED)) #define XFS_BUF_STALE(bp) ((bp)->b_flags |= XFS_B_STALE) #define XFS_BUF_UNSTALE(bp) ((bp)->b_flags &= ~XFS_B_STALE) From owner-xfs@oss.sgi.com Sun Jul 23 23:05:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 23 Jul 2006 23:06:23 -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 k6O65dDW017893 for ; Sun, 23 Jul 2006 23:05:52 -0700 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k6O5vfnx029358 for ; Mon, 24 Jul 2006 00:57:41 -0500 Received: from omx2.sgi.com ([198.149.32.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k6O678Du42435685 for ; Sun, 23 Jul 2006 23:07:09 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id k6O8P6JQ023948 for ; Mon, 24 Jul 2006 01:25:07 -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 PAA27287 for ; Mon, 24 Jul 2006 15:57:34 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k6O5vWgw2093802 for ; Mon, 24 Jul 2006 15:57:33 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6O5vVaq2094825 for xfs@oss.sgi.com; Mon, 24 Jul 2006 15:57:31 +1000 (EST) Date: Mon, 24 Jul 2006 15:57:30 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: review: bump up xlog_state_do_callback loop checking Message-ID: <20060724155730.A2090627@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8409 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: 2477 Lines: 67 Hi, I started running the QA tests with an external log on a ramdisk & now constantly see situations where xlog_state_so_callback reports: Filesystem "sda2": xlog_state_do_callback: looping 10 Filesystem "sda2": xlog_state_do_callback: looping 20 Filesystem "sda2": xlog_state_do_callback: looping 10 Filesystem "sda2": xlog_state_do_callback: looping 10 Filesystem "sda2": xlog_state_do_callback: looping 10 Filesystem "sda2": xlog_state_do_callback: looping 20 on the system console. Tim and I looked into this further, and remembered long ago list discussion on the topic, after others reported this too (also on ramdisks interestingly): http://oss.sgi.com/archives/xfs/2005-02/msg00108.html http://oss.sgi.com/archives/xfs/2005-02/msg00109.html So, it seems Glen added this to try detect infinte loops on systems where we do log callback processing in interrupt context (i.e. IRIX). It seems that with ramdisks its causing spurious warnings due to how quickly the completion handlers will be run (immediate, sync) though. We can quite easily still keep the same infinite loop check but bump up the reporting threshold to something that wont happen for ramdisks/raid caches ... and report each several-thousand iterations instead of each tenth one. It does still seems worthwhile to keep the infinte loop detection though, so at this stage I've left that in there. Tim also insisted I optimise away the modulo operation that we do in the callback processing loop, while I was fixing this other issue, and he's pointed out an easy way to do that... cheers. -- Nathan Index: xfs-linux/xfs_log.c =================================================================== --- xfs-linux.orig/xfs_log.c 2006-07-20 12:06:56.455633750 +1000 +++ xfs-linux/xfs_log.c 2006-07-20 12:17:19.819492000 +1000 @@ -2243,9 +2243,13 @@ xlog_state_do_callback( iclog = iclog->ic_next; } while (first_iclog != iclog); - if (repeats && (repeats % 10) == 0) { + + if (repeats > 5000) { + flushcnt += repeats; + repeats = 0; xfs_fs_cmn_err(CE_WARN, log->l_mp, - "xlog_state_do_callback: looping %d", repeats); + "%s: possible infinite loop (%d iterations)", + __FUNCTION__, flushcnt); } } while (!ioerrors && loopdidcallbacks); @@ -2277,6 +2281,7 @@ xlog_state_do_callback( } #endif + flushcnt = 0; if (log->l_iclog->ic_state & (XLOG_STATE_ACTIVE|XLOG_STATE_IOERROR)) { flushcnt = log->l_flushcnt; log->l_flushcnt = 0; From owner-xfs@oss.sgi.com Mon Jul 24 01:08:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 01:09:11 -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 k6O88UDW010964 for ; Mon, 24 Jul 2006 01:08:35 -0700 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k6O8800C017712 for ; Mon, 24 Jul 2006 17:08:01 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by tyo202.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k6O81aM9005105; Mon, 24 Jul 2006 17:01:36 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k6O81aF19712; Mon, 24 Jul 2006 17:01:36 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k6O81ZU02260; Mon, 24 Jul 2006 17:01:35 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k6O81Xcu030285; Mon, 24 Jul 2006 17:01:34 +0900 To: Nathan Scott , David Chinner 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 In-reply-to: <20060717140751.GW2114946@melbourne.sgi.com> Message-Id: <20060724170133m-saito@mail.aom.tnes.nec.co.jp> References: <20060717140751.GW2114946@melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Mon, 24 Jul 2006 17:01:33 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8410 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: 3267 Lines: 101 Hi Nathan, David, Thank you for comments. >I don't think it fixes the problem because igrab() fails to handle >the case we are hitting where I_CLEAR is set on the inode when we >mark it dirty. There's nothing in this patch preventing us from >sleeping after the !(I_NEW|I_FREEING|I_CLEAR) check is done and then >racing with generic_drop_inode() before the igrab() can take a >reference on the inode. I overlooked the case. Thank you for your review. >Worse, the i_flags field does not use atomic bitops and >there is no consistent locking protecting i_flags so updates >and reads of this filed can race or even get lost.... I agree it, too. I think that we should add new spin_lock for i_flags. >I think a fix is going to be much more invasive than just adding >reference as my fixes appear to have only narrowed the race window >and not solved it. The addition of the lock in the original patch >solves the atomic xfs_iunpin()/xfs_reclaim() execution problem, >but it does not solve the problems with the i_flags field. Adding >a new lock may be our only option here. I'm considering the solution which fixes two problems([a] i_state of the inode is changed while the inode is freed in xfs filesystem and [b] the above i_flags problem) the solution: (1)Add new spin_lock(i_flags_lock) for all refernece and change places of all i_flags. (2)Add igrab()/iput() for xfs_iunpin(). It makes sure that mark_inode_dirty_sync() is never called if xfs_iunpin() runs after I_CLEAR is set. Because XFS_IRECLAIM or XFS_IRECLAIMABLE is set/checked within the spin_lock. And there is the reason that igrab()/iput() is needed even if I add new spin_lock for xfs_iunpin(). We can prevent the following case by adding them. * After passing (I_NEW|I_FREEING|I_CLEAR) check in xfs_iunpin(), I_FREEING is set. * Then mark_inode_dirty_sync() is called and i_state is changed. * Hit BUG_ON(!(inode->i_state & I_FREEING)) in clear_inode(). If these ideas seem to be correct, I'll make patches for above (1),(2). Any comment? (The following is a part of my thinking patch. Only xfs_iunpin().) --- linux-2.6.17.6/fs/xfs/xfs_inode.c.orig 2006-07-22 08:07:50.194236144 +0900 +++ linux-2.6.17.6/fs/xfs/xfs_inode.c 2006-07-25 06:07:18.062853045 +0900 @@ -2729,6 +2729,8 @@ void xfs_iunpin( xfs_inode_t *ip) { + int need_unlock; + ASSERT(atomic_read(&ip->i_pincount) > 0); if (atomic_dec_and_test(&ip->i_pincount)) { @@ -2744,6 +2746,8 @@ xfs_iunpin( * call as the inode reclaim may be blocked waiting for * the inode to become unpinned. */ + spin_lock(&ip->i_flags_lock); + need_unlock = 1; if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) { vnode_t *vp = XFS_ITOV_NULL(ip); @@ -2751,10 +2755,22 @@ xfs_iunpin( if (vp) { struct inode *inode = vn_to_inode(vp); - if (!(inode->i_state & I_NEW)) - mark_inode_dirty_sync(inode); + if (!(inode->i_state & + (I_NEW|I_FREEING|I_CLEAR))) { + inode = igrab(inode); + if (inode != NULL) { + mark_inode_dirty_sync(inode); + spin_unlock(&ip->i_flags_lock); + need_unlock = 0; + iput(inode); + } + } } } + if (need_unlock) { + spin_unlock(&ip->i_flags_lock); + need_unlock = 0; + } wake_up(&ip->i_ipin_wait); } } From owner-xfs@oss.sgi.com Mon Jul 24 03:23:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 03:23:34 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6OANLDW002156 for ; Mon, 24 Jul 2006 03:23:22 -0700 Received: by nf-out-0910.google.com with SMTP id a27so1474121nfc for ; Mon, 24 Jul 2006 03:22:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JxEExewsTVk4P6Hdm6YXf4hohPUP6nlINdqYWLojQYe3ybMVH9+Gi0J2VwGx7ICMEwLFZYOSgwH4ZeExtgzeaDVYuqzWrjY2pUwm2AKTwMRsgxYNLcbggPj401lR+R3bgUFnV8kF6W2VT3xaasDTbqqENcCnoBACEC9GzJv/Zz4= Received: by 10.78.117.10 with SMTP id p10mr1430434huc; Mon, 24 Jul 2006 03:22:55 -0700 (PDT) Received: by 10.78.159.14 with HTTP; Mon, 24 Jul 2006 03:22:55 -0700 (PDT) Message-ID: <68559cef0607240322x6be3a38fp8bd03b20caf2a06a@mail.gmail.com> Date: Mon, 24 Jul 2006 12:22:55 +0200 From: "Luca Maranzano" To: xfs@oss.sgi.com Subject: Re: Page allocation failure writing to an XFS volume via NFS on CentOS 4.3 In-Reply-To: <20060721161326.GE12347@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68559cef0607210519q9f382c6n7104bef9cf9716f3@mail.gmail.com> <20060721161326.GE12347@tuatara.stupidest.org> X-archive-position: 8411 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liuk001@gmail.com Precedence: bulk X-list: xfs Content-Length: 1757 Lines: 63 Hi Crhis, thank you for your reply. I've verified and it seems that nothing should be so piggy to make the server out of memory. The server is essentially an NFS Server and there are no memory hog running besides standard services. /proc/meminfo: MemTotal: 1035832 kB MemFree: 12568 kB Buffers: 10468 kB Cached: 968336 kB SwapCached: 4716 kB Active: 19064 kB Inactive: 967740 kB HighTotal: 131048 kB HighFree: 952 kB LowTotal: 904784 kB LowFree: 11616 kB SwapTotal: 1052248 kB SwapFree: 1041744 kB Dirty: 0 kB Writeback: 0 kB Mapped: 13588 kB Slab: 25124 kB Committed_AS: 52516 kB PageTables: 832 kB VmallocTotal: 106488 kB VmallocUsed: 5528 kB VmallocChunk: 94392 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 4096 kB It seems that there is always a big memory "cached" ( > 900 MB) which could be reclaimed by the kernel as needed, so I'd exclude the memory exhaustion issue. Besides in the last 2 days during the backups via NFS of some machines we have more than 600 messages lines like this from the Kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x2d0) Doing some search I've found Bug 410 (http://oss.sgi.com/bugzilla/show_bug.cgi?id=410) but it seems to affect only 64bit kernel and 2.6.11, while I've a 32 bit Xeon 2.8 Ghz with kernel 2.6.9. The 1GB of DRAM is adequate to my setup in your opinion? TIA. Regards, Luca On 7/21/06, Chris Wedgwood wrote: > On Fri, Jul 21, 2006 at 02:19:34PM +0200, Luca Maranzano wrote: > > > kswapd0: page allocation failure. order:0, mode:0xd0 > > you're out of memory, see what's being so piggy > From owner-xfs@oss.sgi.com Mon Jul 24 04:04:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 04:04:26 -0700 (PDT) Received: from web31709.mail.mud.yahoo.com (web31709.mail.mud.yahoo.com [68.142.201.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6OB41DW008094 for ; Mon, 24 Jul 2006 04:04:03 -0700 Received: (qmail 62602 invoked by uid 60001); 24 Jul 2006 11:03:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RYGxkqLnlY5Nr3w03ORn1T+1ZT6KPmxJQmQszHQofh7BHhdwrTLadPnssyE+MwhAtT2ApdZHdv7tMNF3qIvK3bWVV39d7vFBbEVVICG3Y7+u6BajgQjS3/Zz/SfD5g9O2RLACjvDX56NrU2NmnrDhefWK3f7xNjoWjAr2J6g9zk= ; Message-ID: <20060724110338.62600.qmail@web31709.mail.mud.yahoo.com> Received: from [80.178.93.94] by web31709.mail.mud.yahoo.com via HTTP; Mon, 24 Jul 2006 04:03:38 PDT Date: Mon, 24 Jul 2006 04:03:38 -0700 (PDT) From: Heilige Gheist Subject: Re: XFS setting custom extent size: real-time section only? To: Nathan Scott Cc: xfs@oss.sgi.com In-Reply-To: <20060724100030.E2083275@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8412 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hgheist@yahoo.com Precedence: bulk X-list: xfs Content-Length: 1970 Lines: 60 I've checked source code of 2.6.16.13-4 in SUSE 10.1, it looks like this limitation is no longer there. However the lack of support for this in SLES9 complicates things a bit, for example we're using EMC PowerPath 4.5.1 for MPIO and it doesn't support anything but SLES9 SP2. Hardware driver support is shaky as well. Provided I have to stick with whatever kernel support there's in SLES9, what are the implications of running large volumes (150-300GB) as one big real-time section? Do I have to have non-realtime regular section? Should I expect a performance hit due to large size of real-time section? --alan --- Nathan Scott wrote: > On Sun, Jul 23, 2006 at 04:09:18AM -0700, Heilige Gheist wrote: > > I'm trying to get custom extent size per file working, but > > XFS_IOC_FSSETXATTR ioctl returns with EINVAL, > > both from my code or from xfs_io. > > The environment is SLES9 SP2, 2.6.5-7.252 kernel, > xfsprogs-2.6.25-0.6 > > After examining the kernel code in xfs_vnodeops.c we found out that > > custom extent size is supported on files in real-time section only. > > This is not mentioned anywhere else in the documentation, so I'm > > wondering whether this limitation is removed in further kernel > > versions. > > I've downloaded the recent xfsprogs-2.8.4, it uses a new flag > > XFS_XFLAG_EXTSIZE when setting the custom extent size. > > I'm not sure what kernel version do I need to work with 2.8.4, but > it's > > certainly a sign that kernel support has changed. > > Indeed it has. I'm not sure which kernel version this was merged > into, > but the rough timeframe can be seen on > http://oss.sgi.com/projects/xfs/ > on the "recent changes" table. It wont be there in any SLES9, but > IIRC > SLES10 does now include that code. > > cheers. > > -- > Nathan > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Mon Jul 24 04:50:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 04:50:13 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6OBo1DW019018 for ; Mon, 24 Jul 2006 04:50:02 -0700 Received: by nf-out-0910.google.com with SMTP id a27so1492641nfc for ; Mon, 24 Jul 2006 04:49:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CfEvVDcyfgVH76bYXyrB87cH2IVVqZqAPJ7/ur0G2PbQTPF8IMErCrF0WAOc99eI9avhw019+w5dg1R+5eK+5PbV6xYjkeYhjefU5RGLI1hmJrLPR6MiaD6iyCUfX/oouBKJSkkTDvsLCYX+OatuAjftb3u8xEcb1x0TNRzPwaQ= Received: by 10.78.177.11 with SMTP id z11mr1446547hue; Mon, 24 Jul 2006 04:49:37 -0700 (PDT) Received: by 10.78.159.14 with HTTP; Mon, 24 Jul 2006 04:49:37 -0700 (PDT) Message-ID: <68559cef0607240449m5005231t78f05673bb8309e2@mail.gmail.com> Date: Mon, 24 Jul 2006 13:49:37 +0200 From: "Luca Maranzano" To: xfs@oss.sgi.com Subject: Re: Page allocation failure writing to an XFS volume via NFS on CentOS 4.3 In-Reply-To: <20060721161326.GE12347@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68559cef0607210519q9f382c6n7104bef9cf9716f3@mail.gmail.com> <20060721161326.GE12347@tuatara.stupidest.org> X-archive-position: 8413 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liuk001@gmail.com Precedence: bulk X-list: xfs Content-Length: 619 Lines: 22 Could it be an issue about the min_free_kbytes kernel parameter? On my server its current value is 957, but I've read that this could lead to kernel memory allocation failure even if there is actually enough RAM available. Since my trouble seem to be correlated to NFS access, could it be an interaction between network and disk I/O to trigger this problem? Thanks again. Regards, Luca On 7/21/06, Chris Wedgwood wrote: > On Fri, Jul 21, 2006 at 02:19:34PM +0200, Luca Maranzano wrote: > > > kswapd0: page allocation failure. order:0, mode:0xd0 > > you're out of memory, see what's being so piggy > From owner-xfs@oss.sgi.com Mon Jul 24 07:05:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 07:05:22 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6OE55DW005072 for ; Mon, 24 Jul 2006 07:05:10 -0700 Received: from agami.com ([192.168.168.101]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id k6OCefog006058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 24 Jul 2006 05:40:42 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id k6OCeanY010312 for ; Mon, 24 Jul 2006 05:40:36 -0700 Received: from [10.12.12.141] ([10.12.12.141]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 05:42:02 -0700 Message-ID: <44C4BD30.2050507@agami.com> Date: Mon, 24 Jul 2006 17:59:36 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luca Maranzano CC: xfs@oss.sgi.com Subject: Re: Page allocation failure writing to an XFS volume via NFS on CentOS 4.3 References: <68559cef0607210519q9f382c6n7104bef9cf9716f3@mail.gmail.com> <20060721161326.GE12347@tuatara.stupidest.org> <68559cef0607240449m5005231t78f05673bb8309e2@mail.gmail.com> In-Reply-To: <68559cef0607240449m5005231t78f05673bb8309e2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2006 12:42:02.0734 (UTC) FILETIME=[900DC8E0:01C6AF1E] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 8414 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Content-Length: 3543 Lines: 95 Hi Luca, Almost all of your memory is being used for page cache which is good definitely for any I/O intensive applications. When you set min_free_kbytes to a very low number, it means that the pages used for various things (slab, cached pages) are not started to get cleaned up until it goes down to a very low level. So, it is true that memory allocation might fail if you set to to very low number /proc/meminfo: MemTotal: 1035832 kB MemFree: 12568 kB Buffers: 10468 kB Cached: 968336 kB SwapCached: 4716 kB However, there is another culprit here. The memory cleaner code should typically avoid doing memory allocation in cleanup path; otherwise it may fail. dm_mod is splitting the bio and, hence, requires the page allocation which is definitely bad in such circumstances where memory is chewed up to the last pages. It so happened the bio_alloc pool was empty and required to be filled up. For now, you should set min_free_kbytes to at least 8*1024 and preferably to [16-20] * 1024. As far as XFS memory messages are concerned, those message are indicating that the memory is either running low or so fragmented that the requested page order could not be allocated in reasonable time. kswapd0: page allocation failure. order:0, mode:0xd0 [] __alloc_pages+0x2e1/0x2f7 [] __get_free_pages+0x18/0x24 [] kmem_getpages+0x15/0x94 [] cache_grow+0x107/0x233 [] cache_alloc_refill+0x1f7/0x227 [] kmem_cache_alloc+0x46/0x4c --> Memory allocation request for bio_alloc pool. [] mempool_alloc+0xb6/0x1f9 [] autoremove_wake_function+0x0/0x2d [] autoremove_wake_function+0x0/0x2d [] EmsPlatformCreateIo+0x2a/0x60 [emcp] [] allocPio+0x18/0x40 [emcp] [] emcp_pseudo_mrf+0x27/0x60 [emcp] [] generic_make_request+0x190/0x1a0 [] bio_clone+0x8b/0xa3 [] __map_bio+0x34/0xb4 [dm_mod] [] __clone_and_map+0xc3/0x2c9 [dm_mod] [] __alloc_pages+0x1b1/0x2f7 [] __split_bio+0xaa/0x108 [dm_mod] [] dm_request+0xde/0xf1 [dm_mod] [] generic_make_request+0x190/0x1a0 [] autoremove_wake_function+0x0/0x2d [] submit_bio+0xa4/0xac [] bio_alloc+0x100/0x168 [] submit_bh+0x13e/0x163 [] xfs_submit_page+0x84/0xa8 [xfs] [] xfs_convert_page+0x1e0/0x1f4 [xfs] [] xfs_cluster_write+0x39/0x43 [xfs] [] xfs_page_state_convert+0x4c0/0x50c [xfs] [] linvfs_writepage+0x91/0xc6 [xfs] [] pageout+0x88/0xc5 [] shrink_list+0x209/0x4ea [] shrink_cache+0x1ff/0x454 [] shrink_slab+0x7d/0x14c [] shrink_zone+0x8f/0x9e [] balance_pgdat+0x197/0x2cb --> Cleaner code Regards, Shailendra Luca Maranzano wrote: > Could it be an issue about the min_free_kbytes kernel parameter? > > On my server its current value is 957, but I've read that this could > lead to kernel memory allocation failure even if there is actually > enough RAM available. > > Since my trouble seem to be correlated to NFS access, could it be an > interaction between network and disk I/O to trigger this problem? > > Thanks again. > Regards, > Luca > > > On 7/21/06, Chris Wedgwood wrote: > >> On Fri, Jul 21, 2006 at 02:19:34PM +0200, Luca Maranzano wrote: >> >> > kswapd0: page allocation failure. order:0, mode:0xd0 >> >> you're out of memory, see what's being so piggy >> > > From owner-xfs@oss.sgi.com Mon Jul 24 07:42:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 07:42:10 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6OEfxDW010263 for ; Mon, 24 Jul 2006 07:41:59 -0700 Received: by nf-out-0910.google.com with SMTP id a27so1547302nfc for ; Mon, 24 Jul 2006 07:41:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Vzf4gkXrnPSgu1bCFPUN7q93iMcs+Cw/LB89eWx15AbyVWvopLQ6aIrr3lek4spdL+k9cG/UyXwexl+6K8Eb8qwDS9wG2KaYuj4jlIgf8hkKwtNeZXEhmW9I8YZvh1ssOnmOnPTJuCG0+KuaDOSxkJQniYxIuyPw4mHS8BUdiWw= Received: by 10.78.139.5 with SMTP id m5mr1495907hud; Mon, 24 Jul 2006 06:25:09 -0700 (PDT) Received: by 10.78.165.8 with HTTP; Mon, 24 Jul 2006 06:25:08 -0700 (PDT) Message-ID: Date: Mon, 24 Jul 2006 15:25:09 +0200 From: "Artur Iwaniuk" To: linux-xfs@oss.sgi.com Subject: atime on xfs MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-archive-position: 8415 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aiwaniuk@gmail.com Precedence: bulk X-list: xfs Content-Length: 644 Lines: 22 hello, can anyone can me explain such stat on my xfs partition: File: `194/194.149.231.137' Size: 0 Blocks: 0 IO Block: 4096 pusty zwyk=B3y plik Device: 902h/2306d Inode: 1477457428 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 201/ qmaild) Gid: ( 200/ nofiles) Access: 2006-07-18 09:13:32.903206500 +0200 Modify: 2006-07-18 11:26:23.273786250 +0200 Change: 2006-07-18 11:26:23.273786250 +0200 why access time is earlier than change, modify time ? how is it posible? is there bug in xfs ? i am sure, that file was asscessed yesterday, maybe even today please, help [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Jul 24 09:03:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 09:04:01 -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 k6OG3nDW024688 for ; Mon, 24 Jul 2006 09:03:50 -0700 Received: from stargate.synerway.com (stargate.synerway.com [127.0.0.1]) by stargate.synerway.com (Postfix) with ESMTP id 13EB6454092 for ; Mon, 24 Jul 2006 18:31:30 +0200 (CEST) Received: from venus (unknown [172.16.10.150]) by stargate.synerway.com (Postfix) with ESMTP id 0515C45408E for ; Mon, 24 Jul 2006 18:31:29 +0200 (CEST) Received: by venus (Postfix, from userid 1005) id 65F4B898B0; Mon, 24 Jul 2006 18:03:17 +0200 (CEST) Date: Mon, 24 Jul 2006 18:03:17 +0200 From: Pascal GREGIS To: linux-xfs@oss.sgi.com Subject: currupted files filling with zeros after power failure Message-ID: <20060724160317.GA787@venus.synerway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 8416 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: 1057 Lines: 22 Hello everyone, I'm working on power failures on some test machines in my company. I volunteerly switch off my machine by pressing the power button and restart my machine to see how it behaves. The problem I'm facing is that about once for two crashes the last file (or at least the last file) i which I wrote becomes corrupted and filled with \0 characters. I didn't think XFS could be subject to this type of problem, however here isn't really the reason of my mail. What I would like to know is what can I do to resolve this problem? Is XFS able to recover my file with its right content, at least a consistent content, not only \0 characters? I made some tries with xfs_repair and it didn't repair it, once it put me some inodes in lost+found but id didn't repair my corrupted file. Maybe xfs_db could help, I don't know. I'm running a 2.6.11.11 kernel iwth xfsprogs-2.7.3 and xfsdump-2.2.30. Maybe is a bug in that kernel. Do you guys know if this problem has often been encountered or not,a dn if there is a way to proceed? Thank you Pascal From owner-xfs@oss.sgi.com Mon Jul 24 10:15:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 10:16:10 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6OHFuDW003379 for ; Mon, 24 Jul 2006 10:15:57 -0700 Received: from localhost (dslb-084-056-077-111.pools.arcor-ip.net [84.56.77.111]) by mondschein.lichtvoll.de (Postfix) with ESMTP id C0B45FA68A for ; Mon, 24 Jul 2006 19:15:24 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: currupted files filling with zeros after power failure Date: Mon, 24 Jul 2006 19:15:19 +0200 User-Agent: KMail/1.9.3 References: <20060724160317.GA787@venus.synerway.com> In-Reply-To: <20060724160317.GA787@venus.synerway.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241915.19642.Martin@lichtvoll.de> X-archive-position: 8417 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 2453 Lines: 57 Am Montag 24 Juli 2006 18:03 schrieb Pascal GREGIS: [ files with zero at the end after switching off the computer abruptly) > I didn't think XFS could be subject to this type of problem, however > here isn't really the reason of my mail. Hello Pascal, it is. Cause it does not do data journaling and it doesn't ensure that the data that belongs to a metadata change (i.e. enlarge a file) makes it to the disk before the metadate change. Read about "Journaling options and write latency" in http://www-128.ibm.com/developerworks/library/l-fs8.html to find out more about this. XFS behaves like ext3 with "data=writeback". This is the fastest mode of operation. "data=ordered" => writing data before metadata is slightly slower and "data=journal" => data journalling is twice as slow. AFAIK only Reiser4 (and the commercial WAFL) can do fast data journaling by use of its wandering logs feature: http://en.wikipedia.org/wiki/Wandering_log > What I would like to know is what can I do to resolve this problem? Is > XFS able to recover my file with its right content, at least a > consistent content, not only \0 characters? I made some tries with > xfs_repair and it didn't repair it, once it put me some inodes in > lost+found but id didn't repair my corrupted file. Maybe xfs_db could > help, I don't know. I think you can't fix it without changing XFS to support either data journaling or writing data before metadata. BTW seen from the metadata side the files are not corrupted. The filesystem structure is still fine. Any application that relies on the integrity of the file contents will have a problem tough. Its a speed versus data safety issue unless you use some kind of wandering logs or a another approach which doesn't require writing data twice. Still with data journaling you may get a certain granularity depending on its implementation, maybe a 4K (page granularity) write (data + metadata) made it through, while some more writes where missing. Ideally either a write *as issued* by the application will make it through completely or not at all. An additional approach is having some sort of data journaling in the application which should know best about the integrity of its own data. Many databases and servers take some precautions to ensure data integrity in case of a crash. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Mon Jul 24 14:32:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 14:32:39 -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 k6OLW8DW025835 for ; Mon, 24 Jul 2006 14:32:19 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA14890; Tue, 25 Jul 2006 07:31:26 +1000 Message-ID: <44C53C23.8040008@melbourne.sgi.com> Date: Tue, 25 Jul 2006 07:31:15 +1000 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Artur Iwaniuk CC: linux-xfs@oss.sgi.com Subject: Re: atime on xfs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8418 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1047 Lines: 35 Artur Iwaniuk wrote: > hello, > > can anyone can me explain such stat on my xfs partition: > > File: `194/194.149.231.137' > Size: 0 Blocks: 0 IO Block: 4096 pusty zwyk³y > plik > Device: 902h/2306d Inode: 1477457428 Links: 1 > Access: (0666/-rw-rw-rw-) Uid: ( 201/ qmaild) Gid: ( 200/ nofiles) > Access: 2006-07-18 09:13:32.903206500 +0200 > Modify: 2006-07-18 11:26:23.273786250 +0200 > Change: 2006-07-18 11:26:23.273786250 +0200 > > why access time is earlier than change, modify time ? how is it posible? is > there bug in xfs ? > i am sure, that file was asscessed yesterday, maybe even today > > please, help > > Are you using the noatime mount option? That will cause XFS not to update the atime, its often used since the filesystem normally has to write metadata just because someone read the file. David -- David Chatterton Phone: +61 3 9963 1934 XFS Engineering Manager Mobile: +61 409 154 121 SGI Australia http://www.sgi.com/products/storage From owner-xfs@oss.sgi.com Mon Jul 24 15:44:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 15:45:20 -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 k6OMigDW002687 for ; Mon, 24 Jul 2006 15:44:54 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA16024; Tue, 25 Jul 2006 08:44:01 +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 k6OMhxgw2111668; Tue, 25 Jul 2006 08:43:59 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6OMhuOU2090381; Tue, 25 Jul 2006 08:43:56 +1000 (EST) Date: Tue, 25 Jul 2006 08:43:56 +1000 From: Nathan Scott To: Heilige Gheist Cc: xfs@oss.sgi.com Subject: Re: XFS setting custom extent size: real-time section only? Message-ID: <20060725084356.B2090627@wobbly.melbourne.sgi.com> References: <20060724100030.E2083275@wobbly.melbourne.sgi.com> <20060724110338.62600.qmail@web31709.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060724110338.62600.qmail@web31709.mail.mud.yahoo.com>; from hgheist@yahoo.com on Mon, Jul 24, 2006 at 04:03:38AM -0700 X-archive-position: 8419 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: 1481 Lines: 38 On Mon, Jul 24, 2006 at 04:03:38AM -0700, Heilige Gheist wrote: > I've checked source code of 2.6.16.13-4 in SUSE 10.1, it looks like > this limitation is no longer there. > However the lack of support for this in SLES9 complicates things a bit, > for example we're using EMC PowerPath 4.5.1 for MPIO and it doesn't > support anything but SLES9 SP2. Hardware driver support is shaky as > well. OK. Are you certain you need this feature? (can you describe your usage a bit?) You can get large contiguous chunks of disk space via large direct writes for example, or preallocation, so maybe you could attack the issue from a different angle to solve it? > Provided I have to stick with whatever kernel support there's in SLES9, > what are the implications of running large volumes (150-300GB) as one > big real-time section? I'm not sure off the top of my head (SLES9 SP2 is relatively old now) if the realtime subvolume support there had support for buffered writes (it used to be direct IO only), I suspect it predated that change too. > Do I have to have non-realtime regular section? Yes. All metadata is stored there. > Should I expect a performance hit due to large size of real-time > section? It depends. :) For single disk, I've never seen realtime not outperform the btree allocator, for RAIDs and multiple writers I suspect you might find a different picture. You'd really have to try it and see how your specific application(s) perform. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 24 20:40:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 20:40:43 -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 k6P3e2DW012992 for ; Mon, 24 Jul 2006 20:40:13 -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 NAA21571; Tue, 25 Jul 2006 13:39:23 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 75F0558C38C1; Tue, 25 Jul 2006 13:39:23 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 944409 - readahead Message-Id: <20060725033923.75F0558C38C1@chook.melbourne.sgi.com> Date: Tue, 25 Jul 2006 13:39:23 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8421 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: 476 Lines: 14 When issuing metadata readahead, submit bio with READA not READ. Date: Tue Jul 25 13:39:04 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26603a linux-2.6/xfs_buf.c - 1.224 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.224&r2=text&tr2=1.223&f=h From owner-xfs@oss.sgi.com Mon Jul 24 20:37:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 20:37: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 k6P3aoDW012627 for ; Mon, 24 Jul 2006 20:37:01 -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 NAA21512; Tue, 25 Jul 2006 13:36:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 3AC4F58C38C1; Tue, 25 Jul 2006 13:36:09 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 944409 - DMAPI bulkstat optimisations Message-Id: <20060725033609.3AC4F58C38C1@chook.melbourne.sgi.com> Date: Tue, 25 Jul 2006 13:36:09 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8420 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: 1379 Lines: 37 Ensure we specify the type of bulkstat call we will issue (uninited variable). Date: Tue Jul 25 13:31:08 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26601a dmapi/xfs_dm.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h Rework DMAPI bulkstat calls in such a way that we can directly extract inline attributes out of the bulkstat buffer (for that case), rather than using an (extremely expensive for large icount filesystems) iget for fetching attrs. Date: Tue Jul 25 13:34:45 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26602a xfs_itable.c - 1.141 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h xfs_itable.h - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h dmapi/xfs_dm.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h From owner-xfs@oss.sgi.com Mon Jul 24 20:47:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 20:48:17 -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 k6P3lUDW014120 for ; Mon, 24 Jul 2006 20:47: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 NAA21784; Tue, 25 Jul 2006 13:46:55 +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 k6P3krgw2114902; Tue, 25 Jul 2006 13:46:53 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6P3kpSu2115059; Tue, 25 Jul 2006 13:46:51 +1000 (EST) Date: Tue, 25 Jul 2006 13:46:51 +1000 From: Nathan Scott To: vapo@melbourne.sgi.com Cc: xfs@oss.sgi.com Subject: review: rework bulkstat readahead Message-ID: <20060725134651.D2116482@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8422 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: 5349 Lines: 156 Hi all, This patch rearranges the logic inside xfs_bulkstat to issue readahead in a way that performs alot better. The most critical piece is moving the readahead out of the final read-and-format loop into the earlier build-up-irbuf-array loop. This means: - buffer readaheads are all issued at once, up front, before we start to issue the blocking reads waiting on each inode cluster; - as a by-product, the readahead which is done for the internal nodes of the AGI btree (from within xfs_inobt_increment) is now issued in the correct order relative to all the leaf readahead. I've also removed the incorrect endian swapping on the irbuf array elements, that was always unnecessary as they're only ever held in memory here. cheers. -- Nathan Index: xfs-linux/xfs_itable.c =================================================================== --- xfs-linux.orig/xfs_itable.c 2006-07-25 11:45:27.283811500 +1000 +++ xfs-linux/xfs_itable.c 2006-07-25 11:59:26.144649250 +1000 @@ -326,9 +326,9 @@ xfs_bulkstat( int i; /* loop index */ int icount; /* count of inodes good in irbuf */ xfs_ino_t ino; /* inode number (filesystem) */ - xfs_inobt_rec_t *irbp; /* current irec buffer pointer */ - xfs_inobt_rec_t *irbuf; /* start of irec buffer */ - xfs_inobt_rec_t *irbufend; /* end of good irec buffer entries */ + xfs_inobt_rec_incore_t *irbp; /* current irec buffer pointer */ + xfs_inobt_rec_incore_t *irbuf; /* start of irec buffer */ + xfs_inobt_rec_incore_t *irbufend; /* end of good irec buffer entries */ xfs_ino_t lastino=0; /* last inode number returned */ int nbcluster; /* # of blocks in a cluster */ int nicluster; /* # of inodes in a cluster */ @@ -399,7 +399,7 @@ xfs_bulkstat( * Allocate and initialize a btree cursor for ialloc btree. */ cur = xfs_btree_init_cursor(mp, NULL, agbp, agno, XFS_BTNUM_INO, - (xfs_inode_t *)0, 0); + (xfs_inode_t *)0, 0); irbp = irbuf; irbufend = irbuf + nirbuf; end_of_ag = 0; @@ -436,9 +436,9 @@ xfs_bulkstat( gcnt++; } gfree |= XFS_INOBT_MASKN(0, chunkidx); - irbp->ir_startino = cpu_to_be32(gino); - irbp->ir_freecount = cpu_to_be32(gcnt); - irbp->ir_free = cpu_to_be64(gfree); + irbp->ir_startino = gino; + irbp->ir_freecount = gcnt; + irbp->ir_free = gfree; irbp++; agino = gino + XFS_INODES_PER_CHUNK; icount = XFS_INODES_PER_CHUNK - gcnt; @@ -492,11 +492,27 @@ xfs_bulkstat( } /* * If this chunk has any allocated inodes, save it. + * Also start read-ahead now for this chunk. */ if (gcnt < XFS_INODES_PER_CHUNK) { - irbp->ir_startino = cpu_to_be32(gino); - irbp->ir_freecount = cpu_to_be32(gcnt); - irbp->ir_free = cpu_to_be64(gfree); + /* + * Loop over all clusters in the next chunk. + * Do a readahead if there are any allocated + * inodes in that cluster. + */ + for (agbno = XFS_AGINO_TO_AGBNO(mp, gino), + chunkidx = 0; + chunkidx < XFS_INODES_PER_CHUNK; + chunkidx += nicluster, + agbno += nbcluster) { + if (XFS_INOBT_MASKN(chunkidx, + nicluster) & ~gfree) + xfs_btree_reada_bufs(mp, agno, + agbno, nbcluster); + } + irbp->ir_startino = gino; + irbp->ir_freecount = gcnt; + irbp->ir_free = gfree; irbp++; icount += XFS_INODES_PER_CHUNK - gcnt; } @@ -520,33 +536,11 @@ xfs_bulkstat( for (irbp = irbuf; irbp < irbufend && ubleft >= statstruct_size; irbp++) { /* - * Read-ahead the next chunk's worth of inodes. - */ - if (&irbp[1] < irbufend) { - /* - * Loop over all clusters in the next chunk. - * Do a readahead if there are any allocated - * inodes in that cluster. - */ - for (agbno = XFS_AGINO_TO_AGBNO(mp, - be32_to_cpu(irbp[1].ir_startino)), - chunkidx = 0; - chunkidx < XFS_INODES_PER_CHUNK; - chunkidx += nicluster, - agbno += nbcluster) { - if (XFS_INOBT_MASKN(chunkidx, - nicluster) & - ~(be64_to_cpu(irbp[1].ir_free))) - xfs_btree_reada_bufs(mp, agno, - agbno, nbcluster); - } - } - /* * Now process this chunk of inodes. */ - for (agino = be32_to_cpu(irbp->ir_startino), chunkidx = 0, clustidx = 0; + for (agino = irbp->ir_startino, chunkidx = clustidx = 0; ubleft > 0 && - be32_to_cpu(irbp->ir_freecount) < XFS_INODES_PER_CHUNK; + irbp->ir_freecount < XFS_INODES_PER_CHUNK; chunkidx++, clustidx++, agino++) { ASSERT(chunkidx < XFS_INODES_PER_CHUNK); /* @@ -566,7 +560,7 @@ xfs_bulkstat( */ if ((chunkidx & (nicluster - 1)) == 0) { agbno = XFS_AGINO_TO_AGBNO(mp, - be32_to_cpu(irbp->ir_startino)) + + irbp->ir_startino) + ((chunkidx & nimask) >> mp->m_sb.sb_inopblog); @@ -606,13 +600,13 @@ xfs_bulkstat( /* * Skip if this inode is free. */ - if (XFS_INOBT_MASK(chunkidx) & be64_to_cpu(irbp->ir_free)) + if (XFS_INOBT_MASK(chunkidx) & irbp->ir_free) continue; /* * Count used inodes as free so we can tell * when the chunk is used up. */ - be32_add(&irbp->ir_freecount, 1); + irbp->ir_freecount++; ino = XFS_AGINO_TO_INO(mp, agno, agino); bno = XFS_AGB_TO_DADDR(mp, agno, agbno); if (!xfs_bulkstat_use_dinode(mp, flags, bp, From owner-xfs@oss.sgi.com Mon Jul 24 20:50:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 20:51: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 k6P3ogDW014809 for ; Mon, 24 Jul 2006 20:50:54 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA21834; Tue, 25 Jul 2006 13:50:07 +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 k6P3o5gw2117883; Tue, 25 Jul 2006 13:50:06 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6P3o4rZ2116392; Tue, 25 Jul 2006 13:50:04 +1000 (EST) Date: Tue, 25 Jul 2006 13:50:04 +1000 From: Nathan Scott To: vapo@melbourne.sgi.com Cc: xfs@oss.sgi.com Subject: review: increase bulkstat readahead window Message-ID: <20060725135004.E2116482@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8423 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: 2712 Lines: 69 Hi all, We limit the amount of bulkstat readahead we can issue based on the size of the array of inode cluster records (irbuf), which we allocate on each bulkstat call. Increasing the size of this array has shown noticable performance improvements, and given bulkstat is always called to scan the filesystem from one end to the other, we're going to have to issue that IO at some point, may as well do it up front. We don't want to get silly in sizing this buffer, though, as it needs to be a contiguous chunk of memory. Here I've increased it from 1 page to 4 pages, with some logic to halve the size incrementally if we cant allocate that successfully (as we do in one or two other places in XFS, for other things). cheers. -- Nathan Index: xfs-linux/xfs_itable.c =================================================================== --- xfs-linux.orig/xfs_itable.c 2006-07-25 11:59:26.144649250 +1000 +++ xfs-linux/xfs_itable.c 2006-07-25 12:01:53.734832500 +1000 @@ -325,6 +325,8 @@ xfs_bulkstat( xfs_agino_t gino; /* current btree rec's start inode */ int i; /* loop index */ int icount; /* count of inodes good in irbuf */ + int irbsize; /* size of irec buffer in bytes */ + unsigned int kmflags; /* flags for allocating irec buffer */ xfs_ino_t ino; /* inode number (filesystem) */ xfs_inobt_rec_incore_t *irbp; /* current irec buffer pointer */ xfs_inobt_rec_incore_t *irbuf; /* start of irec buffer */ @@ -370,12 +372,20 @@ xfs_bulkstat( nimask = ~(nicluster - 1); nbcluster = nicluster >> mp->m_sb.sb_inopblog; /* - * Allocate a page-sized buffer for inode btree records. - * We could try allocating something smaller, but for normal - * calls we'll always (potentially) need the whole page. + * Allocate a local buffer for inode cluster btree records. + * This caps our maximum readahead window (so don't be stingy) + * but we must handle the case where we can't get a contiguous + * multi-page buffer, so we drop back toward pagesize; the end + * case we ensure succeeds, via appropriate allocation flags. */ - irbuf = kmem_alloc(NBPC, KM_SLEEP); - nirbuf = NBPC / sizeof(*irbuf); + irbsize = NBPP * 4; + kmflags = KM_SLEEP | KM_MAYFAIL; + while (!(irbuf = kmem_alloc(irbsize, kmflags))) { + if ((irbsize >>= 1) <= NBPP) + kmflags = KM_SLEEP; + } + nirbuf = irbsize / sizeof(*irbuf); + /* * Loop over the allocation groups, starting from the last * inode returned; 0 means start of the allocation group. @@ -673,7 +683,7 @@ xfs_bulkstat( /* * Done, we're either out of filesystem or space to put the data. */ - kmem_free(irbuf, NBPC); + kmem_free(irbuf, irbsize); *ubcountp = ubelem; if (agno >= mp->m_sb.sb_agcount) { /* From owner-xfs@oss.sgi.com Mon Jul 24 21:14:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 24 Jul 2006 21:15: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 k6P4EbDW017486 for ; Mon, 24 Jul 2006 21:14:46 -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 OAA22240; Tue, 25 Jul 2006 14:13:58 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id B966F58C38C1; Tue, 25 Jul 2006 14:13:58 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954772 - remount vs nobarrier/barrier Message-Id: <20060725041358.B966F58C38C1@chook.melbourne.sgi.com> Date: Tue, 25 Jul 2006 14:13:58 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8424 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: 671 Lines: 16 Fix remount vs no/barrier options by ensuring we clear unwanted flags from iclog buffers before submitting them for writing. Date: Tue Jul 25 14:13:32 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes,hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26605a xfs_log.c - 1.324 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.324&r2=text&tr2=1.323&f=h linux-2.6/xfs_buf.h - 1.114 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.114&r2=text&tr2=1.113&f=h From owner-xfs@oss.sgi.com Tue Jul 25 03:51:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 03:51:45 -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 k6PAp7DY001440 for ; Tue, 25 Jul 2006 03:51:10 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G5JOW-0007pb-5G; Tue, 25 Jul 2006 10:40:04 +0100 Date: Tue, 25 Jul 2006 10:40:04 +0100 From: Christoph Hellwig To: Nathan Scott Cc: vapo@melbourne.sgi.com, xfs@oss.sgi.com Subject: Re: review: increase bulkstat readahead window Message-ID: <20060725094004.GB29615@infradead.org> References: <20060725135004.E2116482@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060725135004.E2116482@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8428 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 933 Lines: 18 On Tue, Jul 25, 2006 at 01:50:04PM +1000, Nathan Scott wrote: > Hi all, > > We limit the amount of bulkstat readahead we can issue based on > the size of the array of inode cluster records (irbuf), which we > allocate on each bulkstat call. Increasing the size of this array > has shown noticable performance improvements, and given bulkstat > is always called to scan the filesystem from one end to the other, > we're going to have to issue that IO at some point, may as well do > it up front. We don't want to get silly in sizing this buffer, > though, as it needs to be a contiguous chunk of memory. Here I've > increased it from 1 page to 4 pages, with some logic to halve the > size incrementally if we cant allocate that successfully (as we do > in one or two other places in XFS, for other things). ok. I wonder whether we should add a generic kmalloc_leastmost routine (with a name better than that of course..) From owner-xfs@oss.sgi.com Tue Jul 25 03:51:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 03:51:39 -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 k6PAp7DW001440 for ; Tue, 25 Jul 2006 03:51:09 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G5JRG-0007tY-Hq; Tue, 25 Jul 2006 10:42:54 +0100 Date: Tue, 25 Jul 2006 10:42:54 +0100 From: Christoph Hellwig To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: review: bump up xlog_state_do_callback loop checking Message-ID: <20060725094254.GC29615@infradead.org> References: <20060724155730.A2090627@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060724155730.A2090627@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8426 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 2667 Lines: 67 On Mon, Jul 24, 2006 at 03:57:30PM +1000, Nathan Scott wrote: > Hi, > > I started running the QA tests with an external log on a ramdisk & > now constantly see situations where xlog_state_so_callback reports: > > Filesystem "sda2": xlog_state_do_callback: looping 10 > Filesystem "sda2": xlog_state_do_callback: looping 20 > Filesystem "sda2": xlog_state_do_callback: looping 10 > Filesystem "sda2": xlog_state_do_callback: looping 10 > Filesystem "sda2": xlog_state_do_callback: looping 10 > Filesystem "sda2": xlog_state_do_callback: looping 20 > > on the system console. Tim and I looked into this further, and remembered > long ago list discussion on the topic, after others reported this too (also > on ramdisks interestingly): > http://oss.sgi.com/archives/xfs/2005-02/msg00108.html > http://oss.sgi.com/archives/xfs/2005-02/msg00109.html > > So, it seems Glen added this to try detect infinte loops on systems where > we do log callback processing in interrupt context (i.e. IRIX). It seems > that with ramdisks its causing spurious warnings due to how quickly the > completion handlers will be run (immediate, sync) though. We can quite > easily still keep the same infinite loop check but bump up the reporting > threshold to something that wont happen for ramdisks/raid caches ... and > report each several-thousand iterations instead of each tenth one. It > does still seems worthwhile to keep the infinte loop detection though, so > at this stage I've left that in there. > > Tim also insisted I optimise away the modulo operation that we do in the > callback processing loop, while I was fixing this other issue, and he's > pointed out an easy way to do that... ok > Index: xfs-linux/xfs_log.c > =================================================================== > --- xfs-linux.orig/xfs_log.c 2006-07-20 12:06:56.455633750 +1000 > +++ xfs-linux/xfs_log.c 2006-07-20 12:17:19.819492000 +1000 > @@ -2243,9 +2243,13 @@ xlog_state_do_callback( > > iclog = iclog->ic_next; > } while (first_iclog != iclog); > - if (repeats && (repeats % 10) == 0) { > + > + if (repeats > 5000) { > + flushcnt += repeats; > + repeats = 0; > xfs_fs_cmn_err(CE_WARN, log->l_mp, > - "xlog_state_do_callback: looping %d", repeats); > + "%s: possible infinite loop (%d iterations)", > + __FUNCTION__, flushcnt); > } > } while (!ioerrors && loopdidcallbacks); > > @@ -2277,6 +2281,7 @@ xlog_state_do_callback( > } > #endif > > + flushcnt = 0; > if (log->l_iclog->ic_state & (XLOG_STATE_ACTIVE|XLOG_STATE_IOERROR)) { > flushcnt = log->l_flushcnt; > log->l_flushcnt = 0; > > ---end quoted text--- From owner-xfs@oss.sgi.com Tue Jul 25 03:51:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 03:51:44 -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 k6PAp7DX001440 for ; Tue, 25 Jul 2006 03:51:10 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G5JNC-0007jc-9O; Tue, 25 Jul 2006 10:38:42 +0100 Date: Tue, 25 Jul 2006 10:38:42 +0100 From: Christoph Hellwig To: Nathan Scott Cc: vapo@melbourne.sgi.com, xfs@oss.sgi.com Subject: Re: review: rework bulkstat readahead Message-ID: <20060725093842.GA29615@infradead.org> References: <20060725134651.D2116482@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060725134651.D2116482@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8427 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 942 Lines: 22 On Tue, Jul 25, 2006 at 01:46:51PM +1000, Nathan Scott wrote: > Hi all, > > This patch rearranges the logic inside xfs_bulkstat to issue > readahead in a way that performs alot better. The most critical > piece is moving the readahead out of the final read-and-format > loop into the earlier build-up-irbuf-array loop. This means: > > - buffer readaheads are all issued at once, up front, before we > start to issue the blocking reads waiting on each inode cluster; > > - as a by-product, the readahead which is done for the internal > nodes of the AGI btree (from within xfs_inobt_increment) is now > issued in the correct order relative to all the leaf readahead. > > I've also removed the incorrect endian swapping on the irbuf array > elements, that was always unnecessary as they're only ever held in > memory here. looks good and sorry for not noticing the unessecary swapping when doing the sparse annotations. From owner-xfs@oss.sgi.com Tue Jul 25 03:51:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 03:51:38 -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 k6PAp7DZ001440 for ; Tue, 25 Jul 2006 03:51:11 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G5JSw-0007th-EP; Tue, 25 Jul 2006 10:44:38 +0100 Date: Tue, 25 Jul 2006 10:44:38 +0100 From: Christoph Hellwig To: Nathan Scott Cc: Christoph Hellwig , xfs@oss.sgi.com, jeremy@sgi.com Subject: Re: review: fix remount vs barrier options Message-ID: <20060725094438.GD29615@infradead.org> References: <20060721152807.D1998769@wobbly.melbourne.sgi.com> <20060723190650.GA22180@infradead.org> <20060724100147.F2083275@wobbly.melbourne.sgi.com> <20060724112737.D2085715@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060724112737.D2085715@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8425 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 1085 Lines: 21 On Mon, Jul 24, 2006 at 11:27:37AM +1000, Nathan Scott wrote: > On Mon, Jul 24, 2006 at 10:01:48AM +1000, Nathan Scott wrote: > > On Sun, Jul 23, 2006 at 08:06:50PM +0100, Christoph Hellwig wrote: > > > Shouldn't we make sure we clear all flags when reusing a log buffer? > > > Relying on clearing individual flags seems rather fragile to me. > > > > *nod* - good idea. I'll rework xlog_sync, and resend later. > > After looking more, I'm less convinced. There's some flags we wont > want to touch - the "internal" flags like PAGE_CACHE, etc (that one > is obviously not relevent here, but still, at some point a flag may > be introduced that we accidentally break by clearing all flags). > > There is a ZEROFLAGS macro, I've added ORDERED to that and used it > instead. I also fixed the double barrier issue for the split log > write case - here's an updated patch... The flag clearing changes look good. But why is it okay to skip the ordered flag on the first block? We want to make sure all previous I/O is finished before even doing the first log block write, don't we? From owner-xfs@oss.sgi.com Tue Jul 25 10:01:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 10:01:54 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6PH1RDW015616 for ; Tue, 25 Jul 2006 10:01:39 -0700 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k6PHA0Du42747659; Tue, 25 Jul 2006 10:10:01 -0700 (PDT) Message-ID: <44C64E42.3090502@sgi.com> Date: Tue, 25 Jul 2006 12:00:50 -0500 From: Bill Kendall User-Agent: Mail/News 1.5 (X11/20060228) MIME-Version: 1.0 To: Justin Piszcz CC: xfs@oss.sgi.com Subject: Re: chattr +d dir References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8430 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 1107 Lines: 30 On 07/23/06 14:16, Justin Piszcz wrote: > I used the chattr +d option for no_dump for a certain directory, but it > still appears xfsdump dumped the directory anyway? > > Is there some special usage/way to make xfsdump NOT dump a certain > directory? Perhaps you have an older xfsdump. This was recently added to the xfsdump man page: ticular size. Additionally, when xfsdump is run with the -e option, files that are tagged with the "no dump" file attribute will not be included in the dump. The chattr(1) command can be used to set this attribute on individual files or entire subtrees. To tag an individual file for exclusion from the dump: $ chattr +d file To tag all files in a subtree for exclusion from the dump: $ chattr -R +d directory Note that any new files or directories created in a directory which has the "no dump" attribute set will automatically inherit this attribute. Also note that xfsdump does not check directories for the "no dump" attribute. Bill From owner-xfs@oss.sgi.com Tue Jul 25 10:02:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 10:02:33 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6PH2BDW015785 for ; Tue, 25 Jul 2006 10:02:11 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id E703D61012B4; Tue, 25 Jul 2006 13:01:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id E324E16172ECC; Tue, 25 Jul 2006 13:01:45 -0400 (EDT) Date: Tue, 25 Jul 2006 13:01:45 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Bill Kendall cc: xfs@oss.sgi.com Subject: Re: chattr +d dir In-Reply-To: <44C64E42.3090502@sgi.com> Message-ID: References: <44C64E42.3090502@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8431 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1212 Lines: 41 Thanks for the update. On Tue, 25 Jul 2006, Bill Kendall wrote: > On 07/23/06 14:16, Justin Piszcz wrote: >> I used the chattr +d option for no_dump for a certain directory, but it >> still appears xfsdump dumped the directory anyway? >> >> Is there some special usage/way to make xfsdump NOT dump a certain >> directory? > > Perhaps you have an older xfsdump. This was recently added to the > xfsdump man page: > > ticular size. Additionally, when xfsdump is run with the -e > option, > files that are tagged with the "no dump" file attribute will not > be > included in the dump. The chattr(1) command can be used to set > this > attribute on individual files or entire subtrees. > > To tag an individual file for exclusion from the dump: > > $ chattr +d file > > To tag all files in a subtree for exclusion from the dump: > > $ chattr -R +d directory > > Note that any new files or directories created in a directory which > has > the "no dump" attribute set will automatically inherit this > attribute. > Also note that xfsdump does not check directories for the "no > dump" > attribute. > > Bill > From owner-xfs@oss.sgi.com Tue Jul 25 09:52:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 09:52:16 -0700 (PDT) Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6PGpqDW014458 for ; Tue, 25 Jul 2006 09:51:56 -0700 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6PGpRKA008791 for ; Tue, 25 Jul 2006 09:51:27 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6PGpQ3T015542 for ; Tue, 25 Jul 2006 10:51:26 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k6PGpQ30009401 for ; Tue, 25 Jul 2006 11:51:26 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k6PGpQ1N009400 for xfs@oss.sgi.com; Tue, 25 Jul 2006 11:51:26 -0500 (CDT) Date: Tue, 25 Jul 2006 11:51:26 -0500 From: Dean Roehrich To: xfs@oss.sgi.com Subject: Re: DMF & DMAPI Message-ID: <20060725165126.GA9392@kickball-mn.Central.Sun.COM> References: <44C64704.8000301@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C64704.8000301@gmail.com> User-Agent: Mutt/1.5.9i X-archive-position: 8429 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 658 Lines: 16 On Wed, Jul 26, 2006 at 12:29:56AM +0800, Michael Li (gmail) wrote: > Hi, Dean and all, > > How does DMF using DMAPI? If I lauch a DM application to > receive/response some data event message(read/write/truncate) on the > same MDS on which a DMF server is running, is it possible to bother > DMF's job? If it will happen, is there any tips to help designing such a > DM application? The DMAPI specification does not cover the case of having two independent DMAPI apps that want to see the same events from the same files on the same filesystem. Does that scenario even make sense when you consider the problem that DMAPI was intended to solve? Dean From owner-xfs@oss.sgi.com Tue Jul 25 10:30:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 10:30:48 -0700 (PDT) Received: from mail.exavio.com.cn ([211.102.241.197]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6PHUPDW019949 for ; Tue, 25 Jul 2006 10:30:30 -0700 Received: from [192.168.1.101] ([221.219.118.41]) (authenticated bits=0) by mail.exavio.com.cn (8.12.8/8.12.8) with ESMTP id k6PGOjKK003505; Wed, 26 Jul 2006 00:24:54 +0800 Message-ID: <44C64704.8000301@gmail.com> Date: Wed, 26 Jul 2006 00:29:56 +0800 From: "Michael Li (gmail)" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Roehrich , xfs@oss.sgi.com Subject: DMF & DMAPI Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8432 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 325 Lines: 12 Hi, Dean and all, How does DMF using DMAPI? If I lauch a DM application to receive/response some data event message(read/write/truncate) on the same MDS on which a DMF server is running, is it possible to bother DMF's job? If it will happen, is there any tips to help designing such a DM application? Thanks, Michael From owner-xfs@oss.sgi.com Tue Jul 25 11:08:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 11:09:05 -0700 (PDT) Received: from web31702.mail.mud.yahoo.com (web31702.mail.mud.yahoo.com [68.142.201.182]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6PI8XDW023588 for ; Tue, 25 Jul 2006 11:08:35 -0700 Received: (qmail 64196 invoked by uid 60001); 25 Jul 2006 18:08:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2v0P8Y8f1QBCsUsvLaEoK9C013mAcC7Vv+VwbtlL1J2jIJ2rRbHdjwu7urlnkQT6Sr9qSRTboy8uJy60BvXWdAsWLtf2TcL3dVMJfKtvJ3fk4holkfyZEG71c42CooeSOYRZgMnJbAHAGuq5Qukjpjo03+o8FumMPVBFbi5AM1o= ; Message-ID: <20060725180807.64194.qmail@web31702.mail.mud.yahoo.com> Received: from [80.178.93.94] by web31702.mail.mud.yahoo.com via HTTP; Tue, 25 Jul 2006 11:08:07 PDT Date: Tue, 25 Jul 2006 11:08:07 -0700 (PDT) From: Heilige Gheist Subject: Re: XFS setting custom extent size: real-time section only? To: Nathan Scott Cc: xfs@oss.sgi.com In-Reply-To: <20060725084356.B2090627@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8433 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hgheist@yahoo.com Precedence: bulk X-list: xfs Content-Length: 1394 Lines: 35 [..] > > OK. Are you certain you need this feature? (can you describe your > usage a bit?) You can get large contiguous chunks of disk space via > large direct writes for example, or preallocation, so maybe you could > attack the issue from a different angle to solve it? The application is reading and writing sparse file of 0.5-1GB, with heavy skew toward read. The data is written in clusters of various size, depending on data stream type. The filesystem is constantly being updated with new data, older files are removed, the filesystem gets fragmented and we're down to the allocation extent size in terms of available contiguous disk space. When you speak of pre-allocation, do you suggest using XFS_IOC_RESVSP ioctl interface to explicitly reserve blocks in advance? Can it guarantee contiguous chunk allocation? Provided it can, pre-allocation is pretty much the same as extent management, isn't it? Basically you pay for unfragmented contiguous block layout with extra disk space reserved for unwritten data. If so, why offer custom extent size in the first place? [..] > > Do I have to have non-realtime regular section? > Yes. All metadata is stored there. Is there any way I can do sizing of the meta-data? --alan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Tue Jul 25 13:16:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 13:17:24 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6PKGtDW006473 for ; Tue, 25 Jul 2006 13:16:57 -0700 Received: from linux01.gwdg.de ([134.76.13.21]) by mailer.gwdg.de with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60) (envelope-from ) id 1G5TKK-0000rP-PC; Tue, 25 Jul 2006 22:16:26 +0200 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k6PKGBEx015113; Tue, 25 Jul 2006 22:16:13 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k6PKGAUc015107; Tue, 25 Jul 2006 22:16:11 +0200 Date: Tue, 25 Jul 2006 22:16:10 +0200 (MEST) From: Jan Engelhardt To: Nathan Scott cc: xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 In-Reply-To: <20060724090138.C2083275@wobbly.melbourne.sgi.com> Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <20060724090138.C2083275@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8434 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 241 Lines: 10 Now that 2.6.17.7 is finally there, I am going to eyeball my XFS filesystems. Does xfsprogs 2.7.11 suffice? Please update the XFS FAQ about this problem (and the solution, for others that did not read LKML), thanks! Jan Engelhardt -- From owner-xfs@oss.sgi.com Tue Jul 25 15:22:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 15:22: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 k6PMM0DW019211 for ; Tue, 25 Jul 2006 15:22:12 -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 IAA12366; Wed, 26 Jul 2006 08:21: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 k6PMLFgw2108179; Wed, 26 Jul 2006 08:21:15 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6PMLCd22139508; Wed, 26 Jul 2006 08:21:12 +1000 (EST) Date: Wed, 26 Jul 2006 08:21:12 +1000 From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com, jeremy@sgi.com Subject: Re: review: fix remount vs barrier options Message-ID: <20060726082112.A2118045@wobbly.melbourne.sgi.com> References: <20060721152807.D1998769@wobbly.melbourne.sgi.com> <20060723190650.GA22180@infradead.org> <20060724100147.F2083275@wobbly.melbourne.sgi.com> <20060724112737.D2085715@wobbly.melbourne.sgi.com> <20060725094438.GD29615@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060725094438.GD29615@infradead.org>; from hch@infradead.org on Tue, Jul 25, 2006 at 10:44:38AM +0100 X-archive-position: 8435 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: 997 Lines: 27 Hi Christoph, On Tue, Jul 25, 2006 at 10:44:38AM +0100, Christoph Hellwig wrote: > ... > The flag clearing changes look good. But why is it okay to skip the > ordered flag on the first block? We want to make sure all previous I/O > is finished before even doing the first log block write, don't we? No, thats not necessary - Tim and I looked into this at length - the way the split log write happens, we keep a count in the iclog struct for this write (its initially 2); once the first write completes (and this is guaranteed to be before the final write by the final write's barrier), we atomically decrement that counter. Once it reaches zero (i.e. only one buffer completion was remaining, which is also the non- split log write case) only then will we do any callback processing, metadata unpinning, etc, etc. So, its a safe and valid optimisation - otherwise we do an extra write with barrier whenever we wrap around the physical log end. Thanks for the reviews! cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 25 15:38:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 15:38:51 -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 k6PMbtDW020869 for ; Tue, 25 Jul 2006 15:38:06 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA12643; Wed, 26 Jul 2006 08:37: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 k6PMbCgw2139803; Wed, 26 Jul 2006 08:37:12 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6PMb9dR2136856; Wed, 26 Jul 2006 08:37:09 +1000 (EST) Date: Wed, 26 Jul 2006 08:37:09 +1000 From: Nathan Scott To: Christoph Hellwig , cw@f00f.org Cc: vapo@melbourne.sgi.com, xfs@oss.sgi.com Subject: Re: review: increase bulkstat readahead window Message-ID: <20060726083709.B2118045@wobbly.melbourne.sgi.com> References: <20060725135004.E2116482@wobbly.melbourne.sgi.com> <20060725094004.GB29615@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060725094004.GB29615@infradead.org>; from hch@infradead.org on Tue, Jul 25, 2006 at 10:40:04AM +0100 X-archive-position: 8436 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: 1440 Lines: 31 On Tue, Jul 25, 2006 at 10:40:04AM +0100, Christoph Hellwig wrote: > On Tue, Jul 25, 2006 at 01:50:04PM +1000, Nathan Scott wrote: > > .. it up front. We don't want to get silly in sizing this buffer, > > though, as it needs to be a contiguous chunk of memory. Here I've > > increased it from 1 page to 4 pages, with some logic to halve the > > size incrementally if we cant allocate that successfully (as we do > > in one or two other places in XFS, for other things). > > ok. I wonder whether we should add a generic kmalloc_leastmost routine > (with a name better than that of course..) Yeah, Chris suggested the same thing - probably we should, since two people suggested it now. :) The XFS users I know of are the inode hash, the dquot hash, and this bulkstat code. Oh, and probably the attr_multi ioctl code should use this for its buffer too. If you can suggest a good interface, I'll have at it. Semi-related, I have another patch which instruments our local memory allocation routines to add a KM_LARGE flag - I've been using this to locate and annotate the few remaining places where we will do multi- page allocations inside XFS... any interest in this patch? I've been tossing up whether or not to merge it (its debug only, so no runtime cost is added for usual case), just so we can always easily see where the large allocations are, and trap any inadvertantly introduced new ones... thoughts? cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 25 16:01:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 16:02:17 -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 k6PN1aDW023806 for ; Tue, 25 Jul 2006 16:01:47 -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 JAA13256; Wed, 26 Jul 2006 09:00: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 k6PN0rgw2140302; Wed, 26 Jul 2006 09:00:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6PN0ppk2142639; Wed, 26 Jul 2006 09:00:51 +1000 (EST) Date: Wed, 26 Jul 2006 09:00:51 +1000 From: Nathan Scott To: Heilige Gheist Cc: xfs@oss.sgi.com Subject: Re: XFS setting custom extent size: real-time section only? Message-ID: <20060726090051.C2118045@wobbly.melbourne.sgi.com> References: <20060725084356.B2090627@wobbly.melbourne.sgi.com> <20060725180807.64194.qmail@web31702.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060725180807.64194.qmail@web31702.mail.mud.yahoo.com>; from hgheist@yahoo.com on Tue, Jul 25, 2006 at 11:08:07AM -0700 X-archive-position: 8437 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: 1828 Lines: 53 On Tue, Jul 25, 2006 at 11:08:07AM -0700, Heilige Gheist wrote: > [..] > > > > OK. Are you certain you need this feature? (can you describe your > > usage a bit?) You can get large contiguous chunks of disk space via > > large direct writes for example, or preallocation, so maybe you could > > attack the issue from a different angle to solve it? > > The application is reading and writing sparse file of 0.5-1GB, with > heavy skew toward read. The data is written in clusters of various > size, depending on data stream type. The filesystem is constantly being > updated with new data, older files are removed, the filesystem gets > fragmented and we're down to the allocation extent size in terms of > available contiguous disk space. Hmm. > When you speak of pre-allocation, do you suggest using XFS_IOC_RESVSP > ioctl interface to explicitly reserve blocks in advance? Yes, thats the one. > Can it guarantee contiguous chunk allocation? No, but it does the best it can under the circumstances, which is usually pretty good. > management, isn't it? Basically you pay for unfragmented contiguous > block layout with extra disk space reserved for unwritten data. But its not really "extra" if you know you're going to use it, right? > If so, why offer custom extent size in the first place? Its a different concept, solving different problems really. One is at the extent level, the other is at (typically large) ranges of bytes that can be more than an extent. One is a "harder" guarantee than the the other of getting contiguous space, as they call into the allocator in different ways. > [..] > > > Do I have to have non-realtime regular section? > > Yes. All metadata is stored there. > Is there any way I can do sizing of the meta-data? I'm not sure what you're asking there...? cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 25 16:11:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 16:12:12 -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 k6PNBZDW025094 for ; Tue, 25 Jul 2006 16:11:47 -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 JAA13397; Wed, 26 Jul 2006 09:10:55 +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 k6PNAqgw2138982; Wed, 26 Jul 2006 09:10:53 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6PNAoGe2105822; Wed, 26 Jul 2006 09:10:50 +1000 (EST) Date: Wed, 26 Jul 2006 09:10:50 +1000 From: Nathan Scott To: Jan Engelhardt Cc: xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060726091050.D2118045@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <20060724090138.C2083275@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jengelh@linux01.gwdg.de on Tue, Jul 25, 2006 at 10:16:10PM +0200 X-archive-position: 8438 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: 493 Lines: 18 On Tue, Jul 25, 2006 at 10:16:10PM +0200, Jan Engelhardt wrote: > Now that 2.6.17.7 is finally there, I am going to eyeball my XFS > filesystems. Does xfsprogs 2.7.11 suffice? Sure, except for the repair issue which Barry is working on (see the FAQ). > Please update the XFS FAQ about this problem (and the solution, for > others that did not read LKML), thanks! That was done last week. You shoulda read it before sending this, and saved me some time replying. ;) cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 25 17:16:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 17:16:55 -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 k6Q0GFDW008882 for ; Tue, 25 Jul 2006 17:16:29 -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 KAA14704 for ; Wed, 26 Jul 2006 10:15:40 +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 k6Q0Fcgw2134166 for ; Wed, 26 Jul 2006 10:15:39 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6Q0FbS92140290 for xfs@oss.sgi.com; Wed, 26 Jul 2006 10:15:37 +1000 (EST) Date: Wed, 26 Jul 2006 10:15:37 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: review: block bogus bulkstat messages, last stage Message-ID: <20060726101537.H2118045@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8439 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: 5578 Lines: 175 Hi, Earlier changes removed most of the bogus verbosity from fsstress runs with debug kernels, when bulkstat is asked to report on non- inode data in its stat'ing. This resolves the one remaining case which is the bulkstat_one vs a xfs_dilocate warning, by passing a flag down into dilocate indicating we may be looking up garbage, and not to spam the console in that situation. cheers. -- Nathan Index: xfs-linux/xfs_ialloc.c =================================================================== --- xfs-linux.orig/xfs_ialloc.c 2006-06-15 11:40:12.439501000 +1000 +++ xfs-linux/xfs_ialloc.c 2006-06-15 11:42:31.948219750 +1000 @@ -1196,6 +1196,7 @@ xfs_dilocate( "(0x%llx)", ino, XFS_AGINO_TO_INO(mp, agno, agino)); } + xfs_stack_trace(); #endif /* DEBUG */ return XFS_ERROR(EINVAL); } Index: xfs-linux/xfs_inode.h =================================================================== --- xfs-linux.orig/xfs_inode.h 2006-06-15 11:39:27.000000000 +1000 +++ xfs-linux/xfs_inode.h 2006-06-15 11:42:31.956220250 +1000 @@ -389,11 +389,14 @@ typedef struct xfs_inode { (((vfsp)->vfs_flag & VFS_GRPID) || ((pip)->i_d.di_mode & S_ISGID)) /* - * xfs_iget.c prototypes. + * Flags for xfs_iget() */ +#define XFS_IGET_CREATE 0x1 +#define XFS_IGET_BULKSTAT 0x2 -#define IGET_CREATE 1 - +/* + * xfs_iget.c prototypes. + */ void xfs_ihash_init(struct xfs_mount *); void xfs_ihash_free(struct xfs_mount *); void xfs_chash_init(struct xfs_mount *); @@ -425,7 +428,7 @@ int xfs_itobp(struct xfs_mount *, struc xfs_inode_t *, xfs_dinode_t **, struct xfs_buf **, xfs_daddr_t, uint); int xfs_iread(struct xfs_mount *, struct xfs_trans *, xfs_ino_t, - xfs_inode_t **, xfs_daddr_t); + xfs_inode_t **, xfs_daddr_t, uint); int xfs_iread_extents(struct xfs_trans *, xfs_inode_t *, int); int xfs_ialloc(struct xfs_trans *, xfs_inode_t *, mode_t, xfs_nlink_t, xfs_dev_t, struct cred *, xfs_prid_t, Index: xfs-linux/xfs_itable.c =================================================================== --- xfs-linux.orig/xfs_itable.c 2006-06-15 11:40:53.982097250 +1000 +++ xfs-linux/xfs_itable.c 2006-06-15 11:42:31.972221250 +1000 @@ -52,7 +52,8 @@ xfs_bulkstat_one_iget( bhv_vnode_t *vp; int error; - error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, bno); + error = xfs_iget(mp, NULL, ino, + XFS_IGET_BULKSTAT, XFS_ILOCK_SHARED, &ip, bno); if (error) { *stat = BULKSTAT_RV_NOTHING; return error; Index: xfs-linux/xfs_inode.c =================================================================== --- xfs-linux.orig/xfs_inode.c 2006-06-15 11:39:27.000000000 +1000 +++ xfs-linux/xfs_inode.c 2006-06-15 11:42:32.004223250 +1000 @@ -851,7 +851,8 @@ xfs_iread( xfs_trans_t *tp, xfs_ino_t ino, xfs_inode_t **ipp, - xfs_daddr_t bno) + xfs_daddr_t bno, + uint imap_flags) { xfs_buf_t *bp; xfs_dinode_t *dip; @@ -871,7 +872,7 @@ xfs_iread( * return NULL as well. Set i_blkno to 0 so that xfs_itobp() will * know that this is a new incore inode. */ - error = xfs_itobp(mp, tp, ip, &dip, &bp, bno, 0); + error = xfs_itobp(mp, tp, ip, &dip, &bp, bno, imap_flags); if (error) { kmem_zone_free(xfs_inode_zone, ip); return error; @@ -1110,7 +1111,7 @@ xfs_ialloc( * to prevent others from looking at until we're done. */ error = xfs_trans_iget(tp->t_mountp, tp, ino, - IGET_CREATE, XFS_ILOCK_EXCL, &ip); + XFS_IGET_CREATE, XFS_ILOCK_EXCL, &ip); if (error != 0) { return error; } Index: xfs-linux/xfs_iget.c =================================================================== --- xfs-linux.orig/xfs_iget.c 2006-06-15 11:40:48.181734750 +1000 +++ xfs-linux/xfs_iget.c 2006-06-15 11:42:32.112230000 +1000 @@ -290,11 +290,11 @@ again: finish_inode: if (ip->i_d.di_mode == 0) { - if (!(flags & IGET_CREATE)) + if (!(flags & XFS_IGET_CREATE)) return ENOENT; xfs_iocore_inode_reinit(ip); } - + if (lock_flags != 0) xfs_ilock(ip, lock_flags); @@ -320,21 +320,20 @@ finish_inode: * Read the disk inode attributes into a new inode structure and get * a new vnode for it. This should also initialize i_ino and i_mount. */ - error = xfs_iread(mp, tp, ino, &ip, bno); - if (error) { + error = xfs_iread(mp, tp, ino, &ip, bno, + (flags & XFS_IGET_BULKSTAT) ? XFS_IMAP_BULKSTAT : 0); + if (error) return error; - } vn_trace_exit(vp, "xfs_iget.alloc", (inst_t *)__return_address); xfs_inode_lock_init(ip, vp); xfs_iocore_inode_init(ip); - if (lock_flags != 0) { + if (lock_flags) xfs_ilock(ip, lock_flags); - } - - if ((ip->i_d.di_mode == 0) && !(flags & IGET_CREATE)) { + + if ((ip->i_d.di_mode == 0) && !(flags & XFS_IGET_CREATE)) { xfs_idestroy(ip); return ENOENT; } Index: xfs-linux/dmapi/xfs_dm.c =================================================================== --- xfs-linux.orig/dmapi/xfs_dm.c 2006-06-15 11:40:53.950095250 +1000 +++ xfs-linux/dmapi/xfs_dm.c 2006-06-15 11:42:32.136231500 +1000 @@ -549,7 +549,8 @@ xfs_dm_bulkall_iget_one( int value_len = *value_lenp; int error; - error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, bno); + error = xfs_iget(mp, NULL, ino, + XFS_IGET_BULKSTAT, XFS_ILOCK_SHARED, &ip, bno); if (error) return error; if (ip->i_d.di_mode == 0) { @@ -815,7 +816,8 @@ xfs_dm_bulkattr_iget_one( dm_handle_t handle; int error; - error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, bno); + error = xfs_iget(mp, NULL, ino, + XFS_IGET_BULKSTAT, XFS_ILOCK_SHARED, &ip, bno); if (error) return error; if (ip->i_d.di_mode == 0) { From owner-xfs@oss.sgi.com Tue Jul 25 17:24:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 17:25:21 -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 k6Q0OiDW012178 for ; Tue, 25 Jul 2006 17:24:56 -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 KAA14970 for ; Wed, 26 Jul 2006 10:24:10 +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 k6Q0O7gw2141410 for ; Wed, 26 Jul 2006 10:24:08 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6Q0O6Yw2141785 for xfs@oss.sgi.com; Wed, 26 Jul 2006 10:24:06 +1000 (EST) Date: Wed, 26 Jul 2006 10:24:06 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: review: fix bulkstat error detection logic Message-ID: <20060726102406.I2118045@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8440 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: 1951 Lines: 57 Hi, An earlier patch to remove bulkstat verbosity in debug kernels changed the xfs_itobp logic slightly, such that we no longer do the first stage of buffer checking there. Turns out this isn't the right fix, we need to do that check still, and pass out the error code to bulkstat still, otherwise we either trip up logic in later debug code, or pass out success incorrectly. This fixes that up, and is the last bulkstat change I have for awhile. :) Its error handling is correct once more, its a fair bit quicker, and no more debug-kernel console spam - hooray! cheers. -- Nathan Index: xfs-linux/xfs_inode.c =================================================================== --- xfs-linux.orig/xfs_inode.c 2006-07-25 12:02:05.787585750 +1000 +++ xfs-linux/xfs_inode.c 2006-07-25 13:04:58.941286750 +1000 @@ -335,10 +335,9 @@ xfs_itobp( #if !defined(__KERNEL__) ni = 0; #elif defined(DEBUG) - ni = (imap_flags & XFS_IMAP_BULKSTAT) ? 0 : - (BBTOB(imap.im_len) >> mp->m_sb.sb_inodelog); + ni = BBTOB(imap.im_len) >> mp->m_sb.sb_inodelog; #else /* usual case */ - ni = (imap_flags & XFS_IMAP_BULKSTAT) ? 0 : 1; + ni = 1; #endif for (i = 0; i < ni; i++) { @@ -349,11 +348,15 @@ xfs_itobp( (i << mp->m_sb.sb_inodelog)); di_ok = INT_GET(dip->di_core.di_magic, ARCH_CONVERT) == XFS_DINODE_MAGIC && XFS_DINODE_GOOD_VERSION(INT_GET(dip->di_core.di_version, ARCH_CONVERT)); - if (unlikely(XFS_TEST_ERROR(!di_ok, mp, XFS_ERRTAG_ITOBP_INOTOBP, - XFS_RANDOM_ITOBP_INOTOBP))) { + if (unlikely(XFS_TEST_ERROR(!di_ok, mp, + XFS_ERRTAG_ITOBP_INOTOBP, + XFS_RANDOM_ITOBP_INOTOBP))) { + if (imap_flags & XFS_IMAP_BULKSTAT) { + xfs_trans_brelse(tp, bp); + return XFS_ERROR(EINVAL); + } #ifdef DEBUG - if (!(imap_flags & XFS_IMAP_BULKSTAT)) - cmn_err(CE_ALERT, + cmn_err(CE_ALERT, "Device %s - bad inode magic/vsn " "daddr %lld #%d (magic=%x)", XFS_BUFTARG_NAME(mp->m_ddev_targp), From owner-xfs@oss.sgi.com Tue Jul 25 18:40:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 18:41:22 -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 k6Q1ehDW022295 for ; Tue, 25 Jul 2006 18:40:56 -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 LAA16546; Wed, 26 Jul 2006 11:40:05 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id DD81858C38C1; Wed, 26 Jul 2006 11:40:04 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 944409 - bulkstat Message-Id: <20060726014004.DD81858C38C1@chook.melbourne.sgi.com> Date: Wed, 26 Jul 2006 11:40:04 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8442 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: 555 Lines: 16 Increase the size of the buffer holding the local inode cluster list, to increase our potential readahead window and in turn improve bulkstat performance. Date: Wed Jul 26 11:39:37 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch,cw The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26607a xfs_itable.c - 1.143 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.143&r2=text&tr2=1.142&f=h From owner-xfs@oss.sgi.com Tue Jul 25 18:35:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 18:36:21 -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 k6Q1ZdDW021262 for ; Tue, 25 Jul 2006 18:35:51 -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 LAA16474; Wed, 26 Jul 2006 11:34:59 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 655AA58C38C1; Wed, 26 Jul 2006 11:34:59 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 944409 - bulkstat readahead Message-Id: <20060726013459.655AA58C38C1@chook.melbourne.sgi.com> Date: Wed, 26 Jul 2006 11:34:59 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8441 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: 545 Lines: 16 Drop unneeded endian conversion in bulkstat and start readahead for batches of inode cluster buffers at once, before any blocking reads are issued. Date: Wed Jul 26 11:34:38 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26606a xfs_itable.c - 1.142 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.142&r2=text&tr2=1.141&f=h From owner-xfs@oss.sgi.com Tue Jul 25 22:54:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 25 Jul 2006 22:54:34 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6Q5sJDW022752 for ; Tue, 25 Jul 2006 22:54:20 -0700 Received: by nf-out-0910.google.com with SMTP id a27so488114nfc for ; Tue, 25 Jul 2006 22:53:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=bKzOJ8qH8LzY8H9LKLAClw+7B2TpLRvSKICrK3QghTNinuhOWvd1EfAFVHoWq6g8V8gCtZWUY4D+PG0QVbUi786SIOXTZM4A5pbhCyz7zjeTrEW9KTNWj1jDx6Q7a1/sqiBjeb4jAH1TYejriAmDwDhf5hN/a8IqsfXJ/XfB0jI= Received: by 10.78.158.11 with SMTP id g11mr2831081hue; Tue, 25 Jul 2006 21:24:49 -0700 (PDT) Received: by 10.78.148.2 with HTTP; Tue, 25 Jul 2006 21:24:49 -0700 (PDT) Message-ID: Date: Wed, 26 Jul 2006 12:24:49 +0800 From: "Michael Li (Gmail)" To: "Dean Roehrich" , xfs@oss.sgi.com Subject: Re: DMF & DMAPI MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8444 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikore.li@gmail.com Precedence: bulk X-list: xfs Content-Length: 253 Lines: 13 Hi, Dean, Is there a way to dispatch the read event to different channel? So that we can get both the DM application I mentioned and DMF work together. Is it difficult to do? Seems not so easy... Thanks, Michael [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Jul 26 02:25:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Jul 2006 02:25:29 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6Q9PHDW000330 for ; Wed, 26 Jul 2006 02:25:17 -0700 Received: from deepdance.of.teamix.net (blackhole.teamix.net [194.150.191.251]) by mondschein.lichtvoll.de (Postfix) with ESMTP id A3F68FA68E for ; Wed, 26 Jul 2006 11:24:32 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: finally there it is: 2.6.17.7 contains XFS corruption fix Date: Wed, 26 Jul 2006 11:24:45 +0200 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607261124.45399.Martin@lichtvoll.de> X-archive-position: 8445 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 288 Lines: 16 Hello, 2.6.17.7 contains fix for http://bugzilla.kernel.org/show_bug.cgi?id=6757 So no need to apply the patch manually anymore. Kudos to kernel stable team! Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Wed Jul 26 05:21:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Jul 2006 05:21:54 -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 k6QCL8DW027405 for ; Wed, 26 Jul 2006 05:21:08 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G5gaN-0002dT-J5; Wed, 26 Jul 2006 11:25:51 +0100 Date: Wed, 26 Jul 2006 11:25:51 +0100 From: Christoph Hellwig To: Nathan Scott Cc: cw@f00f.org, vapo@melbourne.sgi.com, xfs@oss.sgi.com Subject: Re: review: increase bulkstat readahead window Message-ID: <20060726102551.GA9141@infradead.org> References: <20060725135004.E2116482@wobbly.melbourne.sgi.com> <20060725094004.GB29615@infradead.org> <20060726083709.B2118045@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060726083709.B2118045@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8446 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 1942 Lines: 46 On Wed, Jul 26, 2006 at 08:37:09AM +1000, Nathan Scott wrote: > On Tue, Jul 25, 2006 at 10:40:04AM +0100, Christoph Hellwig wrote: > > On Tue, Jul 25, 2006 at 01:50:04PM +1000, Nathan Scott wrote: > > > .. it up front. We don't want to get silly in sizing this buffer, > > > though, as it needs to be a contiguous chunk of memory. Here I've > > > increased it from 1 page to 4 pages, with some logic to halve the > > > size incrementally if we cant allocate that successfully (as we do > > > in one or two other places in XFS, for other things). > > > > ok. I wonder whether we should add a generic kmalloc_leastmost routine > > (with a name better than that of course..) > > Yeah, Chris suggested the same thing - probably we should, since two > people suggested it now. :) The XFS users I know of are the inode > hash, the dquot hash, and this bulkstat code. Oh, and probably the > attr_multi ioctl code should use this for its buffer too. If you can > suggest a good interface, I'll have at it. Maybe we can start with a common XFS routine first: kmem_alloc_greedy(size_t *size, size_t minsize, unsigned int flags) { void *ptr; while (!(ptr = kmem_alloc(*size, flags))) { if ((*size >>= 1) <= minsize) flags = KM_SLEEP; } return ptr; } > Semi-related, I have another patch which instruments our local memory > allocation routines to add a KM_LARGE flag - I've been using this to > locate and annotate the few remaining places where we will do multi- > page allocations inside XFS... any interest in this patch? I've been > tossing up whether or not to merge it (its debug only, so no runtime > cost is added for usual case), just so we can always easily see where > the large allocations are, and trap any inadvertantly introduced new > ones... thoughts? I'm happy with that flag, but I'd prefer it only allocations with KM_LARGE would go to vmalloc so that we can start to untangle the allocator wrapping mess. From owner-xfs@oss.sgi.com Wed Jul 26 06:07:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Jul 2006 06:07:45 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6QD7WDW002357 for ; Wed, 26 Jul 2006 06:07:34 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k6QD73vj007623 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 26 Jul 2006 09:07:03 -0400 Subject: [patch]typo From: Ming Zhang Reply-To: mingz@ele.uri.edu To: linux-xfs Content-Type: text/plain Date: Wed, 26 Jul 2006 09:06:57 -0400 Message-Id: <1153919217.2658.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8447 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 642 Lines: 18 A typo in xfs_fsr man page. Ming --- xfs_fsr.8.old 2006-07-26 09:05:06.000000000 -0400 +++ xfs_fsr.8 2006-07-26 09:05:38.000000000 -0400 @@ -107,7 +107,7 @@ file to a temporary location and then interchanging the data extents of the target and temporary files in an atomic manner. This method requires that enough free disk space be available to copy -any given file and that the space be less fragmented then the original +any given file and that the space be less fragmented than the original file. It also requires the owner of the file to have enough remaining filespace quota to do the copy on systems running quotas. From owner-xfs@oss.sgi.com Wed Jul 26 06:30:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Jul 2006 06:30:37 -0700 (PDT) Received: from mail01.miraclelinux.com (ns.miraclelinux.com [219.118.163.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6QDUHDW006609 for ; Wed, 26 Jul 2006 06:30:22 -0700 Received: from mail01 (localhost.localdomain [127.0.0.1]) by mail01.miraclelinux.com (Postfix) with ESMTP id 69C813000EB; Wed, 26 Jul 2006 20:22:51 +0900 (JST) Received: from [10.1.1.93] (dhcp-0093.miraclelinux.com []) by mail01.miraclelinux.com ([10.1.0.10]); Wed, 26 Jul 2006 11:22:51 +0000 Message-ID: <44C7508A.5010500@miraclelinux.com> Date: Wed, 26 Jul 2006 20:22:50 +0900 From: Robert User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Cc: Robert Subject: Unresolved generic_file_write_nolock Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8448 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: robert@miraclelinux.com Precedence: bulk X-list: xfs Content-Length: 1717 Lines: 59 Hi XFS guys I like to use XFS but I have a compile question for xfs-modules-fs-modules-1.3.3-2.4.21-27.0.2.EL.sgi9.src.rpm which is download from ftp://oss.sgi/com/projects/xfs/testing/RHEL3/ I compiled it with kernel-2.4.21-37.EL with normal steps. Everything is ok and then I run the command installkernel but got below error message like this: depmod ..... xfs.o Unresolved symble : generic_file_write_nolock Then I had tried to find this function in 2.4.21-37EL and mainstream kernel-2.4.32, but it does not exist in them. I refer to SPEC file and found this generic_file_write_nolock() already deleted at linux-2.4.21-odirect.patch, no more exist. Even in the old kernel 2.4.21-20.EL, I can not find it. This generic_file_write_nolock() is used in xfs/linux/xfs_lrw.c line 745 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2.4.22) || defined\ (KERNEL_HAS_NEW_O_DIRECT) : : : #else retry : if (ioflags & IO_ISDIRECT) { xfs_inval_cached_pages(vp, io, *offset, 1, 1); } ret = generic_file_write_nolock(file, buf, size, offset); #endif Logically, the #if KERNEL_VERSION_CODE is smaller than 2.4.22. The generic_file_write_nolock should be included by C preprocessor. So, could you guys tell me why the uploaded RPM: xfs-modules-smp-1.3.3-2.4.21_27.0.2.EL.sgi9_sgi2.i686.rpm does not included this function, generic_file_write_nolock? and Did you compile the xfs-modules with the same kernel 2.4.21-27.0.2.EL.sgi9_sgi2? I can not find generic_file_write_nolock in the System.map of the its uploaded RPM : kernel-smp-2.4.21-27.0.2.EL.sgi9.i686.rpm This issue take my time for about 1 week and still not solved. Any comment is thankfully. Best Regards Robert From owner-xfs@oss.sgi.com Wed Jul 26 08:39:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Jul 2006 08:39:55 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6QFdXDW032712 for ; Wed, 26 Jul 2006 08:39:36 -0700 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6QFd7e6023372 for ; Wed, 26 Jul 2006 09:39:07 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6QFZrHD007807 for ; Wed, 26 Jul 2006 09:35:53 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k6QFd6bT014621; Wed, 26 Jul 2006 10:39:06 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k6QFd6nb014620; Wed, 26 Jul 2006 10:39:06 -0500 (CDT) Date: Wed, 26 Jul 2006 10:39:06 -0500 From: Dean Roehrich To: "Michael Li (Gmail)" Cc: xfs@oss.sgi.com Subject: Re: DMF & DMAPI Message-ID: <20060726153906.GA14535@kickball-mn.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 8450 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 473 Lines: 16 On Wed, Jul 26, 2006 at 12:24:49PM +0800, Michael Li (Gmail) wrote: > Hi, Dean, > > Is there a way to dispatch the read event to different channel? So that we > can get both the DM application I mentioned and DMF work together. Is it > difficult to do? Seems not so easy... Given the existing DMAPI specification and implementation, I don't see how to to this. You're using the wrong tool for the job. DMAPI is not designed to be a generalized event mechanism. Dean From owner-xfs@oss.sgi.com Wed Jul 26 18:20:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Jul 2006 18:20:23 -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 k6R1JtDW026818 for ; Wed, 26 Jul 2006 18:20:07 -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 LAA13713 for ; Thu, 27 Jul 2006 11:19:19 +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 k6R1IqEo38285533 for ; Thu, 27 Jul 2006 11:18:53 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6R1IqL337600737 for linux-xfs@oss.sgi.com; Thu, 27 Jul 2006 11:18:52 +1000 (AEST) Date: Thu, 27 Jul 2006 11:18:52 +1000 (AEST) From: Timothy Shimmin Message-Id: <200607270118.k6R1IqL337600737@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE xfs_fsr.8 X-archive-position: 8451 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 501 Lines: 17 Fix typo noticed by Ming Zhang. Thanks. Date: Thu Jul 27 11:18:40 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-cmds Inspected by: mingz@ele.uri.edu The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26614a xfsdump/man/man8/xfs_fsr.8 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/man/man8/xfs_fsr.8.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h - Fix typo noticed by Ming Zhang. From owner-xfs@oss.sgi.com Thu Jul 27 00:37:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 00:37:46 -0700 (PDT) Received: from mail01.miraclelinux.com (ns.miraclelinux.com [219.118.163.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6R7bTDW030805 for ; Thu, 27 Jul 2006 00:37:34 -0700 Received: from mail01 (localhost.localdomain [127.0.0.1]) by mail01.miraclelinux.com (Postfix) with ESMTP id 3640B3000BA; Thu, 27 Jul 2006 16:37:05 +0900 (JST) Received: from [10.1.1.93] (dhcp-0093.miraclelinux.com []) by mail01.miraclelinux.com ([10.1.0.10]); Thu, 27 Jul 2006 07:37:05 +0000 Message-ID: <44C86D20.2040908@miraclelinux.com> Date: Thu, 27 Jul 2006 16:37:04 +0900 From: Robert User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Cc: Robert Subject: Re: Unresolved generic_file_write_nolock References: <44C7508A.5010500@miraclelinux.com> In-Reply-To: <44C7508A.5010500@miraclelinux.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8453 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: robert@miraclelinux.com Precedence: bulk X-list: xfs Content-Length: 2480 Lines: 93 Hi I had solved this problem. I will describe in this email. At frist, the error message for this issue is as below: Loading xfs.o module /lib/xfs.o : unresolved symbol generic_file_write_nolock ERROR : /bin/insmod exited abnormally creating block devices mounting root filesystem mount : error 19 mounting xfs ......... I changed all #if LINUX_VERSION_CODE >= KERNEL_VERSION(2.4.22) || defined\ (KERNEL_HAS_NEW_O_DIRECT) in fs/xfs/linux/xfs_lrw.c to #if LINUX_VERSION_CODE >= KERNEL_VERSION(2.4.21) || defined\ (KERNEL_HAS_NEW_O_DIRECT) and rebuild, install kernel. Everything goes well now. Please comment. Thank you Robert Robert wrote: > Hi XFS guys > > I like to use XFS but I have a compile question for > > xfs-modules-fs-modules-1.3.3-2.4.21-27.0.2.EL.sgi9.src.rpm > > which is download from ftp://oss.sgi/com/projects/xfs/testing/RHEL3/ > > > I compiled it with kernel-2.4.21-37.EL with normal steps. Everything > is ok and then I run the command installkernel but got below error > message like this: > > depmod ..... xfs.o > Unresolved symble : generic_file_write_nolock > > Then I had tried to find this function in 2.4.21-37EL and mainstream > kernel-2.4.32, but it does not exist in them. I refer to SPEC file > and found this generic_file_write_nolock() already deleted at > linux-2.4.21-odirect.patch, no more exist. Even in the old kernel > 2.4.21-20.EL, I can not find it. > > This generic_file_write_nolock() is used in xfs/linux/xfs_lrw.c line 745 > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2.4.22) || defined\ > (KERNEL_HAS_NEW_O_DIRECT) > : > : > : > #else > retry : > if (ioflags & IO_ISDIRECT) { > xfs_inval_cached_pages(vp, io, *offset, 1, 1); > } > ret = generic_file_write_nolock(file, buf, size, offset); > #endif > > Logically, the #if KERNEL_VERSION_CODE is smaller than 2.4.22. > The generic_file_write_nolock should be included by C preprocessor. > So, could you guys tell me why the uploaded RPM: > > xfs-modules-smp-1.3.3-2.4.21_27.0.2.EL.sgi9_sgi2.i686.rpm > > does not included this function, generic_file_write_nolock? > > and Did you compile the xfs-modules with the same kernel > 2.4.21-27.0.2.EL.sgi9_sgi2? > > I can not find generic_file_write_nolock in the System.map of the > its uploaded RPM : > > kernel-smp-2.4.21-27.0.2.EL.sgi9.i686.rpm > > This issue take my time for about 1 week and still not solved. > Any comment is thankfully. > > Best Regards > Robert > From owner-xfs@oss.sgi.com Thu Jul 27 06:25:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 06:25:44 -0700 (PDT) Received: from server077.de-nserver.de (server077.de-nserver.de [62.27.12.245]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6RDPHDW005648 for ; Thu, 27 Jul 2006 06:25:18 -0700 Received: (qmail 7028 invoked from network); 27 Jul 2006 14:24:52 +0200 Received: from unknown (HELO ?192.168.0.70?) (hostmaster@profihost.com@84.134.46.66) by server077.de-nserver.de with SMTP; 27 Jul 2006 14:24:52 +0200 X-User-Auth: Auth by hostmaster@profihost.com through 84.134.46.66 Message-ID: <44C8B08F.8020603@profihost.com> Date: Thu, 27 Jul 2006 14:24:47 +0200 From: ProfiHost - Stefan Priebe User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: nathans@sgi.com CC: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: XFS / Quota Bug in 2.6.17.x and 2.6.18x References: <44C8A5F1.7060604@profihost.com> <20060727120425.GB6825@martell.zuzino.mipt.ru> In-Reply-To: <20060727120425.GB6825@martell.zuzino.mipt.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 8455 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: s.priebe@profihost.com Precedence: bulk X-list: xfs Content-Length: 1907 Lines: 53 Hello! The crash only occurs if you use quota and an IDE Drive without barrier support. The Problem is, that on a new mount of a root filesystem - the flag VFS_RDONLY is set - and so no barrier check is done before checking quota. With this patch barrier check is done always. The partition should not be mounted at that moment, so it could not be READ ONLY. For mount -o remount, rw or something like this - XFS uses another function where VFS_RDONLY is checked. Error Message: ns2 Wed Jul 26 14:22:58 2006 "I/O error in filesystem ("hda6") meta-data dev hda6 block 0x23db5ab ("xlog_iodone") error 5 buf count 1024" ns2 Wed Jul 26 14:22:58 2006 "xfs_force_shutdown(hda6,0x2) called from line 959 of file fs/xfs/xfs_log.c. Return address = 0xc0211535" ns2 Wed Jul 26 14:22:58 2006 "Filesystem "hda6": Log I/O Error Detected. Shutting down filesystem: hda6" ns2 Wed Jul 26 14:22:58 2006 "Please umount the filesystem, and rectify the problem(s)" ns2 Wed Jul 26 14:22:58 2006 "xfs_force_shutdown(hda6,0x1) called from line 338 of file fs/xfs/xfs_rw.c. Return address = 0xc0211535" ns2 Wed Jul 26 14:22:58 2006 "xfs_force_shutdown(hda6,0x1) called from line 338 of file fs/xfs/xfs_rw.c. Return address = 0xc0211535" Patch: --- fs/xfs/xfs_vfsops.c.orig 2006-07-27 14:22:25.185949750 +0200 +++ fs/xfs/xfs_vfsops.c 2006-07-27 14:22:28.246141000 +0200 @@ -523,7 +523,7 @@ xfs_mount( if (error) goto error2; - if ((mp->m_flags & XFS_MOUNT_BARRIER) && !(vfsp->vfs_flag & VFS_RDONLY)) + if (mp->m_flags & XFS_MOUNT_BARRIER) xfs_mountfs_check_barriers(mp); error = XFS_IOINIT(vfsp, args, flags); Best regards, Stefan Ihr ProfiHost Team ------------------------------------------ ProfiHost e.K. Lindener Str 15 38300 Wolfenbüttel Tel.: 05331 996890 Fax: 05331 996899 URL: http://www.profihost.com E-Mail: support@profihost.com From owner-xfs@oss.sgi.com Thu Jul 27 16:21:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 16:22:19 -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 k6RNLPDW010623 for ; Thu, 27 Jul 2006 16:21:36 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09980; Fri, 28 Jul 2006 09:20:45 +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 k6RNKfgw2196160; Fri, 28 Jul 2006 09:20:42 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6RNKac82195100; Fri, 28 Jul 2006 09:20:36 +1000 (EST) Date: Fri, 28 Jul 2006 09:20:36 +1000 From: Nathan Scott To: Josh Triplett Cc: linux-kernel@vger.kernel.org, Andrew Morton , xfs@oss.sgi.com Subject: Re: [PATCH] [xfs] Add lock annotations to xfs_trans_update_ail and xfs_trans_delete_ail Message-ID: <20060728092035.C2196410@wobbly.melbourne.sgi.com> References: <1153938323.12517.58.camel@josh-work.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1153938323.12517.58.camel@josh-work.beaverton.ibm.com>; from josht@us.ibm.com on Wed, Jul 26, 2006 at 11:25:23AM -0700 X-archive-position: 8457 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: 609 Lines: 16 On Wed, Jul 26, 2006 at 11:25:23AM -0700, Josh Triplett wrote: > xfs_trans_update_ail and xfs_trans_delete_ail get called with the AIL lock > held, and release it. Add lock annotations to these two functions (abstracted > like the AIL lock itself) so that sparse can check callers for lock pairing, > and so that sparse will not complain about these functions since they > intentionally use locks in this manner. Thanks Josh, looks good - I'll get it merged. I'd prefer to just open code the use of __acquires/__releases for clarity, but I can easily make that change before merging. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 27 16:18:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 16:19:24 -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 k6RNIODW006209 for ; Thu, 27 Jul 2006 16:18:36 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09942; Fri, 28 Jul 2006 09:17:42 +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 k6RNHdgw2196524; Fri, 28 Jul 2006 09:17:39 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6RNHaWj2195218; Fri, 28 Jul 2006 09:17:36 +1000 (EST) Date: Fri, 28 Jul 2006 09:17:35 +1000 From: Nathan Scott To: Christoph Hellwig Cc: cw@f00f.org, vapo@melbourne.sgi.com, xfs@oss.sgi.com Subject: Re: review: increase bulkstat readahead window Message-ID: <20060728091735.B2196410@wobbly.melbourne.sgi.com> References: <20060725135004.E2116482@wobbly.melbourne.sgi.com> <20060725094004.GB29615@infradead.org> <20060726083709.B2118045@wobbly.melbourne.sgi.com> <20060726102551.GA9141@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060726102551.GA9141@infradead.org>; from hch@infradead.org on Wed, Jul 26, 2006 at 11:25:51AM +0100 X-archive-position: 8456 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: 1180 Lines: 30 On Wed, Jul 26, 2006 at 11:25:51AM +0100, Christoph Hellwig wrote: > Maybe we can start with a common XFS routine first: > > kmem_alloc_greedy(size_t *size, size_t minsize, unsigned int flags) Looks good, I'll create a patch & send out later today. Actually, we could say minsize is 1 page, and simplify - for our uses in XFS, that will suffice... or dya want that extra parameter for the more generic version later? > > cost is added for usual case), just so we can always easily see where > > the large allocations are, and trap any inadvertantly introduced new > > ones... thoughts? > > I'm happy with that flag, but I'd prefer it only allocations with > KM_LARGE would go to vmalloc so that we can start to untangle the > allocator wrapping mess. Yep - that was the other reason why I started down that path - I'm not convinced we really need the vmalloc calls anymore, we don't get near the max slab cutoff on my i386 test box anyway, AFAICT. Long term, we should be removing the vmalloc call, but needs more beating to be sure nothing can get there nowadays - ultimately we should just BUG_ON over a max size (below the current vmalloc cutoff). cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 27 16:43:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 16:44:18 -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 k6RNhcDW014579 for ; Thu, 27 Jul 2006 16:43: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 JAA10341; Fri, 28 Jul 2006 09:43:00 +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 k6RNgvgw2198518; Fri, 28 Jul 2006 09:42:57 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6RNgsEw2197245; Fri, 28 Jul 2006 09:42:54 +1000 (EST) Date: Fri, 28 Jul 2006 09:42:54 +1000 From: Nathan Scott To: ProfiHost - Stefan Priebe Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS / Quota Bug in 2.6.17.x and 2.6.18x Message-ID: <20060728094254.F2196410@wobbly.melbourne.sgi.com> References: <44C8A5F1.7060604@profihost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44C8A5F1.7060604@profihost.com>; from s.priebe@profihost.com on Thu, Jul 27, 2006 at 01:39:29PM +0200 X-archive-position: 8458 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: 777 Lines: 24 Hi Stefan, On Thu, Jul 27, 2006 at 01:39:29PM +0200, ProfiHost - Stefan Priebe wrote: > Hello! > > The crash only occurs if you use quota and IDE without barrier support. > > The Problem is, that on a new mount of a root filesystem - the flag > VFS_RDONLY is set - and so no barrier check is done before checking > quota. With this patch barrier check is done always. The partition > should not be mounted at that moment. For mount -o remount, rw or > something like this it uses another function where VFS_RDONLY is checked. Ah, I see. The patch isn't quite right, I think we will now need to also add a test to xfs_mountfs_check_barriers() to ensure the device beneath us is not bdev_read_only(). I'll add that and get the fix merged, thanks. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 27 20:07:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 20:07: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 k6S37HDW015433 for ; Thu, 27 Jul 2006 20:07:29 -0700 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12814 for ; Fri, 28 Jul 2006 11:55:31 +1000 Message-Id: <200607280155.LAA12814@larry.melbourne.sgi.com> From: "Barry Naujok" To: Subject: Review: xfs_repair fixes for dir2 corruption Date: Fri, 28 Jul 2006 11:58:52 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax00DM5+WfZtIjRIOJK2rx/dCVVAAFQ6xw In-Reply-To: <20060728091735.B2196410@wobbly.melbourne.sgi.com> X-archive-position: 8459 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 48192 Lines: 1572 This patch addresses the following xfs_repair issues: - Can rebuild most corrupted directories. Some will be beyond repair and the contents of those will end up in lost+found. - Fixed potential problems with the duplicate name checking by properly referencing the buffers where the names are stored. - Unified the two hash lists used in directory checks. - Fixed a case where incorrectly reference counted and dirty buffers were never written to disk (most common observation of this is an inaccessible lost+found directory after a repair). For those that are keen to fix the 16777216 problem, give this patch a go. =========================================================================== xfsprogs/include/cache.h =========================================================================== --- a/xfsprogs/include/cache.h 2006-07-28 11:46:09.000000000 +1000 +++ b/xfsprogs/include/cache.h 2006-07-27 16:17:47.804986322 +1000 @@ -30,6 +30,7 @@ struct cache_node; typedef void *cache_key_t; typedef void (*cache_walk_t)(struct cache_node *); typedef struct cache_node * (*cache_node_alloc_t)(void); +typedef void (*cache_node_flush_t)(struct cache_node *); typedef void (*cache_node_relse_t)(struct cache_node *); typedef unsigned int (*cache_node_hash_t)(cache_key_t, unsigned int); typedef int (*cache_node_compare_t)(struct cache_node *, cache_key_t); @@ -38,6 +39,7 @@ typedef unsigned int (*cache_bulk_relse_ struct cache_operations { cache_node_hash_t hash; cache_node_alloc_t alloc; + cache_node_flush_t flush; cache_node_relse_t relse; cache_node_compare_t compare; cache_bulk_relse_t bulkrelse; /* optional */ @@ -49,6 +51,7 @@ struct cache { pthread_mutex_t c_mutex; /* node count mutex */ cache_node_hash_t hash; /* node hash function */ cache_node_alloc_t alloc; /* allocation function */ + cache_node_flush_t flush; /* flush dirty data function */ cache_node_relse_t relse; /* memory free function */ cache_node_compare_t compare; /* comparison routine */ cache_bulk_relse_t bulkrelse; /* bulk release routine */ @@ -75,6 +78,7 @@ struct cache *cache_init(unsigned int, s void cache_destroy(struct cache *); void cache_walk(struct cache *, cache_walk_t); void cache_purge(struct cache *); +void cache_flush(struct cache *); int cache_node_get(struct cache *, cache_key_t, struct cache_node **); void cache_node_put(struct cache_node *); =========================================================================== xfsprogs/include/libxfs.h =========================================================================== --- a/xfsprogs/include/libxfs.h 2006-07-28 11:46:09.000000000 +1000 +++ b/xfsprogs/include/libxfs.h 2006-07-27 16:34:45.308344014 +1000 @@ -257,6 +257,7 @@ extern int libxfs_writebuf_int (xfs_buf_ extern struct cache *libxfs_bcache; extern struct cache_operations libxfs_bcache_operations; extern void libxfs_bcache_purge (void); +extern void libxfs_bcache_flush (void); extern xfs_buf_t *libxfs_getbuf (dev_t, xfs_daddr_t, int); extern void libxfs_putbuf (xfs_buf_t *); extern void libxfs_purgebuf (xfs_buf_t *); @@ -467,6 +468,8 @@ extern int libxfs_bmap_finish (xfs_trans xfs_fsblock_t, int *); extern int libxfs_bmap_next_offset (xfs_trans_t *, xfs_inode_t *, xfs_fileoff_t *, int); +extern int libxfs_bmap_last_offset(xfs_trans_t *, xfs_inode_t *, + xfs_fileoff_t *, int); extern int libxfs_bunmapi (xfs_trans_t *, xfs_inode_t *, xfs_fileoff_t, xfs_filblks_t, int, xfs_extnum_t, xfs_fsblock_t *, xfs_bmap_free_t *, int *); =========================================================================== xfsprogs/libxfs/cache.c =========================================================================== --- a/xfsprogs/libxfs/cache.c 2006-07-28 11:46:09.000000000 +1000 +++ b/xfsprogs/libxfs/cache.c 2006-07-27 17:42:43.812685388 +1000 @@ -60,6 +60,7 @@ cache_init( cache->c_hashsize = hashsize; cache->hash = cache_operations->hash; cache->alloc = cache_operations->alloc; + cache->flush = cache_operations->flush; cache->relse = cache_operations->relse; cache->compare = cache_operations->compare; cache->bulkrelse = cache_operations->bulkrelse ? @@ -422,6 +423,39 @@ cache_purge( cache_abort(); } #endif + /* flush any remaining nodes to disk */ + cache_flush(cache); +} + +/* + * Flush all nodes in the cache to disk. + */ +void +cache_flush( + struct cache * cache) +{ + struct cache_hash * hash; + struct list_head * head; + struct list_head * pos; + struct cache_node * node; + int i; + + if (!cache->flush) + return; + + for (i = 0; i < cache->c_hashsize; i++) { + hash = &cache->c_hash[i]; + + pthread_mutex_lock(&hash->ch_mutex); + head = &hash->ch_list; + for (pos = head->next; pos != head; pos = pos->next) { + node = (struct cache_node *)pos; + pthread_mutex_lock(&node->cn_mutex); + cache->flush(node); + pthread_mutex_unlock(&node->cn_mutex); + } + pthread_mutex_unlock(&hash->ch_mutex); + } } #define HASH_REPORT (3*HASH_CACHE_RATIO) =========================================================================== xfsprogs/libxfs/rdwr.c =========================================================================== --- a/xfsprogs/libxfs/rdwr.c 2006-07-28 11:46:09.000000000 +1000 +++ b/xfsprogs/libxfs/rdwr.c 2006-07-27 16:40:56.612373938 +1000 @@ -416,6 +416,15 @@ libxfs_iomove(xfs_buf_t *bp, uint boff, } static void +libxfs_bflush(struct cache_node *node) +{ + xfs_buf_t *bp = (xfs_buf_t *)node; + + if ((bp != NULL) && (bp->b_flags & LIBXFS_B_DIRTY)) + libxfs_writebufr(bp); +} + +static void libxfs_brelse(struct cache_node *node) { xfs_buf_t *bp = (xfs_buf_t *)node; @@ -442,9 +451,16 @@ libxfs_bcache_purge(void) cache_purge(libxfs_bcache); } +void +libxfs_bcache_flush(void) +{ + cache_flush(libxfs_bcache); +} + struct cache_operations libxfs_bcache_operations = { /* .hash */ libxfs_bhash, /* .alloc */ libxfs_balloc, + /* .flush */ libxfs_bflush, /* .relse */ libxfs_brelse, /* .compare */ libxfs_bcompare, /* .bulkrelse */ NULL /* TODO: lio_listio64 interface? */ @@ -649,6 +665,7 @@ libxfs_icache_purge(void) struct cache_operations libxfs_icache_operations = { /* .hash */ libxfs_ihash, /* .alloc */ libxfs_ialloc, + /* .flush */ NULL, /* .relse */ libxfs_irelse, /* .compare */ libxfs_icompare, /* .bulkrelse */ NULL =========================================================================== xfsprogs/libxfs/xfs.h =========================================================================== --- a/xfsprogs/libxfs/xfs.h 2006-07-28 11:46:09.000000000 +1000 +++ b/xfsprogs/libxfs/xfs.h 2006-07-25 12:05:31.917896892 +1000 @@ -98,6 +98,7 @@ #define xfs_bmapi_single libxfs_bmapi_single #define xfs_bmap_finish libxfs_bmap_finish #define xfs_bmap_del_free libxfs_bmap_del_free +#define xfs_bmap_last_offset libxfs_bmap_last_offset #define xfs_bunmapi libxfs_bunmapi #define xfs_free_extent libxfs_free_extent #define xfs_rtfree_extent libxfs_rtfree_extent =========================================================================== xfsprogs/repair/phase6.c =========================================================================== --- a/xfsprogs/repair/phase6.c 2006-07-28 11:46:09.000000000 +1000 +++ b/xfsprogs/repair/phase6.c 2006-07-28 11:30:50.033905530 +1000 @@ -36,43 +36,35 @@ static int orphanage_entered; /* * Data structures and routines to keep track of directory entries - * and whether their leaf entry has been seen + * and whether their leaf entry has been seen. Also used for name + * duplicate checking and rebuilding step if required. */ typedef struct dir_hash_ent { - struct dir_hash_ent *next; /* pointer to next entry */ + struct dir_hash_ent *nextbyaddr;/* pointer to next entry */ + struct dir_hash_ent *nextbyhash; + struct dir_hash_ent *nextbyorder; xfs_dir2_leaf_entry_t ent; /* address and hash value */ + xfs_ino_t inum; /* inode of name */ short junkit; /* name starts with / */ short seen; /* have seen leaf entry */ + int namelen;/* length of name */ + uchar_t *name; /* pointer to name (no NULL) */ } dir_hash_ent_t; typedef struct dir_hash_tab { int size; /* size of hash table */ - dir_hash_ent_t *tab[1];/* actual hash table, variable size */ + int names_duped; + dir_hash_ent_t *first; + dir_hash_ent_t *last; + dir_hash_ent_t **byhash;/* actual hash table, variable size */ + dir_hash_ent_t **byaddr;/* actual hash table, variable size */ } dir_hash_tab_t; + #define DIR_HASH_TAB_SIZE(n) \ - (offsetof(dir_hash_tab_t, tab) + (sizeof(dir_hash_ent_t *) * (n))) + (sizeof(dir_hash_tab_t) + (sizeof(dir_hash_ent_t *) * (n) * 2)) #define DIR_HASH_FUNC(t,a) ((a) % (t)->size) /* - * Track names to check for duplicates in a directory. - */ - -typedef struct name_hash_ent { - struct name_hash_ent *next; /* pointer to next entry */ - xfs_dahash_t hashval;/* hash value of name */ - int namelen;/* length of name */ - uchar_t *name; /* pointer to name (no NULL) */ -} name_hash_ent_t; - -typedef struct name_hash_tab { - int size; /* size of hash table */ - name_hash_ent_t *tab[1];/* actual hash table, variable size */ -} name_hash_tab_t; -#define NAME_HASH_TAB_SIZE(n) \ - (offsetof(name_hash_tab_t, tab) + (sizeof(name_hash_ent_t *) * (n))) -#define NAME_HASH_FUNC(t,a) ((a) % (t)->size) - -/* * Track the contents of the freespace table in a directory. */ typedef struct freetab { @@ -94,28 +86,75 @@ typedef struct freetab { #define DIR_HASH_CK_BADSTALE 5 #define DIR_HASH_CK_TOTAL 6 -static void +/* + * Returns 0 if the name already exists (ie. a duplicate) + */ +static int dir_hash_add( dir_hash_tab_t *hashtab, - xfs_dahash_t hash, - xfs_dir2_dataptr_t addr, - int junk) -{ - int i; + xfs_dir2_dataptr_t addr, + xfs_ino_t inum, + int namelen, + uchar_t *name) +{ + xfs_dahash_t hash = 0; + int byaddr; + int byhash = 0; dir_hash_ent_t *p; - - i = DIR_HASH_FUNC(hashtab, addr); + int dup; + short junk; + + junk = name[0] == '/'; + byaddr = DIR_HASH_FUNC(hashtab, addr); + dup = 0; + + if (!junk) { + hash = libxfs_da_hashname(name, namelen); + byhash = DIR_HASH_FUNC(hashtab, hash); + + /* + * search hash bucket for existing name. + */ + for (p = hashtab->byhash[byhash]; p; p = p->nextbyhash) { + if (p->ent.hashval == hash && p->namelen == namelen) { + if (memcmp(p->name, name, namelen) == 0) { + dup = 1; + break; + } + } + } + } + if ((p = malloc(sizeof(*p))) == NULL) do_error(_("malloc failed in dir_hash_add (%u bytes)\n"), sizeof(*p)); - p->next = hashtab->tab[i]; - hashtab->tab[i] = p; - if (!(p->junkit = junk)) + + p->nextbyaddr = hashtab->byaddr[byaddr]; + hashtab->byaddr[byaddr] = p; + if (hashtab->last) + hashtab->last->nextbyorder = p; + else + hashtab->first = p; + p->nextbyorder = NULL; + hashtab->last = p; + + if (!(p->junkit = junk)) { p->ent.hashval = hash; + p->nextbyhash = hashtab->byhash[byhash]; + hashtab->byhash[byhash] = p; + } p->ent.address = addr; + p->inum = inum; p->seen = 0; + p->namelen = namelen; + p->name = name; + + return !dup; } +/* + * checks to see if any data entries are not in the leaf blocks + */ static int dir_hash_unseen( dir_hash_tab_t *hashtab) @@ -124,7 +163,7 @@ dir_hash_unseen( dir_hash_ent_t *p; for (i = 0; i < hashtab->size; i++) { - for (p = hashtab->tab[i]; p; p = p->next) { + for (p = hashtab->byaddr[i]; p; p = p->nextbyaddr) { if (p->seen == 0) return 1; } @@ -173,8 +212,10 @@ dir_hash_done( dir_hash_ent_t *p; for (i = 0; i < hashtab->size; i++) { - for (p = hashtab->tab[i]; p; p = n) { - n = p->next; + for (p = hashtab->byaddr[i]; p; p = n) { + n = p->nextbyaddr; + if (hashtab->names_duped) + free(p->name); free(p); } } @@ -196,6 +237,10 @@ dir_hash_init( if ((hashtab = calloc(DIR_HASH_TAB_SIZE(hsize), 1)) == NULL) do_error(_("calloc failed in dir_hash_init\n")); hashtab->size = hsize; + hashtab->byhash = (dir_hash_ent_t**)((char *)hashtab + + sizeof(dir_hash_tab_t)); + hashtab->byaddr = (dir_hash_ent_t**)((char *)hashtab + + sizeof(dir_hash_tab_t) + sizeof(dir_hash_ent_t*) * hsize); return hashtab; } @@ -209,7 +254,7 @@ dir_hash_see( dir_hash_ent_t *p; i = DIR_HASH_FUNC(hashtab, addr); - for (p = hashtab->tab[i]; p; p = p->next) { + for (p = hashtab->byaddr[i]; p; p = p->nextbyaddr) { if (p->ent.address != addr) continue; if (p->seen) @@ -222,6 +267,10 @@ dir_hash_see( return DIR_HASH_CK_NODATA; } +/* + * checks to make sure leafs match a data entry, and that the stale + * count is valid. + */ static int dir_hash_see_all( dir_hash_tab_t *hashtab, @@ -246,81 +295,25 @@ dir_hash_see_all( } /* - * Returns 0 if the name already exists (ie. a duplicate) + * Convert name pointers into locally allocated memory */ -static int -name_hash_add( - name_hash_tab_t *nametab, - uchar_t *name, - int namelen) +static void +dir_hash_dup_names(dir_hash_tab_t *hashtab) { - xfs_dahash_t hash; - int i; - name_hash_ent_t *p; - - hash = libxfs_da_hashname(name, namelen); - - i = NAME_HASH_FUNC(nametab, hash); - - /* - * search hash bucket for existing name. - */ - for (p = nametab->tab[i]; p; p = p->next) { - if (p->hashval == hash && p->namelen == namelen) { - if (memcmp(p->name, name, namelen) == 0) - return 0; /* exists */ - } - } - - if ((p = malloc(sizeof(*p))) == NULL) - do_error(_("malloc failed in name_hash_add (%u bytes)\n"), - sizeof(*p)); + uchar_t *name; + dir_hash_ent_t *p; - p->next = nametab->tab[i]; - p->hashval = hash; - p->name = name; - p->namelen = namelen; - nametab->tab[i] = p; + if (hashtab->names_duped) + return; - return 1; /* success, no duplicate */ -} - -static name_hash_tab_t * -name_hash_init( - xfs_fsize_t size) -{ - name_hash_tab_t *nametab; - int hsize; - - hsize = size / (16 * 4); - if (hsize > 1024) - hsize = 1024; - else if (hsize < 16) - hsize = 16; - if ((nametab = calloc(NAME_HASH_TAB_SIZE(hsize), 1)) == NULL) - do_error(_("calloc failed in name_hash_init\n")); - nametab->size = hsize; - return nametab; -} - -static void -name_hash_done( - name_hash_tab_t *nametab) -{ - int i; - name_hash_ent_t *n; - name_hash_ent_t *p; - - for (i = 0; i < nametab->size; i++) { - for (p = nametab->tab[i]; p; p = n) { - n = p->next; - free(p); - } + for (p = hashtab->first; p; p = p->nextbyorder) { + name = malloc(p->namelen); + memcpy(name, p->name, p->namelen); + p->name = name; } - free(nametab); + hashtab->names_duped = 1; } - /* * Version 1 or 2 directory routine wrappers */ @@ -1385,7 +1378,8 @@ lf_block_dir_entry_check(xfs_mount_t *m dir_stack_t *stack, ino_tree_node_t *current_irec, int current_ino_offset, - name_hash_tab_t *nametab) + dir_hash_tab_t *hashtab, + xfs_dablk_t da_bno) { xfs_dir_leaf_entry_t *entry; ino_tree_node_t *irec; @@ -1545,7 +1539,9 @@ lf_block_dir_entry_check(xfs_mount_t *m /* * check for duplicate names in directory. */ - if (!name_hash_add(nametab, namest->name, entry->namelen)) { + if (!dir_hash_add(hashtab, (da_bno << mp->m_sb.sb_blocklog) + + entry->nameidx, + lino, entry->namelen, namest->name)) { do_warn( _("entry \"%s\" (ino %llu) in dir %llu is a duplicate name"), fname, lino, ino); @@ -1635,7 +1631,7 @@ longform_dir_entry_check(xfs_mount_t *mp dir_stack_t *stack, ino_tree_node_t *irec, int ino_offset, - name_hash_tab_t *nametab) + dir_hash_tab_t *hashtab) { xfs_dir_leafblock_t *leaf; xfs_buf_t *bp; @@ -1677,8 +1673,6 @@ longform_dir_entry_check(xfs_mount_t *mp leaf = (xfs_dir_leafblock_t *)XFS_BUF_PTR(bp); - da_bno = INT_GET(leaf->hdr.info.forw, ARCH_CONVERT); - if (INT_GET(leaf->hdr.info.magic, ARCH_CONVERT) != XFS_DIR_LEAF_MAGIC) { if (!no_modify) { @@ -1699,9 +1693,11 @@ _("bad magic # (0x%x) for dir ino %llu l } if (!skipit) - lf_block_dir_entry_check(mp, ino, leaf, &dirty, - num_illegal, need_dot, stack, - irec, ino_offset, nametab); + lf_block_dir_entry_check(mp, ino, leaf, &dirty, + num_illegal, need_dot, stack, irec, + ino_offset, hashtab, da_bno); + + da_bno = INT_GET(leaf->hdr.info.forw, ARCH_CONVERT); ASSERT(dirty == 0 || (dirty && !no_modify)); @@ -1745,6 +1741,127 @@ _("can't map leaf block %d in dir %llu, } /* + * Unexpected failure during the rebuild will leave the entries in + * lost+found on the next run + */ + +static void +longform_dir2_rebuild( + xfs_mount_t *mp, + xfs_ino_t ino, + xfs_inode_t *ip, + dir_hash_tab_t *hashtab) +{ + int error; + int nres; + xfs_trans_t *tp; + xfs_fileoff_t lastblock; + xfs_fsblock_t firstblock; + xfs_bmap_free_t flist; + xfs_ino_t parentino; + xfs_inode_t *pip; + int byhash; + dir_hash_ent_t *p; + int committed; + int done; + + /* + * trash directory completely and rebuild from scratch using the + * name/inode pairs in the hash table + */ + + do_warn(_("rebuilding directory inode %llu\n"), ino); + + /* + * first attempt to locate the parent inode, if it can't be found, + * we'll use the lost+found inode + */ + byhash = DIR_HASH_FUNC(hashtab, libxfs_da_hashname((uchar_t*)"..", 2)); + parentino = orphanage_ino; + for (p = hashtab->byhash[byhash]; p; p = p->nextbyhash) { + if (p->namelen == 2 && p->name[0] == '.' && p->name[1] == '.') { + parentino = p->inum; + break; + } + } + + XFS_BMAP_INIT(&flist, &firstblock); + + tp = libxfs_trans_alloc(mp, 0); + nres = XFS_REMOVE_SPACE_RES(mp); + error = libxfs_trans_reserve(tp, nres, XFS_REMOVE_LOG_RES(mp), 0, + XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); + if (error) + res_failed(error); + libxfs_trans_ijoin(tp, ip, 0); + libxfs_trans_ihold(tp, ip); + + if ((error = libxfs_bmap_last_offset(tp, ip, &lastblock, + XFS_DATA_FORK))) + do_error(_("xfs_bmap_last_offset failed -- error - %d\n"), + error); + + /* re-init the directory to shortform */ + if ((error = libxfs_trans_iget(mp, tp, parentino, 0, 0, &pip))) + do_error( + _("couldn't iget parent inode %llu -- error - %d\n"), + parentino, error); + + /* free all data, leaf, node and freespace blocks */ + + if ((error = libxfs_bunmapi(tp, ip, 0, lastblock, + XFS_BMAPI_METADATA, 0, &firstblock, &flist, + &done))) + do_error(_("xfs_bunmapi failed -- error - %d\n"), error); + ASSERT(done); + + libxfs_dir2_init(tp, ip, pip); + + error = libxfs_bmap_finish(&tp, &flist, firstblock, &committed); + + libxfs_trans_commit(tp, + XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_SYNC, 0); + + /* go through the hash list and re-add the inodes */ + + for (p = hashtab->first; p; p = p->nextbyorder) { + + if (p->name[0] == '/' || (p->name[0] == '.' && (p->namelen == 1 + || (p->namelen == 2 && p->name[1] == '.')))) + continue; + + tp = libxfs_trans_alloc(mp, 0); + nres = XFS_CREATE_SPACE_RES(mp, p->namelen); + if ((error = libxfs_trans_reserve(tp, nres, + XFS_CREATE_LOG_RES(mp), 0, + XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT))) + do_error( + _("space reservation failed (%d), filesystem may be out of space\n"), + error); + + libxfs_trans_ijoin(tp, ip, 0); + libxfs_trans_ihold(tp, ip); + + XFS_BMAP_INIT(&flist, &firstblock); + if ((error = libxfs_dir2_createname(tp, ip, (char*)p->name, + p->namelen, p->inum, &firstblock, &flist, nres))) + do_error( +_("name create failed in ino %llu (%d), filesystem may be out of space\n"), + ino, error); + + if ((error = libxfs_bmap_finish(&tp, &flist, firstblock, + &committed))) + do_error( + _("bmap finish failed (%d), filesystem may be out of space\n"), + error); + + libxfs_trans_commit(tp, + XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_SYNC, 0); + } +} + + +/* * Kill a block in a version 2 inode. * Makes its own transaction. */ @@ -1807,7 +1924,6 @@ longform_dir2_entry_check_data( xfs_dabuf_t **bpp, dir_hash_tab_t *hashtab, freetab_t **freetabp, - name_hash_tab_t *nametab, xfs_dablk_t da_bno, int isblock) { @@ -1828,6 +1944,7 @@ longform_dir2_entry_check_data( freetab_t *freetab; int i; int ino_offset; + xfs_ino_t inum; ino_tree_node_t *irec; int junkit; int lastfree; @@ -1956,8 +2073,7 @@ longform_dir2_entry_check_data( libxfs_trans_ijoin(tp, ip, 0); libxfs_trans_ihold(tp, ip); libxfs_da_bjoin(tp, bp); - if (isblock) - libxfs_da_bhold(tp, bp); + libxfs_da_bhold(tp, bp); XFS_BMAP_INIT(&flist, &firstblock); if (INT_GET(d->hdr.magic, ARCH_CONVERT) != wantmagic) { do_warn(_("bad directory block magic # %#x for directory inode " @@ -1987,7 +2103,7 @@ longform_dir2_entry_check_data( while (ptr < endptr) { dup = (xfs_dir2_data_unused_t *)ptr; if (INT_GET(dup->freetag, ARCH_CONVERT) == - XFS_DIR2_DATA_FREE_TAG) { + XFS_DIR2_DATA_FREE_TAG) { if (lastfree) { do_warn(_("directory inode %llu block %u has " "consecutive free entries: "), @@ -2011,10 +2127,24 @@ longform_dir2_entry_check_data( addr = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, db, ptr - (char *)d); dep = (xfs_dir2_data_entry_t *)ptr; ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); + inum = INT_GET(dep->inumber, ARCH_CONVERT); lastfree = 0; - dir_hash_add(hashtab, - libxfs_da_hashname((uchar_t *)dep->name, dep->namelen), - addr, dep->name[0] == '/'); + if (!dir_hash_add(hashtab, addr, inum, dep->namelen, + dep->name)) { + do_warn( + _("entry \"%s\" (ino %llu) in dir %llu is a duplicate name"), + fname, inum, ip->i_ino); + if (!no_modify) { + if (verbose) + do_warn( + _(", marking entry to be junked\n")); + else + do_warn("\n"); + } else { + do_warn(_(", would junk entry\n")); + } + dep->name[0] = '/'; + } /* * skip bogus entries (leading '/'). they'll be deleted * later. must still log it, else we leak references to @@ -2029,7 +2159,7 @@ longform_dir2_entry_check_data( junkit = 0; bcopy(dep->name, fname, dep->namelen); fname[dep->namelen] = '\0'; - ASSERT(INT_GET(dep->inumber, ARCH_CONVERT) != NULLFSINO); + ASSERT(inum != NULLFSINO); /* * skip the '..' entry since it's checked when the * directory is reached by something else. if it never @@ -2039,7 +2169,7 @@ longform_dir2_entry_check_data( if (dep->namelen == 2 && dep->name[0] == '.' && dep->name[1] == '.') continue; - ASSERT(no_modify || !verify_inum(mp, INT_GET(dep->inumber, ARCH_CONVERT))); + ASSERT(no_modify || !verify_inum(mp, inum)); /* * special case the . entry. we know there's only one * '.' and only '.' points to itself because bogus entries @@ -2049,7 +2179,7 @@ longform_dir2_entry_check_data( * '..' is already accounted for or will be taken care * of when directory is moved to orphanage. */ - if (ip->i_ino == INT_GET(dep->inumber, ARCH_CONVERT)) { + if (ip->i_ino == inum) { ASSERT(dep->name[0] == '.' && dep->namelen == 1); add_inode_ref(current_irec, current_ino_offset); *need_dot = 0; @@ -2062,23 +2192,18 @@ longform_dir2_entry_check_data( * just skip it. no need to process it and it's .. * link is already accounted for. */ - if (INT_GET(dep->inumber, ARCH_CONVERT) == orphanage_ino && - strcmp(fname, ORPHANAGE) == 0) + if (inum == orphanage_ino && strcmp(fname, ORPHANAGE) == 0) continue; /* * skip entries with bogus inumbers if we're in no modify mode */ - if (no_modify && - verify_inum(mp, INT_GET(dep->inumber, ARCH_CONVERT))) + if (no_modify && verify_inum(mp, inum)) continue; /* * ok, now handle the rest of the cases besides '.' and '..' */ - irec = find_inode_rec( - XFS_INO_TO_AGNO(mp, - INT_GET(dep->inumber, ARCH_CONVERT)), - XFS_INO_TO_AGINO(mp, - INT_GET(dep->inumber, ARCH_CONVERT))); + irec = find_inode_rec(XFS_INO_TO_AGNO(mp, inum), + XFS_INO_TO_AGINO(mp, inum)); if (irec == NULL) { nbad++; do_warn(_("entry \"%s\" in directory inode %llu points " @@ -2093,9 +2218,7 @@ longform_dir2_entry_check_data( } continue; } - ino_offset = XFS_INO_TO_AGINO(mp, - INT_GET(dep->inumber, ARCH_CONVERT)) - - irec->ino_startnum; + ino_offset = XFS_INO_TO_AGINO(mp, inum) - irec->ino_startnum; /* * if it's a free inode, blow out the entry. * by now, any inode that we think is free @@ -2106,18 +2229,13 @@ longform_dir2_entry_check_data( * don't complain if this entry points to the old * and now-free lost+found inode */ - if (verbose || no_modify || - INT_GET(dep->inumber, ARCH_CONVERT) != - old_orphanage_ino) + if (verbose || no_modify || inum != old_orphanage_ino) do_warn( _("entry \"%s\" in directory inode %llu points to free inode %llu"), - fname, ip->i_ino, - INT_GET(dep->inumber, ARCH_CONVERT)); + fname, ip->i_ino, inum); nbad++; if (!no_modify) { - if (verbose || - INT_GET(dep->inumber, ARCH_CONVERT) != - old_orphanage_ino) + if (verbose || inum != old_orphanage_ino) do_warn( _(", marking entry to be junked\n")); else @@ -2130,28 +2248,6 @@ longform_dir2_entry_check_data( continue; } /* - * check for duplicate names in directory. - */ - if (!name_hash_add(nametab, dep->name, dep->namelen)) { - do_warn( - _("entry \"%s\" (ino %llu) in dir %llu is a duplicate name"), - fname, INT_GET(dep->inumber, ARCH_CONVERT), - ip->i_ino); - nbad++; - if (!no_modify) { - if (verbose) - do_warn( - _(", marking entry to be junked\n")); - else - do_warn("\n"); - dep->name[0] = '/'; - libxfs_dir2_data_log_entry(tp, bp, dep); - } else { - do_warn(_(", would junk entry\n")); - } - continue; - } - /* * check easy case first, regular inode, just bump * the link count and continue */ @@ -2172,22 +2268,17 @@ longform_dir2_entry_check_data( junkit = 1; do_warn( _("entry \"%s\" in dir %llu points to an already connected directory inode %llu,\n"), - fname, ip->i_ino, - INT_GET(dep->inumber, ARCH_CONVERT)); + fname, ip->i_ino, inum); } else if (parent == ip->i_ino) { add_inode_reached(irec, ino_offset); add_inode_ref(current_irec, current_ino_offset); - if (!is_inode_refchecked( - INT_GET(dep->inumber, ARCH_CONVERT), irec, - ino_offset)) - push_dir(stack, - INT_GET(dep->inumber, ARCH_CONVERT)); + if (!is_inode_refchecked(inum, irec, ino_offset)) + push_dir(stack, inum); } else { junkit = 1; do_warn( _("entry \"%s\" in dir inode %llu inconsistent with .. value (%llu) in ino %llu,\n"), - fname, ip->i_ino, parent, - INT_GET(dep->inumber, ARCH_CONVERT)); + fname, ip->i_ino, parent, inum); } if (junkit) { junkit = 0; @@ -2195,9 +2286,7 @@ _("entry \"%s\" in dir inode %llu incons if (!no_modify) { dep->name[0] = '/'; libxfs_dir2_data_log_entry(tp, bp, dep); - if (verbose || - INT_GET(dep->inumber, ARCH_CONVERT) != - old_orphanage_ino) + if (verbose || inum != old_orphanage_ino) do_warn( _("\twill clear entry \"%s\"\n"), fname); @@ -2212,8 +2301,6 @@ _("entry \"%s\" in dir inode %llu incons libxfs_dir2_data_freescan(mp, d, &needlog, NULL); if (needlog) libxfs_dir2_data_log_header(tp, bp); - else if (!isblock && !nbad) - libxfs_da_brelse(tp, bp); libxfs_bmap_finish(&tp, &flist, firstblock, &committed); libxfs_trans_commit(tp, 0, 0); freetab->ents[db].v = INT_GET(d->hdr.bestfree[0].length, ARCH_CONVERT); @@ -2306,19 +2393,19 @@ longform_dir2_check_node( xfs_fileoff_t next_da_bno; int seeval = 0; int used; - + for (da_bno = mp->m_dirleafblk, next_da_bno = 0; next_da_bno != NULLFILEOFF && da_bno < mp->m_dirfreeblk; da_bno = (xfs_dablk_t)next_da_bno) { next_da_bno = da_bno + mp->m_dirblkfsbs - 1; - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) + if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) break; if (libxfs_da_read_bufr(NULL, ip, da_bno, -1, &bp, XFS_DATA_FORK)) { - do_error( - _("can't read block %u for directory inode %llu\n"), + do_warn( + _("can't read leaf block %u for directory inode %llu\n"), da_bno, ip->i_ino); - /* NOTREACHED */ + return 1; } leaf = bp->data; if (INT_GET(leaf->hdr.info.magic, ARCH_CONVERT) != @@ -2348,23 +2435,24 @@ longform_dir2_check_node( seeval = dir_hash_see_all(hashtab, leaf->ents, INT_GET(leaf->hdr.count, ARCH_CONVERT), INT_GET(leaf->hdr.stale, ARCH_CONVERT)); libxfs_da_brelse(NULL, bp); - if (seeval != DIR_HASH_CK_OK) + if (seeval != DIR_HASH_CK_OK) return 1; } - if (dir_hash_check(hashtab, ip, seeval)) + if (dir_hash_check(hashtab, ip, seeval)) return 1; + for (da_bno = mp->m_dirfreeblk, next_da_bno = 0; next_da_bno != NULLFILEOFF; da_bno = (xfs_dablk_t)next_da_bno) { next_da_bno = da_bno + mp->m_dirblkfsbs - 1; - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) + if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) break; if (libxfs_da_read_bufr(NULL, ip, da_bno, -1, &bp, XFS_DATA_FORK)) { - do_error(_("can't read block %u for directory inode " - "%llu\n"), + do_warn( + _("can't read freespace block %u for directory inode %llu\n"), da_bno, ip->i_ino); - /* NOTREACHED */ + return 1; } free = bp->data; fdb = XFS_DIR2_DA_TO_DB(mp, da_bno); @@ -2418,388 +2506,9 @@ longform_dir2_check_node( } /* - * Rebuild a directory: set up. - * Turn it into a node-format directory with no contents in the - * upper area. Also has correct freespace blocks. - */ -void -longform_dir2_rebuild_setup( - xfs_mount_t *mp, - xfs_ino_t ino, - xfs_inode_t *ip, - freetab_t *freetab) -{ - xfs_da_args_t args; - int committed; - xfs_dir2_data_t *data = NULL; - xfs_dabuf_t *dbp; - int error; - xfs_dir2_db_t fbno; - xfs_dabuf_t *fbp; - xfs_fsblock_t firstblock; - xfs_bmap_free_t flist; - xfs_dir2_free_t *free; - int i; - int j; - xfs_dablk_t lblkno; - xfs_dabuf_t *lbp; - xfs_dir2_leaf_t *leaf; - int nres; - xfs_trans_t *tp; - - /* read first directory block */ - tp = libxfs_trans_alloc(mp, 0); - nres = XFS_DAENTER_SPACE_RES(mp, XFS_DATA_FORK); - error = libxfs_trans_reserve(tp, - nres, XFS_CREATE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, - XFS_CREATE_LOG_COUNT); - if (error) - res_failed(error); - libxfs_trans_ijoin(tp, ip, 0); - libxfs_trans_ihold(tp, ip); - XFS_BMAP_INIT(&flist, &firstblock); - if (libxfs_da_read_buf(tp, ip, mp->m_dirdatablk, -2, &dbp, - XFS_DATA_FORK)) { - do_error(_("can't read block %u for directory inode %llu\n"), - mp->m_dirdatablk, ino); - /* NOTREACHED */ - } - - if (dbp) - data = dbp->data; - - /* check for block format directory */ - if (data && - INT_GET((data)->hdr.magic, ARCH_CONVERT) == XFS_DIR2_BLOCK_MAGIC) { - xfs_dir2_block_t *block; - xfs_dir2_leaf_entry_t *blp; - xfs_dir2_block_tail_t *btp; - int needlog; - int needscan; - - /* convert directory block from block format to data format */ - INT_SET(data->hdr.magic, ARCH_CONVERT, XFS_DIR2_DATA_MAGIC); - - /* construct freelist */ - block = (xfs_dir2_block_t *)data; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); - needlog = needscan = 0; - libxfs_dir2_data_make_free(tp, dbp, (char *)blp - (char *)block, - (char *)block + mp->m_dirblksize - (char *)blp, - &needlog, &needscan); - if (needscan) - libxfs_dir2_data_freescan(mp, data, &needlog, NULL); - libxfs_da_log_buf(tp, dbp, 0, mp->m_dirblksize - 1); - } else if (dbp) { - libxfs_da_brelse(tp, dbp); - } - - /* allocate blocks for btree */ - bzero(&args, sizeof(args)); - args.trans = tp; - args.dp = ip; - args.whichfork = XFS_DATA_FORK; - args.firstblock = &firstblock; - args.flist = &flist; - args.total = nres; - if ((error = libxfs_da_grow_inode(&args, &lblkno)) || - (error = libxfs_da_get_buf(tp, ip, lblkno, -1, &lbp, XFS_DATA_FORK))) { - do_error(_("can't add btree block to directory inode %llu\n"), - ino); - /* NOTREACHED */ - } - leaf = lbp->data; - bzero(leaf, mp->m_dirblksize); - INT_SET(leaf->hdr.info.magic, ARCH_CONVERT, XFS_DIR2_LEAFN_MAGIC); - libxfs_da_log_buf(tp, lbp, 0, mp->m_dirblksize - 1); - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); - libxfs_trans_commit(tp, 0, 0); - - for (i = 0; i < freetab->nents; i += XFS_DIR2_MAX_FREE_BESTS(mp)) { - tp = libxfs_trans_alloc(mp, 0); - nres = XFS_DAENTER_SPACE_RES(mp, XFS_DATA_FORK); - error = libxfs_trans_reserve(tp, - nres, XFS_CREATE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, - XFS_CREATE_LOG_COUNT); - if (error) - res_failed(error); - libxfs_trans_ijoin(tp, ip, 0); - libxfs_trans_ihold(tp, ip); - XFS_BMAP_INIT(&flist, &firstblock); - bzero(&args, sizeof(args)); - args.trans = tp; - args.dp = ip; - args.whichfork = XFS_DATA_FORK; - args.firstblock = &firstblock; - args.flist = &flist; - args.total = nres; - if ((error = libxfs_dir2_grow_inode(&args, XFS_DIR2_FREE_SPACE, - &fbno)) || - (error = libxfs_da_get_buf(tp, ip, XFS_DIR2_DB_TO_DA(mp, fbno), - -1, &fbp, XFS_DATA_FORK))) { - do_error(_("can't add free block to directory inode " - "%llu\n"), - ino); - /* NOTREACHED */ - } - free = fbp->data; - bzero(free, mp->m_dirblksize); - INT_SET(free->hdr.magic, ARCH_CONVERT, XFS_DIR2_FREE_MAGIC); - INT_SET(free->hdr.firstdb, ARCH_CONVERT, i); - INT_SET(free->hdr.nvalid, ARCH_CONVERT, XFS_DIR2_MAX_FREE_BESTS(mp)); - if (i + INT_GET(free->hdr.nvalid, ARCH_CONVERT) > freetab->nents) - INT_SET(free->hdr.nvalid, ARCH_CONVERT, freetab->nents - i); - for (j = 0; j < INT_GET(free->hdr.nvalid, ARCH_CONVERT); j++) { - INT_SET(free->bests[j], ARCH_CONVERT, freetab->ents[i + j].v); - if (INT_GET(free->bests[j], ARCH_CONVERT) != NULLDATAOFF) - INT_MOD(free->hdr.nused, ARCH_CONVERT, +1); - } - libxfs_da_log_buf(tp, fbp, 0, mp->m_dirblksize - 1); - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); - libxfs_trans_commit(tp, 0, 0); - } -} - -/* - * Rebuild the entries from a single data block. - */ -void -longform_dir2_rebuild_data( - xfs_mount_t *mp, - xfs_ino_t ino, - xfs_inode_t *ip, - xfs_dablk_t da_bno) -{ - xfs_dabuf_t *bp; - xfs_dir2_block_tail_t *btp; - int committed; - xfs_dir2_data_t *data; - xfs_dir2_db_t dbno; - xfs_dir2_data_entry_t *dep; - xfs_dir2_data_unused_t *dup; - char *endptr; - int error; - xfs_dir2_free_t *fblock; - xfs_dabuf_t *fbp; - xfs_dir2_db_t fdb; - int fi; - xfs_fsblock_t firstblock; - xfs_bmap_free_t flist; - int needlog; - int needscan; - int nres; - char *ptr; - xfs_trans_t *tp; - - if (libxfs_da_read_buf(NULL, ip, da_bno, da_bno == 0 ? -2 : -1, &bp, - XFS_DATA_FORK)) { - do_error(_("can't read block %u for directory inode %llu\n"), - da_bno, ino); - /* NOTREACHED */ - } - if (da_bno == 0 && bp == NULL) - /* - * The block was punched out. - */ - return; - ASSERT(bp); - dbno = XFS_DIR2_DA_TO_DB(mp, da_bno); - fdb = XFS_DIR2_DB_TO_FDB(mp, dbno); - if (libxfs_da_read_buf(NULL, ip, XFS_DIR2_DB_TO_DA(mp, fdb), -1, &fbp, - XFS_DATA_FORK)) { - do_error(_("can't read block %u for directory inode %llu\n"), - XFS_DIR2_DB_TO_DA(mp, fdb), ino); - /* NOTREACHED */ - } - data = malloc(mp->m_dirblksize); - if (!data) { - do_error( - _("malloc failed in longform_dir2_rebuild_data (%u bytes)\n"), - mp->m_dirblksize); - exit(1); - } - bcopy(bp->data, data, mp->m_dirblksize); - ptr = (char *)data->u; - if (INT_GET(data->hdr.magic, ARCH_CONVERT) == XFS_DIR2_BLOCK_MAGIC) { - btp = XFS_DIR2_BLOCK_TAIL_P(mp, (xfs_dir2_block_t *)data); - endptr = (char *)XFS_DIR2_BLOCK_LEAF_P(btp); - } else - endptr = (char *)data + mp->m_dirblksize; - fblock = fbp->data; - fi = XFS_DIR2_DB_TO_FDINDEX(mp, dbno); - tp = libxfs_trans_alloc(mp, 0); - error = libxfs_trans_reserve(tp, 0, XFS_CREATE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); - if (error) - res_failed(error); - libxfs_trans_ijoin(tp, ip, 0); - libxfs_trans_ihold(tp, ip); - libxfs_da_bjoin(tp, bp); - libxfs_da_bhold(tp, bp); - libxfs_da_bjoin(tp, fbp); - libxfs_da_bhold(tp, fbp); - XFS_BMAP_INIT(&flist, &firstblock); - needlog = needscan = 0; - bzero(((xfs_dir2_data_t *)(bp->data))->hdr.bestfree, - sizeof(data->hdr.bestfree)); - libxfs_dir2_data_make_free(tp, bp, (xfs_dir2_data_aoff_t)sizeof(data->hdr), - mp->m_dirblksize - sizeof(data->hdr), &needlog, &needscan); - ASSERT(needscan == 0); - libxfs_dir2_data_log_header(tp, bp); - INT_SET(fblock->bests[fi], ARCH_CONVERT, - INT_GET(((xfs_dir2_data_t *)(bp->data))->hdr.bestfree[0].length, ARCH_CONVERT)); - libxfs_dir2_free_log_bests(tp, fbp, fi, fi); - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); - libxfs_trans_commit(tp, 0, 0); - - while (ptr < endptr) { - dup = (xfs_dir2_data_unused_t *)ptr; - if (INT_GET(dup->freetag, ARCH_CONVERT) == XFS_DIR2_DATA_FREE_TAG) { - ptr += INT_GET(dup->length, ARCH_CONVERT); - continue; - } - dep = (xfs_dir2_data_entry_t *)ptr; - ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); - if (dep->name[0] == '/') - continue; - tp = libxfs_trans_alloc(mp, 0); - nres = XFS_CREATE_SPACE_RES(mp, dep->namelen); - error = libxfs_trans_reserve(tp, nres, XFS_CREATE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); - if (error) - res_failed(error); - libxfs_trans_ijoin(tp, ip, 0); - libxfs_trans_ihold(tp, ip); - libxfs_da_bjoin(tp, bp); - libxfs_da_bhold(tp, bp); - libxfs_da_bjoin(tp, fbp); - libxfs_da_bhold(tp, fbp); - XFS_BMAP_INIT(&flist, &firstblock); - error = dir_createname(mp, tp, ip, (char *)dep->name, - dep->namelen, INT_GET(dep->inumber, ARCH_CONVERT), - &firstblock, &flist, nres); - ASSERT(error == 0); - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); - libxfs_trans_commit(tp, 0, 0); - } - libxfs_da_brelse(NULL, bp); - libxfs_da_brelse(NULL, fbp); - free(data); -} - -/* - * Finish the rebuild of a directory. - * Stuff / in and then remove it, this forces the directory to end - * up in the right format. - */ -void -longform_dir2_rebuild_finish( - xfs_mount_t *mp, - xfs_ino_t ino, - xfs_inode_t *ip) -{ - int committed; - int error; - xfs_fsblock_t firstblock; - xfs_bmap_free_t flist; - int nres; - xfs_trans_t *tp; - - tp = libxfs_trans_alloc(mp, 0); - nres = XFS_CREATE_SPACE_RES(mp, 1); - error = libxfs_trans_reserve(tp, nres, XFS_CREATE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); - if (error) - res_failed(error); - libxfs_trans_ijoin(tp, ip, 0); - libxfs_trans_ihold(tp, ip); - XFS_BMAP_INIT(&flist, &firstblock); - error = dir_createname(mp, tp, ip, "/", 1, ino, - &firstblock, &flist, nres); - ASSERT(error == 0); - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); - libxfs_trans_commit(tp, 0, 0); - - /* could kill trailing empty data blocks here */ - - tp = libxfs_trans_alloc(mp, 0); - nres = XFS_REMOVE_SPACE_RES(mp); - error = libxfs_trans_reserve(tp, nres, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); - if (error) - res_failed(error); - libxfs_trans_ijoin(tp, ip, 0); - libxfs_trans_ihold(tp, ip); - XFS_BMAP_INIT(&flist, &firstblock); - error = dir_removename(mp, tp, ip, "/", 1, ino, - &firstblock, &flist, nres); - ASSERT(error == 0); - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); - libxfs_trans_commit(tp, 0, 0); -} - -/* - * Rebuild a directory. - * Remove all the non-data blocks. - * Re-initialize to (empty) node form. - * Loop over the data blocks reinserting each entry. - * Force the directory into the right format. - */ -void -longform_dir2_rebuild( - xfs_mount_t *mp, - xfs_ino_t ino, - xfs_inode_t *ip, - int *num_illegal, - freetab_t *freetab, - int isblock) -{ - xfs_dabuf_t *bp; - xfs_dablk_t da_bno; - xfs_fileoff_t next_da_bno; - - do_warn(_("rebuilding directory inode %llu\n"), ino); - - /* kill leaf blocks */ - for (da_bno = mp->m_dirleafblk, next_da_bno = isblock ? NULLFILEOFF : 0; - next_da_bno != NULLFILEOFF; - da_bno = (xfs_dablk_t)next_da_bno) { - next_da_bno = da_bno + mp->m_dirblkfsbs - 1; - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) - break; - if (libxfs_da_get_buf(NULL, ip, da_bno, -1, &bp, XFS_DATA_FORK)) { - do_error(_("can't get block %u for directory inode " - "%llu\n"), - da_bno, ino); - /* NOTREACHED */ - } - dir2_kill_block(mp, ip, da_bno, bp); - } - - /* rebuild empty btree and freelist */ - longform_dir2_rebuild_setup(mp, ino, ip, freetab); - - /* rebuild directory */ - for (da_bno = mp->m_dirdatablk, next_da_bno = 0; - da_bno < mp->m_dirleafblk && next_da_bno != NULLFILEOFF; - da_bno = (xfs_dablk_t)next_da_bno) { - next_da_bno = da_bno + mp->m_dirblkfsbs - 1; - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) - break; - longform_dir2_rebuild_data(mp, ino, ip, da_bno); - } - - /* put the directory in the appropriate on-disk format */ - longform_dir2_rebuild_finish(mp, ino, ip); - *num_illegal = 0; -} - -/* - * succeeds or dies, inode never gets dirtied since all changes - * happen in file blocks. the inode size and other core info - * is already correct, it's just the leaf entries that get altered. - * XXX above comment is wrong for v2 - need to see why it matters + * If a directory is corrupt, we need to read in as many entries as possible, + * destroy the entry and create a new one with recovered name/inode pairs. + * (ie. get libxfs to do all the grunt work) */ void longform_dir2_entry_check(xfs_mount_t *mp, @@ -2810,15 +2519,14 @@ longform_dir2_entry_check(xfs_mount_t *m dir_stack_t *stack, ino_tree_node_t *irec, int ino_offset, - name_hash_tab_t *nametab) + dir_hash_tab_t *hashtab) { xfs_dir2_block_t *block; xfs_dir2_leaf_entry_t *blp; - xfs_dabuf_t *bp; + xfs_dabuf_t **bplist; xfs_dir2_block_tail_t *btp; xfs_dablk_t da_bno; freetab_t *freetab; - dir_hash_tab_t *hashtab; int i; int isblock; int isleaf; @@ -2840,6 +2548,7 @@ longform_dir2_entry_check(xfs_mount_t *m freetab->ents[i].v = NULLDATAOFF; freetab->ents[i].s = 0; } + bplist = calloc(freetab->naents, sizeof(xfs_dabuf_t*)); /* is this a block, leaf, or node directory? */ libxfs_dir2_isblock(NULL, ip, &isblock); libxfs_dir2_isleaf(NULL, ip, &isleaf); @@ -2847,50 +2556,58 @@ longform_dir2_entry_check(xfs_mount_t *m if (do_prefetch && !isblock) prefetch_p6_dir2(mp, ip); - /* check directory data */ - hashtab = dir_hash_init(ip->i_d.di_size); + /* check directory "data" blocks (ie. name/inode pairs) */ for (da_bno = 0, next_da_bno = 0; next_da_bno != NULLFILEOFF && da_bno < mp->m_dirleafblk; da_bno = (xfs_dablk_t)next_da_bno) { next_da_bno = da_bno + mp->m_dirblkfsbs - 1; + ASSERT(XFS_DIR2_DA_TO_DB(mp, da_bno) < freetab->naents); if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) break; - if (libxfs_da_read_bufr(NULL, ip, da_bno, - da_bno == 0 ? -2 : -1, &bp, XFS_DATA_FORK)) { - do_error(_("can't read block %u for directory inode " - "%llu\n"), + if (libxfs_da_read_bufr(NULL, ip, da_bno, -1, + &bplist[XFS_DIR2_DA_TO_DB(mp, da_bno)], + XFS_DATA_FORK)) { + do_warn(_( + "can't read data block %u for directory inode %llu\n"), da_bno, ino); - /* NOTREACHED */ + *num_illegal++; + continue; /* try and read all "data" blocks */ } - /* is there a hole at the start? */ - if (da_bno == 0 && bp == NULL) - continue; longform_dir2_entry_check_data(mp, ip, num_illegal, need_dot, - stack, irec, ino_offset, &bp, hashtab, &freetab, - nametab, da_bno, isblock); - /* it releases the buffer unless isblock is set */ + stack, irec, ino_offset, + &bplist[XFS_DIR2_DA_TO_DB(mp, da_bno)], hashtab, + &freetab, da_bno, isblock); } fixit = (*num_illegal != 0) || dir2_is_badino(ino); /* check btree and freespace */ if (isblock) { - ASSERT(bp); - block = bp->data; + block = bplist[0]->data; btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); blp = XFS_DIR2_BLOCK_LEAF_P(btp); - seeval = dir_hash_see_all(hashtab, blp, INT_GET(btp->count, ARCH_CONVERT), INT_GET(btp->stale, ARCH_CONVERT)); + seeval = dir_hash_see_all(hashtab, blp, + INT_GET(btp->count, ARCH_CONVERT), + INT_GET(btp->stale, ARCH_CONVERT)); if (dir_hash_check(hashtab, ip, seeval)) fixit |= 1; - libxfs_da_brelse(NULL, bp); } else if (isleaf) { fixit |= longform_dir2_check_leaf(mp, ip, hashtab, freetab); } else { fixit |= longform_dir2_check_node(mp, ip, hashtab, freetab); } - dir_hash_done(hashtab); - if (!no_modify && fixit) - longform_dir2_rebuild(mp, ino, ip, num_illegal, freetab, - isblock); + if (!no_modify && fixit) { + dir_hash_dup_names(hashtab); + for (i = 0; i < freetab->naents; i++) + if (bplist[i]) + libxfs_da_brelse(NULL, bplist[i]); + longform_dir2_rebuild(mp, ino, ip, hashtab); + *num_illegal = 0; + } else { + for (i = 0; i < freetab->naents; i++) + if (bplist[i]) + libxfs_da_brelse(NULL, bplist[i]); + } + free(freetab); } @@ -2906,7 +2623,7 @@ shortform_dir_entry_check(xfs_mount_t *m dir_stack_t *stack, ino_tree_node_t *current_irec, int current_ino_offset, - name_hash_tab_t *nametab) + dir_hash_tab_t *hashtab) { xfs_ino_t lino; xfs_ino_t parent; @@ -3044,7 +2761,7 @@ _("entry \"%s\" in shortform dir %llu re ASSERT(irec != NULL); ino_offset = XFS_INO_TO_AGINO(mp, lino) - irec->ino_startnum; - + /* * if it's a free inode, blow out the entry. * by now, any inode that we think is free @@ -3066,8 +2783,9 @@ _("entry \"%s\" in shortform dir inode % do_warn(_("would junk entry \"%s\"\n"), fname); } - } else if (!name_hash_add(nametab, sf_entry->name, - sf_entry->namelen)) { + } else if (!dir_hash_add(hashtab, + (xfs_dir2_dataptr_t)(sf_entry - &sf->list[0]), + lino, sf_entry->namelen, sf_entry->name)) { /* * check for duplicate names in directory. */ @@ -3311,7 +3029,7 @@ shortform_dir2_entry_check(xfs_mount_t * dir_stack_t *stack, ino_tree_node_t *current_irec, int current_ino_offset, - name_hash_tab_t *nametab) + dir_hash_tab_t *hashtab) { xfs_ino_t lino; xfs_ino_t parent; @@ -3484,7 +3202,9 @@ shortform_dir2_entry_check(xfs_mount_t * do_warn(_("would junk entry \"%s\"\n"), fname); } - } else if (!name_hash_add(nametab, sfep->name, sfep->namelen)) { + } else if (!dir_hash_add(hashtab, (xfs_dir2_dataptr_t) + (sfep - XFS_DIR2_SF_FIRSTENTRY(sfp)), + lino, sfep->namelen, sfep->name)) { /* * check for duplicate names in directory. */ @@ -3650,7 +3370,7 @@ process_dirstack(xfs_mount_t *mp, dir_st xfs_trans_t *tp; xfs_dahash_t hashval; ino_tree_node_t *irec; - name_hash_tab_t *nametab; + dir_hash_tab_t *hashtab; int ino_offset, need_dot, committed; int dirty, num_illegal, error, nres; @@ -3731,7 +3451,7 @@ process_dirstack(xfs_mount_t *mp, dir_st add_inode_refchecked(ino, irec, ino_offset); - nametab = name_hash_init(ip->i_d.di_size); + hashtab = dir_hash_init(ip->i_d.di_size); /* * look for bogus entries @@ -3750,13 +3470,13 @@ process_dirstack(xfs_mount_t *mp, dir_st &num_illegal, &need_dot, stack, irec, ino_offset, - nametab); + hashtab); else longform_dir_entry_check(mp, ino, ip, &num_illegal, &need_dot, stack, irec, ino_offset, - nametab); + hashtab); break; case XFS_DINODE_FMT_LOCAL: tp = libxfs_trans_alloc(mp, 0); @@ -3781,12 +3501,12 @@ process_dirstack(xfs_mount_t *mp, dir_st shortform_dir2_entry_check(mp, ino, ip, &dirty, stack, irec, ino_offset, - nametab); + hashtab); else shortform_dir_entry_check(mp, ino, ip, &dirty, stack, irec, ino_offset, - nametab); + hashtab); ASSERT(dirty == 0 || (dirty && !no_modify)); if (dirty) { @@ -3801,7 +3521,7 @@ process_dirstack(xfs_mount_t *mp, dir_st default: break; } - name_hash_done(nametab); + dir_hash_done(hashtab); hashval = 0; From owner-xfs@oss.sgi.com Thu Jul 27 21:37:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 21:37: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 k6S4awDW001386 for ; Thu, 27 Jul 2006 21:37:10 -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 OAA15723; Fri, 28 Jul 2006 14:36:18 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7ED2A58C38C1; Fri, 28 Jul 2006 14:36:18 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912426 - quota vs barriers Message-Id: <20060728043618.7ED2A58C38C1@chook.melbourne.sgi.com> Date: Fri, 28 Jul 2006 14:36:18 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8460 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: 655 Lines: 16 Fix a barrier related forced shutdown on mounts with quota enabled. Date: Fri Jul 28 14:35:57 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Stefan Priebe The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26622a xfs_vfsops.c - 1.509 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.509&r2=text&tr2=1.508&f=h linux-2.6/xfs_super.c - 1.369 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.369&r2=text&tr2=1.368&f=h From owner-xfs@oss.sgi.com Thu Jul 27 22:14:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 22:14: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 k6S5DuDW008113 for ; Thu, 27 Jul 2006 22:14:07 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16320; Fri, 28 Jul 2006 15:13:17 +1000 Message-ID: <44C99C86.2000208@sgi.com> Date: Fri, 28 Jul 2006 15:11:34 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: xfs@oss.sgi.com Subject: Re: review: block bogus bulkstat messages, last stage References: <20060726101537.H2118045@wobbly.melbourne.sgi.com> In-Reply-To: <20060726101537.H2118045@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8461 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: 1283 Lines: 52 Nathan Scott wrote: > Hi, > > Earlier changes removed most of the bogus verbosity from fsstress > runs with debug kernels, when bulkstat is asked to report on non- > inode data in its stat'ing. This resolves the one remaining case > which is the bulkstat_one vs a xfs_dilocate warning, by passing a > flag down into dilocate indicating we may be looking up garbage, > and not to spam the console in that situation. > > cheers. > 1. xfs_ialloc.c + xfs_stack_trace(); What's the stack trace for? It is just to give more info after one of the 3 error msgs beforehand? Happens in DEBUG. Okay. 2. xfs_inode.h: +#define XFS_IGET_CREATE 0x1 +#define XFS_IGET_BULKSTAT 0x2 Okay. 3. xfs_itable.c xfs_bulkstat_one_iget calls xfs_iget with XFS_IGET_BULKSTAT flag. Okay. 4. xfs_inode.c xfs_iread takes in extra param, imap_flags and passes it on to call of xfs_itobp Okay xfs_ialloc's xfs_trans_iget()'s IGET_CREATE -> XFS_IGET_CREATE Okay 5. xfs_iget.c IGET_CREATE -> XFS_IGET_CREATE ok some cleanup xfs_iget_core calls xfs_iread with extra imap_flags of XFS_IMAP_BULKSTAT if it is given its flag of XFS_IGET_BULKSTAT ok 6. xfs_dm.c xfs_dm_bulkall_iget_one calls xfs_iget with XFS_IGET_BULKSTAT xfs_dm_bulkattr_iget_one calls xfs_iget with XFS_IGET_BULKSTAT ok Seems fine. --Tim From owner-xfs@oss.sgi.com Thu Jul 27 22:23:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 22:24: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 k6S5NQDW010498 for ; Thu, 27 Jul 2006 22:23: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 PAA16578; Fri, 28 Jul 2006 15:22:48 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k6S5Mkgw2200558; Fri, 28 Jul 2006 15:22:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6S5MiOJ2205067; Fri, 28 Jul 2006 15:22:44 +1000 (EST) Date: Fri, 28 Jul 2006 15:22:44 +1000 From: Nathan Scott To: Timothy Shimmin Cc: xfs@oss.sgi.com Subject: Re: review: block bogus bulkstat messages, last stage Message-ID: <20060728152244.H2196410@wobbly.melbourne.sgi.com> References: <20060726101537.H2118045@wobbly.melbourne.sgi.com> <44C99C86.2000208@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44C99C86.2000208@sgi.com>; from tes@sgi.com on Fri, Jul 28, 2006 at 03:11:34PM +1000 X-archive-position: 8462 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: 477 Lines: 20 On Fri, Jul 28, 2006 at 03:11:34PM +1000, Timothy Shimmin wrote: > 1. xfs_ialloc.c > + xfs_stack_trace(); > What's the stack trace for? > It is just to give more info after one of the 3 error msgs > beforehand? Happens in DEBUG. Okay. Yep, basically just to help figure out how the warning got triggered. If it gets triggered now, it always indicates a real problem... while before it was only possibly a problem. > Seems fine. Thanks for the review. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 27 22:46:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 22:47:18 -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 k6S5kfDW015071 for ; Thu, 27 Jul 2006 22:46:52 -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 PAA17100; Fri, 28 Jul 2006 15:46:02 +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 k6S5k0gw2202559; Fri, 28 Jul 2006 15:46:01 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6S5jwvh2178850; Fri, 28 Jul 2006 15:45:58 +1000 (EST) Date: Fri, 28 Jul 2006 15:45:58 +1000 From: Nathan Scott To: Timothy Shimmin Cc: xfs@oss.sgi.com Subject: Re: review: fix bulkstat error detection logic Message-ID: <20060728154558.I2196410@wobbly.melbourne.sgi.com> References: <20060726102406.I2118045@wobbly.melbourne.sgi.com> <44C9A353.1050702@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44C9A353.1050702@sgi.com>; from tes@sgi.com on Fri, Jul 28, 2006 at 03:40:35PM +1000 X-archive-position: 8464 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: 466 Lines: 18 On Fri, Jul 28, 2006 at 03:40:35PM +1000, Timothy Shimmin wrote: > Looks reasonable. > So you still do the inode buffer validation but we don't print out > a corruption error msg and we return EINVAL instead of EFSCORRUPTED. Right. > Can we not be bulkstat'ing over inodes with reasonable numbers/locations but > the inode data on disk is just corrupted? Yes, we can, but we don't want bulkstat to shutdown the filesystem in that situation. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jul 27 22:43:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 22:43:24 -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 k6S5guDW014260 for ; Thu, 27 Jul 2006 22:43:08 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16947; Fri, 28 Jul 2006 15:42:18 +1000 Message-ID: <44C9A353.1050702@sgi.com> Date: Fri, 28 Jul 2006 15:40:35 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: xfs@oss.sgi.com Subject: Re: review: fix bulkstat error detection logic References: <20060726102406.I2118045@wobbly.melbourne.sgi.com> In-Reply-To: <20060726102406.I2118045@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8463 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: 1119 Lines: 30 Nathan Scott wrote: > Hi, > > An earlier patch to remove bulkstat verbosity in debug kernels > changed the xfs_itobp logic slightly, such that we no longer do > the first stage of buffer checking there. Turns out this isn't > the right fix, we need to do that check still, and pass out the > error code to bulkstat still, otherwise we either trip up logic > in later debug code, or pass out success incorrectly. > > This fixes that up, and is the last bulkstat change I have for > awhile. :) Its error handling is correct once more, its a fair > bit quicker, and no more debug-kernel console spam - hooray! > > cheers. > Looks reasonable. So you still do the inode buffer validation but we don't print out a corruption error msg and we return EINVAL instead of EFSCORRUPTED. Can we not be bulkstat'ing over inodes with reasonable numbers/locations but the inode data on disk is just corrupted? (I missed looking at the original patch) (Interesting how previously you set ni to 0 in the XFS_IMAP_BULKSTAT case and yet in the loop which would then never iterate (0<0=F), you test for XFS_IMAP_BULKSTAT :) --Tim From owner-xfs@oss.sgi.com Thu Jul 27 23:45:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 23:45:50 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6S6jdDW025025 for ; Thu, 27 Jul 2006 23:45:40 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id 14B7E2207FB for ; Fri, 28 Jul 2006 08:45:10 +0200 (CEST) Received: from mail.charite.de ([127.0.0.1]) by localhost (mail.charite.de [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 8bRIUKf0uHlD for ; Fri, 28 Jul 2006 08:45:08 +0200 (CEST) Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id ED5292207ED for ; Fri, 28 Jul 2006 08:45:06 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id 76BD0220B65; Fri, 28 Jul 2006 08:45:05 +0200 (CEST) Date: Fri, 28 Jul 2006 08:45:05 +0200 From: Ralf Hildebrandt To: xfs@oss.sgi.com Subject: Problem with xfs_repair Message-ID: <20060728064505.GA14714@charite.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 8466 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: xfs Content-Length: 2139 Lines: 68 xfs_repair gave me this when repairing my / fs using a knoppix boot cd: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 fatal error -- can't read block 16777216 for directory inode 167785633 a) How can I find out which file/directory this inode belongs to? b) Can I mark the block defektiv somehow? -- Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to spamtrap@charite.de From owner-xfs@oss.sgi.com Thu Jul 27 23:42:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 23:43:11 -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 k6S6g5DW024326 for ; Thu, 27 Jul 2006 23:42:17 -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 QAA17942; Fri, 28 Jul 2006 16:41:25 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 66D3558C38C1; Fri, 28 Jul 2006 16:41:25 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954802 - xlog_state_do_callback Message-Id: <20060728064125.66D3558C38C1@chook.melbourne.sgi.com> Date: Fri, 28 Jul 2006 16:41:25 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8465 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: 472 Lines: 14 Ensure xlog_state_do_callback does not report spurious warnings on ramdisks. Date: Fri Jul 28 16:41:12 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch,tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26627a xfs_log.c - 1.325 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.325&r2=text&tr2=1.324&f=h From owner-xfs@oss.sgi.com Thu Jul 27 23:56:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 23:56: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 k6S6uBDW027603 for ; Thu, 27 Jul 2006 23:56:23 -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 QAA18270; Fri, 28 Jul 2006 16:55:32 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7419B58C38C1; Fri, 28 Jul 2006 16:55:32 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 953819 - bulkstat vs debug kernels Message-Id: <20060728065532.7419B58C38C1@chook.melbourne.sgi.com> Date: Fri, 28 Jul 2006 16:55:32 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8467 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: 1605 Lines: 39 Remove last bulkstat false-positives with debug kernels. Date: Fri Jul 28 16:53:21 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26628a xfs_ialloc.c - 1.192 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.192&r2=text&tr2=1.191&f=h xfs_itable.c - 1.144 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.144&r2=text&tr2=1.143&f=h xfs_iget.c - 1.217 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h xfs_inode.c - 1.450 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.450&r2=text&tr2=1.449&f=h xfs_inode.h - 1.215 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.215&r2=text&tr2=1.214&f=h dmapi/xfs_dm.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h Ensure bulkstat from an invalid inode number gets caught always with EINVAL. Date: Fri Jul 28 16:55:15 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26629a xfs_inode.c - 1.451 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.451&r2=text&tr2=1.450&f=h From owner-xfs@oss.sgi.com Thu Jul 27 23:57:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 27 Jul 2006 23:57: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 k6S6vRDW027882 for ; Thu, 27 Jul 2006 23:57:34 -0700 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA18277 for ; Fri, 28 Jul 2006 16:56:52 +1000 Message-Id: <200607280656.QAA18277@larry.melbourne.sgi.com> From: "Barry Naujok" To: Subject: RE: Problem with xfs_repair Date: Fri, 28 Jul 2006 17:01:01 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcayEXTG8XgOgyFsRYKhsTGb0DRJYAAAbIJQ In-Reply-To: <20060728064505.GA14714@charite.de> X-archive-position: 8468 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 772 Lines: 26 Hi Ralf, > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Ralf Hildebrandt > Sent: Friday, 28 July 2006 4:45 PM > To: xfs@oss.sgi.com > Subject: Problem with xfs_repair > > xfs_repair gave me this when repairing my / fs using a > knoppix boot cd: > > Phase 1 - find and verify superblock... [snip] > > fatal error -- can't read block 16777216 for directory inode 167785633 > > a) How can I find out which file/directory this inode belongs to? > b) Can I mark the block defektiv somehow? You have hit a recent regression that is covered in the FAQ http://oss.sgi.com/projects/xfs/faq.html#dir2 You have two options: 1. Do the steps in the FAQ 2. Try the xfs_repair patch I just posted to this list. From owner-xfs@oss.sgi.com Fri Jul 28 01:09:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 01:09:38 -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 k6S88xDW014214 for ; Fri, 28 Jul 2006 01:09: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 SAA19905; Fri, 28 Jul 2006 18:08:18 +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 k6S88Fgw2200124; Fri, 28 Jul 2006 18:08:16 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6S88DdT2210237; Fri, 28 Jul 2006 18:08:13 +1000 (EST) Date: Fri, 28 Jul 2006 18:08:13 +1000 From: Nathan Scott To: Linus Torvalds Cc: Andrew Morton , xfs@oss.sgi.com Subject: XFS fixes for 2.6.18-rc2 Message-ID: <20060728180813.B2197701@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8469 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: 2012 Lines: 72 Hi Linus, Please pull from: git://oss.sgi.com:8090/nathans/xfs-rc-2.6 This will update the following files: fs/xfs/linux-2.6/xfs_buf.h | 4 ++-- fs/xfs/linux-2.6/xfs_super.c | 7 +++++++ fs/xfs/quota/xfs_qm_bhv.c | 19 +++++++++++++------ fs/xfs/xfs_inode.c | 17 ++++++++++------- fs/xfs/xfs_log.c | 12 ++++++------ fs/xfs/xfs_vfsops.c | 2 +- 6 files changed, 39 insertions(+), 22 deletions(-) through these commits: commit 2a293b7d5aa2f0d1e3d87b642f7ac263c2d664e3 Author: Christoph Hellwig Date: Fri Jul 28 17:04:26 2006 +1000 [XFS] All xfs_disk_dquot_t values are (as the name says) disk endian. Before putting them into struct statfs they should be endian-swapped. SGI-PV: 954580 SGI-Modid: xfs-linux-melb:xfs-kern:26550a Signed-off-by: Christoph Hellwig Signed-off-by: Nathan Scott commit f5faad799475c4058416264f672bb33bf8b5ef41 Author: Nathan Scott Date: Fri Jul 28 17:04:44 2006 +1000 [XFS] Fix remount vs no/barrier options by ensuring we clear unwanted flags from iclog buffers before submitting them for writing. SGI-PV: 954772 SGI-Modid: xfs-linux-melb:xfs-kern:26605a Signed-off-by: Nathan Scott commit b2ea401bac39e75ebb64038609ed22efbc799905 Author: Nathan Scott Date: Fri Jul 28 17:05:13 2006 +1000 [XFS] Fix a barrier related forced shutdown on mounts with quota enabled. SGI-PV: 912426 SGI-Modid: xfs-linux-melb:xfs-kern:26622a Signed-off-by: Nathan Scott commit 41ff715abc49324fb2cb20e66bc4e0290cfdbe51 Author: Nathan Scott Date: Fri Jul 28 17:05:51 2006 +1000 [XFS] Ensure bulkstat from an invalid inode number gets caught always with EINVAL. SGI-PV: 953819 SGI-Modid: xfs-linux-melb:xfs-kern:26629a Signed-off-by: Nathan Scott -- Nathan From owner-xfs@oss.sgi.com Fri Jul 28 01:11:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 01:11:50 -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 k6S8AxDW014591 for ; Fri, 28 Jul 2006 01:11: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 SAA19925; Fri, 28 Jul 2006 18:10: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 k6S8AFgw2197202; Fri, 28 Jul 2006 18:10:15 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6S8ADCR2208083; Fri, 28 Jul 2006 18:10:13 +1000 (EST) Date: Fri, 28 Jul 2006 18:10:13 +1000 From: Nathan Scott To: Barry Naujok , mvalluri@sgi.com Cc: xfs@oss.sgi.com Subject: Re: Review: xfs_repair fixes for dir2 corruption Message-ID: <20060728181013.C2197701@wobbly.melbourne.sgi.com> References: <20060728091735.B2196410@wobbly.melbourne.sgi.com> <200607280155.LAA12814@larry.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200607280155.LAA12814@larry.melbourne.sgi.com>; from bnaujok@melbourne.sgi.com on Fri, Jul 28, 2006 at 11:58:52AM +1000 X-archive-position: 8470 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: 51527 Lines: 1584 On Fri, Jul 28, 2006 at 11:58:52AM +1000, Barry Naujok wrote: > This patch addresses the following xfs_repair issues: The libxfs cache stuff looks good to me. Maybe Madan can cast an eye over the repair changes for ya? cheers. > - Can rebuild most corrupted directories. Some will be > beyond repair and the contents of those will end up > in lost+found. > - Fixed potential problems with the duplicate name > checking by properly referencing the buffers where > the names are stored. > - Unified the two hash lists used in directory checks. > - Fixed a case where incorrectly reference counted and > dirty buffers were never written to disk (most > common observation of this is an inaccessible > lost+found directory after a repair). > > For those that are keen to fix the 16777216 problem, give this patch a go. > > > > > =========================================================================== > xfsprogs/include/cache.h > =========================================================================== > > --- a/xfsprogs/include/cache.h 2006-07-28 11:46:09.000000000 +1000 > +++ b/xfsprogs/include/cache.h 2006-07-27 16:17:47.804986322 +1000 > @@ -30,6 +30,7 @@ struct cache_node; > typedef void *cache_key_t; > typedef void (*cache_walk_t)(struct cache_node *); > typedef struct cache_node * (*cache_node_alloc_t)(void); > +typedef void (*cache_node_flush_t)(struct cache_node *); > typedef void (*cache_node_relse_t)(struct cache_node *); > typedef unsigned int (*cache_node_hash_t)(cache_key_t, unsigned int); > typedef int (*cache_node_compare_t)(struct cache_node *, cache_key_t); > @@ -38,6 +39,7 @@ typedef unsigned int (*cache_bulk_relse_ > struct cache_operations { > cache_node_hash_t hash; > cache_node_alloc_t alloc; > + cache_node_flush_t flush; > cache_node_relse_t relse; > cache_node_compare_t compare; > cache_bulk_relse_t bulkrelse; /* optional */ > @@ -49,6 +51,7 @@ struct cache { > pthread_mutex_t c_mutex; /* node count mutex */ > cache_node_hash_t hash; /* node hash function */ > cache_node_alloc_t alloc; /* allocation function */ > + cache_node_flush_t flush; /* flush dirty data function */ > cache_node_relse_t relse; /* memory free function */ > cache_node_compare_t compare; /* comparison routine */ > cache_bulk_relse_t bulkrelse; /* bulk release routine */ > @@ -75,6 +78,7 @@ struct cache *cache_init(unsigned int, s > void cache_destroy(struct cache *); > void cache_walk(struct cache *, cache_walk_t); > void cache_purge(struct cache *); > +void cache_flush(struct cache *); > > int cache_node_get(struct cache *, cache_key_t, struct cache_node **); > void cache_node_put(struct cache_node *); > > =========================================================================== > xfsprogs/include/libxfs.h > =========================================================================== > > --- a/xfsprogs/include/libxfs.h 2006-07-28 11:46:09.000000000 +1000 > +++ b/xfsprogs/include/libxfs.h 2006-07-27 16:34:45.308344014 +1000 > @@ -257,6 +257,7 @@ extern int libxfs_writebuf_int (xfs_buf_ > extern struct cache *libxfs_bcache; > extern struct cache_operations libxfs_bcache_operations; > extern void libxfs_bcache_purge (void); > +extern void libxfs_bcache_flush (void); > extern xfs_buf_t *libxfs_getbuf (dev_t, xfs_daddr_t, int); > extern void libxfs_putbuf (xfs_buf_t *); > extern void libxfs_purgebuf (xfs_buf_t *); > @@ -467,6 +468,8 @@ extern int libxfs_bmap_finish (xfs_trans > xfs_fsblock_t, int *); > extern int libxfs_bmap_next_offset (xfs_trans_t *, xfs_inode_t *, > xfs_fileoff_t *, int); > +extern int libxfs_bmap_last_offset(xfs_trans_t *, xfs_inode_t *, > + xfs_fileoff_t *, int); > extern int libxfs_bunmapi (xfs_trans_t *, xfs_inode_t *, xfs_fileoff_t, > xfs_filblks_t, int, xfs_extnum_t, > xfs_fsblock_t *, xfs_bmap_free_t *, int *); > > =========================================================================== > xfsprogs/libxfs/cache.c > =========================================================================== > > --- a/xfsprogs/libxfs/cache.c 2006-07-28 11:46:09.000000000 +1000 > +++ b/xfsprogs/libxfs/cache.c 2006-07-27 17:42:43.812685388 +1000 > @@ -60,6 +60,7 @@ cache_init( > cache->c_hashsize = hashsize; > cache->hash = cache_operations->hash; > cache->alloc = cache_operations->alloc; > + cache->flush = cache_operations->flush; > cache->relse = cache_operations->relse; > cache->compare = cache_operations->compare; > cache->bulkrelse = cache_operations->bulkrelse ? > @@ -422,6 +423,39 @@ cache_purge( > cache_abort(); > } > #endif > + /* flush any remaining nodes to disk */ > + cache_flush(cache); > +} > + > +/* > + * Flush all nodes in the cache to disk. > + */ > +void > +cache_flush( > + struct cache * cache) > +{ > + struct cache_hash * hash; > + struct list_head * head; > + struct list_head * pos; > + struct cache_node * node; > + int i; > + > + if (!cache->flush) > + return; > + > + for (i = 0; i < cache->c_hashsize; i++) { > + hash = &cache->c_hash[i]; > + > + pthread_mutex_lock(&hash->ch_mutex); > + head = &hash->ch_list; > + for (pos = head->next; pos != head; pos = pos->next) { > + node = (struct cache_node *)pos; > + pthread_mutex_lock(&node->cn_mutex); > + cache->flush(node); > + pthread_mutex_unlock(&node->cn_mutex); > + } > + pthread_mutex_unlock(&hash->ch_mutex); > + } > } > > #define HASH_REPORT (3*HASH_CACHE_RATIO) > > =========================================================================== > xfsprogs/libxfs/rdwr.c > =========================================================================== > > --- a/xfsprogs/libxfs/rdwr.c 2006-07-28 11:46:09.000000000 +1000 > +++ b/xfsprogs/libxfs/rdwr.c 2006-07-27 16:40:56.612373938 +1000 > @@ -416,6 +416,15 @@ libxfs_iomove(xfs_buf_t *bp, uint boff, > } > > static void > +libxfs_bflush(struct cache_node *node) > +{ > + xfs_buf_t *bp = (xfs_buf_t *)node; > + > + if ((bp != NULL) && (bp->b_flags & LIBXFS_B_DIRTY)) > + libxfs_writebufr(bp); > +} > + > +static void > libxfs_brelse(struct cache_node *node) > { > xfs_buf_t *bp = (xfs_buf_t *)node; > @@ -442,9 +451,16 @@ libxfs_bcache_purge(void) > cache_purge(libxfs_bcache); > } > > +void > +libxfs_bcache_flush(void) > +{ > + cache_flush(libxfs_bcache); > +} > + > struct cache_operations libxfs_bcache_operations = { > /* .hash */ libxfs_bhash, > /* .alloc */ libxfs_balloc, > + /* .flush */ libxfs_bflush, > /* .relse */ libxfs_brelse, > /* .compare */ libxfs_bcompare, > /* .bulkrelse */ NULL /* TODO: lio_listio64 interface? */ > @@ -649,6 +665,7 @@ libxfs_icache_purge(void) > struct cache_operations libxfs_icache_operations = { > /* .hash */ libxfs_ihash, > /* .alloc */ libxfs_ialloc, > + /* .flush */ NULL, > /* .relse */ libxfs_irelse, > /* .compare */ libxfs_icompare, > /* .bulkrelse */ NULL > > =========================================================================== > xfsprogs/libxfs/xfs.h > =========================================================================== > > --- a/xfsprogs/libxfs/xfs.h 2006-07-28 11:46:09.000000000 +1000 > +++ b/xfsprogs/libxfs/xfs.h 2006-07-25 12:05:31.917896892 +1000 > @@ -98,6 +98,7 @@ > #define xfs_bmapi_single libxfs_bmapi_single > #define xfs_bmap_finish libxfs_bmap_finish > #define xfs_bmap_del_free libxfs_bmap_del_free > +#define xfs_bmap_last_offset libxfs_bmap_last_offset > #define xfs_bunmapi libxfs_bunmapi > #define xfs_free_extent libxfs_free_extent > #define xfs_rtfree_extent libxfs_rtfree_extent > > =========================================================================== > xfsprogs/repair/phase6.c > =========================================================================== > > --- a/xfsprogs/repair/phase6.c 2006-07-28 11:46:09.000000000 +1000 > +++ b/xfsprogs/repair/phase6.c 2006-07-28 11:30:50.033905530 +1000 > @@ -36,43 +36,35 @@ static int orphanage_entered; > > /* > * Data structures and routines to keep track of directory entries > - * and whether their leaf entry has been seen > + * and whether their leaf entry has been seen. Also used for name > + * duplicate checking and rebuilding step if required. > */ > typedef struct dir_hash_ent { > - struct dir_hash_ent *next; /* pointer to next entry */ > + struct dir_hash_ent *nextbyaddr;/* pointer to next entry */ > + struct dir_hash_ent *nextbyhash; > + struct dir_hash_ent *nextbyorder; > xfs_dir2_leaf_entry_t ent; /* address and hash value */ > + xfs_ino_t inum; /* inode of name */ > short junkit; /* name starts with / */ > short seen; /* have seen leaf entry */ > + int namelen;/* length of name */ > + uchar_t *name; /* pointer to name (no NULL) */ > } dir_hash_ent_t; > > typedef struct dir_hash_tab { > int size; /* size of hash table */ > - dir_hash_ent_t *tab[1];/* actual hash table, variable size */ > + int names_duped; > + dir_hash_ent_t *first; > + dir_hash_ent_t *last; > + dir_hash_ent_t **byhash;/* actual hash table, variable size */ > + dir_hash_ent_t **byaddr;/* actual hash table, variable size */ > } dir_hash_tab_t; > + > #define DIR_HASH_TAB_SIZE(n) \ > - (offsetof(dir_hash_tab_t, tab) + (sizeof(dir_hash_ent_t *) * (n))) > + (sizeof(dir_hash_tab_t) + (sizeof(dir_hash_ent_t *) * (n) * 2)) > #define DIR_HASH_FUNC(t,a) ((a) % (t)->size) > > /* > - * Track names to check for duplicates in a directory. > - */ > - > -typedef struct name_hash_ent { > - struct name_hash_ent *next; /* pointer to next entry */ > - xfs_dahash_t hashval;/* hash value of name */ > - int namelen;/* length of name */ > - uchar_t *name; /* pointer to name (no NULL) */ > -} name_hash_ent_t; > - > -typedef struct name_hash_tab { > - int size; /* size of hash table */ > - name_hash_ent_t *tab[1];/* actual hash table, variable size */ > -} name_hash_tab_t; > -#define NAME_HASH_TAB_SIZE(n) \ > - (offsetof(name_hash_tab_t, tab) + (sizeof(name_hash_ent_t *) * (n))) > -#define NAME_HASH_FUNC(t,a) ((a) % (t)->size) > - > -/* > * Track the contents of the freespace table in a directory. > */ > typedef struct freetab { > @@ -94,28 +86,75 @@ typedef struct freetab { > #define DIR_HASH_CK_BADSTALE 5 > #define DIR_HASH_CK_TOTAL 6 > > -static void > +/* > + * Returns 0 if the name already exists (ie. a duplicate) > + */ > +static int > dir_hash_add( > dir_hash_tab_t *hashtab, > - xfs_dahash_t hash, > - xfs_dir2_dataptr_t addr, > - int junk) > -{ > - int i; > + xfs_dir2_dataptr_t addr, > + xfs_ino_t inum, > + int namelen, > + uchar_t *name) > +{ > + xfs_dahash_t hash = 0; > + int byaddr; > + int byhash = 0; > dir_hash_ent_t *p; > - > - i = DIR_HASH_FUNC(hashtab, addr); > + int dup; > + short junk; > + > + junk = name[0] == '/'; > + byaddr = DIR_HASH_FUNC(hashtab, addr); > + dup = 0; > + > + if (!junk) { > + hash = libxfs_da_hashname(name, namelen); > + byhash = DIR_HASH_FUNC(hashtab, hash); > + > + /* > + * search hash bucket for existing name. > + */ > + for (p = hashtab->byhash[byhash]; p; p = p->nextbyhash) { > + if (p->ent.hashval == hash && p->namelen == namelen) { > + if (memcmp(p->name, name, namelen) == 0) { > + dup = 1; > + break; > + } > + } > + } > + } > + > if ((p = malloc(sizeof(*p))) == NULL) > do_error(_("malloc failed in dir_hash_add (%u bytes)\n"), > sizeof(*p)); > - p->next = hashtab->tab[i]; > - hashtab->tab[i] = p; > - if (!(p->junkit = junk)) > + > + p->nextbyaddr = hashtab->byaddr[byaddr]; > + hashtab->byaddr[byaddr] = p; > + if (hashtab->last) > + hashtab->last->nextbyorder = p; > + else > + hashtab->first = p; > + p->nextbyorder = NULL; > + hashtab->last = p; > + > + if (!(p->junkit = junk)) { > p->ent.hashval = hash; > + p->nextbyhash = hashtab->byhash[byhash]; > + hashtab->byhash[byhash] = p; > + } > p->ent.address = addr; > + p->inum = inum; > p->seen = 0; > + p->namelen = namelen; > + p->name = name; > + > + return !dup; > } > > +/* > + * checks to see if any data entries are not in the leaf blocks > + */ > static int > dir_hash_unseen( > dir_hash_tab_t *hashtab) > @@ -124,7 +163,7 @@ dir_hash_unseen( > dir_hash_ent_t *p; > > for (i = 0; i < hashtab->size; i++) { > - for (p = hashtab->tab[i]; p; p = p->next) { > + for (p = hashtab->byaddr[i]; p; p = p->nextbyaddr) { > if (p->seen == 0) > return 1; > } > @@ -173,8 +212,10 @@ dir_hash_done( > dir_hash_ent_t *p; > > for (i = 0; i < hashtab->size; i++) { > - for (p = hashtab->tab[i]; p; p = n) { > - n = p->next; > + for (p = hashtab->byaddr[i]; p; p = n) { > + n = p->nextbyaddr; > + if (hashtab->names_duped) > + free(p->name); > free(p); > } > } > @@ -196,6 +237,10 @@ dir_hash_init( > if ((hashtab = calloc(DIR_HASH_TAB_SIZE(hsize), 1)) == NULL) > do_error(_("calloc failed in dir_hash_init\n")); > hashtab->size = hsize; > + hashtab->byhash = (dir_hash_ent_t**)((char *)hashtab + > + sizeof(dir_hash_tab_t)); > + hashtab->byaddr = (dir_hash_ent_t**)((char *)hashtab + > + sizeof(dir_hash_tab_t) + sizeof(dir_hash_ent_t*) * hsize); > return hashtab; > } > > @@ -209,7 +254,7 @@ dir_hash_see( > dir_hash_ent_t *p; > > i = DIR_HASH_FUNC(hashtab, addr); > - for (p = hashtab->tab[i]; p; p = p->next) { > + for (p = hashtab->byaddr[i]; p; p = p->nextbyaddr) { > if (p->ent.address != addr) > continue; > if (p->seen) > @@ -222,6 +267,10 @@ dir_hash_see( > return DIR_HASH_CK_NODATA; > } > > +/* > + * checks to make sure leafs match a data entry, and that the stale > + * count is valid. > + */ > static int > dir_hash_see_all( > dir_hash_tab_t *hashtab, > @@ -246,81 +295,25 @@ dir_hash_see_all( > } > > /* > - * Returns 0 if the name already exists (ie. a duplicate) > + * Convert name pointers into locally allocated memory > */ > -static int > -name_hash_add( > - name_hash_tab_t *nametab, > - uchar_t *name, > - int namelen) > +static void > +dir_hash_dup_names(dir_hash_tab_t *hashtab) > { > - xfs_dahash_t hash; > - int i; > - name_hash_ent_t *p; > - > - hash = libxfs_da_hashname(name, namelen); > - > - i = NAME_HASH_FUNC(nametab, hash); > - > - /* > - * search hash bucket for existing name. > - */ > - for (p = nametab->tab[i]; p; p = p->next) { > - if (p->hashval == hash && p->namelen == namelen) { > - if (memcmp(p->name, name, namelen) == 0) > - return 0; /* exists */ > - } > - } > - > - if ((p = malloc(sizeof(*p))) == NULL) > - do_error(_("malloc failed in name_hash_add (%u bytes)\n"), > - sizeof(*p)); > + uchar_t *name; > + dir_hash_ent_t *p; > > - p->next = nametab->tab[i]; > - p->hashval = hash; > - p->name = name; > - p->namelen = namelen; > - nametab->tab[i] = p; > + if (hashtab->names_duped) > + return; > > - return 1; /* success, no duplicate */ > -} > - > -static name_hash_tab_t * > -name_hash_init( > - xfs_fsize_t size) > -{ > - name_hash_tab_t *nametab; > - int hsize; > - > - hsize = size / (16 * 4); > - if (hsize > 1024) > - hsize = 1024; > - else if (hsize < 16) > - hsize = 16; > - if ((nametab = calloc(NAME_HASH_TAB_SIZE(hsize), 1)) == NULL) > - do_error(_("calloc failed in name_hash_init\n")); > - nametab->size = hsize; > - return nametab; > -} > - > -static void > -name_hash_done( > - name_hash_tab_t *nametab) > -{ > - int i; > - name_hash_ent_t *n; > - name_hash_ent_t *p; > - > - for (i = 0; i < nametab->size; i++) { > - for (p = nametab->tab[i]; p; p = n) { > - n = p->next; > - free(p); > - } > + for (p = hashtab->first; p; p = p->nextbyorder) { > + name = malloc(p->namelen); > + memcpy(name, p->name, p->namelen); > + p->name = name; > } > - free(nametab); > + hashtab->names_duped = 1; > } > > - > /* > * Version 1 or 2 directory routine wrappers > */ > @@ -1385,7 +1378,8 @@ lf_block_dir_entry_check(xfs_mount_t *m > dir_stack_t *stack, > ino_tree_node_t *current_irec, > int current_ino_offset, > - name_hash_tab_t *nametab) > + dir_hash_tab_t *hashtab, > + xfs_dablk_t da_bno) > { > xfs_dir_leaf_entry_t *entry; > ino_tree_node_t *irec; > @@ -1545,7 +1539,9 @@ lf_block_dir_entry_check(xfs_mount_t *m > /* > * check for duplicate names in directory. > */ > - if (!name_hash_add(nametab, namest->name, entry->namelen)) { > + if (!dir_hash_add(hashtab, (da_bno << mp->m_sb.sb_blocklog) + > + entry->nameidx, > + lino, entry->namelen, namest->name)) { > do_warn( > _("entry \"%s\" (ino %llu) in dir %llu is a duplicate name"), > fname, lino, ino); > @@ -1635,7 +1631,7 @@ longform_dir_entry_check(xfs_mount_t *mp > dir_stack_t *stack, > ino_tree_node_t *irec, > int ino_offset, > - name_hash_tab_t *nametab) > + dir_hash_tab_t *hashtab) > { > xfs_dir_leafblock_t *leaf; > xfs_buf_t *bp; > @@ -1677,8 +1673,6 @@ longform_dir_entry_check(xfs_mount_t *mp > > leaf = (xfs_dir_leafblock_t *)XFS_BUF_PTR(bp); > > - da_bno = INT_GET(leaf->hdr.info.forw, ARCH_CONVERT); > - > if (INT_GET(leaf->hdr.info.magic, ARCH_CONVERT) != > XFS_DIR_LEAF_MAGIC) { > if (!no_modify) { > @@ -1699,9 +1693,11 @@ _("bad magic # (0x%x) for dir ino %llu l > } > > if (!skipit) > - lf_block_dir_entry_check(mp, ino, leaf, &dirty, > - num_illegal, need_dot, stack, > - irec, ino_offset, nametab); > + lf_block_dir_entry_check(mp, ino, leaf, &dirty, > + num_illegal, need_dot, stack, irec, > + ino_offset, hashtab, da_bno); > + > + da_bno = INT_GET(leaf->hdr.info.forw, ARCH_CONVERT); > > ASSERT(dirty == 0 || (dirty && !no_modify)); > > @@ -1745,6 +1741,127 @@ _("can't map leaf block %d in dir %llu, > } > > /* > + * Unexpected failure during the rebuild will leave the entries in > + * lost+found on the next run > + */ > + > +static void > +longform_dir2_rebuild( > + xfs_mount_t *mp, > + xfs_ino_t ino, > + xfs_inode_t *ip, > + dir_hash_tab_t *hashtab) > +{ > + int error; > + int nres; > + xfs_trans_t *tp; > + xfs_fileoff_t lastblock; > + xfs_fsblock_t firstblock; > + xfs_bmap_free_t flist; > + xfs_ino_t parentino; > + xfs_inode_t *pip; > + int byhash; > + dir_hash_ent_t *p; > + int committed; > + int done; > + > + /* > + * trash directory completely and rebuild from scratch using the > + * name/inode pairs in the hash table > + */ > + > + do_warn(_("rebuilding directory inode %llu\n"), ino); > + > + /* > + * first attempt to locate the parent inode, if it can't be found, > + * we'll use the lost+found inode > + */ > + byhash = DIR_HASH_FUNC(hashtab, libxfs_da_hashname((uchar_t*)"..", 2)); > + parentino = orphanage_ino; > + for (p = hashtab->byhash[byhash]; p; p = p->nextbyhash) { > + if (p->namelen == 2 && p->name[0] == '.' && p->name[1] == '.') { > + parentino = p->inum; > + break; > + } > + } > + > + XFS_BMAP_INIT(&flist, &firstblock); > + > + tp = libxfs_trans_alloc(mp, 0); > + nres = XFS_REMOVE_SPACE_RES(mp); > + error = libxfs_trans_reserve(tp, nres, XFS_REMOVE_LOG_RES(mp), 0, > + XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); > + if (error) > + res_failed(error); > + libxfs_trans_ijoin(tp, ip, 0); > + libxfs_trans_ihold(tp, ip); > + > + if ((error = libxfs_bmap_last_offset(tp, ip, &lastblock, > + XFS_DATA_FORK))) > + do_error(_("xfs_bmap_last_offset failed -- error - %d\n"), > + error); > + > + /* re-init the directory to shortform */ > + if ((error = libxfs_trans_iget(mp, tp, parentino, 0, 0, &pip))) > + do_error( > + _("couldn't iget parent inode %llu -- error - %d\n"), > + parentino, error); > + > + /* free all data, leaf, node and freespace blocks */ > + > + if ((error = libxfs_bunmapi(tp, ip, 0, lastblock, > + XFS_BMAPI_METADATA, 0, &firstblock, &flist, > + &done))) > + do_error(_("xfs_bunmapi failed -- error - %d\n"), error); > + ASSERT(done); > + > + libxfs_dir2_init(tp, ip, pip); > + > + error = libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > + > + libxfs_trans_commit(tp, > + XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_SYNC, 0); > + > + /* go through the hash list and re-add the inodes */ > + > + for (p = hashtab->first; p; p = p->nextbyorder) { > + > + if (p->name[0] == '/' || (p->name[0] == '.' && (p->namelen == 1 > + || (p->namelen == 2 && p->name[1] == '.')))) > + continue; > + > + tp = libxfs_trans_alloc(mp, 0); > + nres = XFS_CREATE_SPACE_RES(mp, p->namelen); > + if ((error = libxfs_trans_reserve(tp, nres, > + XFS_CREATE_LOG_RES(mp), 0, > + XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT))) > + do_error( > + _("space reservation failed (%d), filesystem may be out of space\n"), > + error); > + > + libxfs_trans_ijoin(tp, ip, 0); > + libxfs_trans_ihold(tp, ip); > + > + XFS_BMAP_INIT(&flist, &firstblock); > + if ((error = libxfs_dir2_createname(tp, ip, (char*)p->name, > + p->namelen, p->inum, &firstblock, &flist, nres))) > + do_error( > +_("name create failed in ino %llu (%d), filesystem may be out of space\n"), > + ino, error); > + > + if ((error = libxfs_bmap_finish(&tp, &flist, firstblock, > + &committed))) > + do_error( > + _("bmap finish failed (%d), filesystem may be out of space\n"), > + error); > + > + libxfs_trans_commit(tp, > + XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_SYNC, 0); > + } > +} > + > + > +/* > * Kill a block in a version 2 inode. > * Makes its own transaction. > */ > @@ -1807,7 +1924,6 @@ longform_dir2_entry_check_data( > xfs_dabuf_t **bpp, > dir_hash_tab_t *hashtab, > freetab_t **freetabp, > - name_hash_tab_t *nametab, > xfs_dablk_t da_bno, > int isblock) > { > @@ -1828,6 +1944,7 @@ longform_dir2_entry_check_data( > freetab_t *freetab; > int i; > int ino_offset; > + xfs_ino_t inum; > ino_tree_node_t *irec; > int junkit; > int lastfree; > @@ -1956,8 +2073,7 @@ longform_dir2_entry_check_data( > libxfs_trans_ijoin(tp, ip, 0); > libxfs_trans_ihold(tp, ip); > libxfs_da_bjoin(tp, bp); > - if (isblock) > - libxfs_da_bhold(tp, bp); > + libxfs_da_bhold(tp, bp); > XFS_BMAP_INIT(&flist, &firstblock); > if (INT_GET(d->hdr.magic, ARCH_CONVERT) != wantmagic) { > do_warn(_("bad directory block magic # %#x for directory inode " > @@ -1987,7 +2103,7 @@ longform_dir2_entry_check_data( > while (ptr < endptr) { > dup = (xfs_dir2_data_unused_t *)ptr; > if (INT_GET(dup->freetag, ARCH_CONVERT) == > - XFS_DIR2_DATA_FREE_TAG) { > + XFS_DIR2_DATA_FREE_TAG) { > if (lastfree) { > do_warn(_("directory inode %llu block %u has " > "consecutive free entries: "), > @@ -2011,10 +2127,24 @@ longform_dir2_entry_check_data( > addr = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, db, ptr - (char *)d); > dep = (xfs_dir2_data_entry_t *)ptr; > ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); > + inum = INT_GET(dep->inumber, ARCH_CONVERT); > lastfree = 0; > - dir_hash_add(hashtab, > - libxfs_da_hashname((uchar_t *)dep->name, dep->namelen), > - addr, dep->name[0] == '/'); > + if (!dir_hash_add(hashtab, addr, inum, dep->namelen, > + dep->name)) { > + do_warn( > + _("entry \"%s\" (ino %llu) in dir %llu is a duplicate name"), > + fname, inum, ip->i_ino); > + if (!no_modify) { > + if (verbose) > + do_warn( > + _(", marking entry to be junked\n")); > + else > + do_warn("\n"); > + } else { > + do_warn(_(", would junk entry\n")); > + } > + dep->name[0] = '/'; > + } > /* > * skip bogus entries (leading '/'). they'll be deleted > * later. must still log it, else we leak references to > @@ -2029,7 +2159,7 @@ longform_dir2_entry_check_data( > junkit = 0; > bcopy(dep->name, fname, dep->namelen); > fname[dep->namelen] = '\0'; > - ASSERT(INT_GET(dep->inumber, ARCH_CONVERT) != NULLFSINO); > + ASSERT(inum != NULLFSINO); > /* > * skip the '..' entry since it's checked when the > * directory is reached by something else. if it never > @@ -2039,7 +2169,7 @@ longform_dir2_entry_check_data( > if (dep->namelen == 2 && dep->name[0] == '.' && > dep->name[1] == '.') > continue; > - ASSERT(no_modify || !verify_inum(mp, INT_GET(dep->inumber, ARCH_CONVERT))); > + ASSERT(no_modify || !verify_inum(mp, inum)); > /* > * special case the . entry. we know there's only one > * '.' and only '.' points to itself because bogus entries > @@ -2049,7 +2179,7 @@ longform_dir2_entry_check_data( > * '..' is already accounted for or will be taken care > * of when directory is moved to orphanage. > */ > - if (ip->i_ino == INT_GET(dep->inumber, ARCH_CONVERT)) { > + if (ip->i_ino == inum) { > ASSERT(dep->name[0] == '.' && dep->namelen == 1); > add_inode_ref(current_irec, current_ino_offset); > *need_dot = 0; > @@ -2062,23 +2192,18 @@ longform_dir2_entry_check_data( > * just skip it. no need to process it and it's .. > * link is already accounted for. > */ > - if (INT_GET(dep->inumber, ARCH_CONVERT) == orphanage_ino && > - strcmp(fname, ORPHANAGE) == 0) > + if (inum == orphanage_ino && strcmp(fname, ORPHANAGE) == 0) > continue; > /* > * skip entries with bogus inumbers if we're in no modify mode > */ > - if (no_modify && > - verify_inum(mp, INT_GET(dep->inumber, ARCH_CONVERT))) > + if (no_modify && verify_inum(mp, inum)) > continue; > /* > * ok, now handle the rest of the cases besides '.' and '..' > */ > - irec = find_inode_rec( > - XFS_INO_TO_AGNO(mp, > - INT_GET(dep->inumber, ARCH_CONVERT)), > - XFS_INO_TO_AGINO(mp, > - INT_GET(dep->inumber, ARCH_CONVERT))); > + irec = find_inode_rec(XFS_INO_TO_AGNO(mp, inum), > + XFS_INO_TO_AGINO(mp, inum)); > if (irec == NULL) { > nbad++; > do_warn(_("entry \"%s\" in directory inode %llu points " > @@ -2093,9 +2218,7 @@ longform_dir2_entry_check_data( > } > continue; > } > - ino_offset = XFS_INO_TO_AGINO(mp, > - INT_GET(dep->inumber, ARCH_CONVERT)) - > - irec->ino_startnum; > + ino_offset = XFS_INO_TO_AGINO(mp, inum) - irec->ino_startnum; > /* > * if it's a free inode, blow out the entry. > * by now, any inode that we think is free > @@ -2106,18 +2229,13 @@ longform_dir2_entry_check_data( > * don't complain if this entry points to the old > * and now-free lost+found inode > */ > - if (verbose || no_modify || > - INT_GET(dep->inumber, ARCH_CONVERT) != > - old_orphanage_ino) > + if (verbose || no_modify || inum != old_orphanage_ino) > do_warn( > _("entry \"%s\" in directory inode %llu points to free inode %llu"), > - fname, ip->i_ino, > - INT_GET(dep->inumber, ARCH_CONVERT)); > + fname, ip->i_ino, inum); > nbad++; > if (!no_modify) { > - if (verbose || > - INT_GET(dep->inumber, ARCH_CONVERT) != > - old_orphanage_ino) > + if (verbose || inum != old_orphanage_ino) > do_warn( > _(", marking entry to be junked\n")); > else > @@ -2130,28 +2248,6 @@ longform_dir2_entry_check_data( > continue; > } > /* > - * check for duplicate names in directory. > - */ > - if (!name_hash_add(nametab, dep->name, dep->namelen)) { > - do_warn( > - _("entry \"%s\" (ino %llu) in dir %llu is a duplicate name"), > - fname, INT_GET(dep->inumber, ARCH_CONVERT), > - ip->i_ino); > - nbad++; > - if (!no_modify) { > - if (verbose) > - do_warn( > - _(", marking entry to be junked\n")); > - else > - do_warn("\n"); > - dep->name[0] = '/'; > - libxfs_dir2_data_log_entry(tp, bp, dep); > - } else { > - do_warn(_(", would junk entry\n")); > - } > - continue; > - } > - /* > * check easy case first, regular inode, just bump > * the link count and continue > */ > @@ -2172,22 +2268,17 @@ longform_dir2_entry_check_data( > junkit = 1; > do_warn( > _("entry \"%s\" in dir %llu points to an already connected directory inode %llu,\n"), > - fname, ip->i_ino, > - INT_GET(dep->inumber, ARCH_CONVERT)); > + fname, ip->i_ino, inum); > } else if (parent == ip->i_ino) { > add_inode_reached(irec, ino_offset); > add_inode_ref(current_irec, current_ino_offset); > - if (!is_inode_refchecked( > - INT_GET(dep->inumber, ARCH_CONVERT), irec, > - ino_offset)) > - push_dir(stack, > - INT_GET(dep->inumber, ARCH_CONVERT)); > + if (!is_inode_refchecked(inum, irec, ino_offset)) > + push_dir(stack, inum); > } else { > junkit = 1; > do_warn( > _("entry \"%s\" in dir inode %llu inconsistent with .. value (%llu) in ino %llu,\n"), > - fname, ip->i_ino, parent, > - INT_GET(dep->inumber, ARCH_CONVERT)); > + fname, ip->i_ino, parent, inum); > } > if (junkit) { > junkit = 0; > @@ -2195,9 +2286,7 @@ _("entry \"%s\" in dir inode %llu incons > if (!no_modify) { > dep->name[0] = '/'; > libxfs_dir2_data_log_entry(tp, bp, dep); > - if (verbose || > - INT_GET(dep->inumber, ARCH_CONVERT) != > - old_orphanage_ino) > + if (verbose || inum != old_orphanage_ino) > do_warn( > _("\twill clear entry \"%s\"\n"), > fname); > @@ -2212,8 +2301,6 @@ _("entry \"%s\" in dir inode %llu incons > libxfs_dir2_data_freescan(mp, d, &needlog, NULL); > if (needlog) > libxfs_dir2_data_log_header(tp, bp); > - else if (!isblock && !nbad) > - libxfs_da_brelse(tp, bp); > libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > libxfs_trans_commit(tp, 0, 0); > freetab->ents[db].v = INT_GET(d->hdr.bestfree[0].length, ARCH_CONVERT); > @@ -2306,19 +2393,19 @@ longform_dir2_check_node( > xfs_fileoff_t next_da_bno; > int seeval = 0; > int used; > - > + > for (da_bno = mp->m_dirleafblk, next_da_bno = 0; > next_da_bno != NULLFILEOFF && da_bno < mp->m_dirfreeblk; > da_bno = (xfs_dablk_t)next_da_bno) { > next_da_bno = da_bno + mp->m_dirblkfsbs - 1; > - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) > + if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) > break; > if (libxfs_da_read_bufr(NULL, ip, da_bno, -1, &bp, > XFS_DATA_FORK)) { > - do_error( > - _("can't read block %u for directory inode %llu\n"), > + do_warn( > + _("can't read leaf block %u for directory inode %llu\n"), > da_bno, ip->i_ino); > - /* NOTREACHED */ > + return 1; > } > leaf = bp->data; > if (INT_GET(leaf->hdr.info.magic, ARCH_CONVERT) != > @@ -2348,23 +2435,24 @@ longform_dir2_check_node( > seeval = dir_hash_see_all(hashtab, leaf->ents, INT_GET(leaf->hdr.count, ARCH_CONVERT), > INT_GET(leaf->hdr.stale, ARCH_CONVERT)); > libxfs_da_brelse(NULL, bp); > - if (seeval != DIR_HASH_CK_OK) > + if (seeval != DIR_HASH_CK_OK) > return 1; > } > - if (dir_hash_check(hashtab, ip, seeval)) > + if (dir_hash_check(hashtab, ip, seeval)) > return 1; > + > for (da_bno = mp->m_dirfreeblk, next_da_bno = 0; > next_da_bno != NULLFILEOFF; > da_bno = (xfs_dablk_t)next_da_bno) { > next_da_bno = da_bno + mp->m_dirblkfsbs - 1; > - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) > + if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) > break; > if (libxfs_da_read_bufr(NULL, ip, da_bno, -1, &bp, > XFS_DATA_FORK)) { > - do_error(_("can't read block %u for directory inode " > - "%llu\n"), > + do_warn( > + _("can't read freespace block %u for directory inode %llu\n"), > da_bno, ip->i_ino); > - /* NOTREACHED */ > + return 1; > } > free = bp->data; > fdb = XFS_DIR2_DA_TO_DB(mp, da_bno); > @@ -2418,388 +2506,9 @@ longform_dir2_check_node( > } > > /* > - * Rebuild a directory: set up. > - * Turn it into a node-format directory with no contents in the > - * upper area. Also has correct freespace blocks. > - */ > -void > -longform_dir2_rebuild_setup( > - xfs_mount_t *mp, > - xfs_ino_t ino, > - xfs_inode_t *ip, > - freetab_t *freetab) > -{ > - xfs_da_args_t args; > - int committed; > - xfs_dir2_data_t *data = NULL; > - xfs_dabuf_t *dbp; > - int error; > - xfs_dir2_db_t fbno; > - xfs_dabuf_t *fbp; > - xfs_fsblock_t firstblock; > - xfs_bmap_free_t flist; > - xfs_dir2_free_t *free; > - int i; > - int j; > - xfs_dablk_t lblkno; > - xfs_dabuf_t *lbp; > - xfs_dir2_leaf_t *leaf; > - int nres; > - xfs_trans_t *tp; > - > - /* read first directory block */ > - tp = libxfs_trans_alloc(mp, 0); > - nres = XFS_DAENTER_SPACE_RES(mp, XFS_DATA_FORK); > - error = libxfs_trans_reserve(tp, > - nres, XFS_CREATE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, > - XFS_CREATE_LOG_COUNT); > - if (error) > - res_failed(error); > - libxfs_trans_ijoin(tp, ip, 0); > - libxfs_trans_ihold(tp, ip); > - XFS_BMAP_INIT(&flist, &firstblock); > - if (libxfs_da_read_buf(tp, ip, mp->m_dirdatablk, -2, &dbp, > - XFS_DATA_FORK)) { > - do_error(_("can't read block %u for directory inode %llu\n"), > - mp->m_dirdatablk, ino); > - /* NOTREACHED */ > - } > - > - if (dbp) > - data = dbp->data; > - > - /* check for block format directory */ > - if (data && > - INT_GET((data)->hdr.magic, ARCH_CONVERT) == XFS_DIR2_BLOCK_MAGIC) { > - xfs_dir2_block_t *block; > - xfs_dir2_leaf_entry_t *blp; > - xfs_dir2_block_tail_t *btp; > - int needlog; > - int needscan; > - > - /* convert directory block from block format to data format */ > - INT_SET(data->hdr.magic, ARCH_CONVERT, XFS_DIR2_DATA_MAGIC); > - > - /* construct freelist */ > - block = (xfs_dir2_block_t *)data; > - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); > - blp = XFS_DIR2_BLOCK_LEAF_P(btp); > - needlog = needscan = 0; > - libxfs_dir2_data_make_free(tp, dbp, (char *)blp - (char *)block, > - (char *)block + mp->m_dirblksize - (char *)blp, > - &needlog, &needscan); > - if (needscan) > - libxfs_dir2_data_freescan(mp, data, &needlog, NULL); > - libxfs_da_log_buf(tp, dbp, 0, mp->m_dirblksize - 1); > - } else if (dbp) { > - libxfs_da_brelse(tp, dbp); > - } > - > - /* allocate blocks for btree */ > - bzero(&args, sizeof(args)); > - args.trans = tp; > - args.dp = ip; > - args.whichfork = XFS_DATA_FORK; > - args.firstblock = &firstblock; > - args.flist = &flist; > - args.total = nres; > - if ((error = libxfs_da_grow_inode(&args, &lblkno)) || > - (error = libxfs_da_get_buf(tp, ip, lblkno, -1, &lbp, XFS_DATA_FORK))) { > - do_error(_("can't add btree block to directory inode %llu\n"), > - ino); > - /* NOTREACHED */ > - } > - leaf = lbp->data; > - bzero(leaf, mp->m_dirblksize); > - INT_SET(leaf->hdr.info.magic, ARCH_CONVERT, XFS_DIR2_LEAFN_MAGIC); > - libxfs_da_log_buf(tp, lbp, 0, mp->m_dirblksize - 1); > - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > - libxfs_trans_commit(tp, 0, 0); > - > - for (i = 0; i < freetab->nents; i += XFS_DIR2_MAX_FREE_BESTS(mp)) { > - tp = libxfs_trans_alloc(mp, 0); > - nres = XFS_DAENTER_SPACE_RES(mp, XFS_DATA_FORK); > - error = libxfs_trans_reserve(tp, > - nres, XFS_CREATE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, > - XFS_CREATE_LOG_COUNT); > - if (error) > - res_failed(error); > - libxfs_trans_ijoin(tp, ip, 0); > - libxfs_trans_ihold(tp, ip); > - XFS_BMAP_INIT(&flist, &firstblock); > - bzero(&args, sizeof(args)); > - args.trans = tp; > - args.dp = ip; > - args.whichfork = XFS_DATA_FORK; > - args.firstblock = &firstblock; > - args.flist = &flist; > - args.total = nres; > - if ((error = libxfs_dir2_grow_inode(&args, XFS_DIR2_FREE_SPACE, > - &fbno)) || > - (error = libxfs_da_get_buf(tp, ip, XFS_DIR2_DB_TO_DA(mp, fbno), > - -1, &fbp, XFS_DATA_FORK))) { > - do_error(_("can't add free block to directory inode " > - "%llu\n"), > - ino); > - /* NOTREACHED */ > - } > - free = fbp->data; > - bzero(free, mp->m_dirblksize); > - INT_SET(free->hdr.magic, ARCH_CONVERT, XFS_DIR2_FREE_MAGIC); > - INT_SET(free->hdr.firstdb, ARCH_CONVERT, i); > - INT_SET(free->hdr.nvalid, ARCH_CONVERT, XFS_DIR2_MAX_FREE_BESTS(mp)); > - if (i + INT_GET(free->hdr.nvalid, ARCH_CONVERT) > freetab->nents) > - INT_SET(free->hdr.nvalid, ARCH_CONVERT, freetab->nents - i); > - for (j = 0; j < INT_GET(free->hdr.nvalid, ARCH_CONVERT); j++) { > - INT_SET(free->bests[j], ARCH_CONVERT, freetab->ents[i + j].v); > - if (INT_GET(free->bests[j], ARCH_CONVERT) != NULLDATAOFF) > - INT_MOD(free->hdr.nused, ARCH_CONVERT, +1); > - } > - libxfs_da_log_buf(tp, fbp, 0, mp->m_dirblksize - 1); > - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > - libxfs_trans_commit(tp, 0, 0); > - } > -} > - > -/* > - * Rebuild the entries from a single data block. > - */ > -void > -longform_dir2_rebuild_data( > - xfs_mount_t *mp, > - xfs_ino_t ino, > - xfs_inode_t *ip, > - xfs_dablk_t da_bno) > -{ > - xfs_dabuf_t *bp; > - xfs_dir2_block_tail_t *btp; > - int committed; > - xfs_dir2_data_t *data; > - xfs_dir2_db_t dbno; > - xfs_dir2_data_entry_t *dep; > - xfs_dir2_data_unused_t *dup; > - char *endptr; > - int error; > - xfs_dir2_free_t *fblock; > - xfs_dabuf_t *fbp; > - xfs_dir2_db_t fdb; > - int fi; > - xfs_fsblock_t firstblock; > - xfs_bmap_free_t flist; > - int needlog; > - int needscan; > - int nres; > - char *ptr; > - xfs_trans_t *tp; > - > - if (libxfs_da_read_buf(NULL, ip, da_bno, da_bno == 0 ? -2 : -1, &bp, > - XFS_DATA_FORK)) { > - do_error(_("can't read block %u for directory inode %llu\n"), > - da_bno, ino); > - /* NOTREACHED */ > - } > - if (da_bno == 0 && bp == NULL) > - /* > - * The block was punched out. > - */ > - return; > - ASSERT(bp); > - dbno = XFS_DIR2_DA_TO_DB(mp, da_bno); > - fdb = XFS_DIR2_DB_TO_FDB(mp, dbno); > - if (libxfs_da_read_buf(NULL, ip, XFS_DIR2_DB_TO_DA(mp, fdb), -1, &fbp, > - XFS_DATA_FORK)) { > - do_error(_("can't read block %u for directory inode %llu\n"), > - XFS_DIR2_DB_TO_DA(mp, fdb), ino); > - /* NOTREACHED */ > - } > - data = malloc(mp->m_dirblksize); > - if (!data) { > - do_error( > - _("malloc failed in longform_dir2_rebuild_data (%u bytes)\n"), > - mp->m_dirblksize); > - exit(1); > - } > - bcopy(bp->data, data, mp->m_dirblksize); > - ptr = (char *)data->u; > - if (INT_GET(data->hdr.magic, ARCH_CONVERT) == XFS_DIR2_BLOCK_MAGIC) { > - btp = XFS_DIR2_BLOCK_TAIL_P(mp, (xfs_dir2_block_t *)data); > - endptr = (char *)XFS_DIR2_BLOCK_LEAF_P(btp); > - } else > - endptr = (char *)data + mp->m_dirblksize; > - fblock = fbp->data; > - fi = XFS_DIR2_DB_TO_FDINDEX(mp, dbno); > - tp = libxfs_trans_alloc(mp, 0); > - error = libxfs_trans_reserve(tp, 0, XFS_CREATE_LOG_RES(mp), 0, > - XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); > - if (error) > - res_failed(error); > - libxfs_trans_ijoin(tp, ip, 0); > - libxfs_trans_ihold(tp, ip); > - libxfs_da_bjoin(tp, bp); > - libxfs_da_bhold(tp, bp); > - libxfs_da_bjoin(tp, fbp); > - libxfs_da_bhold(tp, fbp); > - XFS_BMAP_INIT(&flist, &firstblock); > - needlog = needscan = 0; > - bzero(((xfs_dir2_data_t *)(bp->data))->hdr.bestfree, > - sizeof(data->hdr.bestfree)); > - libxfs_dir2_data_make_free(tp, bp, (xfs_dir2_data_aoff_t)sizeof(data->hdr), > - mp->m_dirblksize - sizeof(data->hdr), &needlog, &needscan); > - ASSERT(needscan == 0); > - libxfs_dir2_data_log_header(tp, bp); > - INT_SET(fblock->bests[fi], ARCH_CONVERT, > - INT_GET(((xfs_dir2_data_t *)(bp->data))->hdr.bestfree[0].length, ARCH_CONVERT)); > - libxfs_dir2_free_log_bests(tp, fbp, fi, fi); > - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > - libxfs_trans_commit(tp, 0, 0); > - > - while (ptr < endptr) { > - dup = (xfs_dir2_data_unused_t *)ptr; > - if (INT_GET(dup->freetag, ARCH_CONVERT) == XFS_DIR2_DATA_FREE_TAG) { > - ptr += INT_GET(dup->length, ARCH_CONVERT); > - continue; > - } > - dep = (xfs_dir2_data_entry_t *)ptr; > - ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); > - if (dep->name[0] == '/') > - continue; > - tp = libxfs_trans_alloc(mp, 0); > - nres = XFS_CREATE_SPACE_RES(mp, dep->namelen); > - error = libxfs_trans_reserve(tp, nres, XFS_CREATE_LOG_RES(mp), 0, > - XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); > - if (error) > - res_failed(error); > - libxfs_trans_ijoin(tp, ip, 0); > - libxfs_trans_ihold(tp, ip); > - libxfs_da_bjoin(tp, bp); > - libxfs_da_bhold(tp, bp); > - libxfs_da_bjoin(tp, fbp); > - libxfs_da_bhold(tp, fbp); > - XFS_BMAP_INIT(&flist, &firstblock); > - error = dir_createname(mp, tp, ip, (char *)dep->name, > - dep->namelen, INT_GET(dep->inumber, ARCH_CONVERT), > - &firstblock, &flist, nres); > - ASSERT(error == 0); > - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > - libxfs_trans_commit(tp, 0, 0); > - } > - libxfs_da_brelse(NULL, bp); > - libxfs_da_brelse(NULL, fbp); > - free(data); > -} > - > -/* > - * Finish the rebuild of a directory. > - * Stuff / in and then remove it, this forces the directory to end > - * up in the right format. > - */ > -void > -longform_dir2_rebuild_finish( > - xfs_mount_t *mp, > - xfs_ino_t ino, > - xfs_inode_t *ip) > -{ > - int committed; > - int error; > - xfs_fsblock_t firstblock; > - xfs_bmap_free_t flist; > - int nres; > - xfs_trans_t *tp; > - > - tp = libxfs_trans_alloc(mp, 0); > - nres = XFS_CREATE_SPACE_RES(mp, 1); > - error = libxfs_trans_reserve(tp, nres, XFS_CREATE_LOG_RES(mp), 0, > - XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); > - if (error) > - res_failed(error); > - libxfs_trans_ijoin(tp, ip, 0); > - libxfs_trans_ihold(tp, ip); > - XFS_BMAP_INIT(&flist, &firstblock); > - error = dir_createname(mp, tp, ip, "/", 1, ino, > - &firstblock, &flist, nres); > - ASSERT(error == 0); > - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > - libxfs_trans_commit(tp, 0, 0); > - > - /* could kill trailing empty data blocks here */ > - > - tp = libxfs_trans_alloc(mp, 0); > - nres = XFS_REMOVE_SPACE_RES(mp); > - error = libxfs_trans_reserve(tp, nres, XFS_REMOVE_LOG_RES(mp), 0, > - XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); > - if (error) > - res_failed(error); > - libxfs_trans_ijoin(tp, ip, 0); > - libxfs_trans_ihold(tp, ip); > - XFS_BMAP_INIT(&flist, &firstblock); > - error = dir_removename(mp, tp, ip, "/", 1, ino, > - &firstblock, &flist, nres); > - ASSERT(error == 0); > - libxfs_bmap_finish(&tp, &flist, firstblock, &committed); > - libxfs_trans_commit(tp, 0, 0); > -} > - > -/* > - * Rebuild a directory. > - * Remove all the non-data blocks. > - * Re-initialize to (empty) node form. > - * Loop over the data blocks reinserting each entry. > - * Force the directory into the right format. > - */ > -void > -longform_dir2_rebuild( > - xfs_mount_t *mp, > - xfs_ino_t ino, > - xfs_inode_t *ip, > - int *num_illegal, > - freetab_t *freetab, > - int isblock) > -{ > - xfs_dabuf_t *bp; > - xfs_dablk_t da_bno; > - xfs_fileoff_t next_da_bno; > - > - do_warn(_("rebuilding directory inode %llu\n"), ino); > - > - /* kill leaf blocks */ > - for (da_bno = mp->m_dirleafblk, next_da_bno = isblock ? NULLFILEOFF : 0; > - next_da_bno != NULLFILEOFF; > - da_bno = (xfs_dablk_t)next_da_bno) { > - next_da_bno = da_bno + mp->m_dirblkfsbs - 1; > - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) > - break; > - if (libxfs_da_get_buf(NULL, ip, da_bno, -1, &bp, XFS_DATA_FORK)) { > - do_error(_("can't get block %u for directory inode " > - "%llu\n"), > - da_bno, ino); > - /* NOTREACHED */ > - } > - dir2_kill_block(mp, ip, da_bno, bp); > - } > - > - /* rebuild empty btree and freelist */ > - longform_dir2_rebuild_setup(mp, ino, ip, freetab); > - > - /* rebuild directory */ > - for (da_bno = mp->m_dirdatablk, next_da_bno = 0; > - da_bno < mp->m_dirleafblk && next_da_bno != NULLFILEOFF; > - da_bno = (xfs_dablk_t)next_da_bno) { > - next_da_bno = da_bno + mp->m_dirblkfsbs - 1; > - if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) > - break; > - longform_dir2_rebuild_data(mp, ino, ip, da_bno); > - } > - > - /* put the directory in the appropriate on-disk format */ > - longform_dir2_rebuild_finish(mp, ino, ip); > - *num_illegal = 0; > -} > - > -/* > - * succeeds or dies, inode never gets dirtied since all changes > - * happen in file blocks. the inode size and other core info > - * is already correct, it's just the leaf entries that get altered. > - * XXX above comment is wrong for v2 - need to see why it matters > + * If a directory is corrupt, we need to read in as many entries as possible, > + * destroy the entry and create a new one with recovered name/inode pairs. > + * (ie. get libxfs to do all the grunt work) > */ > void > longform_dir2_entry_check(xfs_mount_t *mp, > @@ -2810,15 +2519,14 @@ longform_dir2_entry_check(xfs_mount_t *m > dir_stack_t *stack, > ino_tree_node_t *irec, > int ino_offset, > - name_hash_tab_t *nametab) > + dir_hash_tab_t *hashtab) > { > xfs_dir2_block_t *block; > xfs_dir2_leaf_entry_t *blp; > - xfs_dabuf_t *bp; > + xfs_dabuf_t **bplist; > xfs_dir2_block_tail_t *btp; > xfs_dablk_t da_bno; > freetab_t *freetab; > - dir_hash_tab_t *hashtab; > int i; > int isblock; > int isleaf; > @@ -2840,6 +2548,7 @@ longform_dir2_entry_check(xfs_mount_t *m > freetab->ents[i].v = NULLDATAOFF; > freetab->ents[i].s = 0; > } > + bplist = calloc(freetab->naents, sizeof(xfs_dabuf_t*)); > /* is this a block, leaf, or node directory? */ > libxfs_dir2_isblock(NULL, ip, &isblock); > libxfs_dir2_isleaf(NULL, ip, &isleaf); > @@ -2847,50 +2556,58 @@ longform_dir2_entry_check(xfs_mount_t *m > if (do_prefetch && !isblock) > prefetch_p6_dir2(mp, ip); > > - /* check directory data */ > - hashtab = dir_hash_init(ip->i_d.di_size); > + /* check directory "data" blocks (ie. name/inode pairs) */ > for (da_bno = 0, next_da_bno = 0; > next_da_bno != NULLFILEOFF && da_bno < mp->m_dirleafblk; > da_bno = (xfs_dablk_t)next_da_bno) { > next_da_bno = da_bno + mp->m_dirblkfsbs - 1; > + ASSERT(XFS_DIR2_DA_TO_DB(mp, da_bno) < freetab->naents); > if (libxfs_bmap_next_offset(NULL, ip, &next_da_bno, XFS_DATA_FORK)) > break; > - if (libxfs_da_read_bufr(NULL, ip, da_bno, > - da_bno == 0 ? -2 : -1, &bp, XFS_DATA_FORK)) { > - do_error(_("can't read block %u for directory inode " > - "%llu\n"), > + if (libxfs_da_read_bufr(NULL, ip, da_bno, -1, > + &bplist[XFS_DIR2_DA_TO_DB(mp, da_bno)], > + XFS_DATA_FORK)) { > + do_warn(_( > + "can't read data block %u for directory inode %llu\n"), > da_bno, ino); > - /* NOTREACHED */ > + *num_illegal++; > + continue; /* try and read all "data" blocks */ > } > - /* is there a hole at the start? */ > - if (da_bno == 0 && bp == NULL) > - continue; > longform_dir2_entry_check_data(mp, ip, num_illegal, need_dot, > - stack, irec, ino_offset, &bp, hashtab, &freetab, > - nametab, da_bno, isblock); > - /* it releases the buffer unless isblock is set */ > + stack, irec, ino_offset, > + &bplist[XFS_DIR2_DA_TO_DB(mp, da_bno)], hashtab, > + &freetab, da_bno, isblock); > } > fixit = (*num_illegal != 0) || dir2_is_badino(ino); > > /* check btree and freespace */ > if (isblock) { > - ASSERT(bp); > - block = bp->data; > + block = bplist[0]->data; > btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); > blp = XFS_DIR2_BLOCK_LEAF_P(btp); > - seeval = dir_hash_see_all(hashtab, blp, INT_GET(btp->count, ARCH_CONVERT), INT_GET(btp->stale, > ARCH_CONVERT)); > + seeval = dir_hash_see_all(hashtab, blp, > + INT_GET(btp->count, ARCH_CONVERT), > + INT_GET(btp->stale, ARCH_CONVERT)); > if (dir_hash_check(hashtab, ip, seeval)) > fixit |= 1; > - libxfs_da_brelse(NULL, bp); > } else if (isleaf) { > fixit |= longform_dir2_check_leaf(mp, ip, hashtab, freetab); > } else { > fixit |= longform_dir2_check_node(mp, ip, hashtab, freetab); > } > - dir_hash_done(hashtab); > - if (!no_modify && fixit) > - longform_dir2_rebuild(mp, ino, ip, num_illegal, freetab, > - isblock); > + if (!no_modify && fixit) { > + dir_hash_dup_names(hashtab); > + for (i = 0; i < freetab->naents; i++) > + if (bplist[i]) > + libxfs_da_brelse(NULL, bplist[i]); > + longform_dir2_rebuild(mp, ino, ip, hashtab); > + *num_illegal = 0; > + } else { > + for (i = 0; i < freetab->naents; i++) > + if (bplist[i]) > + libxfs_da_brelse(NULL, bplist[i]); > + } > + > free(freetab); > } > > @@ -2906,7 +2623,7 @@ shortform_dir_entry_check(xfs_mount_t *m > dir_stack_t *stack, > ino_tree_node_t *current_irec, > int current_ino_offset, > - name_hash_tab_t *nametab) > + dir_hash_tab_t *hashtab) > { > xfs_ino_t lino; > xfs_ino_t parent; > @@ -3044,7 +2761,7 @@ _("entry \"%s\" in shortform dir %llu re > ASSERT(irec != NULL); > > ino_offset = XFS_INO_TO_AGINO(mp, lino) - irec->ino_startnum; > - > + > /* > * if it's a free inode, blow out the entry. > * by now, any inode that we think is free > @@ -3066,8 +2783,9 @@ _("entry \"%s\" in shortform dir inode % > do_warn(_("would junk entry \"%s\"\n"), > fname); > } > - } else if (!name_hash_add(nametab, sf_entry->name, > - sf_entry->namelen)) { > + } else if (!dir_hash_add(hashtab, > + (xfs_dir2_dataptr_t)(sf_entry - &sf->list[0]), > + lino, sf_entry->namelen, sf_entry->name)) { > /* > * check for duplicate names in directory. > */ > @@ -3311,7 +3029,7 @@ shortform_dir2_entry_check(xfs_mount_t * > dir_stack_t *stack, > ino_tree_node_t *current_irec, > int current_ino_offset, > - name_hash_tab_t *nametab) > + dir_hash_tab_t *hashtab) > { > xfs_ino_t lino; > xfs_ino_t parent; > @@ -3484,7 +3202,9 @@ shortform_dir2_entry_check(xfs_mount_t * > do_warn(_("would junk entry \"%s\"\n"), > fname); > } > - } else if (!name_hash_add(nametab, sfep->name, sfep->namelen)) { > + } else if (!dir_hash_add(hashtab, (xfs_dir2_dataptr_t) > + (sfep - XFS_DIR2_SF_FIRSTENTRY(sfp)), > + lino, sfep->namelen, sfep->name)) { > /* > * check for duplicate names in directory. > */ > @@ -3650,7 +3370,7 @@ process_dirstack(xfs_mount_t *mp, dir_st > xfs_trans_t *tp; > xfs_dahash_t hashval; > ino_tree_node_t *irec; > - name_hash_tab_t *nametab; > + dir_hash_tab_t *hashtab; > int ino_offset, need_dot, committed; > int dirty, num_illegal, error, nres; > > @@ -3731,7 +3451,7 @@ process_dirstack(xfs_mount_t *mp, dir_st > > add_inode_refchecked(ino, irec, ino_offset); > > - nametab = name_hash_init(ip->i_d.di_size); > + hashtab = dir_hash_init(ip->i_d.di_size); > > /* > * look for bogus entries > @@ -3750,13 +3470,13 @@ process_dirstack(xfs_mount_t *mp, dir_st > &num_illegal, &need_dot, > stack, irec, > ino_offset, > - nametab); > + hashtab); > else > longform_dir_entry_check(mp, ino, ip, > &num_illegal, &need_dot, > stack, irec, > ino_offset, > - nametab); > + hashtab); > break; > case XFS_DINODE_FMT_LOCAL: > tp = libxfs_trans_alloc(mp, 0); > @@ -3781,12 +3501,12 @@ process_dirstack(xfs_mount_t *mp, dir_st > shortform_dir2_entry_check(mp, ino, ip, &dirty, > stack, irec, > ino_offset, > - nametab); > + hashtab); > else > shortform_dir_entry_check(mp, ino, ip, &dirty, > stack, irec, > ino_offset, > - nametab); > + hashtab); > > ASSERT(dirty == 0 || (dirty && !no_modify)); > if (dirty) { > @@ -3801,7 +3521,7 @@ process_dirstack(xfs_mount_t *mp, dir_st > default: > break; > } > - name_hash_done(nametab); > + dir_hash_done(hashtab); > > hashval = 0; > > > > -- Nathan From owner-xfs@oss.sgi.com Fri Jul 28 01:30:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 01:30:29 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6S8UFDW018821 for ; Fri, 28 Jul 2006 01:30:16 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id F41EF220812 for ; Fri, 28 Jul 2006 10:29:52 +0200 (CEST) Received: from mail.charite.de ([127.0.0.1]) by localhost (mail.charite.de [127.0.0.1]) (amavisd-new, port 10025) with LMTP id eH2n2VPx94-U for ; Fri, 28 Jul 2006 10:29:52 +0200 (CEST) Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id E64462207E0 for ; Fri, 28 Jul 2006 10:29:51 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id 7138A2209F4; Fri, 28 Jul 2006 10:29:50 +0200 (CEST) Date: Fri, 28 Jul 2006 10:29:50 +0200 From: Ralf Hildebrandt To: xfs@oss.sgi.com Subject: Re: Problem with xfs_repair Message-ID: <20060728082950.GA30429@charite.de> References: <20060728064505.GA14714@charite.de> <200607280656.QAA18277@larry.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: <200607280656.QAA18277@larry.melbourne.sgi.com> User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 8471 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: xfs Content-Length: 790 Lines: 23 * Barry Naujok : > You have hit a recent regression that is covered in the FAQ http://oss.sgi.com/projects/xfs/faq.html#dir2 I was only aware of a bug in 2.6.18-rcX (until now). Thanks. I'm in fact running 2.6.17.7 > You have two options: > 1. Do the steps in the FAQ Just what I asked for. > 2. Try the xfs_repair patch I just posted to this list. This means I'd have to get this running under knoppix (or should I try an in place repair)? -- Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to spamtrap@charite.de From owner-xfs@oss.sgi.com Fri Jul 28 07:20:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 07:20:33 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6SEKFDW016849 for ; Fri, 28 Jul 2006 07:20:15 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 6AD5A61012B4; Fri, 28 Jul 2006 10:19:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 6484016172ECC; Fri, 28 Jul 2006 10:19:48 -0400 (EDT) Date: Fri, 28 Jul 2006 10:19:48 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Hildebrandt cc: xfs@oss.sgi.com Subject: Re: Problem with xfs_repair In-Reply-To: <20060728064505.GA14714@charite.de> Message-ID: References: <20060728064505.GA14714@charite.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1170971333-1154096388=:30325" X-archive-position: 8472 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 2764 Lines: 88 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-1170971333-1154096388=:30325 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 28 Jul 2006, Ralf Hildebrandt wrote: > xfs_repair gave me this when repairing my / fs using a knoppix boot cd: > > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno =3D 0 > - agno =3D 1 > - agno =3D 2 > - agno =3D 3 > - agno =3D 4 > - agno =3D 5 > - agno =3D 6 > - agno =3D 7 > - agno =3D 8 > - agno =3D 9 > - agno =3D 10 > - agno =3D 11 > - agno =3D 12 > - agno =3D 13 > - agno =3D 14 > - agno =3D 15 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - clear lost+found (if it exists) ... > - clearing existing "lost+found" inode > - marking entry "lost+found" to be deleted > - check for inodes claiming duplicate blocks... > - agno =3D 0 > - agno =3D 1 > - agno =3D 2 > - agno =3D 3 > - agno =3D 4 > - agno =3D 5 > - agno =3D 6 > - agno =3D 7 > - agno =3D 8 > - agno =3D 9 > - agno =3D 10 > - agno =3D 11 > - agno =3D 12 > - agno =3D 13 > - agno =3D 14 > - agno =3D 15 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 128 > > fatal error -- can't read block 16777216 for directory inode 167785633 > > a) How can I find out which file/directory this inode belongs to? > b) Can I mark the block defektiv somehow? > > --=20 > Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.= de > Charite - Universit=E4tsmedizin Berlin Tel. +49 (0)30-450 570= -155 > Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-9= 62 > IT-Zentrum Standort CBF send no mail to spamtrap@charite.= de > > Is your knoppix boot cd 5.0.1 =3D=3D 2.6.17 =3D=3D bugged kernel? ;P ---1463747160-1170971333-1154096388=:30325-- From owner-xfs@oss.sgi.com Fri Jul 28 07:24:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 07:24:30 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6SEOJDW017643 for ; Fri, 28 Jul 2006 07:24:19 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 1373161012C8; Fri, 28 Jul 2006 10:23:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 08C6116172ECC; Fri, 28 Jul 2006 10:23:54 -0400 (EDT) Date: Fri, 28 Jul 2006 10:23:54 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Hildebrandt cc: xfs@oss.sgi.com Subject: Re: Problem with xfs_repair In-Reply-To: Message-ID: References: <20060728064505.GA14714@charite.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1942593404-1154096634=:30325" X-archive-position: 8473 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 2990 Lines: 96 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-1942593404-1154096634=:30325 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 28 Jul 2006, Justin Piszcz wrote: > > > On Fri, 28 Jul 2006, Ralf Hildebrandt wrote: > >> xfs_repair gave me this when repairing my / fs using a knoppix boot cd: >>=20 >> Phase 1 - find and verify superblock... >> Phase 2 - using internal log >> - zero log... >> - scan filesystem freespace and inode maps... >> - found root inode chunk >> Phase 3 - for each AG... >> - scan and clear agi unlinked lists... >> - process known inodes and perform inode discovery... >> - agno =3D 0 >> - agno =3D 1 >> - agno =3D 2 >> - agno =3D 3 >> - agno =3D 4 >> - agno =3D 5 >> - agno =3D 6 >> - agno =3D 7 >> - agno =3D 8 >> - agno =3D 9 >> - agno =3D 10 >> - agno =3D 11 >> - agno =3D 12 >> - agno =3D 13 >> - agno =3D 14 >> - agno =3D 15 >> - process newly discovered inodes... >> Phase 4 - check for duplicate blocks... >> - setting up duplicate extent list... >> - clear lost+found (if it exists) ... >> - clearing existing "lost+found" inode >> - marking entry "lost+found" to be deleted >> - check for inodes claiming duplicate blocks... >> - agno =3D 0 >> - agno =3D 1 >> - agno =3D 2 >> - agno =3D 3 >> - agno =3D 4 >> - agno =3D 5 >> - agno =3D 6 >> - agno =3D 7 >> - agno =3D 8 >> - agno =3D 9 >> - agno =3D 10 >> - agno =3D 11 >> - agno =3D 12 >> - agno =3D 13 >> - agno =3D 14 >> - agno =3D 15 >> Phase 5 - rebuild AG headers and trees... >> - reset superblock... >> Phase 6 - check inode connectivity... >> - resetting contents of realtime bitmap and summary inodes >> - ensuring existence of lost+found directory >> - traversing filesystem starting at / ... >> rebuilding directory inode 128 >>=20 >> fatal error -- can't read block 16777216 for directory inode 167785633 >>=20 >> a) How can I find out which file/directory this inode belongs to? >> b) Can I mark the block defektiv somehow? >>=20 >> --=20 >> Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite= .de >> Charite - Universit=E4tsmedizin Berlin Tel. +49 (0)30-450 57= 0-155 >> Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-= 962 >> IT-Zentrum Standort CBF send no mail to spamtrap@charite= .de >>=20 >>=20 > > Is your knoppix boot cd 5.0.1 =3D=3D 2.6.17 =3D=3D bugged kernel? ;P When repairing, do not use knoppix 5.0.1 or any version that uses 2.6.17=20 either.. ---1463747160-1942593404-1154096634=:30325-- From owner-xfs@oss.sgi.com Fri Jul 28 07:35:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 07:35:53 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms1.lichtvoll.de [194.150.191.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6SEZgDW019917 for ; Fri, 28 Jul 2006 07:35:42 -0700 Received: from localhost (dslb-084-056-089-058.pools.arcor-ip.net [84.56.89.58]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 46A47FA68E for ; Fri, 28 Jul 2006 16:35:01 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: Problem with xfs_repair Date: Fri, 28 Jul 2006 16:35:10 +0200 User-Agent: KMail/1.9.3 References: <20060728064505.GA14714@charite.de> <200607280656.QAA18277@larry.melbourne.sgi.com> <20060728082950.GA30429@charite.de> In-Reply-To: <20060728082950.GA30429@charite.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607281635.10559.Martin@lichtvoll.de> X-archive-position: 8474 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 555 Lines: 18 Am Freitag 28 Juli 2006 10:29 schrieb Ralf Hildebrandt: > > 2. Try the xfs_repair patch I just posted to this list. > > This means I'd have to get this running under knoppix (or should I try > an in place repair)? Hello Ralf, its possible to compile xfs_repair under Knoppix V5. I did it once. I do not remember the exact steps anymore. I needed uuid lib from ext3-utils as documented and I think some additional packages. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Fri Jul 28 08:50:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 08:51:22 -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 k6SFoiDW003168 for ; Fri, 28 Jul 2006 08:50:54 -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 k6SEjsnx030993 for ; Fri, 28 Jul 2006 09:45:54 -0500 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k6SHDjGv024491 for ; Fri, 28 Jul 2006 10:13:45 -0700 Received: from [134.15.0.8] (mtv-vpn-sw-corp-0-8.corp.sgi.com [134.15.0.8]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k6SErlDu43268240; Fri, 28 Jul 2006 07:53:47 -0700 (PDT) Message-ID: <44CA22F8.2040507@sgi.com> Date: Fri, 28 Jul 2006 07:45:12 -0700 From: Madan Valluri User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nathan Scott CC: Barry Naujok , xfs@oss.sgi.com Subject: Re: Review: xfs_repair fixes for dir2 corruption References: <20060728091735.B2196410@wobbly.melbourne.sgi.com> <200607280155.LAA12814@larry.melbourne.sgi.com> <20060728181013.C2197701@wobbly.melbourne.sgi.com> In-Reply-To: <20060728181013.C2197701@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8475 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mvalluri@sgi.com Precedence: bulk X-list: xfs Content-Length: 1395 Lines: 44 Nathan Scott wrote: > On Fri, Jul 28, 2006 at 11:58:52AM +1000, Barry Naujok wrote: > >> This patch addresses the following xfs_repair issues: >> > > The libxfs cache stuff looks good to me. Maybe Madan can cast > an eye over the repair changes for ya? > > cheers. > > >> 1) Since dir_hash_add can be called for both V1 and V2 directories its second parameter type xfs_dir2_dataptr_t should be neutral. 2) In dir_hash_add when dup is set, do you still need to add to the nextbyhash by list? 3) The following statement in longform_dir2_rebuild looks odd. Besides, FWIW, you can match "/." if (p->name[0] == '/' || (p->name[0] == '.' && (p->namelen == 1 || (p->namelen == 2 && p->name[1] == '.')))) continue; Consider: if (((p->name[0] == '/' || p->name[0] == '.') && p->namelen == 1) || (p->name[0] == '.' && p->name[1] == '.' && p->namelen == 2)) continue; 4) Related to items 2&3, shouldn't the code be skipping duplicate entries? 5) Can we do anything to minimize the do_error calls in longform_dir2_rebuild? Seems like on a full file system, while rebuilding say the root directory, matters can get wacky - The directory is being rebuilt and we have no further room. Sounds like that this how it has been.... Thanks. /Madan From owner-xfs@oss.sgi.com Fri Jul 28 09:25:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 09:25:26 -0700 (PDT) Received: from mail.mdlink.de (hydra.mdlink.de [213.211.192.38]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6SGPDDW009517 for ; Fri, 28 Jul 2006 09:25:13 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.de (Postfix) with ESMTP id BCB0E80E5E6D for ; Fri, 28 Jul 2006 16:21:22 +0200 (CEST) Received: from [213.211.192.21] (premium.mdlink.de [213.211.192.21]) by mail.mdlink.de (Postfix) with ESMTP id 877BF80E37FA for ; Fri, 28 Jul 2006 16:21:22 +0200 (CEST) Message-ID: <44CA1D89.3080104@mdlink.de> Date: Fri, 28 Jul 2006 16:22:01 +0200 From: Frank Patzig User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [xfs] quota project problem Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 8476 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: fp@mdlink.de Precedence: bulk X-list: xfs Content-Length: 2156 Lines: 75 Hallo, i have a problem with project quota. Can i help you. combolix:~ # uname -a Linux combolix 2.6.18_rc1-jen27-default #1 Thu Jul 13 01:34:23 CEST 2006 i686 i686 i386 GNU/Linux combolix:~ # cat /etc/mtab /dev/hdc2 / xfs rw,uquota,gquota,pquota 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 devpts /dev/pts devpts rw,mode=0620,gid=5 0 0 usbfs /proc/bus/usb usbfs rw 0 0 combolix:~ # echo 42:/var/log >> /etc/projects combolix:~ # echo logfiles:42 >> /etc/projid combolix:~ # xfs_quota -x -c 'project -c logfiles' / Checking project logfiles (path /var/log)... Processed 1 /etc/projects paths for project logfiles combolix:~ # xfs_quota -x -c 'limit -p bhard=1g logfiles' / xfs_quota: cannot set limits: No such process xfs_quota -x -c 'state -p' / Project quota state on / (/dev/hdc2) Accounting: OFF Enforcement: OFF Inode: #18446744073709551615 (0 blocks, 0 extents) Blocks grace time: [7 days] Inodes grace time: [7 days] Realtime Blocks grace time: [7 days] combolix:~ # xfs_quota -x -c 'report -p' / not answer combolix:~ # xfs_quota -x -c 'quota -p logfile' / xfs_quota: cannot find project logfile combolix:~ # xfs_quota -x -c 'quota -p 42' / not answer combolix:~ # xfs_quota -x -c 'print' Filesystem Pathname / /dev/hdc2 (uquota) /var/log /dev/hdc2 (project 42, logfiles) combolix:~ # xfs_quota -x -c 'quot -p' /dev/hdc2 (/) Project: 16080 logfiles combolix:~ # xfs_quota -x -c 'free' Filesystem 1K-blocks Used Available Use% Pathname /dev/hdc2 76006520 4666116 71340404 7% / XFS_GETQUOTA: No such process combolix:~ # xfs_quota -x -c 'path' Filesystem Pathname [000] / /dev/hdc2 (uquota) 001 /var/log /dev/hdc2 (project 42, logfiles) I have not a idee for this problem. Thanks -- Frank Patzig MDlink online service center GmbH mail: fp@mdlink.de Universitätsplatz 12 phone: +49 391 25568 0 Magdeburg fax: +49 391 25568 99 39104 http://www.mdlink.de Germany From owner-xfs@oss.sgi.com Fri Jul 28 10:02:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 10:02:43 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6SH2DDW015221 for ; Fri, 28 Jul 2006 10:02:19 -0700 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G6ViU-0007zN-O8; Fri, 28 Jul 2006 19:01:38 +0200 Date: Fri, 28 Jul 2006 17:01:24 +0000 (UTC) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Nathan Scott cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 In-Reply-To: <20060724090138.C2083275@wobbly.melbourne.sgi.com> Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <20060724090138.C2083275@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8477 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evil@g-house.de Precedence: bulk X-list: xfs Content-Length: 1303 Lines: 34 Hello again, On Mon, 24 Jul 2006, Nathan Scott wrote: > filesystem too. See the FAQ entry for a description on how to > translate inums to paths, and also the repair -n step to detect > any corruption ondisk. I had two xfs filesystems and I first noticed that /data/Scratch was befallen from this bug. I did not care much about this (hence the name :)) and I wanted to postpone the xfs_db surgery. Unfortunately I forgot that "/" was also an XFS and it crashed yesterday. remounting ro helped a bit (so no process attempted to write on it. however, cp'ing from the ro-mounted xfs sometimes hung, unkillable), I setup a mini-root somewhere else and followed the instructions in the FAQ. It did not go too well, lots of stuff was moved to lost+found, but every subsequent xfs_repair run found more and more errors. I decided to mkfs the partition and make use of my backups. my other "scratch" partition is still XFS but mounted ro and I'll try the xfsprogs fixes Nathan published on this one. Oh, and I dd'ed the corrupt xfs-filesystem to a file, so I can play around with this one as well. If anyone is interested, here are the typescripts from the horrible xfs_repair runs: http://nerdbynature.de/bits/2.6.18-rc2/log/ cheers, Christian. -- BOFH excuse #21: POSIX compliance problem From owner-xfs@oss.sgi.com Fri Jul 28 10:15:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 10:15:34 -0700 (PDT) Received: from mxout.fs-cfc.co.uk (mxout.fs-cfc.co.uk [193.203.83.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6SHFCDW017677 for ; Fri, 28 Jul 2006 10:15:22 -0700 Received: from localhost (unknown [127.0.0.1]) by mxout.fs-cfc.co.uk (Postfix) with ESMTP id 1D841138064 for ; Fri, 28 Jul 2006 16:15:48 +0100 (BST) Received: from mxout.fs-cfc.co.uk ([127.0.0.1]) by localhost (mx-out.prod.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 11641-02 for ; Fri, 28 Jul 2006 16:15:47 +0100 (BST) Received: from mail.admin.local (mail.admin.local [192.168.0.15]) by mxout.fs-cfc.co.uk (Postfix) with ESMTP id 41AAF13803B for ; Fri, 28 Jul 2006 16:15:47 +0100 (BST) Received: from localhost (unknown [127.0.0.1]) by mail.admin.local (Postfix) with ESMTP id 9B00F73B48C for ; Fri, 28 Jul 2006 15:14:04 +0000 (UTC) Received: from mail.admin.local ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 17049-01 for ; Fri, 28 Jul 2006 16:14:04 +0100 (BST) Received: from [172.17.80.198] (sys198.prod.local [172.17.80.198]) by mail.admin.local (Postfix) with ESMTP id EC00B73F3EB for ; Fri, 28 Jul 2006 16:14:03 +0100 (BST) Message-ID: <44CA29BB.6080706@framestore-cfc.com> Date: Fri, 28 Jul 2006 16:14:03 +0100 From: Marcin Stangel User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: question - xfs stress tests Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8478 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mstangel@framestore-cfc.com Precedence: bulk X-list: xfs Content-Length: 281 Lines: 17 Hi there, I have a 2TB raid5 device and I need to do some stress tests, I've read about xfstests tool but I couldn't find sources. is there somewhere a tar.gz file available ? cheers! Marcin -- Marcin Stangel Systems Support 9 Noel Street London W1F 8GH +44 (0)20 7106 2544 From owner-xfs@oss.sgi.com Fri Jul 28 13:55:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 13:55:51 -0700 (PDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6SKtZDW021555 for ; Fri, 28 Jul 2006 13:55:35 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G6YGg-0000xD-1I for xfs@oss.sgi.com; Fri, 28 Jul 2006 12:45:06 -0700 Message-ID: <5545990.post@talk.nabble.com> Date: Fri, 28 Jul 2006 12:45:06 -0700 (PDT) From: calembour To: xfs@oss.sgi.com Subject: write back cache and barriers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mrcekets@gmail.com X-Nabble-From: calembour X-archive-position: 8479 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mrcekets@gmail.com Precedence: bulk X-list: xfs Content-Length: 1332 Lines: 32 Hi, I don't have a deep knowledge about filesystems and I've few experiences with raid configuration, so I need someone who can answer some questions about write back cache and barriers. I have two sata hd (sda, sdb) configured in bios-raid 0 and relative device created by dmraid on boot (nvidia_ihfaaicb). (1) what should I do to know if the write back cache is enabled or not ? (2) if the write cache is enabled on both sda and sdb this mean that is enabled also on the raid device (/dev/mapper/nvidia_ihfaaicb) ? (3) how should I do to enable/disable the write cache on the raid device ? If I try mounting a xfs filesystem I get a message like "barriers are not supported by this device" but if I mount a ext3 or a reiserfs filesystem respectively with options barrier=1 and barrier=flush they don't complain. If I mount the reiserfs I explicity get a message like "using barriers". So who tells the truth ?? (4) is there a way to know if the raid device supports barrier or not ? (5) is there a (not dangerous) test I can do to figure out if barriers are really enabled and used with ext3 and reiserfs filesystems ? Thanks for reading the message Marco -- View this message in context: http://www.nabble.com/write-back-cache-and-barriers-tf2017234.html#a5545990 Sent from the Xfs - General forum at Nabble.com. From owner-xfs@oss.sgi.com Fri Jul 28 14:49:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 14:49:36 -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 k6SLmqDW030596 for ; Fri, 28 Jul 2006 14:49: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 HAA08151; Sat, 29 Jul 2006 07:48:10 +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 k6SLm7gw2223045; Sat, 29 Jul 2006 07:48:07 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6SLm30G2225759; Sat, 29 Jul 2006 07:48:03 +1000 (EST) Date: Sat, 29 Jul 2006 07:48:03 +1000 From: Nathan Scott To: Christian Kujau Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060729074803.A2222647@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <20060724090138.C2083275@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from evil@g-house.de on Fri, Jul 28, 2006 at 05:01:24PM +0000 X-archive-position: 8481 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: 649 Lines: 17 On Fri, Jul 28, 2006 at 05:01:24PM +0000, Christian Kujau wrote: > I had two xfs filesystems and I first noticed that /data/Scratch was > befallen from this bug. I did not care much about this (hence the > name :)) and I wanted to postpone the xfs_db surgery. > ... > found more and more errors. I decided to mkfs the partition and make use > of my backups. my other "scratch" partition is still XFS but mounted ro > and I'll try the xfsprogs fixes Nathan published on this one. Barry sent an xfs_repair patch to resolve this issue to the xfs@oss.sgi.com list yesterday; please give that a go and let us know how it fares. cheers. -- Nathan From owner-xfs@oss.sgi.com Fri Jul 28 15:08:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 15:08: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 k6SM83DW001159 for ; Fri, 28 Jul 2006 15:08:17 -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 IAA08462; Sat, 29 Jul 2006 08:07:21 +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 k6SM7Igw2221108; Sat, 29 Jul 2006 08:07:18 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6SM7F8R2225767; Sat, 29 Jul 2006 08:07:15 +1000 (EST) Date: Sat, 29 Jul 2006 08:07:15 +1000 From: Nathan Scott To: Marcin Stangel Cc: linux-xfs@oss.sgi.com Subject: Re: question - xfs stress tests Message-ID: <20060729080715.C2222647@wobbly.melbourne.sgi.com> References: <44CA29BB.6080706@framestore-cfc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44CA29BB.6080706@framestore-cfc.com>; from mstangel@framestore-cfc.com on Fri, Jul 28, 2006 at 04:14:03PM +0100 X-archive-position: 8482 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: 334 Lines: 15 On Fri, Jul 28, 2006 at 04:14:03PM +0100, Marcin Stangel wrote: > Hi there, > > I have a 2TB raid5 device and I need to do some stress tests, I've read > about xfstests tool but I couldn't find sources. > > is there somewhere a tar.gz file available ? No tarball - CVS is the only way to access these tools. cheers. -- Nathan From owner-xfs@oss.sgi.com Fri Jul 28 21:22:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Jul 2006 21:22:13 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6T4LtDW024235 for ; Fri, 28 Jul 2006 21:22:01 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id C96D418DE2F33 for ; Fri, 28 Jul 2006 23:21:25 -0500 (CDT) Message-ID: <44CAE247.6020608@sandeen.net> Date: Fri, 28 Jul 2006 23:21:27 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] kill leftover WANT_FUNCS macro indirection Content-Type: multipart/mixed; boundary="------------040402000908070606030002" X-archive-position: 8483 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 37808 Lines: 1008 This is a multi-part message in MIME format. --------------040402000908070606030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This gets rid of some pointless macro defines... I had a version that lower-cased it all too but Nathan liked this better, and he's the man! :) -Eric --------------040402000908070606030002 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="kill-wantfuncs-simple" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kill-wantfuncs-simple" Remove unnecessary macro indirection - left over from old WANT_FUNCS days Signed-Off-By: Eric Sandeen xfs_attr_leaf.h | 24 ++++------------ xfs_bit.h | 12 ++------ xfs_bmap.h | 6 +--- xfs_bmap_btree.h | 12 ++------ xfs_dir2_block.h | 6 +--- xfs_dir2_data.h | 10 ++---- xfs_dir2_leaf.h | 44 +++++++++--------------------- xfs_dir2_node.h | 6 +--- xfs_dir2_sf.h | 36 ++++++------------------ xfs_ialloc.h | 6 +--- xfs_ialloc_btree.h | 3 -- xfs_inode_item.h | 9 ++---- xfs_mount.h | 15 +++------- xfs_rw.h | 6 +--- xfs_sb.h | 77 +++++++++++++++++------------------------------------ xfs_trans.h | 33 +++++++--------------- 16 files changed, 97 insertions(+), 208 deletions(-) Index: xfs-linux-killwantfuncs/xfs_attr_leaf.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_attr_leaf.h +++ xfs-linux-killwantfuncs/xfs_attr_leaf.h @@ -138,27 +138,21 @@ typedef struct xfs_attr_leafblock { /* * Cast typed pointers for "local" and "remote" name/value structs. */ -#define XFS_ATTR_LEAF_NAME_REMOTE(leafp,idx) \ - xfs_attr_leaf_name_remote(leafp,idx) static inline xfs_attr_leaf_name_remote_t * -xfs_attr_leaf_name_remote(xfs_attr_leafblock_t *leafp, int idx) +XFS_ATTR_LEAF_NAME_REMOTE(xfs_attr_leafblock_t *leafp, int idx) { return (xfs_attr_leaf_name_remote_t *) &((char *)leafp)[be16_to_cpu(leafp->entries[idx].nameidx)]; } -#define XFS_ATTR_LEAF_NAME_LOCAL(leafp,idx) \ - xfs_attr_leaf_name_local(leafp,idx) static inline xfs_attr_leaf_name_local_t * -xfs_attr_leaf_name_local(xfs_attr_leafblock_t *leafp, int idx) +XFS_ATTR_LEAF_NAME_LOCAL(xfs_attr_leafblock_t *leafp, int idx) { return (xfs_attr_leaf_name_local_t *) &((char *)leafp)[be16_to_cpu(leafp->entries[idx].nameidx)]; } -#define XFS_ATTR_LEAF_NAME(leafp,idx) \ - xfs_attr_leaf_name(leafp,idx) -static inline char *xfs_attr_leaf_name(xfs_attr_leafblock_t *leafp, int idx) +static inline char *XFS_ATTR_LEAF_NAME(xfs_attr_leafblock_t *leafp, int idx) { return &((char *)leafp)[be16_to_cpu(leafp->entries[idx].nameidx)]; } @@ -168,25 +162,19 @@ static inline char *xfs_attr_leaf_name(x * a "local" name/value structure, a "remote" name/value structure, and * a pointer which might be either. */ -#define XFS_ATTR_LEAF_ENTSIZE_REMOTE(nlen) \ - xfs_attr_leaf_entsize_remote(nlen) -static inline int xfs_attr_leaf_entsize_remote(int nlen) +static inline int XFS_ATTR_LEAF_ENTSIZE_REMOTE(int nlen) { return ((uint)sizeof(xfs_attr_leaf_name_remote_t) - 1 + (nlen) + \ XFS_ATTR_LEAF_NAME_ALIGN - 1) & ~(XFS_ATTR_LEAF_NAME_ALIGN - 1); } -#define XFS_ATTR_LEAF_ENTSIZE_LOCAL(nlen,vlen) \ - xfs_attr_leaf_entsize_local(nlen,vlen) -static inline int xfs_attr_leaf_entsize_local(int nlen, int vlen) +static inline int XFS_ATTR_LEAF_ENTSIZE_LOCAL(int nlen, int vlen) { return ((uint)sizeof(xfs_attr_leaf_name_local_t) - 1 + (nlen) + (vlen) + XFS_ATTR_LEAF_NAME_ALIGN - 1) & ~(XFS_ATTR_LEAF_NAME_ALIGN - 1); } -#define XFS_ATTR_LEAF_ENTSIZE_LOCAL_MAX(bsize) \ - xfs_attr_leaf_entsize_local_max(bsize) -static inline int xfs_attr_leaf_entsize_local_max(int bsize) +static inline int XFS_ATTR_LEAF_ENTSIZE_LOCAL_MAX(int bsize) { return (((bsize) >> 1) + ((bsize) >> 2)); } Index: xfs-linux-killwantfuncs/xfs_bit.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_bit.h +++ xfs-linux-killwantfuncs/xfs_bit.h @@ -25,23 +25,19 @@ /* * masks with n high/low bits set, 32-bit values & 64-bit values */ -#define XFS_MASK32HI(n) xfs_mask32hi(n) -static inline __uint32_t xfs_mask32hi(int n) +static inline __uint32_t XFS_MASK32HI(int n) { return (__uint32_t)-1 << (32 - (n)); } -#define XFS_MASK64HI(n) xfs_mask64hi(n) -static inline __uint64_t xfs_mask64hi(int n) +static inline __uint64_t XFS_MASK64HI(int n) { return (__uint64_t)-1 << (64 - (n)); } -#define XFS_MASK32LO(n) xfs_mask32lo(n) -static inline __uint32_t xfs_mask32lo(int n) +static inline __uint32_t XFS_MASK32LO(int n) { return ((__uint32_t)1 << (n)) - 1; } -#define XFS_MASK64LO(n) xfs_mask64lo(n) -static inline __uint64_t xfs_mask64lo(int n) +static inline __uint64_t XFS_MASK64LO(int n) { return ((__uint64_t)1 << (n)) - 1; } Index: xfs-linux-killwantfuncs/xfs_bmap.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_bmap.h +++ xfs-linux-killwantfuncs/xfs_bmap.h @@ -82,8 +82,7 @@ typedef struct xfs_bmap_free /* need write cache flushing and no */ /* additional allocation alignments */ -#define XFS_BMAPI_AFLAG(w) xfs_bmapi_aflag(w) -static inline int xfs_bmapi_aflag(int w) +static inline int XFS_BMAPI_AFLAG(int w) { return (w == XFS_ATTR_FORK ? XFS_BMAPI_ATTRFORK : 0); } @@ -94,8 +93,7 @@ static inline int xfs_bmapi_aflag(int w) #define DELAYSTARTBLOCK ((xfs_fsblock_t)-1LL) #define HOLESTARTBLOCK ((xfs_fsblock_t)-2LL) -#define XFS_BMAP_INIT(flp,fbp) xfs_bmap_init(flp,fbp) -static inline void xfs_bmap_init(xfs_bmap_free_t *flp, xfs_fsblock_t *fbp) +static inline void XFS_BMAP_INIT(xfs_bmap_free_t *flp, xfs_fsblock_t *fbp) { ((flp)->xbf_first = NULL, (flp)->xbf_count = 0, \ (flp)->xbf_low = 0, *(fbp) = NULLFSBLOCK); Index: xfs-linux-killwantfuncs/xfs_bmap_btree.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_bmap_btree.h +++ xfs-linux-killwantfuncs/xfs_bmap_btree.h @@ -100,27 +100,23 @@ typedef xfs_bmbt_rec_64_t xfs_bmbt_rec_t #define DSTARTBLOCKMASK \ (((((xfs_dfsbno_t)1) << DSTARTBLOCKMASKBITS) - 1) << STARTBLOCKVALBITS) -#define ISNULLSTARTBLOCK(x) isnullstartblock(x) -static inline int isnullstartblock(xfs_fsblock_t x) +static inline int ISNULLSTARTBLOCK(xfs_fsblock_t x) { return ((x) & STARTBLOCKMASK) == STARTBLOCKMASK; } -#define ISNULLDSTARTBLOCK(x) isnulldstartblock(x) -static inline int isnulldstartblock(xfs_dfsbno_t x) +static inline int ISNULLDSTARTBLOCK(xfs_dfsbno_t x) { return ((x) & DSTARTBLOCKMASK) == DSTARTBLOCKMASK; } -#define NULLSTARTBLOCK(k) nullstartblock(k) -static inline xfs_fsblock_t nullstartblock(int k) +static inline xfs_fsblock_t NULLSTARTBLOCK(int k) { ASSERT(k < (1 << STARTBLOCKVALBITS)); return STARTBLOCKMASK | (k); } -#define STARTBLOCKVAL(x) startblockval(x) -static inline xfs_filblks_t startblockval(xfs_fsblock_t x) +static inline xfs_filblks_t STARTBLOCKVAL(xfs_fsblock_t x) { return (xfs_filblks_t)((x) & ~STARTBLOCKMASK); } Index: xfs-linux-killwantfuncs/xfs_dir2_block.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_dir2_block.h +++ xfs-linux-killwantfuncs/xfs_dir2_block.h @@ -60,9 +60,8 @@ typedef struct xfs_dir2_block { /* * Pointer to the leaf header embedded in a data block (1-block format) */ -#define XFS_DIR2_BLOCK_TAIL_P(mp,block) xfs_dir2_block_tail_p(mp,block) static inline xfs_dir2_block_tail_t * -xfs_dir2_block_tail_p(struct xfs_mount *mp, xfs_dir2_block_t *block) +XFS_DIR2_BLOCK_TAIL_P(struct xfs_mount *mp, xfs_dir2_block_t *block) { return (((xfs_dir2_block_tail_t *) ((char *)(block) + (mp)->m_dirblksize)) - 1); @@ -71,9 +70,8 @@ xfs_dir2_block_tail_p(struct xfs_mount * /* * Pointer to the leaf entries embedded in a data block (1-block format) */ -#define XFS_DIR2_BLOCK_LEAF_P(btp) xfs_dir2_block_leaf_p(btp) static inline struct xfs_dir2_leaf_entry * -xfs_dir2_block_leaf_p(xfs_dir2_block_tail_t *btp) +XFS_DIR2_BLOCK_LEAF_P(xfs_dir2_block_tail_t *btp) { return ((struct xfs_dir2_leaf_entry *)btp) - be32_to_cpu(btp->count); } Index: xfs-linux-killwantfuncs/xfs_dir2_data.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_dir2_data.h +++ xfs-linux-killwantfuncs/xfs_dir2_data.h @@ -123,8 +123,7 @@ typedef struct xfs_dir2_data { /* * Size of a data entry. */ -#define XFS_DIR2_DATA_ENTSIZE(n) xfs_dir2_data_entsize(n) -static inline int xfs_dir2_data_entsize(int n) +static inline int XFS_DIR2_DATA_ENTSIZE(int n) { return (int)roundup(offsetof(xfs_dir2_data_entry_t, name[0]) + (n) + \ (uint)sizeof(xfs_dir2_data_off_t), XFS_DIR2_DATA_ALIGN); @@ -133,9 +132,8 @@ static inline int xfs_dir2_data_entsize( /* * Pointer to an entry's tag word. */ -#define XFS_DIR2_DATA_ENTRY_TAG_P(dep) xfs_dir2_data_entry_tag_p(dep) static inline __be16 * -xfs_dir2_data_entry_tag_p(xfs_dir2_data_entry_t *dep) +XFS_DIR2_DATA_ENTRY_TAG_P(xfs_dir2_data_entry_t *dep) { return (__be16 *)((char *)dep + XFS_DIR2_DATA_ENTSIZE(dep->namelen) - sizeof(__be16)); @@ -144,10 +142,8 @@ xfs_dir2_data_entry_tag_p(xfs_dir2_data_ /* * Pointer to a freespace's tag word. */ -#define XFS_DIR2_DATA_UNUSED_TAG_P(dup) \ - xfs_dir2_data_unused_tag_p(dup) static inline __be16 * -xfs_dir2_data_unused_tag_p(xfs_dir2_data_unused_t *dup) +XFS_DIR2_DATA_UNUSED_TAG_P(xfs_dir2_data_unused_t *dup) { return (__be16 *)((char *)dup + be16_to_cpu(dup->length) - sizeof(__be16)); Index: xfs-linux-killwantfuncs/xfs_dir2_leaf.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_dir2_leaf.h +++ xfs-linux-killwantfuncs/xfs_dir2_leaf.h @@ -82,8 +82,7 @@ typedef struct xfs_dir2_leaf { * DB blocks here are logical directory block numbers, not filesystem blocks. */ -#define XFS_DIR2_MAX_LEAF_ENTS(mp) xfs_dir2_max_leaf_ents(mp) -static inline int xfs_dir2_max_leaf_ents(struct xfs_mount *mp) +static inline int XFS_DIR2_MAX_LEAF_ENTS(struct xfs_mount *mp) { return (int)(((mp)->m_dirblksize - (uint)sizeof(xfs_dir2_leaf_hdr_t)) / (uint)sizeof(xfs_dir2_leaf_entry_t)); @@ -92,9 +91,8 @@ static inline int xfs_dir2_max_leaf_ents /* * Get address of the bestcount field in the single-leaf block. */ -#define XFS_DIR2_LEAF_TAIL_P(mp,lp) xfs_dir2_leaf_tail_p(mp, lp) static inline xfs_dir2_leaf_tail_t * -xfs_dir2_leaf_tail_p(struct xfs_mount *mp, xfs_dir2_leaf_t *lp) +XFS_DIR2_LEAF_TAIL_P(struct xfs_mount *mp, xfs_dir2_leaf_t *lp) { return (xfs_dir2_leaf_tail_t *) ((char *)(lp) + (mp)->m_dirblksize - @@ -104,9 +102,8 @@ xfs_dir2_leaf_tail_p(struct xfs_mount *m /* * Get address of the bests array in the single-leaf block. */ -#define XFS_DIR2_LEAF_BESTS_P(ltp) xfs_dir2_leaf_bests_p(ltp) static inline __be16 * -xfs_dir2_leaf_bests_p(xfs_dir2_leaf_tail_t *ltp) +XFS_DIR2_LEAF_BESTS_P(xfs_dir2_leaf_tail_t *ltp) { return (__be16 *)ltp - be32_to_cpu(ltp->bestcount); } @@ -114,9 +111,8 @@ xfs_dir2_leaf_bests_p(xfs_dir2_leaf_tail /* * Convert dataptr to byte in file space */ -#define XFS_DIR2_DATAPTR_TO_BYTE(mp,dp) xfs_dir2_dataptr_to_byte(mp, dp) static inline xfs_dir2_off_t -xfs_dir2_dataptr_to_byte(struct xfs_mount *mp, xfs_dir2_dataptr_t dp) +XFS_DIR2_DATAPTR_TO_BYTE(struct xfs_mount *mp, xfs_dir2_dataptr_t dp) { return (xfs_dir2_off_t)(dp) << XFS_DIR2_DATA_ALIGN_LOG; } @@ -124,9 +120,8 @@ xfs_dir2_dataptr_to_byte(struct xfs_moun /* * Convert byte in file space to dataptr. It had better be aligned. */ -#define XFS_DIR2_BYTE_TO_DATAPTR(mp,by) xfs_dir2_byte_to_dataptr(mp,by) static inline xfs_dir2_dataptr_t -xfs_dir2_byte_to_dataptr(struct xfs_mount *mp, xfs_dir2_off_t by) +XFS_DIR2_BYTE_TO_DATAPTR(struct xfs_mount *mp, xfs_dir2_off_t by) { return (xfs_dir2_dataptr_t)((by) >> XFS_DIR2_DATA_ALIGN_LOG); } @@ -134,9 +129,8 @@ xfs_dir2_byte_to_dataptr(struct xfs_moun /* * Convert byte in space to (DB) block */ -#define XFS_DIR2_BYTE_TO_DB(mp,by) xfs_dir2_byte_to_db(mp, by) static inline xfs_dir2_db_t -xfs_dir2_byte_to_db(struct xfs_mount *mp, xfs_dir2_off_t by) +XFS_DIR2_BYTE_TO_DB(struct xfs_mount *mp, xfs_dir2_off_t by) { return (xfs_dir2_db_t)((by) >> \ ((mp)->m_sb.sb_blocklog + (mp)->m_sb.sb_dirblklog)); @@ -145,9 +139,8 @@ xfs_dir2_byte_to_db(struct xfs_mount *mp /* * Convert dataptr to a block number */ -#define XFS_DIR2_DATAPTR_TO_DB(mp,dp) xfs_dir2_dataptr_to_db(mp, dp) static inline xfs_dir2_db_t -xfs_dir2_dataptr_to_db(struct xfs_mount *mp, xfs_dir2_dataptr_t dp) +XFS_DIR2_DATAPTR_TO_DB(struct xfs_mount *mp, xfs_dir2_dataptr_t dp) { return XFS_DIR2_BYTE_TO_DB(mp, XFS_DIR2_DATAPTR_TO_BYTE(mp, dp)); } @@ -155,9 +148,8 @@ xfs_dir2_dataptr_to_db(struct xfs_mount /* * Convert byte in space to offset in a block */ -#define XFS_DIR2_BYTE_TO_OFF(mp,by) xfs_dir2_byte_to_off(mp, by) static inline xfs_dir2_data_aoff_t -xfs_dir2_byte_to_off(struct xfs_mount *mp, xfs_dir2_off_t by) +XFS_DIR2_BYTE_TO_OFF(struct xfs_mount *mp, xfs_dir2_off_t by) { return (xfs_dir2_data_aoff_t)((by) & \ ((1 << ((mp)->m_sb.sb_blocklog + (mp)->m_sb.sb_dirblklog)) - 1)); @@ -176,10 +168,8 @@ xfs_dir2_dataptr_to_off(struct xfs_mount /* * Convert block and offset to byte in space */ -#define XFS_DIR2_DB_OFF_TO_BYTE(mp,db,o) \ - xfs_dir2_db_off_to_byte(mp, db, o) static inline xfs_dir2_off_t -xfs_dir2_db_off_to_byte(struct xfs_mount *mp, xfs_dir2_db_t db, +XFS_DIR2_DB_OFF_TO_BYTE(struct xfs_mount *mp, xfs_dir2_db_t db, xfs_dir2_data_aoff_t o) { return ((xfs_dir2_off_t)(db) << \ @@ -189,9 +179,8 @@ xfs_dir2_db_off_to_byte(struct xfs_mount /* * Convert block (DB) to block (dablk) */ -#define XFS_DIR2_DB_TO_DA(mp,db) xfs_dir2_db_to_da(mp, db) static inline xfs_dablk_t -xfs_dir2_db_to_da(struct xfs_mount *mp, xfs_dir2_db_t db) +XFS_DIR2_DB_TO_DA(struct xfs_mount *mp, xfs_dir2_db_t db) { return (xfs_dablk_t)((db) << (mp)->m_sb.sb_dirblklog); } @@ -199,9 +188,8 @@ xfs_dir2_db_to_da(struct xfs_mount *mp, /* * Convert byte in space to (DA) block */ -#define XFS_DIR2_BYTE_TO_DA(mp,by) xfs_dir2_byte_to_da(mp, by) static inline xfs_dablk_t -xfs_dir2_byte_to_da(struct xfs_mount *mp, xfs_dir2_off_t by) +XFS_DIR2_BYTE_TO_DA(struct xfs_mount *mp, xfs_dir2_off_t by) { return XFS_DIR2_DB_TO_DA(mp, XFS_DIR2_BYTE_TO_DB(mp, by)); } @@ -209,10 +197,8 @@ xfs_dir2_byte_to_da(struct xfs_mount *mp /* * Convert block and offset to dataptr */ -#define XFS_DIR2_DB_OFF_TO_DATAPTR(mp,db,o) \ - xfs_dir2_db_off_to_dataptr(mp, db, o) static inline xfs_dir2_dataptr_t -xfs_dir2_db_off_to_dataptr(struct xfs_mount *mp, xfs_dir2_db_t db, +XFS_DIR2_DB_OFF_TO_DATAPTR(struct xfs_mount *mp, xfs_dir2_db_t db, xfs_dir2_data_aoff_t o) { return XFS_DIR2_BYTE_TO_DATAPTR(mp, XFS_DIR2_DB_OFF_TO_BYTE(mp, db, o)); @@ -221,9 +207,8 @@ xfs_dir2_db_off_to_dataptr(struct xfs_mo /* * Convert block (dablk) to block (DB) */ -#define XFS_DIR2_DA_TO_DB(mp,da) xfs_dir2_da_to_db(mp, da) static inline xfs_dir2_db_t -xfs_dir2_da_to_db(struct xfs_mount *mp, xfs_dablk_t da) +XFS_DIR2_DA_TO_DB(struct xfs_mount *mp, xfs_dablk_t da) { return (xfs_dir2_db_t)((da) >> (mp)->m_sb.sb_dirblklog); } @@ -231,9 +216,8 @@ xfs_dir2_da_to_db(struct xfs_mount *mp, /* * Convert block (dablk) to byte offset in space */ -#define XFS_DIR2_DA_TO_BYTE(mp,da) xfs_dir2_da_to_byte(mp, da) static inline xfs_dir2_off_t -xfs_dir2_da_to_byte(struct xfs_mount *mp, xfs_dablk_t da) +XFS_DIR2_DA_TO_BYTE(struct xfs_mount *mp, xfs_dablk_t da) { return XFS_DIR2_DB_OFF_TO_BYTE(mp, XFS_DIR2_DA_TO_DB(mp, da), 0); } Index: xfs-linux-killwantfuncs/xfs_dir2_node.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_dir2_node.h +++ xfs-linux-killwantfuncs/xfs_dir2_node.h @@ -60,9 +60,8 @@ typedef struct xfs_dir2_free { /* * Convert data space db to the corresponding free db. */ -#define XFS_DIR2_DB_TO_FDB(mp,db) xfs_dir2_db_to_fdb(mp, db) static inline xfs_dir2_db_t -xfs_dir2_db_to_fdb(struct xfs_mount *mp, xfs_dir2_db_t db) +XFS_DIR2_DB_TO_FDB(struct xfs_mount *mp, xfs_dir2_db_t db) { return (XFS_DIR2_FREE_FIRSTDB(mp) + (db) / XFS_DIR2_MAX_FREE_BESTS(mp)); } @@ -70,9 +69,8 @@ xfs_dir2_db_to_fdb(struct xfs_mount *mp, /* * Convert data space db to the corresponding index in a free db. */ -#define XFS_DIR2_DB_TO_FDINDEX(mp,db) xfs_dir2_db_to_fdindex(mp, db) static inline int -xfs_dir2_db_to_fdindex(struct xfs_mount *mp, xfs_dir2_db_t db) +XFS_DIR2_DB_TO_FDINDEX(struct xfs_mount *mp, xfs_dir2_db_t db) { return ((db) % XFS_DIR2_MAX_FREE_BESTS(mp)); } Index: xfs-linux-killwantfuncs/xfs_dir2_sf.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_dir2_sf.h +++ xfs-linux-killwantfuncs/xfs_dir2_sf.h @@ -90,33 +90,27 @@ typedef struct xfs_dir2_sf { xfs_dir2_sf_entry_t list[1]; /* shortform entries */ } xfs_dir2_sf_t; -#define XFS_DIR2_SF_HDR_SIZE(i8count) xfs_dir2_sf_hdr_size(i8count) -static inline int xfs_dir2_sf_hdr_size(int i8count) +static inline int XFS_DIR2_SF_HDR_SIZE(int i8count) { return ((uint)sizeof(xfs_dir2_sf_hdr_t) - \ ((i8count) == 0) * \ ((uint)sizeof(xfs_dir2_ino8_t) - (uint)sizeof(xfs_dir2_ino4_t))); } -#define XFS_DIR2_SF_INUMBERP(sfep) xfs_dir2_sf_inumberp(sfep) -static inline xfs_dir2_inou_t *xfs_dir2_sf_inumberp(xfs_dir2_sf_entry_t *sfep) +static inline xfs_dir2_inou_t *XFS_DIR2_SF_INUMBERP(xfs_dir2_sf_entry_t *sfep) { return (xfs_dir2_inou_t *)&(sfep)->name[(sfep)->namelen]; } -#define XFS_DIR2_SF_GET_INUMBER(sfp, from) \ - xfs_dir2_sf_get_inumber(sfp, from) static inline xfs_intino_t -xfs_dir2_sf_get_inumber(xfs_dir2_sf_t *sfp, xfs_dir2_inou_t *from) +XFS_DIR2_SF_GET_INUMBER(xfs_dir2_sf_t *sfp, xfs_dir2_inou_t *from) { return ((sfp)->hdr.i8count == 0 ? \ (xfs_intino_t)XFS_GET_DIR_INO4((from)->i4) : \ (xfs_intino_t)XFS_GET_DIR_INO8((from)->i8)); } -#define XFS_DIR2_SF_PUT_INUMBER(sfp,from,to) \ - xfs_dir2_sf_put_inumber(sfp,from,to) -static inline void xfs_dir2_sf_put_inumber(xfs_dir2_sf_t *sfp, xfs_ino_t *from, +static inline void XFS_DIR2_SF_PUT_INUMBER(xfs_dir2_sf_t *sfp, xfs_ino_t *from, xfs_dir2_inou_t *to) { if ((sfp)->hdr.i8count == 0) @@ -125,51 +119,41 @@ static inline void xfs_dir2_sf_put_inumb XFS_PUT_DIR_INO8(*(from), (to)->i8); } -#define XFS_DIR2_SF_GET_OFFSET(sfep) \ - xfs_dir2_sf_get_offset(sfep) static inline xfs_dir2_data_aoff_t -xfs_dir2_sf_get_offset(xfs_dir2_sf_entry_t *sfep) +XFS_DIR2_SF_GET_OFFSET(xfs_dir2_sf_entry_t *sfep) { return INT_GET_UNALIGNED_16_BE(&(sfep)->offset.i); } -#define XFS_DIR2_SF_PUT_OFFSET(sfep,off) \ - xfs_dir2_sf_put_offset(sfep,off) static inline void -xfs_dir2_sf_put_offset(xfs_dir2_sf_entry_t *sfep, xfs_dir2_data_aoff_t off) +XFS_DIR2_SF_PUT_OFFSET(xfs_dir2_sf_entry_t *sfep, xfs_dir2_data_aoff_t off) { INT_SET_UNALIGNED_16_BE(&(sfep)->offset.i, off); } -#define XFS_DIR2_SF_ENTSIZE_BYNAME(sfp,len) \ - xfs_dir2_sf_entsize_byname(sfp,len) -static inline int xfs_dir2_sf_entsize_byname(xfs_dir2_sf_t *sfp, int len) +static inline int XFS_DIR2_SF_ENTSIZE_BYNAME(xfs_dir2_sf_t *sfp, int len) { return ((uint)sizeof(xfs_dir2_sf_entry_t) - 1 + (len) - \ ((sfp)->hdr.i8count == 0) * \ ((uint)sizeof(xfs_dir2_ino8_t) - (uint)sizeof(xfs_dir2_ino4_t))); } -#define XFS_DIR2_SF_ENTSIZE_BYENTRY(sfp,sfep) \ - xfs_dir2_sf_entsize_byentry(sfp,sfep) static inline int -xfs_dir2_sf_entsize_byentry(xfs_dir2_sf_t *sfp, xfs_dir2_sf_entry_t *sfep) +XFS_DIR2_SF_ENTSIZE_BYENTRY(xfs_dir2_sf_t *sfp, xfs_dir2_sf_entry_t *sfep) { return ((uint)sizeof(xfs_dir2_sf_entry_t) - 1 + (sfep)->namelen - \ ((sfp)->hdr.i8count == 0) * \ ((uint)sizeof(xfs_dir2_ino8_t) - (uint)sizeof(xfs_dir2_ino4_t))); } -#define XFS_DIR2_SF_FIRSTENTRY(sfp) xfs_dir2_sf_firstentry(sfp) -static inline xfs_dir2_sf_entry_t *xfs_dir2_sf_firstentry(xfs_dir2_sf_t *sfp) +static inline xfs_dir2_sf_entry_t *XFS_DIR2_SF_FIRSTENTRY(xfs_dir2_sf_t *sfp) { return ((xfs_dir2_sf_entry_t *) \ ((char *)(sfp) + XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count))); } -#define XFS_DIR2_SF_NEXTENTRY(sfp,sfep) xfs_dir2_sf_nextentry(sfp,sfep) static inline xfs_dir2_sf_entry_t * -xfs_dir2_sf_nextentry(xfs_dir2_sf_t *sfp, xfs_dir2_sf_entry_t *sfep) +XFS_DIR2_SF_NEXTENTRY(xfs_dir2_sf_t *sfp, xfs_dir2_sf_entry_t *sfep) { return ((xfs_dir2_sf_entry_t *) \ ((char *)(sfep) + XFS_DIR2_SF_ENTSIZE_BYENTRY(sfp,sfep))); Index: xfs-linux-killwantfuncs/xfs_ialloc.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_ialloc.h +++ xfs-linux-killwantfuncs/xfs_ialloc.h @@ -43,9 +43,8 @@ struct xfs_trans; /* * Make an inode pointer out of the buffer/offset. */ -#define XFS_MAKE_IPTR(mp,b,o) xfs_make_iptr(mp,b,o) static inline struct xfs_dinode * -xfs_make_iptr(struct xfs_mount *mp, struct xfs_buf *b, int o) +XFS_MAKE_IPTR(struct xfs_mount *mp, struct xfs_buf *b, int o) { return (xfs_dinode_t *) (xfs_buf_offset(b, o << (mp)->m_sb.sb_inodelog)); @@ -54,8 +53,7 @@ xfs_make_iptr(struct xfs_mount *mp, stru /* * Find a free (set) bit in the inode bitmask. */ -#define XFS_IALLOC_FIND_FREE(fp) xfs_ialloc_find_free(fp) -static inline int xfs_ialloc_find_free(xfs_inofree_t *fp) +static inline int XFS_IALLOC_FIND_FREE(xfs_inofree_t *fp) { return xfs_lowbit64(*fp); } Index: xfs-linux-killwantfuncs/xfs_ialloc_btree.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_ialloc_btree.h +++ xfs-linux-killwantfuncs/xfs_ialloc_btree.h @@ -37,8 +37,7 @@ typedef __uint64_t xfs_inofree_t; #define XFS_INODES_PER_CHUNK_LOG (XFS_NBBYLOG + 3) #define XFS_INOBT_ALL_FREE ((xfs_inofree_t)-1) -#define XFS_INOBT_MASKN(i,n) xfs_inobt_maskn(i,n) -static inline xfs_inofree_t xfs_inobt_maskn(int i, int n) +static inline xfs_inofree_t XFS_INOBT_MASKN(int i, int n) { return (((n) >= XFS_INODES_PER_CHUNK ? \ (xfs_inofree_t)0 : ((xfs_inofree_t)1 << (n))) - 1) << (i); Index: xfs-linux-killwantfuncs/xfs_inode_item.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_inode_item.h +++ xfs-linux-killwantfuncs/xfs_inode_item.h @@ -148,22 +148,19 @@ typedef struct xfs_inode_log_item { } xfs_inode_log_item_t; -#define XFS_ILOG_FDATA(w) xfs_ilog_fdata(w) -static inline int xfs_ilog_fdata(int w) +static inline int XFS_ILOG_FDATA(int w) { return (w == XFS_DATA_FORK ? XFS_ILOG_DDATA : XFS_ILOG_ADATA); } #endif /* __KERNEL__ */ -#define XFS_ILOG_FBROOT(w) xfs_ilog_fbroot(w) -static inline int xfs_ilog_fbroot(int w) +static inline int XFS_ILOG_FBROOT(int w) { return (w == XFS_DATA_FORK ? XFS_ILOG_DBROOT : XFS_ILOG_ABROOT); } -#define XFS_ILOG_FEXT(w) xfs_ilog_fext(w) -static inline int xfs_ilog_fext(int w) +static inline int XFS_ILOG_FEXT(int w) { return (w == XFS_DATA_FORK ? XFS_ILOG_DEXT : XFS_ILOG_AEXT); } Index: xfs-linux-killwantfuncs/xfs_mount.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_mount.h +++ xfs-linux-killwantfuncs/xfs_mount.h @@ -526,36 +526,31 @@ xfs_preferred_iosize(xfs_mount_t *mp) /* * Macros for getting from mount to vfs and back. */ -#define XFS_MTOVFS(mp) xfs_mtovfs(mp) -static inline struct bhv_vfs *xfs_mtovfs(xfs_mount_t *mp) +static inline struct bhv_vfs *XFS_MTOVFS(xfs_mount_t *mp) { return bhvtovfs(&mp->m_bhv); } -#define XFS_BHVTOM(bdp) xfs_bhvtom(bdp) -static inline xfs_mount_t *xfs_bhvtom(bhv_desc_t *bdp) +static inline xfs_mount_t *XFS_BHVTOM(bhv_desc_t *bdp) { return (xfs_mount_t *)BHV_PDATA(bdp); } -#define XFS_VFSTOM(vfs) xfs_vfstom(vfs) -static inline xfs_mount_t *xfs_vfstom(bhv_vfs_t *vfs) +static inline xfs_mount_t *XFS_VFSTOM(bhv_vfs_t *vfs) { return XFS_BHVTOM(bhv_lookup(VFS_BHVHEAD(vfs), &xfs_vfsops)); } -#define XFS_DADDR_TO_AGNO(mp,d) xfs_daddr_to_agno(mp,d) static inline xfs_agnumber_t -xfs_daddr_to_agno(struct xfs_mount *mp, xfs_daddr_t d) +XFS_DADDR_TO_AGNO(struct xfs_mount *mp, xfs_daddr_t d) { xfs_daddr_t ld = XFS_BB_TO_FSBT(mp, d); do_div(ld, mp->m_sb.sb_agblocks); return (xfs_agnumber_t) ld; } -#define XFS_DADDR_TO_AGBNO(mp,d) xfs_daddr_to_agbno(mp,d) static inline xfs_agblock_t -xfs_daddr_to_agbno(struct xfs_mount *mp, xfs_daddr_t d) +XFS_DADDR_TO_AGBNO(struct xfs_mount *mp, xfs_daddr_t d) { xfs_daddr_t ld = XFS_BB_TO_FSBT(mp, d); return (xfs_agblock_t) do_div(ld, mp->m_sb.sb_agblocks); Index: xfs-linux-killwantfuncs/xfs_rw.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_rw.h +++ xfs-linux-killwantfuncs/xfs_rw.h @@ -54,17 +54,15 @@ struct xfs_mount; * file is a real time file or not, because the bmap code * does. */ -#define XFS_FSB_TO_DB(ip,fsb) xfs_fsb_to_db(ip,fsb) static inline xfs_daddr_t -xfs_fsb_to_db(struct xfs_inode *ip, xfs_fsblock_t fsb) +XFS_FSB_TO_DB(struct xfs_inode *ip, xfs_fsblock_t fsb) { return (((ip)->i_d.di_flags & XFS_DIFLAG_REALTIME) ? \ (xfs_daddr_t)XFS_FSB_TO_BB((ip)->i_mount, (fsb)) : \ XFS_FSB_TO_DADDR((ip)->i_mount, (fsb))); } -#define XFS_FSB_TO_DB_IO(io,fsb) xfs_fsb_to_db_io(io,fsb) static inline xfs_daddr_t -xfs_fsb_to_db_io(struct xfs_iocore *io, xfs_fsblock_t fsb) +XFS_FSB_TO_DB_IO(struct xfs_iocore *io, xfs_fsblock_t fsb) { return (((io)->io_flags & XFS_IOCORE_RT) ? \ XFS_FSB_TO_BB((io)->io_mount, (fsb)) : \ Index: xfs-linux-killwantfuncs/xfs_sb.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_sb.h +++ xfs-linux-killwantfuncs/xfs_sb.h @@ -212,9 +212,8 @@ typedef enum { #define XFS_SB_VERSION_NUM(sbp) ((sbp)->sb_versionnum & XFS_SB_VERSION_NUMBITS) -#define XFS_SB_GOOD_VERSION(sbp) xfs_sb_good_version(sbp) #ifdef __KERNEL__ -static inline int xfs_sb_good_version(xfs_sb_t *sbp) +static inline int XFS_SB_GOOD_VERSION(xfs_sb_t *sbp) { return (((sbp->sb_versionnum >= XFS_SB_VERSION_1) && \ (sbp->sb_versionnum <= XFS_SB_VERSION_3)) || \ @@ -225,7 +224,7 @@ static inline int xfs_sb_good_version(xf (sbp->sb_shared_vn <= XFS_SB_MAX_SHARED_VN))); } #else -static inline int xfs_sb_good_version(xfs_sb_t *sbp) +static inline int XFS_SB_GOOD_VERSION(xfs_sb_t *sbp) { return (((sbp->sb_versionnum >= XFS_SB_VERSION_1) && \ (sbp->sb_versionnum <= XFS_SB_VERSION_3)) || \ @@ -244,8 +243,7 @@ static inline int xfs_sb_good_version(xf ((XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ !((sbp)->sb_versionnum & ~XFS_SB_VERSION_OKSASHBITS))) -#define XFS_SB_VERSION_TONEW(v) xfs_sb_version_tonew(v) -static inline unsigned xfs_sb_version_tonew(unsigned v) +static inline unsigned XFS_SB_VERSION_TONEW(unsigned v) { return ((((v) == XFS_SB_VERSION_1) ? \ 0 : \ @@ -255,8 +253,7 @@ static inline unsigned xfs_sb_version_to XFS_SB_VERSION_4); } -#define XFS_SB_VERSION_TOOLD(v) xfs_sb_version_toold(v) -static inline unsigned xfs_sb_version_toold(unsigned v) +static inline unsigned XFS_SB_VERSION_TOOLD(unsigned v) { return (((v) & (XFS_SB_VERSION_QUOTABIT | XFS_SB_VERSION_ALIGNBIT)) ? \ 0 : \ @@ -267,8 +264,7 @@ static inline unsigned xfs_sb_version_to XFS_SB_VERSION_1))); } -#define XFS_SB_VERSION_HASATTR(sbp) xfs_sb_version_hasattr(sbp) -static inline int xfs_sb_version_hasattr(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASATTR(xfs_sb_t *sbp) { return ((sbp)->sb_versionnum == XFS_SB_VERSION_2) || \ ((sbp)->sb_versionnum == XFS_SB_VERSION_3) || \ @@ -276,8 +272,7 @@ static inline int xfs_sb_version_hasattr ((sbp)->sb_versionnum & XFS_SB_VERSION_ATTRBIT)); } -#define XFS_SB_VERSION_ADDATTR(sbp) xfs_sb_version_addattr(sbp) -static inline void xfs_sb_version_addattr(xfs_sb_t *sbp) +static inline void XFS_SB_VERSION_ADDATTR(xfs_sb_t *sbp) { (sbp)->sb_versionnum = (((sbp)->sb_versionnum == XFS_SB_VERSION_1) ? \ XFS_SB_VERSION_2 : \ @@ -286,31 +281,27 @@ static inline void xfs_sb_version_addatt (XFS_SB_VERSION_4 | XFS_SB_VERSION_ATTRBIT))); } -#define XFS_SB_VERSION_HASNLINK(sbp) xfs_sb_version_hasnlink(sbp) -static inline int xfs_sb_version_hasnlink(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASNLINK(xfs_sb_t *sbp) { return ((sbp)->sb_versionnum == XFS_SB_VERSION_3) || \ ((XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_NLINKBIT)); } -#define XFS_SB_VERSION_ADDNLINK(sbp) xfs_sb_version_addnlink(sbp) -static inline void xfs_sb_version_addnlink(xfs_sb_t *sbp) +static inline void XFS_SB_VERSION_ADDNLINK(xfs_sb_t *sbp) { (sbp)->sb_versionnum = ((sbp)->sb_versionnum <= XFS_SB_VERSION_2 ? \ XFS_SB_VERSION_3 : \ ((sbp)->sb_versionnum | XFS_SB_VERSION_NLINKBIT)); } -#define XFS_SB_VERSION_HASQUOTA(sbp) xfs_sb_version_hasquota(sbp) -static inline int xfs_sb_version_hasquota(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASQUOTA(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_QUOTABIT); } -#define XFS_SB_VERSION_ADDQUOTA(sbp) xfs_sb_version_addquota(sbp) -static inline void xfs_sb_version_addquota(xfs_sb_t *sbp) +static inline void XFS_SB_VERSION_ADDQUOTA(xfs_sb_t *sbp) { (sbp)->sb_versionnum = \ (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4 ? \ @@ -319,99 +310,85 @@ static inline void xfs_sb_version_addquo XFS_SB_VERSION_QUOTABIT)); } -#define XFS_SB_VERSION_HASALIGN(sbp) xfs_sb_version_hasalign(sbp) -static inline int xfs_sb_version_hasalign(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASALIGN(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_ALIGNBIT); } -#define XFS_SB_VERSION_SUBALIGN(sbp) xfs_sb_version_subalign(sbp) -static inline void xfs_sb_version_subalign(xfs_sb_t *sbp) +static inline void XFS_SB_VERSION_SUBALIGN(xfs_sb_t *sbp) { (sbp)->sb_versionnum = \ XFS_SB_VERSION_TOOLD((sbp)->sb_versionnum & ~XFS_SB_VERSION_ALIGNBIT); } -#define XFS_SB_VERSION_HASDALIGN(sbp) xfs_sb_version_hasdalign(sbp) -static inline int xfs_sb_version_hasdalign(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASDALIGN(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_DALIGNBIT); } -#define XFS_SB_VERSION_ADDDALIGN(sbp) xfs_sb_version_adddalign(sbp) -static inline int xfs_sb_version_adddalign(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_ADDDALIGN(xfs_sb_t *sbp) { return (sbp)->sb_versionnum = \ ((sbp)->sb_versionnum | XFS_SB_VERSION_DALIGNBIT); } -#define XFS_SB_VERSION_HASSHARED(sbp) xfs_sb_version_hasshared(sbp) -static inline int xfs_sb_version_hasshared(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASSHARED(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_SHAREDBIT); } -#define XFS_SB_VERSION_ADDSHARED(sbp) xfs_sb_version_addshared(sbp) -static inline int xfs_sb_version_addshared(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_ADDSHARED(xfs_sb_t *sbp) { return (sbp)->sb_versionnum = \ ((sbp)->sb_versionnum | XFS_SB_VERSION_SHAREDBIT); } -#define XFS_SB_VERSION_SUBSHARED(sbp) xfs_sb_version_subshared(sbp) -static inline int xfs_sb_version_subshared(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_SUBSHARED(xfs_sb_t *sbp) { return (sbp)->sb_versionnum = \ ((sbp)->sb_versionnum & ~XFS_SB_VERSION_SHAREDBIT); } -#define XFS_SB_VERSION_HASDIRV2(sbp) xfs_sb_version_hasdirv2(sbp) -static inline int xfs_sb_version_hasdirv2(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASDIRV2(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_DIRV2BIT); } -#define XFS_SB_VERSION_HASLOGV2(sbp) xfs_sb_version_haslogv2(sbp) -static inline int xfs_sb_version_haslogv2(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASLOGV2(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_LOGV2BIT); } -#define XFS_SB_VERSION_HASEXTFLGBIT(sbp) xfs_sb_version_hasextflgbit(sbp) -static inline int xfs_sb_version_hasextflgbit(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASEXTFLGBIT(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_EXTFLGBIT); } -#define XFS_SB_VERSION_ADDEXTFLGBIT(sbp) xfs_sb_version_addextflgbit(sbp) -static inline int xfs_sb_version_addextflgbit(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_ADDEXTFLGBIT(xfs_sb_t *sbp) { return (sbp)->sb_versionnum = \ ((sbp)->sb_versionnum | XFS_SB_VERSION_EXTFLGBIT); } -#define XFS_SB_VERSION_SUBEXTFLGBIT(sbp) xfs_sb_version_subextflgbit(sbp) -static inline int xfs_sb_version_subextflgbit(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_SUBEXTFLGBIT(xfs_sb_t *sbp) { return (sbp)->sb_versionnum = \ ((sbp)->sb_versionnum & ~XFS_SB_VERSION_EXTFLGBIT); } -#define XFS_SB_VERSION_HASSECTOR(sbp) xfs_sb_version_hassector(sbp) -static inline int xfs_sb_version_hassector(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASSECTOR(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_SECTORBIT); } -#define XFS_SB_VERSION_HASMOREBITS(sbp) xfs_sb_version_hasmorebits(sbp) -static inline int xfs_sb_version_hasmorebits(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASMOREBITS(xfs_sb_t *sbp) { return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ ((sbp)->sb_versionnum & XFS_SB_VERSION_MOREBITSBIT); @@ -427,15 +404,13 @@ static inline int xfs_sb_version_hasmore * ((sbp)->sb_features2 & XFS_SB_VERSION2_FUNBIT) */ -#define XFS_SB_VERSION_HASATTR2(sbp) xfs_sb_version_hasattr2(sbp) -static inline int xfs_sb_version_hasattr2(xfs_sb_t *sbp) +static inline int XFS_SB_VERSION_HASATTR2(xfs_sb_t *sbp) { return (XFS_SB_VERSION_HASMOREBITS(sbp)) && \ ((sbp)->sb_features2 & XFS_SB_VERSION2_ATTR2BIT); } -#define XFS_SB_VERSION_ADDATTR2(sbp) xfs_sb_version_addattr2(sbp) -static inline void xfs_sb_version_addattr2(xfs_sb_t *sbp) +static inline void XFS_SB_VERSION_ADDATTR2(xfs_sb_t *sbp) { ((sbp)->sb_versionnum = \ ((sbp)->sb_versionnum | XFS_SB_VERSION_MOREBITSBIT), \ Index: xfs-linux-killwantfuncs/xfs_trans.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_trans.h +++ xfs-linux-killwantfuncs/xfs_trans.h @@ -220,63 +220,53 @@ typedef struct xfs_log_item_chunk { * lic_unused to the right value (0 matches all free). The * lic_descs.lid_index values are set up as each desc is allocated. */ -#define XFS_LIC_INIT(cp) xfs_lic_init(cp) -static inline void xfs_lic_init(xfs_log_item_chunk_t *cp) +static inline void XFS_LIC_INIT(xfs_log_item_chunk_t *cp) { cp->lic_free = XFS_LIC_FREEMASK; } -#define XFS_LIC_INIT_SLOT(cp,slot) xfs_lic_init_slot(cp, slot) -static inline void xfs_lic_init_slot(xfs_log_item_chunk_t *cp, int slot) +static inline void XFS_LIC_INIT_SLOT(xfs_log_item_chunk_t *cp, int slot) { cp->lic_descs[slot].lid_index = (unsigned char)(slot); } -#define XFS_LIC_VACANCY(cp) xfs_lic_vacancy(cp) -static inline int xfs_lic_vacancy(xfs_log_item_chunk_t *cp) +static inline int XFS_LIC_VACANCY(xfs_log_item_chunk_t *cp) { return cp->lic_free & XFS_LIC_FREEMASK; } -#define XFS_LIC_ALL_FREE(cp) xfs_lic_all_free(cp) -static inline void xfs_lic_all_free(xfs_log_item_chunk_t *cp) +static inline void XFS_LIC_ALL_FREE(xfs_log_item_chunk_t *cp) { cp->lic_free = XFS_LIC_FREEMASK; } -#define XFS_LIC_ARE_ALL_FREE(cp) xfs_lic_are_all_free(cp) -static inline int xfs_lic_are_all_free(xfs_log_item_chunk_t *cp) +static inline int XFS_LIC_ARE_ALL_FREE(xfs_log_item_chunk_t *cp) { return ((cp->lic_free & XFS_LIC_FREEMASK) == XFS_LIC_FREEMASK); } -#define XFS_LIC_ISFREE(cp,slot) xfs_lic_isfree(cp,slot) -static inline int xfs_lic_isfree(xfs_log_item_chunk_t *cp, int slot) +static inline int XFS_LIC_ISFREE(xfs_log_item_chunk_t *cp, int slot) { return (cp->lic_free & (1 << slot)); } -#define XFS_LIC_CLAIM(cp,slot) xfs_lic_claim(cp,slot) -static inline void xfs_lic_claim(xfs_log_item_chunk_t *cp, int slot) +static inline void XFS_LIC_CLAIM(xfs_log_item_chunk_t *cp, int slot) { cp->lic_free &= ~(1 << slot); } -#define XFS_LIC_RELSE(cp,slot) xfs_lic_relse(cp,slot) -static inline void xfs_lic_relse(xfs_log_item_chunk_t *cp, int slot) +static inline void XFS_LIC_RELSE(xfs_log_item_chunk_t *cp, int slot) { cp->lic_free |= 1 << slot; } -#define XFS_LIC_SLOT(cp,slot) xfs_lic_slot(cp,slot) static inline xfs_log_item_desc_t * -xfs_lic_slot(xfs_log_item_chunk_t *cp, int slot) +XFS_LIC_SLOT(xfs_log_item_chunk_t *cp, int slot) { return &(cp->lic_descs[slot]); } -#define XFS_LIC_DESC_TO_SLOT(dp) xfs_lic_desc_to_slot(dp) -static inline int xfs_lic_desc_to_slot(xfs_log_item_desc_t *dp) +static inline int XFS_LIC_DESC_TO_SLOT(xfs_log_item_desc_t *dp) { return (uint)dp->lid_index; } @@ -288,9 +278,8 @@ static inline int xfs_lic_desc_to_slot(x * All of this yields the address of the chunk, which is * cast to a chunk pointer. */ -#define XFS_LIC_DESC_TO_CHUNK(dp) xfs_lic_desc_to_chunk(dp) static inline xfs_log_item_chunk_t * -xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) +XFS_LIC_DESC_TO_CHUNK(xfs_log_item_desc_t *dp) { return (xfs_log_item_chunk_t*) \ (((xfs_caddr_t)((dp) - (dp)->lid_index)) - \ --------------040402000908070606030002-- From owner-xfs@oss.sgi.com Sat Jul 29 00:50:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 00:50:54 -0700 (PDT) Received: from ds666.l4x.org (mail.trixing.net [87.230.125.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6T7oODW023278 for ; Sat, 29 Jul 2006 00:50:29 -0700 Received: from [192.168.1.3] (helo=[192.168.182.5]) by ds666.l4x.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.62) (envelope-from ) id 1G6jZw-0008BU-UE; Sat, 29 Jul 2006 09:49:45 +0200 Message-ID: <44CB1303.7010303@l4x.org> Date: Sat, 29 Jul 2006 09:49:23 +0200 From: Jan Dittmer User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: kernel CC: linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <44BF29CD.1000809@l4x.org> <44CB0BF7.6030204@idccenter.cn> In-Reply-To: <44CB0BF7.6030204@idccenter.cn> Content-Type: text/plain; charset=gb18030; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 192.168.1.3 X-SA-Exim-Mail-From: jdi@l4x.org Subject: Re: XFS Bug null pointer dereference in xfs_free_ag_extent X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on ds666.l4x.org) X-archive-position: 8484 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jdi@l4x.org Precedence: bulk X-list: xfs Content-Length: 4367 Lines: 95 kernel schrieb: > I have the same problem, but it seems not have a patch right now. > No, I got zero feedback, but let's cc the correct mailing list. I also filed bug 6877 at kernel.org Regards, Jan > Jan Dittmer wrote: > >> Got the following oops from xfs. Afterwards lots of processes in D >> state, probably trying to read the partition in question. Kernel >> 2.6.18-rc2 >> >> [196027.687020] BUG: unable to handle kernel NULL pointer dereference >> at virtual address 00000060 >> [196027.687216] printing eip: >> [196027.687273] c01acc00 >> [196027.687275] *pde = 00000000 >> [196027.687337] Oops: 0000 [#1] >> [196027.687395] SMP >> [196027.687458] Modules linked in: rfcomm l2cap bluetooth nfsd >> exportfs lockd nfs_acl sunrpc pppoe pppox ipv6 ppp_generic slhc >> twofish serpent aes blowfish sha256 crypto_null ipt_LOG ipt_recent >> ipt_TCPMSS xt_tcpmss xt_tcpudp xt_state iptable_filter ipt_MASQUERADE >> iptable_nat ip_tables x_tables dm_mod ip_nat_ftp ip_nat >> ip_conntrack_ftp ip_conntrack nfnetlink tun vfat fat loop lp eeprom >> i2c_dev i2c_isa usb_storage button processor ac e100 snd_seq_dummy >> snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq cx88_dvb >> cx88_vp3054_i2c mt352 dvb_pll or51132 video_buf_dvb dvb_core nxt200x >> isl6421 zl10353 cx24123 lgdt330x cx22702 cx8802 snd_via82xx >> firmware_class snd_ac97_codec cx2341x snd_ac97_bus cx88xx snd_pcm_oss >> ir_common snd_mixer_oss video_buf tveeprom compat_ioctl32 snd_pcm >> snd_timer snd_page_alloc snd_mpu401_uart via_agp btcx_risc snd_rawmidi >> snd_seq_device videodev agpgart v4l1_compat snd ehci_hcd via_rhine >> v4l2_common uhci_hcd soundcore usbcore parport_pc parport floppy rtc >> [196027.690285] CPU: 0 >> [196027.690286] EIP: 0060:[] Not tainted VLI >> [196027.690288] EFLAGS: 00210293 (2.6.18-rc2-ds666-via #9) >> [196027.690545] EIP is at xfs_btree_init_cursor+0x2f/0x171 >> [196027.690645] eax: d42b3834 ebx: de835000 ecx: d42b3834 edx: >> 0000008c >> [196027.690771] esi: 00000000 edi: cb701038 ebp: 00000000 esp: >> cfb20c68 >> [196027.690896] ds: 007b es: 007b ss: 0068 >> [196027.690978] Process imap (pid: 14978, ti=cfb20000 task=d4d5a570 >> task.ti=cfb20000) >> [196027.691119] Stack: 00000000 00000017 cb701038 00000017 c0193c67 >> 00000005 00000000 00000000 >> [196027.691389] 00000000 00000005 00000000 cb701038 cd848f04 >> de835000 0000007a 00000000 >> [196027.692097] 0004e1d8 df2e18e0 de835000 df2e18e0 c01c9645 >> 00000000 00000017 cb701038 >> [196027.692805] Call Trace: >> [196027.693104] [] xfs_free_ag_extent+0x32/0x5e2 >> [196027.693445] [] xlog_grant_push_ail+0x30/0xfe >> [196027.693771] [] xfs_free_extent+0xbc/0xd9 >> [196027.694094] [] xfs_log_reserve+0x60/0x5a8 >> [196027.694436] [] xfs_efd_init+0x2f/0x5a >> [196027.694741] [] xfs_bmap_finish+0xe6/0x167 >> [196027.695070] [] xfs_rename+0x866/0xa33 >> [196027.695412] [] xfs_vn_rename+0x24/0x64 >> [196027.695707] [] mntput_no_expire+0x11/0x5d >> [196027.696029] [] link_path_walk+0xb3/0xbd >> [196027.696356] [] pagevec_lookup_tag+0x1b/0x22 >> [196027.696681] [] kstrdup+0x26/0x60 >> [196027.696993] [] vfs_rename+0x1b6/0x2ef >> [196027.697313] [] __lookup_hash+0x4a/0xc5 >> [196027.697632] [] sys_renameat+0x155/0x1b9 >> [196027.697961] [] pagevec_lookup_tag+0x1b/0x22 >> [196027.698281] [] wait_on_page_writeback_range+0xa6/0xf1 >> [196027.698637] [] xfs_file_fsync+0x3f/0x48 >> [196027.698953] [] sys_rename+0x11/0x15 >> [196027.699265] [] sysenter_past_esp+0x56/0x79 >> [196027.699600] Code: 89 d7 ba 01 00 00 00 56 53 89 c3 8b 74 24 18 a1 >> c8 86 4a c0 e8 2b 13 03 00 83 fe 02 89 c1 74 16 72 09 31 c0 83 fe 03 >> 75 78 eb 51 <8b> 45 60 8b 44 b0 1c 0f c8 eb 6b 83 7c 24 20 00 75 09 8b >> 44 24 >> [196027.701445] EIP: [] xfs_btree_init_cursor+0x2f/0x171 >> SS:ESP 0068:cfb20c68 >> [196027.705801] >> >> Jan >> - >> To unsubscribe from this list: send the line "unsubscribe >> linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > From owner-xfs@oss.sgi.com Sat Jul 29 05:57:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 05:58:07 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms1.lichtvoll.de [194.150.191.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6TCvqDW029184 for ; Sat, 29 Jul 2006 05:57:53 -0700 Received: from localhost (dslb-084-056-097-058.pools.arcor-ip.net [84.56.97.58]) by mondschein.lichtvoll.de (Postfix) with ESMTP id C4ACBFA50A for ; Sat, 29 Jul 2006 14:57:08 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: Problem with xfs_repair Date: Sat, 29 Jul 2006 14:57:19 +0200 User-Agent: KMail/1.9.3 References: <20060728064505.GA14714@charite.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607291457.20760.Martin@lichtvoll.de> X-archive-position: 8486 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1148 Lines: 32 Am Freitag 28 Juli 2006 16:23 schrieb Justin Piszcz: > > Is your knoppix boot cd 5.0.1 == 2.6.17 == bugged kernel? ;P > > When repairing, do not use knoppix 5.0.1 or any version that uses > 2.6.17 either.. Hello Justin, since xfs_repair works independently of the in-kernel XFS implementation it is possible to repair a directory-corruption broken XFS filesystem with Knoppix 5.0.1. It did so already. I used 5.0.1 to rsync a workstation image and sure it had this slight corruption afterwards. Thus I xfs_repair'ed it and xfs_check'ed it afterwards and all was well again. No this is not a recommendation to use Knoppix 5.0.1 to rsync an workstation image ;), but an xfs_repair should be possible (unless one hits the unfixable bug). Important: When XFS needs to be mounted first before repair in order to clean the log it might not be wise to use Knoppix 5.0.1 tough. BTW when using Knoppix 5 or even an older version instead I recommend switching off the write cache to be on the safe side (hdparm -W0). Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sat Jul 29 09:55:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 09:56:01 -0700 (PDT) Received: from slimak.dkm.cz (slimak.dkm.cz [62.24.64.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6TGtoDW029359 for ; Sat, 29 Jul 2006 09:55:50 -0700 Received: (qmail 63661 invoked by uid 0); 29 Jul 2006 15:55:21 -0000 Received: from r5cw78.chello.upc.cz (HELO reykjavik) (86.49.112.78) by slimak.dkm.cz with SMTP; 29 Jul 2006 15:55:21 -0000 From: =?iso-8859-2?Q?Ladislav_Durch=E1nek?= To: Subject: FW: Tree Quota error message suggestion Date: Sat, 29 Jul 2006 17:55:46 +0200 Message-ID: <018f01c6b327$74523980$0201a8c0@reykjavik> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcazJyV5LZ/HZSWNQti5XP6oYojV8AAACKEQ Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-archive-position: 8488 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: durchanek@gmail.com Precedence: bulk X-list: xfs Content-Length: 986 Lines: 44 I forgot, i'm using XFS on Linux 2.6.17 Gentoo. =20 L=E1=EFa =20 _____=20=20 From: Ladislav Durch=E1nek [mailto:durchanek@gmail.com]=20 Sent: Saturday, July 29, 2006 5:54 PM To: 'xfs@oss.sgi.com' Subject: Tree Quota error message suggestion =20 Hi everybody, First at all I have to say that XFS is great. Especially its built-in quota support is really nice thing. I found tree quotas extremely useful for hosting servers where uploaded files are created with other owner than customer is. =20 But there is a one thing which could be done better I think: When I define tree quota and user tries to exceed id, error message returned is "No space left on device" which is not true - there is a plenty of space on device. Only when quota is totally full, next message is "Disk quota exceeded". I think it should be better if first message will be also "Disk quota exceeded". =20 Cheers =20 L=E1=EFa Durch=E1nek [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Jul 29 09:53:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 09:53:48 -0700 (PDT) Received: from slimak.dkm.cz (slimak.dkm.cz [62.24.64.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6TGrYDW029042 for ; Sat, 29 Jul 2006 09:53:35 -0700 Received: (qmail 40309 invoked by uid 0); 29 Jul 2006 15:53:09 -0000 Received: from r5cw78.chello.upc.cz (HELO reykjavik) (86.49.112.78) by slimak.dkm.cz with SMTP; 29 Jul 2006 15:53:09 -0000 From: =?iso-8859-2?Q?Ladislav_Durch=E1nek?= To: Subject: Tree Quota error message suggestion Date: Sat, 29 Jul 2006 17:53:34 +0200 Message-ID: <018a01c6b327$25bc6d40$0201a8c0@reykjavik> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcazJyV5LZ/HZSWNQti5XP6oYojV8A== Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-archive-position: 8487 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: durchanek@gmail.com Precedence: bulk X-list: xfs Content-Length: 720 Lines: 27 Hi everybody, First at all I have to say that XFS is great. Especially its built-in quota support is really nice thing. I found tree quotas extremely useful for hosting servers where uploaded files are created with other owner than customer is. =20 But there is a one thing which could be done better I think: When I define tree quota and user tries to exceed id, error message returned is "No space left on device" which is not true - there is a plenty of space on device. Only when quota is totally full, next message is "Disk quota exceeded". I think it should be better if first message will be also "Disk quota exceeded". =20 Cheers =20 L=E1=EFa Durch=E1nek [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Jul 29 12:27:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 12:27:26 -0700 (PDT) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6TJR9DW018846 for ; Sat, 29 Jul 2006 12:27:11 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id A45B3C189E26 for ; Sun, 30 Jul 2006 02:18:01 +0800 (PHT) Received: from musang.free.net.ph (unknown [203.177.91.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 27662C189E29 for ; Sun, 30 Jul 2006 02:17:55 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 2F6C920144E9; Sun, 30 Jul 2006 02:17:50 +0800 (PHT) Date: Sun, 30 Jul 2006 02:17:50 +0800 From: Federico Sevilla III To: xfs@oss.sgi.com Subject: Re: FW: Tree Quota error message suggestion Message-ID: <20060729181750.GA3520@free.net.ph> Mail-Followup-To: xfs@oss.sgi.com References: <018f01c6b327$74523980$0201a8c0@reykjavik> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <018f01c6b327$74523980$0201a8c0@reykjavik> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.11 X-archive-position: 8489 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: xfs Content-Length: 370 Lines: 14 On Sat, Jul 29, 2006 at 05:55:46PM +0200, Ladislav Durchánek wrote: > I forgot, i'm using XFS on Linux 2.6.17 Gentoo. You may want to upgrade to 2.6.17.7 ASAP. See for why. --> Jijo -- Federico Vicente C. Sevilla III Information Technology Consultant Q Software Research Corporation Website: http://jijo.free.net.ph From owner-xfs@oss.sgi.com Sat Jul 29 13:22:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 13:23:23 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6TKMtDW026332 for ; Sat, 29 Jul 2006 13:22:56 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id 6E47E220A3B; Sat, 29 Jul 2006 22:22:26 +0200 (CEST) Received: from mail.charite.de ([127.0.0.1]) by localhost (mail.charite.de [127.0.0.1]) (amavisd-new, port 10025) with LMTP id AYYT9FqRDbGo; Sat, 29 Jul 2006 22:22:24 +0200 (CEST) Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id 786A3220A4A; Sat, 29 Jul 2006 22:22:24 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id 4C148220AB5; Sat, 29 Jul 2006 22:22:24 +0200 (CEST) Date: Sat, 29 Jul 2006 22:22:24 +0200 From: Ralf Hildebrandt To: Nathan Scott Cc: Christian Kujau , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 Message-ID: <20060729202223.GD20039@charite.de> Mail-Followup-To: Nathan Scott , Christian Kujau , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <20060724090138.C2083275@wobbly.melbourne.sgi.com> <20060729074803.A2222647@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: <20060729074803.A2222647@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 8490 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: xfs Content-Length: 1060 Lines: 27 * Nathan Scott : > Barry sent an xfs_repair patch to resolve this issue to the xfs@oss.sgi.com > list yesterday; please give that a go and let us know how it fares. Just to let you know, I did a cvs checkout of xfs-cmds as described on http://oss.sgi.com/projects/xfs/source.html Then I saved the patch from http://oss.sgi.com/archives/xfs/2006-07/msg00374.html using the "Original" link on hat page. I build a xfs_Repair binary using that, transferred it onto an old KLAX boot cd I had and repaired the XFS root on my laptop. I got 5000 files in lost and found, mostly the whole manpages from my system. Had to reinstall a few packages to restore lost binaries, but that's all. When will that horrible bug be fixed in 2.6.x? -- Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to spamtrap@charite.de From owner-xfs@oss.sgi.com Sat Jul 29 14:25:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 14:26:12 -0700 (PDT) Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6TLPqDW002889 for ; Sat, 29 Jul 2006 14:25:57 -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 525A0F95F; Sat, 29 Jul 2006 22:08:26 +0200 (CEST) To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] kill leftover WANT_FUNCS macro indirection References: <44CAE247.6020608@sandeen.net> From: Andi Kleen Date: 29 Jul 2006 22:08:21 +0200 In-Reply-To: <44CAE247.6020608@sandeen.net> 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: 8491 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: 268 Lines: 9 Eric Sandeen writes: > This gets rid of some pointless macro defines... I had a version that > lower-cased it all too but Nathan liked this better, and he's the man! > :) Shouted function names is not exactly Linux code style at least. -Andi From owner-xfs@oss.sgi.com Sat Jul 29 15:23:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 15:24:54 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6TMNTDW010676 for ; Sat, 29 Jul 2006 15:23:29 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id BFFC81806631D; Sat, 29 Jul 2006 17:23:02 -0500 (CDT) Message-ID: <44CBDFC9.3040202@sandeen.net> Date: Sat, 29 Jul 2006 17:23:05 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Andi Kleen , xfs@oss.sgi.com Subject: Re: [PATCH] kill leftover WANT_FUNCS macro indirection References: <44CAE247.6020608@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8492 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 605 Lines: 22 Andi Kleen wrote: > Eric Sandeen writes: > >> This gets rid of some pointless macro defines... I had a version that >> lower-cased it all too but Nathan liked this better, and he's the man! >> :) > > Shouted function names is not exactly Linux code style at least. > > -Andi > well, *shrug* I have both versions, Nathan can take his pick :) honestly, one-liner static inlines isn't exactly linux code style either, tho the typechecking is nice. I guess I shouldn't have said "Nathan liked this better" - I think he was being pragmatic about the scope of the change. -Eric From owner-xfs@oss.sgi.com Sat Jul 29 16:37:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 16:37:58 -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 k6TNbKDW024027 for ; Sat, 29 Jul 2006 16:37:32 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA00948; Sun, 30 Jul 2006 08:28:18 +1000 Message-ID: <44CBE0F5.3050201@melbourne.sgi.com> Date: Sun, 30 Jul 2006 08:28:05 +1000 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nathan Scott , Christian Kujau , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS breakage in 2.6.18-rc1 References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <20060724090138.C2083275@wobbly.melbourne.sgi.com> <20060729074803.A2222647@wobbly.melbourne.sgi.com> <20060729202223.GD20039@charite.de> In-Reply-To: <20060729202223.GD20039@charite.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8493 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 856 Lines: 29 Ralf Hildebrandt wrote: > * Nathan Scott : > >> Barry sent an xfs_repair patch to resolve this issue to the xfs@oss.sgi.com >> list yesterday; please give that a go and let us know how it fares. > > Just to let you know, I did a cvs checkout of xfs-cmds > as described on http://oss.sgi.com/projects/xfs/source.html > > Then I saved the patch from > http://oss.sgi.com/archives/xfs/2006-07/msg00374.html using the > "Original" link on hat page. > > I build a xfs_Repair binary using that, transferred it onto an old > KLAX boot cd I had and repaired the XFS root on my laptop. > > I got 5000 files in lost and found, mostly the whole manpages from my > system. Had to reinstall a few packages to restore lost binaries, but > that's all. > > When will that horrible bug be fixed in 2.6.x? > The bug is fixed in 2.6.17.7. David From owner-xfs@oss.sgi.com Sat Jul 29 20:41:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 20:41:43 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6U3fVDW028897 for ; Sat, 29 Jul 2006 20:41:31 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A79FC18DE2F33 for ; Sat, 29 Jul 2006 22:41:06 -0500 (CDT) Message-ID: <44CC2A55.6030207@sandeen.net> Date: Sat, 29 Jul 2006 22:41:09 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] kill no-op buf macros Content-Type: multipart/mixed; boundary="------------060303000702070608060508" X-archive-position: 8495 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 15627 Lines: 490 This is a multi-part message in MIME format. --------------060303000702070608060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It looks like these macros are not particularly interesting... this patch kills them. #define XFS_BUF_BUSY(bp) do { } while (0) #define XFS_BUF_ISBUSY(bp) (1) #define XFS_BUF_SHUT(bp) do { } while (0) #define XFS_BUF_UNSHUT(bp) do { } while (0) #define XFS_BUF_ISSHUT(bp) (0) #define XFS_BUF_ISUNINITIAL(bp) (0) #define XFS_BUF_BP_ISMAPPED(bp) (1) #define XFS_BUF_SET_START(bp) do { } while (0) #define XFS_BUF_SET_VTYPE_REF(bp, type, ref) do { } while (0) #define XFS_BUF_SET_VTYPE(bp, type) do { } while (0) #define XFS_BUF_SET_REF(bp, ref) do { } while (0) Thanks, -Eric --------------060303000702070608060508 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="kill-buf-macros" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kill-buf-macros" linux-2.6/xfs_buf.h | 16 ---------------- quota/xfs_dquot.c | 7 ------- xfs_alloc.c | 2 -- xfs_btree.c | 13 ------------- xfs_buf_item.c | 20 +------------------- xfs_da_btree.c | 9 --------- xfs_ialloc.c | 1 - xfs_inode.c | 13 ------------- xfs_log.c | 4 ---- xfs_log_recover.c | 2 -- xfs_mount.c | 2 -- xfs_trans_buf.c | 9 --------- 12 files changed, 1 insertion(+), 97 deletions(-) Signed-Off-By: Eric Sandeen Index: xfs-linux-killwantfuncs/linux-2.6/xfs_buf.h =================================================================== --- xfs-linux-killwantfuncs.orig/linux-2.6/xfs_buf.h +++ xfs-linux-killwantfuncs/linux-2.6/xfs_buf.h @@ -274,9 +274,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_UNDONE(bp) ((bp)->b_flags &= ~XBF_DONE) #define XFS_BUF_ISDONE(bp) ((bp)->b_flags & XBF_DONE) -#define XFS_BUF_BUSY(bp) do { } while (0) -#define XFS_BUF_ISBUSY(bp) (1) - #define XFS_BUF_ASYNC(bp) ((bp)->b_flags |= XBF_ASYNC) #define XFS_BUF_UNASYNC(bp) ((bp)->b_flags &= ~XBF_ASYNC) #define XFS_BUF_ISASYNC(bp) ((bp)->b_flags & XBF_ASYNC) @@ -284,10 +281,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_ORDERED(bp) ((bp)->b_flags |= XBF_ORDERED) #define XFS_BUF_UNORDERED(bp) ((bp)->b_flags &= ~XBF_ORDERED) -#define XFS_BUF_SHUT(bp) do { } while (0) -#define XFS_BUF_UNSHUT(bp) do { } while (0) -#define XFS_BUF_ISSHUT(bp) (0) - #define XFS_BUF_HOLD(bp) xfs_buf_hold(bp) #define XFS_BUF_READ(bp) ((bp)->b_flags |= XBF_READ) #define XFS_BUF_UNREAD(bp) ((bp)->b_flags &= ~XBF_READ) @@ -296,10 +289,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_WRITE(bp) ((bp)->b_flags |= XBF_WRITE) #define XFS_BUF_UNWRITE(bp) ((bp)->b_flags &= ~XBF_WRITE) -#define XFS_BUF_ISUNINITIAL(bp) (0) - -#define XFS_BUF_BP_ISMAPPED(bp) (1) - #define XFS_BUF_IODONE_FUNC(bp) ((bp)->b_iodone) #define XFS_BUF_SET_IODONE_FUNC(bp, func) ((bp)->b_iodone = (func)) #define XFS_BUF_CLR_IODONE_FUNC(bp) ((bp)->b_iodone = NULL) @@ -312,7 +301,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_SET_FSPRIVATE2(bp, val) ((bp)->b_fspriv2 = (void*)(val)) #define XFS_BUF_FSPRIVATE3(bp, type) ((type)(bp)->b_fspriv3) #define XFS_BUF_SET_FSPRIVATE3(bp, val) ((bp)->b_fspriv3 = (void*)(val)) -#define XFS_BUF_SET_START(bp) do { } while (0) #define XFS_BUF_SET_BRELSE_FUNC(bp, func) ((bp)->b_relse = (func)) #define XFS_BUF_PTR(bp) (xfs_caddr_t)((bp)->b_addr) @@ -323,10 +311,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_SET_COUNT(bp, cnt) ((bp)->b_count_desired = (cnt)) #define XFS_BUF_SIZE(bp) ((bp)->b_buffer_length) -#define XFS_BUF_SET_VTYPE_REF(bp, type, ref) do { } while (0) -#define XFS_BUF_SET_VTYPE(bp, type) do { } while (0) -#define XFS_BUF_SET_REF(bp, ref) do { } while (0) - #define XFS_BUF_ISPINNED(bp) xfs_buf_ispin(bp) #define XFS_BUF_VALUSEMA(bp) xfs_buf_lock_value(bp) Index: xfs-linux-killwantfuncs/quota/xfs_dquot.c =================================================================== --- xfs-linux-killwantfuncs.orig/quota/xfs_dquot.c +++ xfs-linux-killwantfuncs/quota/xfs_dquot.c @@ -369,7 +369,6 @@ xfs_qm_init_dquot_blk( int curid, i; ASSERT(tp); - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); d = (xfs_dqblk_t *)XFS_BUF_PTR(bp); @@ -609,7 +608,6 @@ xfs_qm_dqtobp( if (error || !bp) return XFS_ERROR(error); } - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); /* @@ -627,7 +625,6 @@ xfs_qm_dqtobp( xfs_trans_brelse(tp, bp); return XFS_ERROR(EIO); } - XFS_BUF_BUSY(bp); /* We dirtied this */ } *O_bpp = bp; @@ -680,9 +677,6 @@ xfs_qm_dqread( dqp->q_res_icount = be64_to_cpu(ddqp->d_icount); dqp->q_res_rtbcount = be64_to_cpu(ddqp->d_rtbcount); - /* Mark the buf so that this will stay incore a little longer */ - XFS_BUF_SET_VTYPE_REF(bp, B_FS_DQUOT, XFS_DQUOT_REF); - /* * We got the buffer with a xfs_trans_read_buf() (in dqtobp()) * So we need to release with xfs_trans_brelse(). @@ -695,7 +689,6 @@ xfs_qm_dqread( * this particular dquot was repaired. We still aren't afraid to * brelse it because we have the changes incore. */ - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); xfs_trans_brelse(tp, bp); Index: xfs-linux-killwantfuncs/xfs_alloc.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_alloc.c +++ xfs-linux-killwantfuncs/xfs_alloc.c @@ -409,7 +409,6 @@ xfs_alloc_read_agfl( return error; ASSERT(bp); ASSERT(!XFS_BUF_GETERROR(bp)); - XFS_BUF_SET_VTYPE_REF(bp, B_FS_AGFL, XFS_AGFL_REF); *bpp = bp; return 0; } @@ -2206,7 +2205,6 @@ xfs_alloc_read_agf( be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNTi])); } #endif - XFS_BUF_SET_VTYPE_REF(bp, B_FS_AGF, XFS_AGF_REF); *bpp = bp; return 0; } Index: xfs-linux-killwantfuncs/xfs_btree.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_btree.c +++ xfs-linux-killwantfuncs/xfs_btree.c @@ -759,9 +759,6 @@ xfs_btree_read_bufl( return error; } ASSERT(!bp || !XFS_BUF_GETERROR(bp)); - if (bp != NULL) { - XFS_BUF_SET_VTYPE_REF(bp, B_FS_MAP, refval); - } *bpp = bp; return 0; } @@ -792,16 +789,6 @@ xfs_btree_read_bufs( return error; } ASSERT(!bp || !XFS_BUF_GETERROR(bp)); - if (bp != NULL) { - switch (refval) { - case XFS_ALLOC_BTREE_REF: - XFS_BUF_SET_VTYPE_REF(bp, B_FS_MAP, refval); - break; - case XFS_INO_BTREE_REF: - XFS_BUF_SET_VTYPE_REF(bp, B_FS_INOMAP, refval); - break; - } - } *bpp = bp; return 0; } Index: xfs-linux-killwantfuncs/xfs_buf_item.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_buf_item.c +++ xfs-linux-killwantfuncs/xfs_buf_item.c @@ -234,7 +234,6 @@ xfs_buf_item_format( ASSERT((bip->bli_flags & XFS_BLI_LOGGED) || (bip->bli_flags & XFS_BLI_STALE)); bp = bip->bli_buf; - ASSERT(XFS_BUF_BP_ISMAPPED(bp)); vecp = log_vector; /* @@ -351,7 +350,6 @@ xfs_buf_item_pin( xfs_buf_t *bp; bp = bip->bli_buf; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(atomic_read(&bip->bli_refcount) > 0); ASSERT((bip->bli_flags & XFS_BLI_LOGGED) || (bip->bli_flags & XFS_BLI_STALE)); @@ -901,7 +899,6 @@ xfs_buf_item_relse( XFS_BUF_SET_FSPRIVATE(bp, bip->bli_item.li_bio_list); if ((XFS_BUF_FSPRIVATE(bp, void *) == NULL) && (XFS_BUF_IODONE_FUNC(bp) != NULL)) { - ASSERT((XFS_BUF_ISUNINITIAL(bp)) == 0); XFS_BUF_CLR_IODONE_FUNC(bp); } @@ -936,7 +933,6 @@ xfs_buf_attach_iodone( { xfs_log_item_t *head_lip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); lip->li_cb = cb; @@ -1008,20 +1004,7 @@ xfs_buf_iodone_callbacks( xfs_buf_do_callbacks(bp, lip); XFS_BUF_SET_FSPRIVATE(bp, NULL); XFS_BUF_CLR_IODONE_FUNC(bp); - - /* - * XFS_SHUT flag gets set when we go thru the - * entire buffer cache and deliberately start - * throwing away delayed write buffers. - * Since there's no biowait done on those, - * we should just brelse them. - */ - if (XFS_BUF_ISSHUT(bp)) { - XFS_BUF_UNSHUT(bp); - xfs_buf_relse(bp); - } else { - xfs_biodone(bp); - } + xfs_biodone(bp); return; } @@ -1051,7 +1034,6 @@ xfs_buf_iodone_callbacks( if (!(XFS_BUF_ISSTALE(bp))) { XFS_BUF_DELAYWRITE(bp); XFS_BUF_DONE(bp); - XFS_BUF_SET_START(bp); } ASSERT(XFS_BUF_IODONE_FUNC(bp)); xfs_buftrace("BUF_IODONE ASYNC", bp); Index: xfs-linux-killwantfuncs/xfs_da_btree.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_da_btree.c +++ xfs-linux-killwantfuncs/xfs_da_btree.c @@ -2033,15 +2033,6 @@ xfs_da_do_buf( } if (!bp) continue; - if (caller == 1) { - if (whichfork == XFS_ATTR_FORK) { - XFS_BUF_SET_VTYPE_REF(bp, B_FS_ATTR_BTREE, - XFS_ATTR_BTREE_REF); - } else { - XFS_BUF_SET_VTYPE_REF(bp, B_FS_DIR_BTREE, - XFS_DIR_BTREE_REF); - } - } if (bplist) { bplist[nbplist++] = bp; } Index: xfs-linux-killwantfuncs/xfs_ialloc.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_ialloc.c +++ xfs-linux-killwantfuncs/xfs_ialloc.c @@ -1405,7 +1405,6 @@ xfs_ialloc_read_agi( } #endif - XFS_BUF_SET_VTYPE_REF(bp, B_FS_AGI, XFS_AGI_REF); *bpp = bp; return 0; } Index: xfs-linux-killwantfuncs/xfs_inode.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_inode.c +++ xfs-linux-killwantfuncs/xfs_inode.c @@ -369,11 +369,6 @@ xfs_itobp( xfs_inobp_check(mp, bp); /* - * Mark the buffer as an inode buffer now that it looks good - */ - XFS_BUF_SET_VTYPE(bp, B_FS_INO); - - /* * Set *dipp to point to the on-disk inode in the buffer. */ *dipp = (xfs_dinode_t *)xfs_buf_offset(bp, imap.im_boffset); @@ -978,13 +973,6 @@ xfs_iread( ip->i_delayed_blks = 0; /* - * Mark the buffer containing the inode as something to keep - * around for a while. This helps to keep recently accessed - * meta-data in-core longer. - */ - XFS_BUF_SET_REF(bp, XFS_INO_REF); - - /* * Use xfs_trans_brelse() to release the buffer containing the * on-disk inode, because it was acquired with xfs_trans_read_buf() * in xfs_itobp() above. If tp is NULL, this is just a normal @@ -3233,7 +3221,6 @@ cluster_corrupt_out: XFS_BUF_CLR_BDSTRAT_FUNC(bp); XFS_BUF_UNDONE(bp); XFS_BUF_STALE(bp); - XFS_BUF_SHUT(bp); XFS_BUF_ERROR(bp,EIO); xfs_biodone(bp); } else { Index: xfs-linux-killwantfuncs/xfs_log.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_log.c +++ xfs-linux-killwantfuncs/xfs_log.c @@ -1169,7 +1169,6 @@ xlog_alloc_log(xfs_mount_t *mp, XFS_BUF_SET_IODONE_FUNC(bp, xlog_iodone); XFS_BUF_SET_BDSTRAT_FUNC(bp, xlog_bdstrat_cb); XFS_BUF_SET_FSPRIVATE2(bp, (unsigned long)1); - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); log->l_xbuf = bp; @@ -1224,7 +1223,6 @@ xlog_alloc_log(xfs_mount_t *mp, iclog->ic_callback_tail = &(iclog->ic_callback); iclog->ic_datap = (char *)iclog->hic_data + log->l_iclog_hsize; - ASSERT(XFS_BUF_ISBUSY(iclog->ic_bp)); ASSERT(XFS_BUF_VALUSEMA(iclog->ic_bp) <= 0); sv_init(&iclog->ic_forcesema, SV_DEFAULT, "iclog-force"); sv_init(&iclog->ic_writesema, SV_DEFAULT, "iclog-write"); @@ -1430,7 +1428,6 @@ xlog_sync(xlog_t *log, } XFS_BUF_SET_PTR(bp, (xfs_caddr_t) &(iclog->ic_header), count); XFS_BUF_SET_FSPRIVATE(bp, iclog); /* save for later */ - XFS_BUF_BUSY(bp); XFS_BUF_ASYNC(bp); /* * Do an ordered write for the log block. @@ -1468,7 +1465,6 @@ xlog_sync(xlog_t *log, XFS_BUF_SET_PTR(bp, (xfs_caddr_t)((__psint_t)&(iclog->ic_header)+ (__psint_t)count), split); XFS_BUF_SET_FSPRIVATE(bp, iclog); - XFS_BUF_BUSY(bp); XFS_BUF_ASYNC(bp); if (log->l_mp->m_flags & XFS_MOUNT_BARRIER) XFS_BUF_ORDERED(bp); Index: xfs-linux-killwantfuncs/xfs_log_recover.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_log_recover.c +++ xfs-linux-killwantfuncs/xfs_log_recover.c @@ -115,7 +115,6 @@ xlog_bread( XFS_BUF_SET_ADDR(bp, log->l_logBBstart + blk_no); XFS_BUF_READ(bp); - XFS_BUF_BUSY(bp); XFS_BUF_SET_COUNT(bp, BBTOB(nbblks)); XFS_BUF_SET_TARGET(bp, log->l_mp->m_logdev_targp); @@ -150,7 +149,6 @@ xlog_bwrite( XFS_BUF_SET_ADDR(bp, log->l_logBBstart + blk_no); XFS_BUF_ZEROFLAGS(bp); - XFS_BUF_BUSY(bp); XFS_BUF_HOLD(bp); XFS_BUF_PSEMA(bp, PRIBIO); XFS_BUF_SET_COUNT(bp, BBTOB(nbblks)); Index: xfs-linux-killwantfuncs/xfs_mount.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_mount.c +++ xfs-linux-killwantfuncs/xfs_mount.c @@ -499,7 +499,6 @@ xfs_readsb(xfs_mount_t *mp, int flags) error = bp ? XFS_BUF_GETERROR(bp) : ENOMEM; goto fail; } - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); /* @@ -541,7 +540,6 @@ xfs_readsb(xfs_mount_t *mp, int flags) error = bp ? XFS_BUF_GETERROR(bp) : ENOMEM; goto fail; } - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); } Index: xfs-linux-killwantfuncs/xfs_trans_buf.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_trans_buf.c +++ xfs-linux-killwantfuncs/xfs_trans_buf.c @@ -649,7 +649,6 @@ xfs_trans_bjoin(xfs_trans_t *tp, { xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, void *) == NULL); /* @@ -694,7 +693,6 @@ xfs_trans_bhold(xfs_trans_t *tp, { xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); @@ -716,7 +714,6 @@ xfs_trans_bhold_release(xfs_trans_t *tp, { xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); @@ -747,7 +744,6 @@ xfs_trans_log_buf(xfs_trans_t *tp, xfs_buf_log_item_t *bip; xfs_log_item_desc_t *lidp; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); ASSERT((first <= last) && (last < XFS_BUF_COUNT(bp))); @@ -824,7 +820,6 @@ xfs_trans_binval( xfs_log_item_desc_t *lidp; xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); @@ -902,7 +897,6 @@ xfs_trans_inode_buf( { xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); @@ -928,7 +922,6 @@ xfs_trans_stale_inode_buf( { xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); @@ -958,7 +951,6 @@ xfs_trans_inode_alloc_buf( { xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); @@ -988,7 +980,6 @@ xfs_trans_dquot_buf( { xfs_buf_log_item_t *bip; - ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_FSPRIVATE2(bp, xfs_trans_t *) == tp); ASSERT(XFS_BUF_FSPRIVATE(bp, void *) != NULL); ASSERT(type == XFS_BLI_UDQUOT_BUF || --------------060303000702070608060508-- From owner-xfs@oss.sgi.com Sat Jul 29 20:34:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 20:34:57 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6U3YeDW027837 for ; Sat, 29 Jul 2006 20:34:41 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E92811806631D for ; Sat, 29 Jul 2006 22:34:15 -0500 (CDT) Message-ID: <44CC28BA.7070005@sandeen.net> Date: Sat, 29 Jul 2006 22:34:18 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] Kill off a bunch of unused macros Content-Type: multipart/mixed; boundary="------------010804030805080203090806" X-archive-position: 8494 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 19814 Lines: 514 This is a multi-part message in MIME format. --------------010804030805080203090806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This kills off 74 unused macros; more could go but I left some in for symmetry, bitfields, etc... *shrug* Nathan, maybe you don't want all these to go, but surely some can. I left xfs_mac.h intact but it's really not used at this point either... Thanks, -Eric --------------010804030805080203090806 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="kill-unused-macros" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kill-unused-macros" linux-2.6/sv.h | 4 ---- linux-2.6/xfs_buf.h | 10 ---------- linux-2.6/xfs_linux.h | 7 ------- linux-2.6/xfs_vfs.h | 10 ---------- linux-2.6/xfs_vnode.h | 3 --- quota/xfs_qm.h | 6 ------ quota/xfs_quota_priv.h | 2 -- support/radix-tree.h | 15 --------------- xfs_acl.h | 4 ---- xfs_bmap_btree.h | 3 --- xfs_cap.h | 19 ------------------- xfs_da_btree.h | 2 -- xfs_error.h | 8 -------- xfs_fs.h | 4 ---- xfs_log.h | 8 -------- xfs_log_priv.h | 4 ---- xfs_quota.h | 3 --- xfs_sb.h | 22 ---------------------- 18 files changed, 134 deletions(-) Signed-Off-By: Eric Sandeen Index: xfs-linux-killwantfuncs/linux-2.6/sv.h =================================================================== --- xfs-linux-killwantfuncs.orig/linux-2.6/sv.h +++ xfs-linux-killwantfuncs/linux-2.6/sv.h @@ -33,12 +33,8 @@ typedef struct sv_s { } sv_t; #define SV_FIFO 0x0 /* sv_t is FIFO type */ -#define SV_LIFO 0x2 /* sv_t is LIFO type */ -#define SV_PRIO 0x4 /* sv_t is PRIO type */ -#define SV_KEYED 0x6 /* sv_t is KEYED type */ #define SV_DEFAULT SV_FIFO - static inline void _sv_wait(sv_t *sv, spinlock_t *lock, int state, unsigned long timeout) { Index: xfs-linux-killwantfuncs/linux-2.6/xfs_buf.h =================================================================== --- xfs-linux-killwantfuncs.orig/linux-2.6/xfs_buf.h +++ xfs-linux-killwantfuncs/linux-2.6/xfs_buf.h @@ -275,7 +275,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_ISDONE(bp) ((bp)->b_flags & XBF_DONE) #define XFS_BUF_BUSY(bp) do { } while (0) -#define XFS_BUF_UNBUSY(bp) do { } while (0) #define XFS_BUF_ISBUSY(bp) (1) #define XFS_BUF_ASYNC(bp) ((bp)->b_flags |= XBF_ASYNC) @@ -284,7 +283,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_ORDERED(bp) ((bp)->b_flags |= XBF_ORDERED) #define XFS_BUF_UNORDERED(bp) ((bp)->b_flags &= ~XBF_ORDERED) -#define XFS_BUF_ISORDERED(bp) ((bp)->b_flags & XBF_ORDERED) #define XFS_BUF_SHUT(bp) do { } while (0) #define XFS_BUF_UNSHUT(bp) do { } while (0) @@ -297,10 +295,8 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_WRITE(bp) ((bp)->b_flags |= XBF_WRITE) #define XFS_BUF_UNWRITE(bp) ((bp)->b_flags &= ~XBF_WRITE) -#define XFS_BUF_ISWRITE(bp) ((bp)->b_flags & XBF_WRITE) #define XFS_BUF_ISUNINITIAL(bp) (0) -#define XFS_BUF_UNUNINITIAL(bp) (0) #define XFS_BUF_BP_ISMAPPED(bp) (1) @@ -323,12 +319,9 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_SET_PTR(bp, val, cnt) xfs_buf_associate_memory(bp, val, cnt) #define XFS_BUF_ADDR(bp) ((bp)->b_bn) #define XFS_BUF_SET_ADDR(bp, bno) ((bp)->b_bn = (xfs_daddr_t)(bno)) -#define XFS_BUF_OFFSET(bp) ((bp)->b_file_offset) -#define XFS_BUF_SET_OFFSET(bp, off) ((bp)->b_file_offset = (off)) #define XFS_BUF_COUNT(bp) ((bp)->b_count_desired) #define XFS_BUF_SET_COUNT(bp, cnt) ((bp)->b_count_desired = (cnt)) #define XFS_BUF_SIZE(bp) ((bp)->b_buffer_length) -#define XFS_BUF_SET_SIZE(bp, cnt) ((bp)->b_buffer_length = (cnt)) #define XFS_BUF_SET_VTYPE_REF(bp, type, ref) do { } while (0) #define XFS_BUF_SET_VTYPE(bp, type) do { } while (0) @@ -338,7 +331,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_VALUSEMA(bp) xfs_buf_lock_value(bp) #define XFS_BUF_CPSEMA(bp) (xfs_buf_cond_lock(bp) == 0) -#define XFS_BUF_VSEMA(bp) xfs_buf_unlock(bp) #define XFS_BUF_PSEMA(bp,x) xfs_buf_lock(bp) #define XFS_BUF_V_IODONESEMA(bp) up(&bp->b_iodonesema); @@ -394,8 +386,6 @@ static inline int XFS_bwrite(xfs_buf_t * return error; } -#define XFS_bdwrite(bp) xfs_buf_iostart(bp, XBF_DELWRI | XBF_ASYNC) - static inline int xfs_bdwrite(void *mp, xfs_buf_t *bp) { bp->b_strat = xfs_bdstrat_cb; Index: xfs-linux-killwantfuncs/linux-2.6/xfs_linux.h =================================================================== --- xfs-linux-killwantfuncs.orig/linux-2.6/xfs_linux.h +++ xfs-linux-killwantfuncs/linux-2.6/xfs_linux.h @@ -152,11 +152,7 @@ BUFFER_FNS(PrivateStart, unwritten); (current->flags = ((current->flags & ~(f)) | (*(sp) & (f)))) #define NBPP PAGE_SIZE -#define DPPSHFT (PAGE_SHIFT - 9) #define NDPP (1 << (PAGE_SHIFT - 9)) -#define dtop(DD) (((DD) + NDPP - 1) >> DPPSHFT) -#define dtopt(DD) ((DD) >> DPPSHFT) -#define dpoff(DD) ((DD) & (NDPP-1)) #define NBBY 8 /* number of bits per byte */ #define NBPC PAGE_SIZE /* Number of bytes per click */ @@ -176,8 +172,6 @@ BUFFER_FNS(PrivateStart, unwritten); #define btoct(x) ((__psunsigned_t)(x)>>BPCSHIFT) #define btoc64(x) (((__uint64_t)(x)+(NBPC-1))>>BPCSHIFT) #define btoct64(x) ((__uint64_t)(x)>>BPCSHIFT) -#define io_btoc(x) (((__psunsigned_t)(x)+(IO_NBPC-1))>>IO_BPCSHIFT) -#define io_btoct(x) ((__psunsigned_t)(x)>>IO_BPCSHIFT) /* off_t bytes to clicks */ #define offtoc(x) (((__uint64_t)(x)+(NBPC-1))>>BPCSHIFT) @@ -190,7 +184,6 @@ BUFFER_FNS(PrivateStart, unwritten); #define ctob(x) ((__psunsigned_t)(x)<>BPCSHIFT) #define ctob64(x) ((__uint64_t)(x)<>BPCSHIFT) Index: xfs-linux-killwantfuncs/linux-2.6/xfs_vfs.h =================================================================== --- xfs-linux-killwantfuncs.orig/linux-2.6/xfs_vfs.h +++ xfs-linux-killwantfuncs/linux-2.6/xfs_vfs.h @@ -166,18 +166,8 @@ typedef struct bhv_vfsops { #define bhv_next_vfs_mount(b, ma,cr) vfs_mount(b, ma,cr) #define bhv_next_vfs_parseargs(b, o,ma,f) vfs_parseargs(b, o,ma,f) #define bhv_next_vfs_showargs(b, m) vfs_showargs(b, m) -#define bhv_next_vfs_unmount(b, f,cr) vfs_unmount(b, f,cr) -#define bhv_next_vfs_mntupdate(b, fl,args) vfs_mntupdate(b, fl, args) -#define bhv_next_vfs_root(b, vpp) vfs_root(b, vpp) #define bhv_next_vfs_statvfs(b, sp,vp) vfs_statvfs(b, sp,vp) #define bhv_next_vfs_sync(b, flag,cr) vfs_sync(b, flag,cr) -#define bhv_next_vfs_vget(b, vpp,fidp) vfs_vget(b, vpp,fidp) -#define bhv_next_vfs_dmapiops(b, p) vfs_dmapiops(b, p) -#define bhv_next_vfs_quotactl(b, c,id,p) vfs_quotactl(b, c,id,p) -#define bhv_next_vfs_get_inode(b, ino,fl) vfs_get_inode(b, ino,fl) -#define bhv_next_vfs_init_vnode(b, vp,b2,ul) vfs_init_vnode(b, vp,b2,ul) -#define bhv_next_force_shutdown(b, fl,f,l) vfs_force_shutdown(b, fl,f,l) -#define bhv_next_vfs_freeze(b) vfs_freeze(b) extern int vfs_mount(bhv_desc_t *, struct xfs_mount_args *, struct cred *); extern int vfs_parseargs(bhv_desc_t *, char *, struct xfs_mount_args *, int); Index: xfs-linux-killwantfuncs/linux-2.6/xfs_vnode.h =================================================================== --- xfs-linux-killwantfuncs.orig/linux-2.6/xfs_vnode.h +++ xfs-linux-killwantfuncs/linux-2.6/xfs_vnode.h @@ -294,10 +294,7 @@ typedef struct bhv_vnodeops { #define bhv_vop_release(vp) VOP(vop_release, vp)(VNHEAD(vp)) #define bhv_vop_fid2(vp,fidp) VOP(vop_fid2, vp)(VNHEAD(vp),fidp) #define bhv_vop_rwlock(vp,i) VOP(vop_rwlock, vp)(VNHEAD(vp),i) -#define bhv_vop_rwlock_try(vp,i) VOP(vop_rwlock, vp)(VNHEAD(vp),i) #define bhv_vop_rwunlock(vp,i) VOP(vop_rwunlock, vp)(VNHEAD(vp),i) -#define bhv_vop_frlock(vp,c,fl,flags,offset,fr) \ - VOP(vop_frlock, vp)(VNHEAD(vp),c,fl,flags,offset,fr) #define bhv_vop_reclaim(vp) VOP(vop_reclaim, vp)(VNHEAD(vp)) #define bhv_vop_attr_get(vp, name, val, vallenp, fl, cred) \ VOP(vop_attr_get, vp)(VNHEAD(vp),name,val,vallenp,fl,cred) Index: xfs-linux-killwantfuncs/quota/xfs_quota_priv.h =================================================================== --- xfs-linux-killwantfuncs.orig/quota/xfs_quota_priv.h +++ xfs-linux-killwantfuncs/quota/xfs_quota_priv.h @@ -75,7 +75,6 @@ static inline int XQMISLCKD(struct xfs_d #define xfs_qm_freelist_lock(qm) XQMLCK(&((qm)->qm_dqfreelist)) #define xfs_qm_freelist_unlock(qm) XQMUNLCK(&((qm)->qm_dqfreelist)) -#define XFS_QM_IS_FREELIST_LOCKED(qm) XQMISLCKD(&((qm)->qm_dqfreelist)) /* * Hash into a bucket in the dquot hash table, based on . @@ -170,6 +169,5 @@ for ((dqp) = (qlist)->qh_next; (dqp) != #define DQFLAGTO_TYPESTR(d) (((d)->dq_flags & XFS_DQ_USER) ? "USR" : \ (((d)->dq_flags & XFS_DQ_GROUP) ? "GRP" : \ (((d)->dq_flags & XFS_DQ_PROJ) ? "PRJ":"???"))) -#define DQFLAGTO_DIRTYSTR(d) (XFS_DQ_IS_DIRTY(d) ? "DIRTY" : "NOTDIRTY") #endif /* __XFS_QUOTA_PRIV_H__ */ Index: xfs-linux-killwantfuncs/support/radix-tree.h =================================================================== --- xfs-linux-killwantfuncs.orig/support/radix-tree.h +++ xfs-linux-killwantfuncs/support/radix-tree.h @@ -24,20 +24,6 @@ struct radix_tree_root { struct radix_tree_node *rnode; }; -#define RADIX_TREE_INIT(mask) { \ - .height = 0, \ - .rnode = NULL, \ -} - -#define RADIX_TREE(name, mask) \ - struct radix_tree_root name = RADIX_TREE_INIT(mask) - -#define INIT_RADIX_TREE(root, mask) \ -do { \ - (root)->height = 0; \ - (root)->rnode = NULL; \ -} while (0) - #define RADIX_TREE_MAX_TAGS 2 int radix_tree_insert(struct radix_tree_root *, unsigned long, void *); @@ -47,7 +33,6 @@ void *radix_tree_delete(struct radix_tre unsigned int radix_tree_gang_lookup(struct radix_tree_root *root, void **results, unsigned long first_index, unsigned int max_items); -#define radix_tree_preload(gfp_mask) do { } while (0) void radix_tree_init(void); void *radix_tree_tag_set(struct radix_tree_root *root, unsigned long index, unsigned int tag); Index: xfs-linux-killwantfuncs/xfs_acl.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_acl.h +++ xfs-linux-killwantfuncs/xfs_acl.h @@ -72,9 +72,7 @@ extern int xfs_acl_vremove(struct bhv_vn #define _ACL_PERM_INVALID(perm) ((perm) & ~(ACL_READ|ACL_WRITE|ACL_EXECUTE)) #define _ACL_INHERIT(c,v,d) (xfs_acl_inherit(c,v,d)) -#define _ACL_GET_ACCESS(pv,pa) (xfs_acl_vtoacl(pv,pa,NULL) == 0) #define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) -#define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access #define _ACL_DEFAULT_EXISTS xfs_acl_vhasacl_default #define _ACL_XFS_IACCESS(i,m,c) (XFS_IFORK_Q(i) ? xfs_acl_iaccess(i,m,c) : -1) @@ -92,9 +90,7 @@ extern int xfs_acl_vremove(struct bhv_vn #define _ACL_ALLOC(a) (1) /* successfully allocate nothing */ #define _ACL_FREE(a) ((void)0) #define _ACL_INHERIT(c,v,d) (0) -#define _ACL_GET_ACCESS(pv,pa) (0) #define _ACL_GET_DEFAULT(pv,pd) (0) -#define _ACL_ACCESS_EXISTS (NULL) #define _ACL_DEFAULT_EXISTS (NULL) #define _ACL_XFS_IACCESS(i,m,c) (-1) #endif Index: xfs-linux-killwantfuncs/xfs_bmap_btree.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_bmap_btree.h +++ xfs-linux-killwantfuncs/xfs_bmap_btree.h @@ -74,9 +74,6 @@ typedef struct xfs_bmdr_block { #endif /* XFS_NATIVE_HOST */ - -#define BMBT_USE_64 1 - typedef struct xfs_bmbt_rec_32 { __uint32_t l0, l1, l2, l3; Index: xfs-linux-killwantfuncs/xfs_cap.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_cap.h +++ xfs-linux-killwantfuncs/xfs_cap.h @@ -29,12 +29,6 @@ typedef struct xfs_cap_set { xfs_cap_value_t cap_inheritable;/* pass through exec */ } xfs_cap_set_t; -/* On-disk XFS extended attribute names */ -#define SGI_CAP_FILE "SGI_CAP_FILE" -#define SGI_CAP_FILE_SIZE (sizeof(SGI_CAP_FILE)-1) -#define SGI_CAP_LINUX "SGI_CAP_LINUX" -#define SGI_CAP_LINUX_SIZE (sizeof(SGI_CAP_LINUX)-1) - /* * For Linux, we take the bitfields directly from capability.h * and no longer attempt to keep this attribute ondisk compatible @@ -50,19 +44,6 @@ typedef struct xfs_cap_set { #include struct bhv_vnode; - -extern int xfs_cap_vhascap(struct bhv_vnode *); -extern int xfs_cap_vset(struct bhv_vnode *, void *, size_t); -extern int xfs_cap_vget(struct bhv_vnode *, void *, size_t); -extern int xfs_cap_vremove(struct bhv_vnode *); - -#define _CAP_EXISTS xfs_cap_vhascap - -#else -#define xfs_cap_vset(v,p,sz) (-EOPNOTSUPP) -#define xfs_cap_vget(v,p,sz) (-EOPNOTSUPP) -#define xfs_cap_vremove(v) (-EOPNOTSUPP) -#define _CAP_EXISTS (NULL) #endif #endif /* __KERNEL__ */ Index: xfs-linux-killwantfuncs/xfs_da_btree.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_da_btree.h +++ xfs-linux-killwantfuncs/xfs_da_btree.h @@ -72,8 +72,6 @@ typedef struct xfs_da_intnode { typedef struct xfs_da_node_hdr xfs_da_node_hdr_t; typedef struct xfs_da_node_entry xfs_da_node_entry_t; -#define XFS_DA_MAXHASH ((xfs_dahash_t)-1) /* largest valid hash value */ - #define XFS_LBSIZE(mp) (mp)->m_sb.sb_blocksize #define XFS_LBLOG(mp) (mp)->m_sb.sb_blocklog Index: xfs-linux-killwantfuncs/xfs_error.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_error.h +++ xfs-linux-killwantfuncs/xfs_error.h @@ -18,14 +18,6 @@ #ifndef __XFS_ERROR_H__ #define __XFS_ERROR_H__ -#define XFS_ERECOVER 1 /* Failure to recover log */ -#define XFS_ELOGSTAT 2 /* Failure to stat log in user space */ -#define XFS_ENOLOGSPACE 3 /* Reservation too large */ -#define XFS_ENOTSUP 4 /* Operation not supported */ -#define XFS_ENOLSN 5 /* Can't find the lsn you asked for */ -#define XFS_ENOTFOUND 6 -#define XFS_ENOTXFS 7 /* Not XFS filesystem */ - #ifdef DEBUG #define XFS_ERROR_NTRAP 10 extern int xfs_etrap[XFS_ERROR_NTRAP]; Index: xfs-linux-killwantfuncs/xfs_fs.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_fs.h +++ xfs-linux-killwantfuncs/xfs_fs.h @@ -22,8 +22,6 @@ * SGI's XFS filesystem's major stuff (constants, structures) */ -#define XFS_NAME "xfs" - /* * Direct I/O attribute record used with XFS_IOC_DIOINFO * d_miniosz is the min xfer size, xfer size multiple and file seek offset @@ -428,8 +426,6 @@ typedef struct xfs_handle { #define XFS_HANDLE_CMP(h1, h2) memcmp(h1, h2, sizeof(xfs_handle_t)) -#define FSHSIZE sizeof(fsid_t) - /* * Flags for going down operation */ Index: xfs-linux-killwantfuncs/xfs_sb.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_sb.h +++ xfs-linux-killwantfuncs/xfs_sb.h @@ -60,10 +60,6 @@ struct xfs_mount; XFS_SB_VERSION_LOGV2BIT | \ XFS_SB_VERSION_SECTORBIT | \ XFS_SB_VERSION_MOREBITSBIT) -#define XFS_SB_VERSION_OKSASHBITS \ - (XFS_SB_VERSION_NUMBITS | \ - XFS_SB_VERSION_REALFBITS | \ - XFS_SB_VERSION_OKSASHFBITS) #define XFS_SB_VERSION_OKREALBITS \ (XFS_SB_VERSION_NUMBITS | \ XFS_SB_VERSION_OKREALFBITS | \ @@ -81,9 +77,6 @@ struct xfs_mount; #define XFS_SB_VERSION2_RESERVED2BIT 0x00000002 #define XFS_SB_VERSION2_RESERVED4BIT 0x00000004 #define XFS_SB_VERSION2_ATTR2BIT 0x00000008 /* Inline attr rework */ -#define XFS_SB_VERSION2_SASHFBITS 0xff000000 /* Mask: features that - require changing - PROM and SASH */ #define XFS_SB_VERSION2_OKREALFBITS \ (XFS_SB_VERSION2_ATTR2BIT) @@ -237,12 +230,6 @@ static inline int XFS_SB_GOOD_VERSION(xf } #endif /* __KERNEL__ */ -#define XFS_SB_GOOD_SASH_VERSION(sbp) \ - ((((sbp)->sb_versionnum >= XFS_SB_VERSION_1) && \ - ((sbp)->sb_versionnum <= XFS_SB_VERSION_3)) || \ - ((XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ - !((sbp)->sb_versionnum & ~XFS_SB_VERSION_OKSASHBITS))) - static inline unsigned XFS_SB_VERSION_TONEW(unsigned v) { return ((((v) == XFS_SB_VERSION_1) ? \ @@ -436,15 +423,6 @@ static inline void XFS_SB_VERSION_ADDATT * File system sector to basic block conversions. */ #define XFS_FSS_TO_BB(mp,sec) ((sec) << (mp)->m_sectbb_log) -#define XFS_BB_TO_FSS(mp,bb) \ - (((bb) + (XFS_FSS_TO_BB(mp,1) - 1)) >> (mp)->m_sectbb_log) -#define XFS_BB_TO_FSST(mp,bb) ((bb) >> (mp)->m_sectbb_log) - -/* - * File system sector to byte conversions. - */ -#define XFS_FSS_TO_B(mp,sectno) ((xfs_fsize_t)(sectno) << (mp)->m_sb.sb_sectlog) -#define XFS_B_TO_FSST(mp,b) (((__uint64_t)(b)) >> (mp)->m_sb.sb_sectlog) /* * File system block to basic block conversions. Index: xfs-linux-killwantfuncs/quota/xfs_qm.h =================================================================== --- xfs-linux-killwantfuncs.orig/quota/xfs_qm.h +++ xfs-linux-killwantfuncs/quota/xfs_qm.h @@ -56,12 +56,6 @@ extern kmem_zone_t *qm_dqtrxzone; #define XFS_QM_HASHSIZE_HIGH ((NBPP * 4) / sizeof(xfs_dqhash_t)) /* - * We output a cmn_err when quotachecking a quota file with more than - * this many fsbs. - */ -#define XFS_QM_BIG_QCHECK_NBLKS 500 - -/* * This defines the unit of allocation of dquots. * Currently, it is just one file system block, and a 4K blk contains 30 * (136 * 30 = 4080) dquots. It's probably not worth trying to make Index: xfs-linux-killwantfuncs/xfs_log.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_log.h +++ xfs-linux-killwantfuncs/xfs_log.h @@ -48,16 +48,10 @@ static inline xfs_lsn_t _lsn_cmp(xfs_lsn */ /* - * Flags to xfs_log_mount - */ -#define XFS_LOG_RECOVER 0x1 - -/* * Flags to xfs_log_done() */ #define XFS_LOG_REL_PERM_RESERV 0x1 - /* * Flags to xfs_log_reserve() * @@ -70,8 +64,6 @@ static inline xfs_lsn_t _lsn_cmp(xfs_lsn #define XFS_LOG_SLEEP 0x0 #define XFS_LOG_NOSLEEP 0x1 #define XFS_LOG_PERM_RESERV 0x2 -#define XFS_LOG_RESV_ALL (XFS_LOG_NOSLEEP|XFS_LOG_PERM_RESERV) - /* * Flags to xfs_log_force() Index: xfs-linux-killwantfuncs/xfs_log_priv.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_log_priv.h +++ xfs-linux-killwantfuncs/xfs_log_priv.h @@ -32,7 +32,6 @@ struct xfs_mount; #define XLOG_MIN_ICLOGS 2 #define XLOG_MED_ICLOGS 4 #define XLOG_MAX_ICLOGS 8 -#define XLOG_CALLBACK_SIZE 10 #define XLOG_HEADER_MAGIC_NUM 0xFEEDbabe /* Invalid cycle number */ #define XLOG_VERSION_1 1 #define XLOG_VERSION_2 2 /* Large IClogs, Log sunit */ @@ -149,9 +148,6 @@ struct xfs_mount; #define XLOG_WAS_CONT_TRANS 0x08 /* Cont this trans into new region */ #define XLOG_END_TRANS 0x10 /* End a continued transaction */ #define XLOG_UNMOUNT_TRANS 0x20 /* Unmount a filesystem transaction */ -#define XLOG_SKIP_TRANS (XLOG_COMMIT_TRANS | XLOG_CONTINUE_TRANS | \ - XLOG_WAS_CONT_TRANS | XLOG_END_TRANS | \ - XLOG_UNMOUNT_TRANS) #ifdef __KERNEL__ /* Index: xfs-linux-killwantfuncs/xfs_quota.h =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_quota.h +++ xfs-linux-killwantfuncs/xfs_quota.h @@ -281,9 +281,6 @@ typedef struct xfs_qoff_logformat { XFS_UQUOTA_CHKD|XFS_PQUOTA_ACCT|\ XFS_OQUOTA_ENFD|XFS_OQUOTA_CHKD|\ XFS_GQUOTA_ACCT) -#define XFS_MOUNT_QUOTA_MASK (XFS_MOUNT_QUOTA_ALL | XFS_UQUOTA_ACTIVE | \ - XFS_GQUOTA_ACTIVE | XFS_PQUOTA_ACTIVE) - /* * The structure kept inside the xfs_trans_t keep track of dquot changes --------------010804030805080203090806-- From owner-xfs@oss.sgi.com Sat Jul 29 20:53:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 20:53:30 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6U3rKDW031248 for ; Sat, 29 Jul 2006 20:53:20 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id B69F11806631D; Sat, 29 Jul 2006 22:52:55 -0500 (CDT) Message-ID: <44CC2D1A.3060805@sandeen.net> Date: Sat, 29 Jul 2006 22:52:58 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: calembour Cc: xfs@oss.sgi.com Subject: Re: write back cache and barriers References: <5545990.post@talk.nabble.com> In-Reply-To: <5545990.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8497 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1714 Lines: 50 calembour wrote: > Hi, > I don't have a deep knowledge about filesystems and I've few experiences > with > raid configuration, so I need someone who can answer some questions about > write back cache and barriers. > > I have two sata hd (sda, sdb) configured in bios-raid 0 and relative device > created by dmraid on boot (nvidia_ihfaaicb). > > (1) what should I do to know if the write back cache is enabled or not ? lots of this is in the faq: http://oss.sgi.com/projects/xfs/faq.html#wcache > (2) if the write cache is enabled on both sda and sdb this mean that is > enabled > also on the raid device (/dev/mapper/nvidia_ihfaaicb) ? I'd guess that if there's a write cache anywhere under your device, then in effect the raid device would be considered write-cached. > (3) how should I do to enable/disable the write cache on the raid device ? see faq > If I try mounting a xfs filesystem I get a message like "barriers are not > supported by this device" but if I mount a ext3 or a reiserfs filesystem > respectively with options barrier=1 and barrier=flush they don't complain. > If I mount the reiserfs I explicity get a message like "using barriers". > So who tells the truth ?? I don't see ext3 or reiser actually checking whether the underlying device supports barriers. xfs does, in xfs_mountfs_check_barriers(). > (4) is there a way to know if the raid device supports barrier or not ? I'm not sure how barriers interact with multiple devices; perhaps someone else can answer.... > (5) is there a (not dangerous) test I can do to figure out if barriers are > really enabled and used with ext3 and reiserfs filesystems ? Dunno :) -Eric > Thanks for reading the message > Marco From owner-xfs@oss.sgi.com Sat Jul 29 20:53:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 20:53:22 -0700 (PDT) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6U3r2DW031184 for ; Sat, 29 Jul 2006 20:53:03 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 2BF4DC0DF780 for ; Sun, 30 Jul 2006 11:52:38 +0800 (PHT) Received: from musang.free.net.ph (unknown [203.177.91.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 4096FC05F0D3 for ; Sun, 30 Jul 2006 11:51:50 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 983E120144EA; Sun, 30 Jul 2006 11:38:02 +0800 (PHT) Date: Sun, 30 Jul 2006 11:38:02 +0800 From: Federico Sevilla III To: XFS Mailing List Subject: Filesystem Shutdown due to Error 22 Message-ID: <20060730033802.GA3647@free.net.ph> Mail-Followup-To: XFS Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.11 X-archive-position: 8496 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: xfs Content-Length: 1450 Lines: 37 Hi, I am running Linux 2.6.17.7 on a Debian GNU/Linux Sarge machine (xfsprogs 2.6.20 and xfsdump 2.2.27). I was hit recently by the dir2 corruption problem, but already fixed this using the procedure in the FAQ after upgrading the kernel. I have a weekly scheduled task that runs xfs_fsr and this morning found that my server's filesystem (the same one previously hit by the dir2 issue) had been shut down. I don't have console access to this server but managed to get the following off the logs which are on a separate filesystem: kernel: xfs_inotobp: xfs_imap() returned an error 22 on md1. Returning error. kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on md1. Returning error. kernel: xfs_inactive:^Ixfs_ifree() returned an error = 22 on md1 kernel: xfs_force_shutdown(md1,0x1) called from line 1763 of file fs/xfs/xfs_vnodeops.c. Return address = 0xc01fa80c I ran xfs_repair, and found 20 disconnected inodes of which 16 are filled with nulls. No other problems were found with the filesystem. I have an identical server (hardware, kernel and core utilities, albeit different applications) which went through the same upgrade path and dir2 corruption, but went through today's xfs_fsr without any problems. Any clues as to what's causing this? Cheers! --> Jijo -- Federico Vicente C. Sevilla III Information Technology Consultant Q Software Research Corporation Website: http://jijo.free.net.ph From owner-xfs@oss.sgi.com Sat Jul 29 23:43:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 29 Jul 2006 23:44:12 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6U6hgDW021560 for ; Sat, 29 Jul 2006 23:43:42 -0700 Received: from [82.41.152.154] (helo=[192.168.10.36]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G73hh-00065h-8o; Sun, 30 Jul 2006 07:19:09 +0200 Date: Sun, 30 Jul 2006 06:19:32 +0100 (BST) From: christian X-X-Sender: evil@prinz64.housecafe.de To: Barry Naujok cc: xfs@oss.sgi.com Subject: Re: Review: xfs_repair fixes for dir2 corruption In-Reply-To: <200607280155.LAA12814@larry.melbourne.sgi.com> Message-ID: References: <200607280155.LAA12814@larry.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463809270-1081969773-1154236772=:4981" X-archive-position: 8498 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 67160 Lines: 1121 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463809270-1081969773-1154236772=:4981 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hello Barry, On Fri, 28 Jul 2006, Barry Naujok wrote: > For those that are keen to fix the 16777216 problem, give this patch a go. thanks for the patch, worked for me ;-) (somehow your patch here was linewrapped around line 1389 or so, so I attach it again) I've compiled xfsprogs from cvs with your patch applied on x86_64 to work on a saved copy of a corrupt xfs (from a i386 box). for the record, here is how it went: http://nerdbynature.de/bits/2.6.18-rc2/sda5_prinz64.log.gz Thanks again, Christian. -- BOFH excuse #158: Defunct processes ---1463809270-1081969773-1154236772=:4981 Content-Type: TEXT/plain; charset=US-ASCII; name=xfs_repair_#631.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=xfs_repair_#631.diff Iw0KIyBUaGlzIHBhdGNoIGFkZHJlc3NlcyB0aGUgZm9sbG93aW5nIHhmc19y ZXBhaXIgaXNzdWVzOg0KIyAgLSBDYW4gcmVidWlsZCBtb3N0IGNvcnJ1cHRl ZCBkaXJlY3Rvcmllcy4gU29tZSB3aWxsIGJlIA0KIyAgICBiZXlvbmQgcmVw YWlyIGFuZCB0aGUgY29udGVudHMgb2YgdGhvc2Ugd2lsbCBlbmQgdXAgDQoj ICAgIGluIGxvc3QrZm91bmQuDQojICAtIEZpeGVkIHBvdGVudGlhbCBwcm9i bGVtcyB3aXRoIHRoZSBkdXBsaWNhdGUgbmFtZSANCiMgICAgY2hlY2tpbmcg YnkgcHJvcGVybHkgcmVmZXJlbmNpbmcgdGhlIGJ1ZmZlcnMgd2hlcmUNCiMg ICAgdGhlIG5hbWVzIGFyZSBzdG9yZWQuDQojICAtIFVuaWZpZWQgdGhlIHR3 byBoYXNoIGxpc3RzIHVzZWQgaW4gZGlyZWN0b3J5IGNoZWNrcy4NCiMgIC0g Rml4ZWQgYSBjYXNlIHdoZXJlIGluY29ycmVjdGx5IHJlZmVyZW5jZSBjb3Vu dGVkIGFuZA0KIyAgICBkaXJ0eSBidWZmZXJzIHdlcmUgbmV2ZXIgd3JpdHRl biB0byBkaXNrIChtb3N0IA0KIyAgICBjb21tb24gb2JzZXJ2YXRpb24gb2Yg dGhpcyBpcyBhbiBpbmFjY2Vzc2libGUgDQojICAgIGxvc3QrZm91bmQgZGly ZWN0b3J5IGFmdGVyIGEgcmVwYWlyKS4NCiMNCiMgRm9yIHRob3NlIHRoYXQg YXJlIGtlZW4gdG8gZml4IHRoZSAxNjc3NzIxNiBwcm9ibGVtLCBnaXZlIHRo aXMgcGF0Y2ggYSBnby4NCiMNCi0tLSBhL3hmc3Byb2dzL2luY2x1ZGUvY2Fj aGUuaAkyMDA2LTA3LTI4IDExOjQ2OjA5LjAwMDAwMDAwMCArMTAwMA0KKysr IGIveGZzcHJvZ3MvaW5jbHVkZS9jYWNoZS5oCTIwMDYtMDctMjcgMTY6MTc6 NDcuODA0OTg2MzIyICsxMDAwDQpAQCAtMzAsNiArMzAsNyBAQCBzdHJ1Y3Qg Y2FjaGVfbm9kZTsNCiB0eXBlZGVmIHZvaWQgKmNhY2hlX2tleV90Ow0KIHR5 cGVkZWYgdm9pZCAoKmNhY2hlX3dhbGtfdCkoc3RydWN0IGNhY2hlX25vZGUg Kik7DQogdHlwZWRlZiBzdHJ1Y3QgY2FjaGVfbm9kZSAqICgqY2FjaGVfbm9k ZV9hbGxvY190KSh2b2lkKTsNCit0eXBlZGVmIHZvaWQgKCpjYWNoZV9ub2Rl X2ZsdXNoX3QpKHN0cnVjdCBjYWNoZV9ub2RlICopOw0KIHR5cGVkZWYgdm9p ZCAoKmNhY2hlX25vZGVfcmVsc2VfdCkoc3RydWN0IGNhY2hlX25vZGUgKik7 DQogdHlwZWRlZiB1bnNpZ25lZCBpbnQgKCpjYWNoZV9ub2RlX2hhc2hfdCko Y2FjaGVfa2V5X3QsIHVuc2lnbmVkIGludCk7DQogdHlwZWRlZiBpbnQgKCpj YWNoZV9ub2RlX2NvbXBhcmVfdCkoc3RydWN0IGNhY2hlX25vZGUgKiwgY2Fj aGVfa2V5X3QpOw0KQEAgLTM4LDYgKzM5LDcgQEAgdHlwZWRlZiB1bnNpZ25l ZCBpbnQgKCpjYWNoZV9idWxrX3JlbHNlXw0KIHN0cnVjdCBjYWNoZV9vcGVy YXRpb25zIHsNCiAJY2FjaGVfbm9kZV9oYXNoX3QJaGFzaDsNCiAJY2FjaGVf bm9kZV9hbGxvY190CWFsbG9jOw0KKwljYWNoZV9ub2RlX2ZsdXNoX3QJZmx1 c2g7DQogCWNhY2hlX25vZGVfcmVsc2VfdAlyZWxzZTsNCiAJY2FjaGVfbm9k ZV9jb21wYXJlX3QJY29tcGFyZTsNCiAJY2FjaGVfYnVsa19yZWxzZV90CWJ1 bGtyZWxzZTsJLyogb3B0aW9uYWwgKi8NCkBAIC00OSw2ICs1MSw3IEBAIHN0 cnVjdCBjYWNoZSB7DQogCXB0aHJlYWRfbXV0ZXhfdAkJY19tdXRleDsJLyog bm9kZSBjb3VudCBtdXRleCAqLw0KIAljYWNoZV9ub2RlX2hhc2hfdAloYXNo OwkJLyogbm9kZSBoYXNoIGZ1bmN0aW9uICovDQogCWNhY2hlX25vZGVfYWxs b2NfdAlhbGxvYzsJCS8qIGFsbG9jYXRpb24gZnVuY3Rpb24gKi8NCisJY2Fj aGVfbm9kZV9mbHVzaF90CWZsdXNoOwkJLyogZmx1c2ggZGlydHkgZGF0YSBm dW5jdGlvbiAqLw0KIAljYWNoZV9ub2RlX3JlbHNlX3QJcmVsc2U7CQkvKiBt ZW1vcnkgZnJlZSBmdW5jdGlvbiAqLw0KIAljYWNoZV9ub2RlX2NvbXBhcmVf dAljb21wYXJlOwkvKiBjb21wYXJpc29uIHJvdXRpbmUgKi8NCiAJY2FjaGVf YnVsa19yZWxzZV90CWJ1bGtyZWxzZTsJLyogYnVsayByZWxlYXNlIHJvdXRp bmUgKi8NCkBAIC03NSw2ICs3OCw3IEBAIHN0cnVjdCBjYWNoZSAqY2FjaGVf aW5pdCh1bnNpZ25lZCBpbnQsIHMNCiB2b2lkIGNhY2hlX2Rlc3Ryb3koc3Ry dWN0IGNhY2hlICopOw0KIHZvaWQgY2FjaGVfd2FsayhzdHJ1Y3QgY2FjaGUg KiwgY2FjaGVfd2Fsa190KTsNCiB2b2lkIGNhY2hlX3B1cmdlKHN0cnVjdCBj YWNoZSAqKTsNCit2b2lkIGNhY2hlX2ZsdXNoKHN0cnVjdCBjYWNoZSAqKTsN CiANCiBpbnQgY2FjaGVfbm9kZV9nZXQoc3RydWN0IGNhY2hlICosIGNhY2hl X2tleV90LCBzdHJ1Y3QgY2FjaGVfbm9kZSAqKik7DQogdm9pZCBjYWNoZV9u b2RlX3B1dChzdHJ1Y3QgY2FjaGVfbm9kZSAqKTsNCg0KLS0tIGEveGZzcHJv Z3MvaW5jbHVkZS9saWJ4ZnMuaAkyMDA2LTA3LTI4IDExOjQ2OjA5LjAwMDAw MDAwMCArMTAwMA0KKysrIGIveGZzcHJvZ3MvaW5jbHVkZS9saWJ4ZnMuaAky MDA2LTA3LTI3IDE2OjM0OjQ1LjMwODM0NDAxNCArMTAwMA0KQEAgLTI1Nyw2 ICsyNTcsNyBAQCBleHRlcm4gaW50CWxpYnhmc193cml0ZWJ1Zl9pbnQgKHhm c19idWZfDQogZXh0ZXJuIHN0cnVjdCBjYWNoZQkqbGlieGZzX2JjYWNoZTsN CiBleHRlcm4gc3RydWN0IGNhY2hlX29wZXJhdGlvbnMJbGlieGZzX2JjYWNo ZV9vcGVyYXRpb25zOw0KIGV4dGVybiB2b2lkCWxpYnhmc19iY2FjaGVfcHVy Z2UgKHZvaWQpOw0KK2V4dGVybiB2b2lkCWxpYnhmc19iY2FjaGVfZmx1c2gg KHZvaWQpOw0KIGV4dGVybiB4ZnNfYnVmX3QJKmxpYnhmc19nZXRidWYgKGRl dl90LCB4ZnNfZGFkZHJfdCwgaW50KTsNCiBleHRlcm4gdm9pZAlsaWJ4ZnNf cHV0YnVmICh4ZnNfYnVmX3QgKik7DQogZXh0ZXJuIHZvaWQJbGlieGZzX3B1 cmdlYnVmICh4ZnNfYnVmX3QgKik7DQpAQCAtNDY3LDYgKzQ2OCw4IEBAIGV4 dGVybiBpbnQJbGlieGZzX2JtYXBfZmluaXNoICh4ZnNfdHJhbnMNCiAJCQkJ eGZzX2ZzYmxvY2tfdCwgaW50ICopOw0KIGV4dGVybiBpbnQJbGlieGZzX2Jt YXBfbmV4dF9vZmZzZXQgKHhmc190cmFuc190ICosIHhmc19pbm9kZV90ICos DQogCQkJCXhmc19maWxlb2ZmX3QgKiwgaW50KTsNCitleHRlcm4gaW50CWxp Ynhmc19ibWFwX2xhc3Rfb2Zmc2V0KHhmc190cmFuc190ICosIHhmc19pbm9k ZV90ICosIA0KKwkJCQl4ZnNfZmlsZW9mZl90ICosIGludCk7DQogZXh0ZXJu IGludAlsaWJ4ZnNfYnVubWFwaSAoeGZzX3RyYW5zX3QgKiwgeGZzX2lub2Rl X3QgKiwgeGZzX2ZpbGVvZmZfdCwNCiAJCQkJeGZzX2ZpbGJsa3NfdCwgaW50 LCB4ZnNfZXh0bnVtX3QsDQogCQkJCXhmc19mc2Jsb2NrX3QgKiwgeGZzX2Jt YXBfZnJlZV90ICosIGludCAqKTsNCg0KLS0tIGEveGZzcHJvZ3MvbGlieGZz L2NhY2hlLmMJMjAwNi0wNy0yOCAxMTo0NjowOS4wMDAwMDAwMDAgKzEwMDAN CisrKyBiL3hmc3Byb2dzL2xpYnhmcy9jYWNoZS5jCTIwMDYtMDctMjcgMTc6 NDI6NDMuODEyNjg1Mzg4ICsxMDAwDQpAQCAtNjAsNiArNjAsNyBAQCBjYWNo ZV9pbml0KA0KIAljYWNoZS0+Y19oYXNoc2l6ZSA9IGhhc2hzaXplOw0KIAlj YWNoZS0+aGFzaCA9IGNhY2hlX29wZXJhdGlvbnMtPmhhc2g7DQogCWNhY2hl LT5hbGxvYyA9IGNhY2hlX29wZXJhdGlvbnMtPmFsbG9jOw0KKwljYWNoZS0+ Zmx1c2ggPSBjYWNoZV9vcGVyYXRpb25zLT5mbHVzaDsNCiAJY2FjaGUtPnJl bHNlID0gY2FjaGVfb3BlcmF0aW9ucy0+cmVsc2U7DQogCWNhY2hlLT5jb21w YXJlID0gY2FjaGVfb3BlcmF0aW9ucy0+Y29tcGFyZTsNCiAJY2FjaGUtPmJ1 bGtyZWxzZSA9IGNhY2hlX29wZXJhdGlvbnMtPmJ1bGtyZWxzZSA/DQpAQCAt NDIyLDYgKzQyMywzOSBAQCBjYWNoZV9wdXJnZSgNCiAJCWNhY2hlX2Fib3J0 KCk7DQogCX0NCiAjZW5kaWYNCisJLyogZmx1c2ggYW55IHJlbWFpbmluZyBu b2RlcyB0byBkaXNrICovDQorCWNhY2hlX2ZsdXNoKGNhY2hlKTsNCit9DQor DQorLyoNCisgKiBGbHVzaCBhbGwgbm9kZXMgaW4gdGhlIGNhY2hlIHRvIGRp c2suIA0KKyAqLw0KK3ZvaWQNCitjYWNoZV9mbHVzaCgNCisJc3RydWN0IGNh Y2hlICoJCWNhY2hlKQ0KK3sNCisJc3RydWN0IGNhY2hlX2hhc2ggKgloYXNo Ow0KKwlzdHJ1Y3QgbGlzdF9oZWFkICoJaGVhZDsNCisJc3RydWN0IGxpc3Rf aGVhZCAqCXBvczsNCisJc3RydWN0IGNhY2hlX25vZGUgKglub2RlOw0KKwlp bnQJCQlpOw0KKwkNCisJaWYgKCFjYWNoZS0+Zmx1c2gpDQorCQlyZXR1cm47 DQorCQ0KKwlmb3IgKGkgPSAwOyBpIDwgY2FjaGUtPmNfaGFzaHNpemU7IGkr Kykgew0KKwkJaGFzaCA9ICZjYWNoZS0+Y19oYXNoW2ldOw0KKwkJDQorCQlw dGhyZWFkX211dGV4X2xvY2soJmhhc2gtPmNoX211dGV4KTsNCisJCWhlYWQg PSAmaGFzaC0+Y2hfbGlzdDsNCisJCWZvciAocG9zID0gaGVhZC0+bmV4dDsg cG9zICE9IGhlYWQ7IHBvcyA9IHBvcy0+bmV4dCkgew0KKwkJCW5vZGUgPSAo c3RydWN0IGNhY2hlX25vZGUgKilwb3M7DQorCQkJcHRocmVhZF9tdXRleF9s b2NrKCZub2RlLT5jbl9tdXRleCk7DQorCQkJY2FjaGUtPmZsdXNoKG5vZGUp Ow0KKwkJCXB0aHJlYWRfbXV0ZXhfdW5sb2NrKCZub2RlLT5jbl9tdXRleCk7 DQorCQl9DQorCQlwdGhyZWFkX211dGV4X3VubG9jaygmaGFzaC0+Y2hfbXV0 ZXgpOw0KKwl9DQogfQ0KIA0KICNkZWZpbmUJSEFTSF9SRVBPUlQJKDMqSEFT SF9DQUNIRV9SQVRJTykNCg0KLS0tIGEveGZzcHJvZ3MvbGlieGZzL3Jkd3Iu YwkyMDA2LTA3LTI4IDExOjQ2OjA5LjAwMDAwMDAwMCArMTAwMA0KKysrIGIv eGZzcHJvZ3MvbGlieGZzL3Jkd3IuYwkyMDA2LTA3LTI3IDE2OjQwOjU2LjYx MjM3MzkzOCArMTAwMA0KQEAgLTQxNiw2ICs0MTYsMTUgQEAgbGlieGZzX2lv bW92ZSh4ZnNfYnVmX3QgKmJwLCB1aW50IGJvZmYsIA0KIH0NCiANCiBzdGF0 aWMgdm9pZA0KK2xpYnhmc19iZmx1c2goc3RydWN0IGNhY2hlX25vZGUgKm5v ZGUpDQorew0KKwl4ZnNfYnVmX3QJCSpicCA9ICh4ZnNfYnVmX3QgKilub2Rl Ow0KKw0KKwlpZiAoKGJwICE9IE5VTEwpICYmIChicC0+Yl9mbGFncyAmIExJ QlhGU19CX0RJUlRZKSkNCisJCWxpYnhmc193cml0ZWJ1ZnIoYnApOw0KK30N CisNCitzdGF0aWMgdm9pZA0KIGxpYnhmc19icmVsc2Uoc3RydWN0IGNhY2hl X25vZGUgKm5vZGUpDQogew0KIAl4ZnNfYnVmX3QJCSpicCA9ICh4ZnNfYnVm X3QgKilub2RlOw0KQEAgLTQ0Miw5ICs0NTEsMTYgQEAgbGlieGZzX2JjYWNo ZV9wdXJnZSh2b2lkKQ0KIAljYWNoZV9wdXJnZShsaWJ4ZnNfYmNhY2hlKTsN CiB9DQogDQordm9pZCANCitsaWJ4ZnNfYmNhY2hlX2ZsdXNoKHZvaWQpDQor ew0KKwljYWNoZV9mbHVzaChsaWJ4ZnNfYmNhY2hlKTsNCit9DQorDQogc3Ry dWN0IGNhY2hlX29wZXJhdGlvbnMgbGlieGZzX2JjYWNoZV9vcGVyYXRpb25z ID0gew0KIAkvKiAuaGFzaCAqLwlsaWJ4ZnNfYmhhc2gsDQogCS8qIC5hbGxv YyAqLwlsaWJ4ZnNfYmFsbG9jLA0KKwkvKiAuZmx1c2ggKi8JbGlieGZzX2Jm bHVzaCwNCiAJLyogLnJlbHNlICovCWxpYnhmc19icmVsc2UsDQogCS8qIC5j b21wYXJlICovCWxpYnhmc19iY29tcGFyZSwNCiAJLyogLmJ1bGtyZWxzZSAq LyBOVUxMCS8qIFRPRE86IGxpb19saXN0aW82NCBpbnRlcmZhY2U/ICovDQpA QCAtNjQ5LDYgKzY2NSw3IEBAIGxpYnhmc19pY2FjaGVfcHVyZ2Uodm9pZCkN CiBzdHJ1Y3QgY2FjaGVfb3BlcmF0aW9ucyBsaWJ4ZnNfaWNhY2hlX29wZXJh dGlvbnMgPSB7DQogCS8qIC5oYXNoICovCWxpYnhmc19paGFzaCwNCiAJLyog LmFsbG9jICovCWxpYnhmc19pYWxsb2MsDQorCS8qIC5mbHVzaCAqLwlOVUxM LA0KIAkvKiAucmVsc2UgKi8JbGlieGZzX2lyZWxzZSwNCiAJLyogLmNvbXBh cmUgKi8JbGlieGZzX2ljb21wYXJlLA0KIAkvKiAuYnVsa3JlbHNlICovIE5V TEwNCg0KLS0tIGEveGZzcHJvZ3MvbGlieGZzL3hmcy5oCTIwMDYtMDctMjgg MTE6NDY6MDkuMDAwMDAwMDAwICsxMDAwDQorKysgYi94ZnNwcm9ncy9saWJ4 ZnMveGZzLmgJMjAwNi0wNy0yNSAxMjowNTozMS45MTc4OTY4OTIgKzEwMDAN CkBAIC05OCw2ICs5OCw3IEBADQogI2RlZmluZSB4ZnNfYm1hcGlfc2luZ2xl CQlsaWJ4ZnNfYm1hcGlfc2luZ2xlDQogI2RlZmluZSB4ZnNfYm1hcF9maW5p c2gJCQlsaWJ4ZnNfYm1hcF9maW5pc2gNCiAjZGVmaW5lIHhmc19ibWFwX2Rl bF9mcmVlCQlsaWJ4ZnNfYm1hcF9kZWxfZnJlZQ0KKyNkZWZpbmUgeGZzX2Jt YXBfbGFzdF9vZmZzZXQJCWxpYnhmc19ibWFwX2xhc3Rfb2Zmc2V0DQogI2Rl ZmluZSB4ZnNfYnVubWFwaQkJCWxpYnhmc19idW5tYXBpDQogI2RlZmluZSB4 ZnNfZnJlZV9leHRlbnQJCQlsaWJ4ZnNfZnJlZV9leHRlbnQNCiAjZGVmaW5l IHhmc19ydGZyZWVfZXh0ZW50CQlsaWJ4ZnNfcnRmcmVlX2V4dGVudA0KDQot LS0gYS94ZnNwcm9ncy9yZXBhaXIvcGhhc2U2LmMJMjAwNi0wNy0yOCAxMTo0 NjowOS4wMDAwMDAwMDAgKzEwMDANCisrKyBiL3hmc3Byb2dzL3JlcGFpci9w aGFzZTYuYwkyMDA2LTA3LTI4IDExOjMwOjUwLjAzMzkwNTUzMCArMTAwMA0K QEAgLTM2LDQzICszNiwzNSBAQCBzdGF0aWMgaW50IG9ycGhhbmFnZV9lbnRl cmVkOw0KIA0KIC8qDQogICogRGF0YSBzdHJ1Y3R1cmVzIGFuZCByb3V0aW5l cyB0byBrZWVwIHRyYWNrIG9mIGRpcmVjdG9yeSBlbnRyaWVzDQotICogYW5k IHdoZXRoZXIgdGhlaXIgbGVhZiBlbnRyeSBoYXMgYmVlbiBzZWVuDQorICog YW5kIHdoZXRoZXIgdGhlaXIgbGVhZiBlbnRyeSBoYXMgYmVlbiBzZWVuLiBB bHNvIHVzZWQgZm9yIG5hbWUNCisgKiBkdXBsaWNhdGUgY2hlY2tpbmcgYW5k IHJlYnVpbGRpbmcgc3RlcCBpZiByZXF1aXJlZC4NCiAgKi8NCiB0eXBlZGVm IHN0cnVjdCBkaXJfaGFzaF9lbnQgew0KLQlzdHJ1Y3QgZGlyX2hhc2hfZW50 CSpuZXh0OwkvKiBwb2ludGVyIHRvIG5leHQgZW50cnkgKi8NCisJc3RydWN0 IGRpcl9oYXNoX2VudAkqbmV4dGJ5YWRkcjsvKiBwb2ludGVyIHRvIG5leHQg ZW50cnkgKi8NCisJc3RydWN0IGRpcl9oYXNoX2VudAkqbmV4dGJ5aGFzaDsN CisJc3RydWN0IGRpcl9oYXNoX2VudAkqbmV4dGJ5b3JkZXI7DQogCXhmc19k aXIyX2xlYWZfZW50cnlfdAllbnQ7CS8qIGFkZHJlc3MgYW5kIGhhc2ggdmFs dWUgKi8NCisJeGZzX2lub190IAkJaW51bTsJLyogaW5vZGUgb2YgbmFtZSAq Lw0KIAlzaG9ydAkJCWp1bmtpdDsJLyogbmFtZSBzdGFydHMgd2l0aCAvICov DQogCXNob3J0CQkJc2VlbjsJLyogaGF2ZSBzZWVuIGxlYWYgZW50cnkgKi8N CisJaW50CSAgCSAgICAJbmFtZWxlbjsvKiBsZW5ndGggb2YgbmFtZSAqLw0K Kwl1Y2hhcl90ICAgIAkgICAgCSpuYW1lOwkvKiBwb2ludGVyIHRvIG5hbWUg KG5vIE5VTEwpICovDQogfSBkaXJfaGFzaF9lbnRfdDsNCiANCiB0eXBlZGVm IHN0cnVjdCBkaXJfaGFzaF90YWIgew0KIAlpbnQJCQlzaXplOwkvKiBzaXpl IG9mIGhhc2ggdGFibGUgKi8NCi0JZGlyX2hhc2hfZW50X3QJCSp0YWJbMV07 LyogYWN0dWFsIGhhc2ggdGFibGUsIHZhcmlhYmxlIHNpemUgKi8NCisJaW50 CQkJbmFtZXNfZHVwZWQ7DQorCWRpcl9oYXNoX2VudF90CQkqZmlyc3Q7DQor CWRpcl9oYXNoX2VudF90CQkqbGFzdDsNCisJZGlyX2hhc2hfZW50X3QJCSoq YnloYXNoOy8qIGFjdHVhbCBoYXNoIHRhYmxlLCB2YXJpYWJsZSBzaXplICov DQorCWRpcl9oYXNoX2VudF90CQkqKmJ5YWRkcjsvKiBhY3R1YWwgaGFzaCB0 YWJsZSwgdmFyaWFibGUgc2l6ZSAqLw0KIH0gZGlyX2hhc2hfdGFiX3Q7DQor DQogI2RlZmluZQlESVJfSEFTSF9UQUJfU0laRShuKQlcDQotCShvZmZzZXRv ZihkaXJfaGFzaF90YWJfdCwgdGFiKSArIChzaXplb2YoZGlyX2hhc2hfZW50 X3QgKikgKiAobikpKQ0KKwkoc2l6ZW9mKGRpcl9oYXNoX3RhYl90KSArIChz aXplb2YoZGlyX2hhc2hfZW50X3QgKikgKiAobikgKiAyKSkNCiAjZGVmaW5l CURJUl9IQVNIX0ZVTkModCxhKQkoKGEpICUgKHQpLT5zaXplKQ0KIA0KIC8q DQotICogVHJhY2sgbmFtZXMgdG8gY2hlY2sgZm9yIGR1cGxpY2F0ZXMgaW4g YSBkaXJlY3RvcnkuDQotICovDQotDQotdHlwZWRlZiBzdHJ1Y3QgbmFtZV9o YXNoX2VudCB7DQotCXN0cnVjdCBuYW1lX2hhc2hfZW50CSpuZXh0OwkvKiBw b2ludGVyIHRvIG5leHQgZW50cnkgKi8NCi0JeGZzX2RhaGFzaF90CQloYXNo dmFsOy8qIGhhc2ggdmFsdWUgb2YgbmFtZSAqLw0KLQlpbnQJICAJICAgIAlu YW1lbGVuOy8qIGxlbmd0aCBvZiBuYW1lICovDQotCXVjaGFyX3QgICAgCSAg ICAJKm5hbWU7CS8qIHBvaW50ZXIgdG8gbmFtZSAobm8gTlVMTCkgKi8NCi19 IG5hbWVfaGFzaF9lbnRfdDsJCQ0KLQ0KLXR5cGVkZWYgc3RydWN0IG5hbWVf aGFzaF90YWIgew0KLQlpbnQJCQlzaXplOwkvKiBzaXplIG9mIGhhc2ggdGFi bGUgKi8NCi0JbmFtZV9oYXNoX2VudF90CQkqdGFiWzFdOy8qIGFjdHVhbCBo YXNoIHRhYmxlLCB2YXJpYWJsZSBzaXplICovDQotfSBuYW1lX2hhc2hfdGFi X3Q7DQotI2RlZmluZQlOQU1FX0hBU0hfVEFCX1NJWkUobikJXA0KLQkob2Zm c2V0b2YobmFtZV9oYXNoX3RhYl90LCB0YWIpICsgKHNpemVvZihuYW1lX2hh c2hfZW50X3QgKikgKiAobikpKQ0KLSNkZWZpbmUJTkFNRV9IQVNIX0ZVTkMo dCxhKQkoKGEpICUgKHQpLT5zaXplKQ0KLQ0KLS8qDQogICogVHJhY2sgdGhl IGNvbnRlbnRzIG9mIHRoZSBmcmVlc3BhY2UgdGFibGUgaW4gYSBkaXJlY3Rv cnkuDQogICovDQogdHlwZWRlZiBzdHJ1Y3QgZnJlZXRhYiB7DQpAQCAtOTQs MjggKzg2LDc1IEBAIHR5cGVkZWYgc3RydWN0IGZyZWV0YWIgew0KICNkZWZp bmUJRElSX0hBU0hfQ0tfQkFEU1RBTEUJNQ0KICNkZWZpbmUJRElSX0hBU0hf Q0tfVE9UQUwJNg0KIA0KLXN0YXRpYyB2b2lkDQorLyoNCisgKiBSZXR1cm5z IDAgaWYgdGhlIG5hbWUgYWxyZWFkeSBleGlzdHMgKGllLiBhIGR1cGxpY2F0 ZSkNCisgKi8NCitzdGF0aWMgaW50DQogZGlyX2hhc2hfYWRkKA0KIAlkaXJf aGFzaF90YWJfdAkJKmhhc2h0YWIsDQotCXhmc19kYWhhc2hfdAkJaGFzaCwN Ci0JeGZzX2RpcjJfZGF0YXB0cl90CWFkZHIsDQotCWludAkJCWp1bmspDQot ew0KLQlpbnQJCQlpOw0KKwl4ZnNfZGlyMl9kYXRhcHRyX3QJYWRkciwJDQor CXhmc19pbm9fdAkJaW51bSwNCisJaW50CQkJbmFtZWxlbiwNCisJdWNoYXJf dAkJCSpuYW1lKQ0KK3sNCisJeGZzX2RhaGFzaF90CQloYXNoID0gMDsNCisJ aW50CQkJYnlhZGRyOw0KKwlpbnQJCQlieWhhc2ggPSAwOw0KIAlkaXJfaGFz aF9lbnRfdAkJKnA7DQotDQotCWkgPSBESVJfSEFTSF9GVU5DKGhhc2h0YWIs IGFkZHIpOw0KKwlpbnQJCQlkdXA7DQorCXNob3J0CQkJanVuazsNCisJDQor CWp1bmsgPSBuYW1lWzBdID09ICcvJzsNCisJYnlhZGRyID0gRElSX0hBU0hf RlVOQyhoYXNodGFiLCBhZGRyKTsNCisJZHVwID0gMDsNCisNCisJaWYgKCFq dW5rKSB7DQorCQloYXNoID0gbGlieGZzX2RhX2hhc2huYW1lKG5hbWUsIG5h bWVsZW4pOw0KKwkJYnloYXNoID0gRElSX0hBU0hfRlVOQyhoYXNodGFiLCBo YXNoKTsNCisNCisJCS8qIA0KKwkJICogc2VhcmNoIGhhc2ggYnVja2V0IGZv ciBleGlzdGluZyBuYW1lLg0KKwkJICovDQorCQlmb3IgKHAgPSBoYXNodGFi LT5ieWhhc2hbYnloYXNoXTsgcDsgcCA9IHAtPm5leHRieWhhc2gpIHsNCisJ CQlpZiAocC0+ZW50Lmhhc2h2YWwgPT0gaGFzaCAmJiBwLT5uYW1lbGVuID09 IG5hbWVsZW4pIHsNCisJCQkJaWYgKG1lbWNtcChwLT5uYW1lLCBuYW1lLCBu YW1lbGVuKSA9PSAwKSB7DQorCQkJCQlkdXAgPSAxOw0KKwkJCQkJYnJlYWs7 DQorCQkJCX0NCisJCQl9DQorCQl9DQorCX0NCisJDQogCWlmICgocCA9IG1h bGxvYyhzaXplb2YoKnApKSkgPT0gTlVMTCkNCiAJCWRvX2Vycm9yKF8oIm1h bGxvYyBmYWlsZWQgaW4gZGlyX2hhc2hfYWRkICgldSBieXRlcylcbiIpLA0K IAkJCXNpemVvZigqcCkpOw0KLQlwLT5uZXh0ID0gaGFzaHRhYi0+dGFiW2ld Ow0KLQloYXNodGFiLT50YWJbaV0gPSBwOw0KLQlpZiAoIShwLT5qdW5raXQg PSBqdW5rKSkNCisJDQorCXAtPm5leHRieWFkZHIgPSBoYXNodGFiLT5ieWFk ZHJbYnlhZGRyXTsNCisJaGFzaHRhYi0+YnlhZGRyW2J5YWRkcl0gPSBwOw0K KwlpZiAoaGFzaHRhYi0+bGFzdCkgDQorCQloYXNodGFiLT5sYXN0LT5uZXh0 YnlvcmRlciA9IHA7DQorCWVsc2UNCisJCWhhc2h0YWItPmZpcnN0ID0gcDsN CisJcC0+bmV4dGJ5b3JkZXIgPSBOVUxMOw0KKwloYXNodGFiLT5sYXN0ID0g cDsNCisJDQorCWlmICghKHAtPmp1bmtpdCA9IGp1bmspKSB7DQogCQlwLT5l bnQuaGFzaHZhbCA9IGhhc2g7DQorCQlwLT5uZXh0YnloYXNoID0gaGFzaHRh Yi0+YnloYXNoW2J5aGFzaF07DQorCQloYXNodGFiLT5ieWhhc2hbYnloYXNo XSA9IHA7DQorCX0NCiAJcC0+ZW50LmFkZHJlc3MgPSBhZGRyOw0KKwlwLT5p bnVtID0gaW51bTsNCiAJcC0+c2VlbiA9IDA7DQorCXAtPm5hbWVsZW4gPSBu YW1lbGVuOw0KKwlwLT5uYW1lID0gbmFtZTsNCisJDQorCXJldHVybiAhZHVw Ow0KIH0NCiANCisvKg0KKyAqIGNoZWNrcyB0byBzZWUgaWYgYW55IGRhdGEg ZW50cmllcyBhcmUgbm90IGluIHRoZSBsZWFmIGJsb2NrcyANCisgKi8NCiBz dGF0aWMgaW50DQogZGlyX2hhc2hfdW5zZWVuKA0KIAlkaXJfaGFzaF90YWJf dAkqaGFzaHRhYikNCkBAIC0xMjQsNyArMTYzLDcgQEAgZGlyX2hhc2hfdW5z ZWVuKA0KIAlkaXJfaGFzaF9lbnRfdAkqcDsNCiANCiAJZm9yIChpID0gMDsg aSA8IGhhc2h0YWItPnNpemU7IGkrKykgew0KLQkJZm9yIChwID0gaGFzaHRh Yi0+dGFiW2ldOyBwOyBwID0gcC0+bmV4dCkgew0KKwkJZm9yIChwID0gaGFz aHRhYi0+YnlhZGRyW2ldOyBwOyBwID0gcC0+bmV4dGJ5YWRkcikgew0KIAkJ CWlmIChwLT5zZWVuID09IDApDQogCQkJCXJldHVybiAxOw0KIAkJfQ0KQEAg LTE3Myw4ICsyMTIsMTAgQEAgZGlyX2hhc2hfZG9uZSgNCiAJZGlyX2hhc2hf ZW50X3QJKnA7DQogDQogCWZvciAoaSA9IDA7IGkgPCBoYXNodGFiLT5zaXpl OyBpKyspIHsNCi0JCWZvciAocCA9IGhhc2h0YWItPnRhYltpXTsgcDsgcCA9 IG4pIHsNCi0JCQluID0gcC0+bmV4dDsNCisJCWZvciAocCA9IGhhc2h0YWIt PmJ5YWRkcltpXTsgcDsgcCA9IG4pIHsNCisJCQluID0gcC0+bmV4dGJ5YWRk cjsNCisJCQlpZiAoaGFzaHRhYi0+bmFtZXNfZHVwZWQpDQorCQkJCWZyZWUo cC0+bmFtZSk7DQogCQkJZnJlZShwKTsNCiAJCX0NCiAJfQ0KQEAgLTE5Niw2 ICsyMzcsMTAgQEAgZGlyX2hhc2hfaW5pdCgNCiAJaWYgKChoYXNodGFiID0g Y2FsbG9jKERJUl9IQVNIX1RBQl9TSVpFKGhzaXplKSwgMSkpID09IE5VTEwp DQogCQlkb19lcnJvcihfKCJjYWxsb2MgZmFpbGVkIGluIGRpcl9oYXNoX2lu aXRcbiIpKTsNCiAJaGFzaHRhYi0+c2l6ZSA9IGhzaXplOw0KKwloYXNodGFi LT5ieWhhc2ggPSAoZGlyX2hhc2hfZW50X3QqKikoKGNoYXIgKiloYXNodGFi ICsgDQorCQlzaXplb2YoZGlyX2hhc2hfdGFiX3QpKTsNCisJaGFzaHRhYi0+ YnlhZGRyID0gKGRpcl9oYXNoX2VudF90KiopKChjaGFyICopaGFzaHRhYiAr IA0KKwkJc2l6ZW9mKGRpcl9oYXNoX3RhYl90KSArIHNpemVvZihkaXJfaGFz aF9lbnRfdCopICogaHNpemUpOw0KIAlyZXR1cm4gaGFzaHRhYjsNCiB9DQog DQpAQCAtMjA5LDcgKzI1NCw3IEBAIGRpcl9oYXNoX3NlZSgNCiAJZGlyX2hh c2hfZW50X3QJCSpwOw0KIA0KIAlpID0gRElSX0hBU0hfRlVOQyhoYXNodGFi LCBhZGRyKTsNCi0JZm9yIChwID0gaGFzaHRhYi0+dGFiW2ldOyBwOyBwID0g cC0+bmV4dCkgew0KKwlmb3IgKHAgPSBoYXNodGFiLT5ieWFkZHJbaV07IHA7 IHAgPSBwLT5uZXh0YnlhZGRyKSB7DQogCQlpZiAocC0+ZW50LmFkZHJlc3Mg IT0gYWRkcikNCiAJCQljb250aW51ZTsNCiAJCWlmIChwLT5zZWVuKQ0KQEAg LTIyMiw2ICsyNjcsMTAgQEAgZGlyX2hhc2hfc2VlKA0KIAlyZXR1cm4gRElS X0hBU0hfQ0tfTk9EQVRBOw0KIH0NCiANCisvKg0KKyAqIGNoZWNrcyB0byBt YWtlIHN1cmUgbGVhZnMgbWF0Y2ggYSBkYXRhIGVudHJ5LCBhbmQgdGhhdCB0 aGUgc3RhbGUNCisgKiBjb3VudCBpcyB2YWxpZC4NCisgKi8NCiBzdGF0aWMg aW50DQogZGlyX2hhc2hfc2VlX2FsbCgNCiAJZGlyX2hhc2hfdGFiX3QJCSpo YXNodGFiLA0KQEAgLTI0Niw4MSArMjk1LDI1IEBAIGRpcl9oYXNoX3NlZV9h bGwoDQogfQ0KIA0KIC8qDQotICogUmV0dXJucyAwIGlmIHRoZSBuYW1lIGFs cmVhZHkgZXhpc3RzIChpZS4gYSBkdXBsaWNhdGUpDQorICogQ29udmVydCBu YW1lIHBvaW50ZXJzIGludG8gbG9jYWxseSBhbGxvY2F0ZWQgbWVtb3J5DQog ICovDQotc3RhdGljIGludA0KLW5hbWVfaGFzaF9hZGQoDQotCW5hbWVfaGFz aF90YWJfdAkJKm5hbWV0YWIsDQotCXVjaGFyX3QJCQkqbmFtZSwNCi0JaW50 CQkJbmFtZWxlbikNCitzdGF0aWMgdm9pZA0KK2Rpcl9oYXNoX2R1cF9uYW1l cyhkaXJfaGFzaF90YWJfdCAqaGFzaHRhYikNCiB7DQotCXhmc19kYWhhc2hf dAkJaGFzaDsNCi0JaW50CQkJaTsNCi0JbmFtZV9oYXNoX2VudF90CQkqcDsN Ci0NCi0JaGFzaCA9IGxpYnhmc19kYV9oYXNobmFtZShuYW1lLCBuYW1lbGVu KTsNCi0JCQkNCi0JaSA9IE5BTUVfSEFTSF9GVU5DKG5hbWV0YWIsIGhhc2gp Ow0KLQkNCi0JLyogDQotCSAqIHNlYXJjaCBoYXNoIGJ1Y2tldCBmb3IgZXhp c3RpbmcgbmFtZS4NCi0JICovDQotCWZvciAocCA9IG5hbWV0YWItPnRhYltp XTsgcDsgcCA9IHAtPm5leHQpIHsNCi0JCWlmIChwLT5oYXNodmFsID09IGhh c2ggJiYgcC0+bmFtZWxlbiA9PSBuYW1lbGVuKSB7DQotCQkJaWYgKG1lbWNt cChwLT5uYW1lLCBuYW1lLCBuYW1lbGVuKSA9PSAwKSANCi0JCQkJcmV0dXJu IDA7IC8qIGV4aXN0cyAqLw0KLQkJfQ0KLQl9DQotCQ0KLQlpZiAoKHAgPSBt YWxsb2Moc2l6ZW9mKCpwKSkpID09IE5VTEwpDQotCQlkb19lcnJvcihfKCJt YWxsb2MgZmFpbGVkIGluIG5hbWVfaGFzaF9hZGQgKCV1IGJ5dGVzKVxuIiks DQotCQkJc2l6ZW9mKCpwKSk7DQorCXVjaGFyX3QJCQkqbmFtZTsNCisJZGly X2hhc2hfZW50X3QJCSpwOw0KIAkNCi0JcC0+bmV4dCA9IG5hbWV0YWItPnRh YltpXTsNCi0JcC0+aGFzaHZhbCA9IGhhc2g7DQotCXAtPm5hbWUgPSBuYW1l Ow0KLQlwLT5uYW1lbGVuID0gbmFtZWxlbjsNCi0JbmFtZXRhYi0+dGFiW2ld ID0gcDsNCisJaWYgKGhhc2h0YWItPm5hbWVzX2R1cGVkKQ0KKwkJcmV0dXJu Ow0KIAkNCi0JcmV0dXJuIDE7CS8qIHN1Y2Nlc3MsIG5vIGR1cGxpY2F0ZSAq Lw0KLX0NCi0NCi1zdGF0aWMgbmFtZV9oYXNoX3RhYl90ICoNCi1uYW1lX2hh c2hfaW5pdCgNCi0JeGZzX2ZzaXplX3QJc2l6ZSkNCi17DQotCW5hbWVfaGFz aF90YWJfdAkqbmFtZXRhYjsNCi0JaW50CQloc2l6ZTsNCi0NCi0JaHNpemUg PSBzaXplIC8gKDE2ICogNCk7DQotCWlmIChoc2l6ZSA+IDEwMjQpDQotCQlo c2l6ZSA9IDEwMjQ7DQotCWVsc2UgaWYgKGhzaXplIDwgMTYpDQotCQloc2l6 ZSA9IDE2Ow0KLQlpZiAoKG5hbWV0YWIgPSBjYWxsb2MoTkFNRV9IQVNIX1RB Ql9TSVpFKGhzaXplKSwgMSkpID09IE5VTEwpDQotCQlkb19lcnJvcihfKCJj YWxsb2MgZmFpbGVkIGluIG5hbWVfaGFzaF9pbml0XG4iKSk7DQotCW5hbWV0 YWItPnNpemUgPSBoc2l6ZTsNCi0JcmV0dXJuIG5hbWV0YWI7DQotfQ0KLQ0K LXN0YXRpYyB2b2lkDQotbmFtZV9oYXNoX2RvbmUoDQotCW5hbWVfaGFzaF90 YWJfdAkqbmFtZXRhYikNCi17DQotCWludAkJaTsNCi0JbmFtZV9oYXNoX2Vu dF90CSpuOw0KLQluYW1lX2hhc2hfZW50X3QJKnA7DQotDQotCWZvciAoaSA9 IDA7IGkgPCBuYW1ldGFiLT5zaXplOyBpKyspIHsNCi0JCWZvciAocCA9IG5h bWV0YWItPnRhYltpXTsgcDsgcCA9IG4pIHsNCi0JCQluID0gcC0+bmV4dDsN Ci0JCQlmcmVlKHApOw0KLQkJfQ0KKwlmb3IgKHAgPSBoYXNodGFiLT5maXJz dDsgcDsgcCA9IHAtPm5leHRieW9yZGVyKSB7DQorCQluYW1lID0gbWFsbG9j KHAtPm5hbWVsZW4pOw0KKwkJbWVtY3B5KG5hbWUsIHAtPm5hbWUsIHAtPm5h bWVsZW4pOw0KKwkJcC0+bmFtZSA9IG5hbWU7DQogCX0NCi0JZnJlZShuYW1l dGFiKTsNCisJaGFzaHRhYi0+bmFtZXNfZHVwZWQgPSAxOw0KIH0NCiANCi0N CiAvKg0KICAqIFZlcnNpb24gMSBvciAyIGRpcmVjdG9yeSByb3V0aW5lIHdy YXBwZXJzDQogKi8NCkBAIC0xMzg1LDcgKzEzNzgsOCBAQCBsZl9ibG9ja19k aXJfZW50cnlfY2hlY2soeGZzX21vdW50X3QJCSptDQogCQkJZGlyX3N0YWNr X3QJCSpzdGFjaywNCiAJCQlpbm9fdHJlZV9ub2RlX3QJCSpjdXJyZW50X2ly ZWMsDQogCQkJaW50CQkJY3VycmVudF9pbm9fb2Zmc2V0LA0KLQkJCW5hbWVf aGFzaF90YWJfdAkJKm5hbWV0YWIpDQorCQkJZGlyX2hhc2hfdGFiX3QJCSpo YXNodGFiLA0KKwkJCXhmc19kYWJsa190CQlkYV9ibm8pDQogew0KIAl4ZnNf ZGlyX2xlYWZfZW50cnlfdAkqZW50cnk7DQogCWlub190cmVlX25vZGVfdAkJ KmlyZWM7DQpAQCAtMTU0NSw3ICsxNTM5LDkgQEAgbGZfYmxvY2tfZGlyX2Vu dHJ5X2NoZWNrKHhmc19tb3VudF90CQkqbQ0KIAkJLyoNCiAJCSAqIGNoZWNr IGZvciBkdXBsaWNhdGUgbmFtZXMgaW4gZGlyZWN0b3J5Lg0KIAkJICovIA0K LQkJaWYgKCFuYW1lX2hhc2hfYWRkKG5hbWV0YWIsIG5hbWVzdC0+bmFtZSwg ZW50cnktPm5hbWVsZW4pKSB7DQorCQlpZiAoIWRpcl9oYXNoX2FkZChoYXNo dGFiLCAoZGFfYm5vIDw8IG1wLT5tX3NiLnNiX2Jsb2NrbG9nKSArIA0KKwkJ CQkJCWVudHJ5LT5uYW1laWR4LCANCisJCQkJbGlubywgZW50cnktPm5hbWVs ZW4sIG5hbWVzdC0+bmFtZSkpIHsNCiAJCQlkb193YXJuKA0KIAkJXygiZW50 cnkgXCIlc1wiIChpbm8gJWxsdSkgaW4gZGlyICVsbHUgaXMgYSBkdXBsaWNh dGUgbmFtZSIpLA0KIAkJCQlmbmFtZSwgbGlubywgaW5vKTsNCkBAIC0xNjM1 LDcgKzE2MzEsNyBAQCBsb25nZm9ybV9kaXJfZW50cnlfY2hlY2soeGZzX21v dW50X3QJKm1wDQogCQkJZGlyX3N0YWNrX3QJKnN0YWNrLA0KIAkJCWlub190 cmVlX25vZGVfdAkqaXJlYywNCiAJCQlpbnQJCWlub19vZmZzZXQsDQotCQkJ bmFtZV9oYXNoX3RhYl90CSpuYW1ldGFiKQ0KKwkJCWRpcl9oYXNoX3RhYl90 CSpoYXNodGFiKQ0KIHsNCiAJeGZzX2Rpcl9sZWFmYmxvY2tfdAkqbGVhZjsN CiAJeGZzX2J1Zl90CQkqYnA7DQpAQCAtMTY3Nyw4ICsxNjczLDYgQEAgbG9u Z2Zvcm1fZGlyX2VudHJ5X2NoZWNrKHhmc19tb3VudF90CSptcA0KIA0KIAkJ bGVhZiA9ICh4ZnNfZGlyX2xlYWZibG9ja190ICopWEZTX0JVRl9QVFIoYnAp Ow0KIA0KLQkJZGFfYm5vID0gSU5UX0dFVChsZWFmLT5oZHIuaW5mby5mb3J3 LCBBUkNIX0NPTlZFUlQpOw0KLQ0KIAkJaWYgKElOVF9HRVQobGVhZi0+aGRy LmluZm8ubWFnaWMsIEFSQ0hfQ09OVkVSVCkgIT0NCiAJCSAgICBYRlNfRElS X0xFQUZfTUFHSUMpICB7DQogCQkJaWYgKCFub19tb2RpZnkpICB7DQpAQCAt MTY5OSw5ICsxNjkzLDExIEBAIF8oImJhZCBtYWdpYyAjICgweCV4KSBmb3Ig ZGlyIGlubyAlbGx1IGwNCiAJCX0NCiANCiAJCWlmICghc2tpcGl0KQ0KLQkJ CWxmX2Jsb2NrX2Rpcl9lbnRyeV9jaGVjayhtcCwgaW5vLCBsZWFmLCAmZGly dHksDQotCQkJCQkJbnVtX2lsbGVnYWwsIG5lZWRfZG90LCBzdGFjaywNCi0J CQkJCQlpcmVjLCBpbm9fb2Zmc2V0LCBuYW1ldGFiKTsNCisJCQlsZl9ibG9j a19kaXJfZW50cnlfY2hlY2sobXAsIGlubywgbGVhZiwgJmRpcnR5LCANCisJ CQkJCW51bV9pbGxlZ2FsLCBuZWVkX2RvdCwgc3RhY2ssIGlyZWMsIA0KKwkJ CQkJaW5vX29mZnNldCwgaGFzaHRhYiwgZGFfYm5vKTsNCisNCisJCWRhX2Ju byA9IElOVF9HRVQobGVhZi0+aGRyLmluZm8uZm9ydywgQVJDSF9DT05WRVJU KTsNCiANCiAJCUFTU0VSVChkaXJ0eSA9PSAwIHx8IChkaXJ0eSAmJiAhbm9f bW9kaWZ5KSk7DQogDQpAQCAtMTc0NSw2ICsxNzQxLDEyNyBAQCBfKCJjYW4n dCBtYXAgbGVhZiBibG9jayAlZCBpbiBkaXIgJWxsdSwgDQogfQ0KIA0KIC8q DQorICogVW5leHBlY3RlZCBmYWlsdXJlIGR1cmluZyB0aGUgcmVidWlsZCB3 aWxsIGxlYXZlIHRoZSBlbnRyaWVzIGluDQorICogbG9zdCtmb3VuZCBvbiB0 aGUgbmV4dCBydW4NCisgKi8NCisNCitzdGF0aWMgdm9pZCANCitsb25nZm9y bV9kaXIyX3JlYnVpbGQoDQorCXhmc19tb3VudF90CSptcCwNCisJeGZzX2lu b190CWlubywNCisJeGZzX2lub2RlX3QJKmlwLA0KKwlkaXJfaGFzaF90YWJf dAkqaGFzaHRhYikNCit7DQorCWludAkJCWVycm9yOw0KKwlpbnQJCQlucmVz Ow0KKwl4ZnNfdHJhbnNfdAkJKnRwOw0KKwl4ZnNfZmlsZW9mZl90CQlsYXN0 YmxvY2s7DQorCXhmc19mc2Jsb2NrX3QJCWZpcnN0YmxvY2s7DQorCXhmc19i bWFwX2ZyZWVfdAkJZmxpc3Q7DQorCXhmc19pbm9fdAkJcGFyZW50aW5vOw0K Kwl4ZnNfaW5vZGVfdAkJKnBpcDsNCisJaW50CQkJYnloYXNoOw0KKwlkaXJf aGFzaF9lbnRfdAkJKnA7DQorCWludAkJCWNvbW1pdHRlZDsNCisJaW50CQkJ ZG9uZTsNCisJDQorCS8qIA0KKwkgKiB0cmFzaCBkaXJlY3RvcnkgY29tcGxl dGVseSBhbmQgcmVidWlsZCBmcm9tIHNjcmF0Y2ggdXNpbmcgdGhlDQorCSAq IG5hbWUvaW5vZGUgcGFpcnMgaW4gdGhlIGhhc2ggdGFibGUNCisJICovDQor CSANCisJZG9fd2FybihfKCJyZWJ1aWxkaW5nIGRpcmVjdG9yeSBpbm9kZSAl bGx1XG4iKSwgaW5vKTsNCisJDQorCS8qIA0KKwkgKiBmaXJzdCBhdHRlbXB0 IHRvIGxvY2F0ZSB0aGUgcGFyZW50IGlub2RlLCBpZiBpdCBjYW4ndCBiZSBm b3VuZCwNCisJICogd2UnbGwgdXNlIHRoZSBsb3N0K2ZvdW5kIGlub2RlIA0K KwkgKi8NCisJYnloYXNoID0gRElSX0hBU0hfRlVOQyhoYXNodGFiLCBsaWJ4 ZnNfZGFfaGFzaG5hbWUoKHVjaGFyX3QqKSIuLiIsIDIpKTsNCisJcGFyZW50 aW5vID0gb3JwaGFuYWdlX2lubzsNCisJZm9yIChwID0gaGFzaHRhYi0+Ynlo YXNoW2J5aGFzaF07IHA7IHAgPSBwLT5uZXh0YnloYXNoKSB7DQorCQlpZiAo cC0+bmFtZWxlbiA9PSAyICYmIHAtPm5hbWVbMF0gPT0gJy4nICYmIHAtPm5h bWVbMV0gPT0gJy4nKSB7DQorCQkJcGFyZW50aW5vID0gcC0+aW51bTsNCisJ CQlicmVhazsNCisJCX0NCisJfQ0KKw0KKwlYRlNfQk1BUF9JTklUKCZmbGlz dCwgJmZpcnN0YmxvY2spOw0KKwkJDQorCXRwID0gbGlieGZzX3RyYW5zX2Fs bG9jKG1wLCAwKTsNCisJbnJlcyA9IFhGU19SRU1PVkVfU1BBQ0VfUkVTKG1w KTsNCisJZXJyb3IgPSBsaWJ4ZnNfdHJhbnNfcmVzZXJ2ZSh0cCwgbnJlcywg WEZTX1JFTU9WRV9MT0dfUkVTKG1wKSwgMCwNCisJCQlYRlNfVFJBTlNfUEVS TV9MT0dfUkVTLCBYRlNfUkVNT1ZFX0xPR19DT1VOVCk7DQorCWlmIChlcnJv cikNCisJCXJlc19mYWlsZWQoZXJyb3IpOw0KKwlsaWJ4ZnNfdHJhbnNfaWpv aW4odHAsIGlwLCAwKTsNCisJbGlieGZzX3RyYW5zX2lob2xkKHRwLCBpcCk7 DQorCQ0KKwlpZiAoKGVycm9yID0gbGlieGZzX2JtYXBfbGFzdF9vZmZzZXQo dHAsIGlwLCAmbGFzdGJsb2NrLCANCisJCQkJCQlYRlNfREFUQV9GT1JLKSkp DQorCQlkb19lcnJvcihfKCJ4ZnNfYm1hcF9sYXN0X29mZnNldCBmYWlsZWQg LS0gZXJyb3IgLSAlZFxuIiksIA0KKwkJCWVycm9yKTsNCisJDQorCS8qIHJl LWluaXQgdGhlIGRpcmVjdG9yeSB0byBzaG9ydGZvcm0gKi8NCisJaWYgKChl cnJvciA9IGxpYnhmc190cmFuc19pZ2V0KG1wLCB0cCwgcGFyZW50aW5vLCAw LCAwLCAmcGlwKSkpDQorCQlkb19lcnJvcigNCisJCV8oImNvdWxkbid0IGln ZXQgcGFyZW50IGlub2RlICVsbHUgLS0gZXJyb3IgLSAlZFxuIiksDQorCQkJ cGFyZW50aW5vLCBlcnJvcik7DQorDQorCS8qIGZyZWUgYWxsIGRhdGEsIGxl YWYsIG5vZGUgYW5kIGZyZWVzcGFjZSBibG9ja3MgKi8NCisJDQorCWlmICgo ZXJyb3IgPSBsaWJ4ZnNfYnVubWFwaSh0cCwgaXAsIDAsIGxhc3RibG9jaywg DQorCQkJWEZTX0JNQVBJX01FVEFEQVRBLCAwLCAmZmlyc3RibG9jaywgJmZs aXN0LA0KKwkJCSZkb25lKSkpIA0KKwkJZG9fZXJyb3IoXygieGZzX2J1bm1h cGkgZmFpbGVkIC0tIGVycm9yIC0gJWRcbiIpLCBlcnJvcik7DQorCUFTU0VS VChkb25lKTsNCisNCisJbGlieGZzX2RpcjJfaW5pdCh0cCwgaXAsIHBpcCk7 DQorCQ0KKwllcnJvciA9IGxpYnhmc19ibWFwX2ZpbmlzaCgmdHAsICZmbGlz dCwgZmlyc3RibG9jaywgJmNvbW1pdHRlZCk7DQorCQkJCQ0KKwlsaWJ4ZnNf dHJhbnNfY29tbWl0KHRwLCANCisJCQlYRlNfVFJBTlNfUkVMRUFTRV9MT0df UkVTfFhGU19UUkFOU19TWU5DLCAwKTsNCisJCQ0KKwkvKiBnbyB0aHJvdWdo IHRoZSBoYXNoIGxpc3QgYW5kIHJlLWFkZCB0aGUgaW5vZGVzICovDQorDQor CWZvciAocCA9IGhhc2h0YWItPmZpcnN0OyBwOyBwID0gcC0+bmV4dGJ5b3Jk ZXIpIHsNCisJCQ0KKwkJaWYgKHAtPm5hbWVbMF0gPT0gJy8nIHx8IChwLT5u YW1lWzBdID09ICcuJyAmJiAocC0+bmFtZWxlbiA9PSAxIA0KKwkJCQl8fCAo cC0+bmFtZWxlbiA9PSAyICYmIHAtPm5hbWVbMV0gPT0gJy4nKSkpKQ0KKwkJ CWNvbnRpbnVlOw0KKwkJDQorCQl0cCA9IGxpYnhmc190cmFuc19hbGxvYyht cCwgMCk7DQorCQlucmVzID0gWEZTX0NSRUFURV9TUEFDRV9SRVMobXAsIHAt Pm5hbWVsZW4pOw0KKwkJaWYgKChlcnJvciA9IGxpYnhmc190cmFuc19yZXNl cnZlKHRwLCBucmVzLCANCisJCQkJWEZTX0NSRUFURV9MT0dfUkVTKG1wKSwg MCwNCisJCQkJWEZTX1RSQU5TX1BFUk1fTE9HX1JFUywgWEZTX0NSRUFURV9M T0dfQ09VTlQpKSkNCisJCQlkb19lcnJvcigNCisJXygic3BhY2UgcmVzZXJ2 YXRpb24gZmFpbGVkICglZCksIGZpbGVzeXN0ZW0gbWF5IGJlIG91dCBvZiBz cGFjZVxuIiksDQorCQkJCWVycm9yKTsNCisNCisJCWxpYnhmc190cmFuc19p am9pbih0cCwgaXAsIDApOw0KKwkJbGlieGZzX3RyYW5zX2lob2xkKHRwLCBp cCk7DQorDQorCQlYRlNfQk1BUF9JTklUKCZmbGlzdCwgJmZpcnN0YmxvY2sp Ow0KKwkJaWYgKChlcnJvciA9IGxpYnhmc19kaXIyX2NyZWF0ZW5hbWUodHAs IGlwLCAoY2hhciopcC0+bmFtZSwgDQorCQkJCXAtPm5hbWVsZW4sIHAtPmlu dW0sICZmaXJzdGJsb2NrLCAmZmxpc3QsIG5yZXMpKSkNCisJCQlkb19lcnJv cigNCitfKCJuYW1lIGNyZWF0ZSBmYWlsZWQgaW4gaW5vICVsbHUgKCVkKSwg ZmlsZXN5c3RlbSBtYXkgYmUgb3V0IG9mIHNwYWNlXG4iKSwNCisJCQkJaW5v LCBlcnJvcik7DQorDQorCQlpZiAoKGVycm9yID0gbGlieGZzX2JtYXBfZmlu aXNoKCZ0cCwgJmZsaXN0LCBmaXJzdGJsb2NrLCANCisJCQkJJmNvbW1pdHRl ZCkpKQ0KKwkJCWRvX2Vycm9yKA0KKwlfKCJibWFwIGZpbmlzaCBmYWlsZWQg KCVkKSwgZmlsZXN5c3RlbSBtYXkgYmUgb3V0IG9mIHNwYWNlXG4iKSwNCisJ CQkJZXJyb3IpOw0KKw0KKwkJbGlieGZzX3RyYW5zX2NvbW1pdCh0cCwgDQor CQkJCVhGU19UUkFOU19SRUxFQVNFX0xPR19SRVN8WEZTX1RSQU5TX1NZTkMs IDApOw0KKwl9DQorfQ0KKw0KKw0KKy8qDQogICogS2lsbCBhIGJsb2NrIGlu IGEgdmVyc2lvbiAyIGlub2RlLg0KICAqIE1ha2VzIGl0cyBvd24gdHJhbnNh Y3Rpb24uDQogICovDQpAQCAtMTgwNyw3ICsxOTI0LDYgQEAgbG9uZ2Zvcm1f ZGlyMl9lbnRyeV9jaGVja19kYXRhKA0KIAl4ZnNfZGFidWZfdAkJKipicHAs DQogCWRpcl9oYXNoX3RhYl90CQkqaGFzaHRhYiwNCiAJZnJlZXRhYl90CQkq KmZyZWV0YWJwLA0KLQluYW1lX2hhc2hfdGFiX3QJCSpuYW1ldGFiLA0KIAl4 ZnNfZGFibGtfdAkJZGFfYm5vLA0KIAlpbnQJCQlpc2Jsb2NrKQ0KIHsNCkBA IC0xODI4LDYgKzE5NDQsNyBAQCBsb25nZm9ybV9kaXIyX2VudHJ5X2NoZWNr X2RhdGEoDQogCWZyZWV0YWJfdAkJKmZyZWV0YWI7DQogCWludAkJCWk7DQog CWludAkJCWlub19vZmZzZXQ7DQorCXhmc19pbm9fdAkJaW51bTsNCiAJaW5v X3RyZWVfbm9kZV90CQkqaXJlYzsNCiAJaW50CQkJanVua2l0Ow0KIAlpbnQJ CQlsYXN0ZnJlZTsNCkBAIC0xOTU2LDggKzIwNzMsNyBAQCBsb25nZm9ybV9k aXIyX2VudHJ5X2NoZWNrX2RhdGEoDQogCWxpYnhmc190cmFuc19pam9pbih0 cCwgaXAsIDApOw0KIAlsaWJ4ZnNfdHJhbnNfaWhvbGQodHAsIGlwKTsNCiAJ bGlieGZzX2RhX2Jqb2luKHRwLCBicCk7DQotCWlmIChpc2Jsb2NrKQ0KLQkJ bGlieGZzX2RhX2Job2xkKHRwLCBicCk7DQorCWxpYnhmc19kYV9iaG9sZCh0 cCwgYnApOw0KIAlYRlNfQk1BUF9JTklUKCZmbGlzdCwgJmZpcnN0YmxvY2sp Ow0KIAlpZiAoSU5UX0dFVChkLT5oZHIubWFnaWMsIEFSQ0hfQ09OVkVSVCkg IT0gd2FudG1hZ2ljKSB7DQogCQlkb193YXJuKF8oImJhZCBkaXJlY3Rvcnkg YmxvY2sgbWFnaWMgIyAlI3ggZm9yIGRpcmVjdG9yeSBpbm9kZSAiDQpAQCAt MTk4Nyw3ICsyMTAzLDcgQEAgbG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVja19k YXRhKA0KIAl3aGlsZSAocHRyIDwgZW5kcHRyKSB7DQogCQlkdXAgPSAoeGZz X2RpcjJfZGF0YV91bnVzZWRfdCAqKXB0cjsNCiAJCWlmIChJTlRfR0VUKGR1 cC0+ZnJlZXRhZywgQVJDSF9DT05WRVJUKSA9PQ0KLQkJICAgIFhGU19ESVIy X0RBVEFfRlJFRV9UQUcpIHsNCisJCSAgICAJCQkJWEZTX0RJUjJfREFUQV9G UkVFX1RBRykgew0KIAkJCWlmIChsYXN0ZnJlZSkgew0KIAkJCQlkb193YXJu KF8oImRpcmVjdG9yeSBpbm9kZSAlbGx1IGJsb2NrICV1IGhhcyAiDQogCQkJ CQkgICJjb25zZWN1dGl2ZSBmcmVlIGVudHJpZXM6ICIpLA0KQEAgLTIwMTEs MTAgKzIxMjcsMjQgQEAgbG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVja19kYXRh KA0KIAkJYWRkciA9IFhGU19ESVIyX0RCX09GRl9UT19EQVRBUFRSKG1wLCBk YiwgcHRyIC0gKGNoYXIgKilkKTsNCiAJCWRlcCA9ICh4ZnNfZGlyMl9kYXRh X2VudHJ5X3QgKilwdHI7DQogCQlwdHIgKz0gWEZTX0RJUjJfREFUQV9FTlRT SVpFKGRlcC0+bmFtZWxlbik7DQorCQlpbnVtID0gSU5UX0dFVChkZXAtPmlu dW1iZXIsIEFSQ0hfQ09OVkVSVCk7DQogCQlsYXN0ZnJlZSA9IDA7DQotCQlk aXJfaGFzaF9hZGQoaGFzaHRhYiwNCi0JCQlsaWJ4ZnNfZGFfaGFzaG5hbWUo KHVjaGFyX3QgKilkZXAtPm5hbWUsIGRlcC0+bmFtZWxlbiksDQotCQkJYWRk ciwgZGVwLT5uYW1lWzBdID09ICcvJyk7DQorCQlpZiAoIWRpcl9oYXNoX2Fk ZChoYXNodGFiLCBhZGRyLCBpbnVtLCBkZXAtPm5hbWVsZW4sIA0KKwkJCQlk ZXAtPm5hbWUpKSB7DQorCQkJZG9fd2FybigNCisJCV8oImVudHJ5IFwiJXNc IiAoaW5vICVsbHUpIGluIGRpciAlbGx1IGlzIGEgZHVwbGljYXRlIG5hbWUi KSwNCisJCQkJZm5hbWUsIGludW0sIGlwLT5pX2lubyk7DQorCQkJaWYgKCFu b19tb2RpZnkpIHsNCisJCQkJaWYgKHZlcmJvc2UpDQorCQkJCQlkb193YXJu KA0KKwkJCQkJXygiLCBtYXJraW5nIGVudHJ5IHRvIGJlIGp1bmtlZFxuIikp Ow0KKwkJCQllbHNlDQorCQkJCQlkb193YXJuKCJcbiIpOw0KKwkJCX0gZWxz ZSB7DQorCQkJCWRvX3dhcm4oXygiLCB3b3VsZCBqdW5rIGVudHJ5XG4iKSk7 DQorCQkJfQ0KKwkJCWRlcC0+bmFtZVswXSA9ICcvJzsNCisJCX0NCiAJCS8q DQogCQkgKiBza2lwIGJvZ3VzIGVudHJpZXMgKGxlYWRpbmcgJy8nKS4gIHRo ZXknbGwgYmUgZGVsZXRlZA0KIAkJICogbGF0ZXIuICBtdXN0IHN0aWxsIGxv ZyBpdCwgZWxzZSB3ZSBsZWFrIHJlZmVyZW5jZXMgdG8NCkBAIC0yMDI5LDcg KzIxNTksNyBAQCBsb25nZm9ybV9kaXIyX2VudHJ5X2NoZWNrX2RhdGEoDQog CQlqdW5raXQgPSAwOw0KIAkJYmNvcHkoZGVwLT5uYW1lLCBmbmFtZSwgZGVw LT5uYW1lbGVuKTsNCiAJCWZuYW1lW2RlcC0+bmFtZWxlbl0gPSAnXDAnOw0K LQkJQVNTRVJUKElOVF9HRVQoZGVwLT5pbnVtYmVyLCBBUkNIX0NPTlZFUlQp ICE9IE5VTExGU0lOTyk7DQorCQlBU1NFUlQoaW51bSAhPSBOVUxMRlNJTk8p Ow0KIAkJLyoNCiAJCSAqIHNraXAgdGhlICcuLicgZW50cnkgc2luY2UgaXQn cyBjaGVja2VkIHdoZW4gdGhlDQogCQkgKiBkaXJlY3RvcnkgaXMgcmVhY2hl ZCBieSBzb21ldGhpbmcgZWxzZS4gIGlmIGl0IG5ldmVyDQpAQCAtMjAzOSw3 ICsyMTY5LDcgQEAgbG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVja19kYXRhKA0K IAkJaWYgKGRlcC0+bmFtZWxlbiA9PSAyICYmIGRlcC0+bmFtZVswXSA9PSAn LicgJiYNCiAJCSAgICBkZXAtPm5hbWVbMV0gPT0gJy4nKQ0KIAkJCWNvbnRp bnVlOw0KLQkJQVNTRVJUKG5vX21vZGlmeSB8fCAhdmVyaWZ5X2ludW0obXAs IElOVF9HRVQoZGVwLT5pbnVtYmVyLCBBUkNIX0NPTlZFUlQpKSk7DQorCQlB U1NFUlQobm9fbW9kaWZ5IHx8ICF2ZXJpZnlfaW51bShtcCwgaW51bSkpOw0K IAkJLyoNCiAJCSAqIHNwZWNpYWwgY2FzZSB0aGUgLiBlbnRyeS4gIHdlIGtu b3cgdGhlcmUncyBvbmx5IG9uZQ0KIAkJICogJy4nIGFuZCBvbmx5ICcuJyBw b2ludHMgdG8gaXRzZWxmIGJlY2F1c2UgYm9ndXMgZW50cmllcw0KQEAgLTIw NDksNyArMjE3OSw3IEBAIGxvbmdmb3JtX2RpcjJfZW50cnlfY2hlY2tfZGF0 YSgNCiAJCSAqICcuLicgaXMgYWxyZWFkeSBhY2NvdW50ZWQgZm9yIG9yIHdp bGwgYmUgdGFrZW4gY2FyZQ0KIAkJICogb2Ygd2hlbiBkaXJlY3RvcnkgaXMg bW92ZWQgdG8gb3JwaGFuYWdlLg0KIAkJICovDQotCQlpZiAoaXAtPmlfaW5v ID09IElOVF9HRVQoZGVwLT5pbnVtYmVyLCBBUkNIX0NPTlZFUlQpKSAgew0K KwkJaWYgKGlwLT5pX2lubyA9PSBpbnVtKSAgew0KIAkJCUFTU0VSVChkZXAt Pm5hbWVbMF0gPT0gJy4nICYmIGRlcC0+bmFtZWxlbiA9PSAxKTsNCiAJCQlh ZGRfaW5vZGVfcmVmKGN1cnJlbnRfaXJlYywgY3VycmVudF9pbm9fb2Zmc2V0 KTsNCiAJCQkqbmVlZF9kb3QgPSAwOw0KQEAgLTIwNjIsMjMgKzIxOTIsMTgg QEAgbG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVja19kYXRhKA0KIAkJICoganVz dCBza2lwIGl0LiAgbm8gbmVlZCB0byBwcm9jZXNzIGl0IGFuZCBpdCdzIC4u DQogCQkgKiBsaW5rIGlzIGFscmVhZHkgYWNjb3VudGVkIGZvci4NCiAJCSAq Lw0KLQkJaWYgKElOVF9HRVQoZGVwLT5pbnVtYmVyLCBBUkNIX0NPTlZFUlQp ID09IG9ycGhhbmFnZV9pbm8gJiYNCi0JCSAgICBzdHJjbXAoZm5hbWUsIE9S UEhBTkFHRSkgPT0gMCkNCisJCWlmIChpbnVtID09IG9ycGhhbmFnZV9pbm8g JiYgc3RyY21wKGZuYW1lLCBPUlBIQU5BR0UpID09IDApDQogCQkJY29udGlu dWU7DQogCQkvKg0KIAkJICogc2tpcCBlbnRyaWVzIHdpdGggYm9ndXMgaW51 bWJlcnMgaWYgd2UncmUgaW4gbm8gbW9kaWZ5IG1vZGUNCiAJCSAqLw0KLQkJ aWYgKG5vX21vZGlmeSAmJg0KLQkJICAgIHZlcmlmeV9pbnVtKG1wLCBJTlRf R0VUKGRlcC0+aW51bWJlciwgQVJDSF9DT05WRVJUKSkpDQorCQlpZiAobm9f bW9kaWZ5ICYmIHZlcmlmeV9pbnVtKG1wLCBpbnVtKSkNCiAJCQljb250aW51 ZTsNCiAJCS8qDQogCQkgKiBvaywgbm93IGhhbmRsZSB0aGUgcmVzdCBvZiB0 aGUgY2FzZXMgYmVzaWRlcyAnLicgYW5kICcuLicNCiAJCSAqLw0KLQkJaXJl YyA9IGZpbmRfaW5vZGVfcmVjKA0KLQkJCVhGU19JTk9fVE9fQUdOTyhtcCwN Ci0JCQkJSU5UX0dFVChkZXAtPmludW1iZXIsIEFSQ0hfQ09OVkVSVCkpLA0K LQkJCVhGU19JTk9fVE9fQUdJTk8obXAsDQotCQkJCUlOVF9HRVQoZGVwLT5p bnVtYmVyLCBBUkNIX0NPTlZFUlQpKSk7DQorCQlpcmVjID0gZmluZF9pbm9k ZV9yZWMoWEZTX0lOT19UT19BR05PKG1wLCBpbnVtKSwNCisJCQkJCVhGU19J Tk9fVE9fQUdJTk8obXAsIGludW0pKTsNCiAJCWlmIChpcmVjID09IE5VTEwp ICB7DQogCQkJbmJhZCsrOw0KIAkJCWRvX3dhcm4oXygiZW50cnkgXCIlc1wi IGluIGRpcmVjdG9yeSBpbm9kZSAlbGx1IHBvaW50cyAiDQpAQCAtMjA5Myw5 ICsyMjE4LDcgQEAgbG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVja19kYXRhKA0K IAkJCX0NCiAJCQljb250aW51ZTsNCiAJCX0NCi0JCWlub19vZmZzZXQgPSBY RlNfSU5PX1RPX0FHSU5PKG1wLA0KLQkJCQlJTlRfR0VUKGRlcC0+aW51bWJl ciwgQVJDSF9DT05WRVJUKSkgLQ0KLQkJCQkJaXJlYy0+aW5vX3N0YXJ0bnVt Ow0KKwkJaW5vX29mZnNldCA9IFhGU19JTk9fVE9fQUdJTk8obXAsIGludW0p IC0gaXJlYy0+aW5vX3N0YXJ0bnVtOw0KIAkJLyoNCiAJCSAqIGlmIGl0J3Mg YSBmcmVlIGlub2RlLCBibG93IG91dCB0aGUgZW50cnkuDQogCQkgKiBieSBu b3csIGFueSBpbm9kZSB0aGF0IHdlIHRoaW5rIGlzIGZyZWUNCkBAIC0yMTA2 LDE4ICsyMjI5LDEzIEBAIGxvbmdmb3JtX2RpcjJfZW50cnlfY2hlY2tfZGF0 YSgNCiAJCQkgKiBkb24ndCBjb21wbGFpbiBpZiB0aGlzIGVudHJ5IHBvaW50 cyB0byB0aGUgb2xkDQogCQkJICogYW5kIG5vdy1mcmVlIGxvc3QrZm91bmQg aW5vZGUNCiAJCQkgKi8NCi0JCQlpZiAodmVyYm9zZSB8fCBub19tb2RpZnkg fHwNCi0JCQkgICAgSU5UX0dFVChkZXAtPmludW1iZXIsIEFSQ0hfQ09OVkVS VCkgIT0NCi0JCQkgICAgb2xkX29ycGhhbmFnZV9pbm8pDQorCQkJaWYgKHZl cmJvc2UgfHwgbm9fbW9kaWZ5IHx8IGludW0gIT0gb2xkX29ycGhhbmFnZV9p bm8pDQogCQkJCWRvX3dhcm4oDQogCV8oImVudHJ5IFwiJXNcIiBpbiBkaXJl Y3RvcnkgaW5vZGUgJWxsdSBwb2ludHMgdG8gZnJlZSBpbm9kZSAlbGx1Iiks DQotCQkJCQlmbmFtZSwgaXAtPmlfaW5vLA0KLQkJCQkJSU5UX0dFVChkZXAt PmludW1iZXIsIEFSQ0hfQ09OVkVSVCkpOw0KKwkJCQkJZm5hbWUsIGlwLT5p X2lubywgaW51bSk7DQogCQkJbmJhZCsrOw0KIAkJCWlmICghbm9fbW9kaWZ5 KSAgew0KLQkJCQlpZiAodmVyYm9zZSB8fA0KLQkJCQkgICAgSU5UX0dFVChk ZXAtPmludW1iZXIsIEFSQ0hfQ09OVkVSVCkgIT0NCi0JCQkJICAgIG9sZF9v cnBoYW5hZ2VfaW5vKQ0KKwkJCQlpZiAodmVyYm9zZSB8fCBpbnVtICE9IG9s ZF9vcnBoYW5hZ2VfaW5vKQ0KIAkJCQkJZG9fd2FybigNCiAJCQkJCV8oIiwg bWFya2luZyBlbnRyeSB0byBiZSBqdW5rZWRcbiIpKTsNCiAJCQkJZWxzZQ0K QEAgLTIxMzAsMjggKzIyNDgsNiBAQCBsb25nZm9ybV9kaXIyX2VudHJ5X2No ZWNrX2RhdGEoDQogCQkJY29udGludWU7DQogCQl9DQogCQkvKg0KLQkJICog Y2hlY2sgZm9yIGR1cGxpY2F0ZSBuYW1lcyBpbiBkaXJlY3RvcnkuDQotCQkg Ki8gDQotCQlpZiAoIW5hbWVfaGFzaF9hZGQobmFtZXRhYiwgZGVwLT5uYW1l LCBkZXAtPm5hbWVsZW4pKSB7DQotCQkJZG9fd2FybigNCi0JCV8oImVudHJ5 IFwiJXNcIiAoaW5vICVsbHUpIGluIGRpciAlbGx1IGlzIGEgZHVwbGljYXRl IG5hbWUiKSwNCi0JCQkJZm5hbWUsIElOVF9HRVQoZGVwLT5pbnVtYmVyLCBB UkNIX0NPTlZFUlQpLA0KLQkJCQlpcC0+aV9pbm8pOw0KLQkJCW5iYWQrKzsN Ci0JCQlpZiAoIW5vX21vZGlmeSkgew0KLQkJCQlpZiAodmVyYm9zZSkNCi0J CQkJCWRvX3dhcm4oDQotCQkJCQlfKCIsIG1hcmtpbmcgZW50cnkgdG8gYmUg anVua2VkXG4iKSk7DQotCQkJCWVsc2UNCi0JCQkJCWRvX3dhcm4oIlxuIik7 DQotCQkJCWRlcC0+bmFtZVswXSA9ICcvJzsNCi0JCQkJbGlieGZzX2RpcjJf ZGF0YV9sb2dfZW50cnkodHAsIGJwLCBkZXApOw0KLQkJCX0gZWxzZSB7DQot CQkJCWRvX3dhcm4oXygiLCB3b3VsZCBqdW5rIGVudHJ5XG4iKSk7DQotCQkJ fQ0KLQkJCWNvbnRpbnVlOw0KLQkJfQ0KLQkJLyoNCiAJCSAqIGNoZWNrIGVh c3kgY2FzZSBmaXJzdCwgcmVndWxhciBpbm9kZSwganVzdCBidW1wDQogCQkg KiB0aGUgbGluayBjb3VudCBhbmQgY29udGludWUNCiAJCSAqLw0KQEAgLTIx NzIsMjIgKzIyNjgsMTcgQEAgbG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVja19k YXRhKA0KIAkJCWp1bmtpdCA9IDE7DQogCQkJZG9fd2FybigNCiBfKCJlbnRy eSBcIiVzXCIgaW4gZGlyICVsbHUgcG9pbnRzIHRvIGFuIGFscmVhZHkgY29u bmVjdGVkIGRpcmVjdG9yeSBpbm9kZSAlbGx1LFxuIiksDQotCQkJCWZuYW1l LCBpcC0+aV9pbm8sDQotCQkJCUlOVF9HRVQoZGVwLT5pbnVtYmVyLCBBUkNI X0NPTlZFUlQpKTsNCisJCQkJZm5hbWUsIGlwLT5pX2lubywgaW51bSk7DQog CQl9IGVsc2UgaWYgKHBhcmVudCA9PSBpcC0+aV9pbm8pICB7DQogCQkJYWRk X2lub2RlX3JlYWNoZWQoaXJlYywgaW5vX29mZnNldCk7DQogCQkJYWRkX2lu b2RlX3JlZihjdXJyZW50X2lyZWMsIGN1cnJlbnRfaW5vX29mZnNldCk7DQot CQkJaWYgKCFpc19pbm9kZV9yZWZjaGVja2VkKA0KLQkJCQlJTlRfR0VUKGRl cC0+aW51bWJlciwgQVJDSF9DT05WRVJUKSwgaXJlYywNCi0JCQkJCWlub19v ZmZzZXQpKQ0KLQkJCQlwdXNoX2RpcihzdGFjaywNCi0JCQkJCUlOVF9HRVQo ZGVwLT5pbnVtYmVyLCBBUkNIX0NPTlZFUlQpKTsNCisJCQlpZiAoIWlzX2lu b2RlX3JlZmNoZWNrZWQoaW51bSwgaXJlYywgaW5vX29mZnNldCkpDQorCQkJ CXB1c2hfZGlyKHN0YWNrLCBpbnVtKTsNCiAJCX0gZWxzZSAgew0KIAkJCWp1 bmtpdCA9IDE7DQogCQkJZG9fd2FybigNCiBfKCJlbnRyeSBcIiVzXCIgaW4g ZGlyIGlub2RlICVsbHUgaW5jb25zaXN0ZW50IHdpdGggLi4gdmFsdWUgKCVs bHUpIGluIGlubyAlbGx1LFxuIiksDQotCQkJCWZuYW1lLCBpcC0+aV9pbm8s IHBhcmVudCwNCi0JCQkJSU5UX0dFVChkZXAtPmludW1iZXIsIEFSQ0hfQ09O VkVSVCkpOw0KKwkJCQlmbmFtZSwgaXAtPmlfaW5vLCBwYXJlbnQsIGludW0p Ow0KIAkJfQ0KIAkJaWYgKGp1bmtpdCkgIHsNCiAJCQlqdW5raXQgPSAwOw0K QEAgLTIxOTUsOSArMjI4Niw3IEBAIF8oImVudHJ5IFwiJXNcIiBpbiBkaXIg aW5vZGUgJWxsdSBpbmNvbnMNCiAJCQlpZiAoIW5vX21vZGlmeSkgIHsNCiAJ CQkJZGVwLT5uYW1lWzBdID0gJy8nOw0KIAkJCQlsaWJ4ZnNfZGlyMl9kYXRh X2xvZ19lbnRyeSh0cCwgYnAsIGRlcCk7DQotCQkJCWlmICh2ZXJib3NlIHx8 DQotCQkJCSAgICBJTlRfR0VUKGRlcC0+aW51bWJlciwgQVJDSF9DT05WRVJU KSAhPQ0KLQkJCQkgICAgb2xkX29ycGhhbmFnZV9pbm8pDQorCQkJCWlmICh2 ZXJib3NlIHx8IGludW0gIT0gb2xkX29ycGhhbmFnZV9pbm8pDQogCQkJCQlk b193YXJuKA0KIAkJCQkJXygiXHR3aWxsIGNsZWFyIGVudHJ5IFwiJXNcIlxu IiksDQogCQkJCQkJZm5hbWUpOw0KQEAgLTIyMTIsOCArMjMwMSw2IEBAIF8o ImVudHJ5IFwiJXNcIiBpbiBkaXIgaW5vZGUgJWxsdSBpbmNvbnMNCiAJCWxp Ynhmc19kaXIyX2RhdGFfZnJlZXNjYW4obXAsIGQsICZuZWVkbG9nLCBOVUxM KTsNCiAJaWYgKG5lZWRsb2cpDQogCQlsaWJ4ZnNfZGlyMl9kYXRhX2xvZ19o ZWFkZXIodHAsIGJwKTsNCi0JZWxzZSBpZiAoIWlzYmxvY2sgJiYgIW5iYWQp DQotCQlsaWJ4ZnNfZGFfYnJlbHNlKHRwLCBicCk7DQogCWxpYnhmc19ibWFw X2ZpbmlzaCgmdHAsICZmbGlzdCwgZmlyc3RibG9jaywgJmNvbW1pdHRlZCk7 DQogCWxpYnhmc190cmFuc19jb21taXQodHAsIDAsIDApOw0KIAlmcmVldGFi LT5lbnRzW2RiXS52ID0gSU5UX0dFVChkLT5oZHIuYmVzdGZyZWVbMF0ubGVu Z3RoLCBBUkNIX0NPTlZFUlQpOw0KQEAgLTIzMDYsMTkgKzIzOTMsMTkgQEAg bG9uZ2Zvcm1fZGlyMl9jaGVja19ub2RlKA0KIAl4ZnNfZmlsZW9mZl90CQlu ZXh0X2RhX2JubzsNCiAJaW50CQkJc2VldmFsID0gMDsNCiAJaW50CQkJdXNl ZDsNCi0NCisJDQogCWZvciAoZGFfYm5vID0gbXAtPm1fZGlybGVhZmJsaywg bmV4dF9kYV9ibm8gPSAwOw0KIAkgICAgIG5leHRfZGFfYm5vICE9IE5VTExG SUxFT0ZGICYmIGRhX2JubyA8IG1wLT5tX2RpcmZyZWVibGs7DQogCSAgICAg ZGFfYm5vID0gKHhmc19kYWJsa190KW5leHRfZGFfYm5vKSB7DQogCQluZXh0 X2RhX2JubyA9IGRhX2JubyArIG1wLT5tX2RpcmJsa2ZzYnMgLSAxOw0KLQkJ aWYgKGxpYnhmc19ibWFwX25leHRfb2Zmc2V0KE5VTEwsIGlwLCAmbmV4dF9k YV9ibm8sIFhGU19EQVRBX0ZPUkspKQ0KKwkJaWYgKGxpYnhmc19ibWFwX25l eHRfb2Zmc2V0KE5VTEwsIGlwLCAmbmV4dF9kYV9ibm8sIFhGU19EQVRBX0ZP UkspKSANCiAJCQlicmVhazsNCiAJCWlmIChsaWJ4ZnNfZGFfcmVhZF9idWZy KE5VTEwsIGlwLCBkYV9ibm8sIC0xLCAmYnAsDQogCQkJCVhGU19EQVRBX0ZP UkspKSB7DQotCQkJZG9fZXJyb3IoDQotCQkJXygiY2FuJ3QgcmVhZCBibG9j ayAldSBmb3IgZGlyZWN0b3J5IGlub2RlICVsbHVcbiIpLA0KKwkJCWRvX3dh cm4oDQorCQkJXygiY2FuJ3QgcmVhZCBsZWFmIGJsb2NrICV1IGZvciBkaXJl Y3RvcnkgaW5vZGUgJWxsdVxuIiksDQogCQkJCWRhX2JubywgaXAtPmlfaW5v KTsNCi0JCQkvKiBOT1RSRUFDSEVEICovDQorCQkJcmV0dXJuIDE7DQogCQl9 DQogCQlsZWFmID0gYnAtPmRhdGE7DQogCQlpZiAoSU5UX0dFVChsZWFmLT5o ZHIuaW5mby5tYWdpYywgQVJDSF9DT05WRVJUKSAhPQ0KQEAgLTIzNDgsMjMg KzI0MzUsMjQgQEAgbG9uZ2Zvcm1fZGlyMl9jaGVja19ub2RlKA0KIAkJc2Vl dmFsID0gZGlyX2hhc2hfc2VlX2FsbChoYXNodGFiLCBsZWFmLT5lbnRzLCBJ TlRfR0VUKGxlYWYtPmhkci5jb3VudCwgQVJDSF9DT05WRVJUKSwNCiAJCQlJ TlRfR0VUKGxlYWYtPmhkci5zdGFsZSwgQVJDSF9DT05WRVJUKSk7DQogCQls aWJ4ZnNfZGFfYnJlbHNlKE5VTEwsIGJwKTsNCi0JCWlmIChzZWV2YWwgIT0g RElSX0hBU0hfQ0tfT0spDQorCQlpZiAoc2VldmFsICE9IERJUl9IQVNIX0NL X09LKSANCiAJCQlyZXR1cm4gMTsNCiAJfQ0KLQlpZiAoZGlyX2hhc2hfY2hl Y2soaGFzaHRhYiwgaXAsIHNlZXZhbCkpDQorCWlmIChkaXJfaGFzaF9jaGVj ayhoYXNodGFiLCBpcCwgc2VldmFsKSkgDQogCQlyZXR1cm4gMTsNCisJDQog CWZvciAoZGFfYm5vID0gbXAtPm1fZGlyZnJlZWJsaywgbmV4dF9kYV9ibm8g PSAwOw0KIAkgICAgIG5leHRfZGFfYm5vICE9IE5VTExGSUxFT0ZGOw0KIAkg ICAgIGRhX2JubyA9ICh4ZnNfZGFibGtfdCluZXh0X2RhX2Jubykgew0KIAkJ bmV4dF9kYV9ibm8gPSBkYV9ibm8gKyBtcC0+bV9kaXJibGtmc2JzIC0gMTsN Ci0JCWlmIChsaWJ4ZnNfYm1hcF9uZXh0X29mZnNldChOVUxMLCBpcCwgJm5l eHRfZGFfYm5vLCBYRlNfREFUQV9GT1JLKSkNCisJCWlmIChsaWJ4ZnNfYm1h cF9uZXh0X29mZnNldChOVUxMLCBpcCwgJm5leHRfZGFfYm5vLCBYRlNfREFU QV9GT1JLKSkgDQogCQkJYnJlYWs7DQogCQlpZiAobGlieGZzX2RhX3JlYWRf YnVmcihOVUxMLCBpcCwgZGFfYm5vLCAtMSwgJmJwLA0KIAkJCQlYRlNfREFU QV9GT1JLKSkgew0KLQkJCWRvX2Vycm9yKF8oImNhbid0IHJlYWQgYmxvY2sg JXUgZm9yIGRpcmVjdG9yeSBpbm9kZSAiDQotCQkJCSAgICIlbGx1XG4iKSwN CisJCQlkb193YXJuKA0KKwkJXygiY2FuJ3QgcmVhZCBmcmVlc3BhY2UgYmxv Y2sgJXUgZm9yIGRpcmVjdG9yeSBpbm9kZSAlbGx1XG4iKSwNCiAJCQkJZGFf Ym5vLCBpcC0+aV9pbm8pOw0KLQkJCS8qIE5PVFJFQUNIRUQgKi8NCisJCQly ZXR1cm4gMTsNCiAJCX0NCiAJCWZyZWUgPSBicC0+ZGF0YTsNCiAJCWZkYiA9 IFhGU19ESVIyX0RBX1RPX0RCKG1wLCBkYV9ibm8pOw0KQEAgLTI0MTgsMzg4 ICsyNTA2LDkgQEAgbG9uZ2Zvcm1fZGlyMl9jaGVja19ub2RlKA0KIH0NCiAN CiAvKg0KLSAqIFJlYnVpbGQgYSBkaXJlY3Rvcnk6IHNldCB1cC4NCi0gKiBU dXJuIGl0IGludG8gYSBub2RlLWZvcm1hdCBkaXJlY3Rvcnkgd2l0aCBubyBj b250ZW50cyBpbiB0aGUNCi0gKiB1cHBlciBhcmVhLiAgQWxzbyBoYXMgY29y cmVjdCBmcmVlc3BhY2UgYmxvY2tzLg0KLSAqLw0KLXZvaWQNCi1sb25nZm9y bV9kaXIyX3JlYnVpbGRfc2V0dXAoDQotCXhmc19tb3VudF90CQkqbXAsDQot CXhmc19pbm9fdAkJaW5vLA0KLQl4ZnNfaW5vZGVfdAkJKmlwLA0KLQlmcmVl dGFiX3QJCSpmcmVldGFiKQ0KLXsNCi0JeGZzX2RhX2FyZ3NfdAkJYXJnczsN Ci0JaW50CQkJY29tbWl0dGVkOw0KLQl4ZnNfZGlyMl9kYXRhX3QJCSpkYXRh ID0gTlVMTDsNCi0JeGZzX2RhYnVmX3QJCSpkYnA7DQotCWludAkJCWVycm9y Ow0KLQl4ZnNfZGlyMl9kYl90CQlmYm5vOw0KLQl4ZnNfZGFidWZfdAkJKmZi cDsNCi0JeGZzX2ZzYmxvY2tfdAkJZmlyc3RibG9jazsNCi0JeGZzX2JtYXBf ZnJlZV90CQlmbGlzdDsNCi0JeGZzX2RpcjJfZnJlZV90CQkqZnJlZTsNCi0J aW50CQkJaTsNCi0JaW50CQkJajsNCi0JeGZzX2RhYmxrX3QJCWxibGtubzsN Ci0JeGZzX2RhYnVmX3QJCSpsYnA7DQotCXhmc19kaXIyX2xlYWZfdAkJKmxl YWY7DQotCWludAkJCW5yZXM7DQotCXhmc190cmFuc190CQkqdHA7DQotDQot CS8qIHJlYWQgZmlyc3QgZGlyZWN0b3J5IGJsb2NrICovDQotCXRwID0gbGli eGZzX3RyYW5zX2FsbG9jKG1wLCAwKTsNCi0JbnJlcyA9IFhGU19EQUVOVEVS X1NQQUNFX1JFUyhtcCwgWEZTX0RBVEFfRk9SSyk7DQotCWVycm9yID0gbGli eGZzX3RyYW5zX3Jlc2VydmUodHAsDQotCQlucmVzLCBYRlNfQ1JFQVRFX0xP R19SRVMobXApLCAwLCBYRlNfVFJBTlNfUEVSTV9MT0dfUkVTLA0KLQkJWEZT X0NSRUFURV9MT0dfQ09VTlQpOw0KLQlpZiAoZXJyb3IpDQotCQlyZXNfZmFp bGVkKGVycm9yKTsNCi0JbGlieGZzX3RyYW5zX2lqb2luKHRwLCBpcCwgMCk7 DQotCWxpYnhmc190cmFuc19paG9sZCh0cCwgaXApOw0KLQlYRlNfQk1BUF9J TklUKCZmbGlzdCwgJmZpcnN0YmxvY2spOw0KLQlpZiAobGlieGZzX2RhX3Jl YWRfYnVmKHRwLCBpcCwgbXAtPm1fZGlyZGF0YWJsaywgLTIsICZkYnAsDQot CQkJWEZTX0RBVEFfRk9SSykpIHsNCi0JCWRvX2Vycm9yKF8oImNhbid0IHJl YWQgYmxvY2sgJXUgZm9yIGRpcmVjdG9yeSBpbm9kZSAlbGx1XG4iKSwNCi0J CQltcC0+bV9kaXJkYXRhYmxrLCBpbm8pOw0KLQkJLyogTk9UUkVBQ0hFRCAq Lw0KLQl9DQotDQotCWlmIChkYnApDQotCQlkYXRhID0gZGJwLT5kYXRhOw0K LQ0KLQkvKiBjaGVjayBmb3IgYmxvY2sgZm9ybWF0IGRpcmVjdG9yeSAqLw0K LQlpZiAoZGF0YSAmJg0KLQkgICAgSU5UX0dFVCgoZGF0YSktPmhkci5tYWdp YywgQVJDSF9DT05WRVJUKSA9PSBYRlNfRElSMl9CTE9DS19NQUdJQykgew0K LQkJeGZzX2RpcjJfYmxvY2tfdAkqYmxvY2s7DQotCQl4ZnNfZGlyMl9sZWFm X2VudHJ5X3QJKmJscDsNCi0JCXhmc19kaXIyX2Jsb2NrX3RhaWxfdAkqYnRw Ow0KLQkJaW50CQkJbmVlZGxvZzsNCi0JCWludAkJCW5lZWRzY2FuOw0KLQ0K LQkJLyogY29udmVydCBkaXJlY3RvcnkgYmxvY2sgZnJvbSBibG9jayBmb3Jt YXQgdG8gZGF0YSBmb3JtYXQgKi8NCi0JCUlOVF9TRVQoZGF0YS0+aGRyLm1h Z2ljLCBBUkNIX0NPTlZFUlQsIFhGU19ESVIyX0RBVEFfTUFHSUMpOw0KLQ0K LQkJLyogY29uc3RydWN0IGZyZWVsaXN0ICovDQotCQlibG9jayA9ICh4ZnNf ZGlyMl9ibG9ja190ICopZGF0YTsNCi0JCWJ0cCA9IFhGU19ESVIyX0JMT0NL X1RBSUxfUChtcCwgYmxvY2spOw0KLQkJYmxwID0gWEZTX0RJUjJfQkxPQ0tf TEVBRl9QKGJ0cCk7DQotCQluZWVkbG9nID0gbmVlZHNjYW4gPSAwOw0KLQkJ bGlieGZzX2RpcjJfZGF0YV9tYWtlX2ZyZWUodHAsIGRicCwgKGNoYXIgKili bHAgLSAoY2hhciAqKWJsb2NrLA0KLQkJCShjaGFyICopYmxvY2sgKyBtcC0+ bV9kaXJibGtzaXplIC0gKGNoYXIgKilibHAsDQotCQkJJm5lZWRsb2csICZu ZWVkc2Nhbik7DQotCQlpZiAobmVlZHNjYW4pDQotCQkJbGlieGZzX2RpcjJf ZGF0YV9mcmVlc2NhbihtcCwgZGF0YSwgJm5lZWRsb2csIE5VTEwpOw0KLQkJ bGlieGZzX2RhX2xvZ19idWYodHAsIGRicCwgMCwgbXAtPm1fZGlyYmxrc2l6 ZSAtIDEpOw0KLQl9IGVsc2UgaWYgKGRicCkgew0KLQkJbGlieGZzX2RhX2Jy ZWxzZSh0cCwgZGJwKTsNCi0JfQ0KLQ0KLQkvKiBhbGxvY2F0ZSBibG9ja3Mg Zm9yIGJ0cmVlICovDQotCWJ6ZXJvKCZhcmdzLCBzaXplb2YoYXJncykpOw0K LQlhcmdzLnRyYW5zID0gdHA7DQotCWFyZ3MuZHAgPSBpcDsNCi0JYXJncy53 aGljaGZvcmsgPSBYRlNfREFUQV9GT1JLOw0KLQlhcmdzLmZpcnN0YmxvY2sg PSAmZmlyc3RibG9jazsNCi0JYXJncy5mbGlzdCA9ICZmbGlzdDsNCi0JYXJn cy50b3RhbCA9IG5yZXM7DQotCWlmICgoZXJyb3IgPSBsaWJ4ZnNfZGFfZ3Jv d19pbm9kZSgmYXJncywgJmxibGtubykpIHx8DQotCSAgICAoZXJyb3IgPSBs aWJ4ZnNfZGFfZ2V0X2J1Zih0cCwgaXAsIGxibGtubywgLTEsICZsYnAsIFhG U19EQVRBX0ZPUkspKSkgew0KLQkJZG9fZXJyb3IoXygiY2FuJ3QgYWRkIGJ0 cmVlIGJsb2NrIHRvIGRpcmVjdG9yeSBpbm9kZSAlbGx1XG4iKSwNCi0JCQlp bm8pOw0KLQkJLyogTk9UUkVBQ0hFRCAqLw0KLQl9DQotCWxlYWYgPSBsYnAt PmRhdGE7DQotCWJ6ZXJvKGxlYWYsIG1wLT5tX2RpcmJsa3NpemUpOw0KLQlJ TlRfU0VUKGxlYWYtPmhkci5pbmZvLm1hZ2ljLCBBUkNIX0NPTlZFUlQsIFhG U19ESVIyX0xFQUZOX01BR0lDKTsNCi0JbGlieGZzX2RhX2xvZ19idWYodHAs IGxicCwgMCwgbXAtPm1fZGlyYmxrc2l6ZSAtIDEpOw0KLQlsaWJ4ZnNfYm1h cF9maW5pc2goJnRwLCAmZmxpc3QsIGZpcnN0YmxvY2ssICZjb21taXR0ZWQp Ow0KLQlsaWJ4ZnNfdHJhbnNfY29tbWl0KHRwLCAwLCAwKTsNCi0NCi0JZm9y IChpID0gMDsgaSA8IGZyZWV0YWItPm5lbnRzOyBpICs9IFhGU19ESVIyX01B WF9GUkVFX0JFU1RTKG1wKSkgew0KLQkJdHAgPSBsaWJ4ZnNfdHJhbnNfYWxs b2MobXAsIDApOw0KLQkJbnJlcyA9IFhGU19EQUVOVEVSX1NQQUNFX1JFUyht cCwgWEZTX0RBVEFfRk9SSyk7DQotCQllcnJvciA9IGxpYnhmc190cmFuc19y ZXNlcnZlKHRwLA0KLQkJCW5yZXMsIFhGU19DUkVBVEVfTE9HX1JFUyhtcCks IDAsIFhGU19UUkFOU19QRVJNX0xPR19SRVMsDQotCQkJWEZTX0NSRUFURV9M T0dfQ09VTlQpOw0KLQkJaWYgKGVycm9yKQ0KLQkJCXJlc19mYWlsZWQoZXJy b3IpOw0KLQkJbGlieGZzX3RyYW5zX2lqb2luKHRwLCBpcCwgMCk7DQotCQls aWJ4ZnNfdHJhbnNfaWhvbGQodHAsIGlwKTsNCi0JCVhGU19CTUFQX0lOSVQo JmZsaXN0LCAmZmlyc3RibG9jayk7DQotCQliemVybygmYXJncywgc2l6ZW9m KGFyZ3MpKTsNCi0JCWFyZ3MudHJhbnMgPSB0cDsNCi0JCWFyZ3MuZHAgPSBp cDsNCi0JCWFyZ3Mud2hpY2hmb3JrID0gWEZTX0RBVEFfRk9SSzsNCi0JCWFy Z3MuZmlyc3RibG9jayA9ICZmaXJzdGJsb2NrOw0KLQkJYXJncy5mbGlzdCA9 ICZmbGlzdDsNCi0JCWFyZ3MudG90YWwgPSBucmVzOw0KLQkJaWYgKChlcnJv ciA9IGxpYnhmc19kaXIyX2dyb3dfaW5vZGUoJmFyZ3MsIFhGU19ESVIyX0ZS RUVfU1BBQ0UsDQotCQkJCQkJICZmYm5vKSkgfHwNCi0JCSAgICAoZXJyb3Ig PSBsaWJ4ZnNfZGFfZ2V0X2J1Zih0cCwgaXAsIFhGU19ESVIyX0RCX1RPX0RB KG1wLCBmYm5vKSwNCi0JCQkJCSAgICAtMSwgJmZicCwgWEZTX0RBVEFfRk9S SykpKSB7DQotCQkJZG9fZXJyb3IoXygiY2FuJ3QgYWRkIGZyZWUgYmxvY2sg dG8gZGlyZWN0b3J5IGlub2RlICINCi0JCQkJICAgIiVsbHVcbiIpLA0KLQkJ CQlpbm8pOw0KLQkJCS8qIE5PVFJFQUNIRUQgKi8NCi0JCX0NCi0JCWZyZWUg PSBmYnAtPmRhdGE7DQotCQliemVybyhmcmVlLCBtcC0+bV9kaXJibGtzaXpl KTsNCi0JCUlOVF9TRVQoZnJlZS0+aGRyLm1hZ2ljLCBBUkNIX0NPTlZFUlQs IFhGU19ESVIyX0ZSRUVfTUFHSUMpOw0KLQkJSU5UX1NFVChmcmVlLT5oZHIu Zmlyc3RkYiwgQVJDSF9DT05WRVJULCBpKTsNCi0JCUlOVF9TRVQoZnJlZS0+ aGRyLm52YWxpZCwgQVJDSF9DT05WRVJULCBYRlNfRElSMl9NQVhfRlJFRV9C RVNUUyhtcCkpOw0KLQkJaWYgKGkgKyBJTlRfR0VUKGZyZWUtPmhkci5udmFs aWQsIEFSQ0hfQ09OVkVSVCkgPiBmcmVldGFiLT5uZW50cykNCi0JCQlJTlRf U0VUKGZyZWUtPmhkci5udmFsaWQsIEFSQ0hfQ09OVkVSVCwgZnJlZXRhYi0+ bmVudHMgLSBpKTsNCi0JCWZvciAoaiA9IDA7IGogPCBJTlRfR0VUKGZyZWUt Pmhkci5udmFsaWQsIEFSQ0hfQ09OVkVSVCk7IGorKykgew0KLQkJCUlOVF9T RVQoZnJlZS0+YmVzdHNbal0sIEFSQ0hfQ09OVkVSVCwgZnJlZXRhYi0+ZW50 c1tpICsgal0udik7DQotCQkJaWYgKElOVF9HRVQoZnJlZS0+YmVzdHNbal0s IEFSQ0hfQ09OVkVSVCkgIT0gTlVMTERBVEFPRkYpDQotCQkJCUlOVF9NT0Qo ZnJlZS0+aGRyLm51c2VkLCBBUkNIX0NPTlZFUlQsICsxKTsNCi0JCX0NCi0J CWxpYnhmc19kYV9sb2dfYnVmKHRwLCBmYnAsIDAsIG1wLT5tX2RpcmJsa3Np emUgLSAxKTsNCi0JCWxpYnhmc19ibWFwX2ZpbmlzaCgmdHAsICZmbGlzdCwg Zmlyc3RibG9jaywgJmNvbW1pdHRlZCk7DQotCQlsaWJ4ZnNfdHJhbnNfY29t bWl0KHRwLCAwLCAwKTsNCi0JfQ0KLX0NCi0NCi0vKg0KLSAqIFJlYnVpbGQg dGhlIGVudHJpZXMgZnJvbSBhIHNpbmdsZSBkYXRhIGJsb2NrLg0KLSAqLw0K LXZvaWQNCi1sb25nZm9ybV9kaXIyX3JlYnVpbGRfZGF0YSgNCi0JeGZzX21v dW50X3QJCSptcCwNCi0JeGZzX2lub190CQlpbm8sDQotCXhmc19pbm9kZV90 CQkqaXAsDQotCXhmc19kYWJsa190CQlkYV9ibm8pDQotew0KLQl4ZnNfZGFi dWZfdAkJKmJwOw0KLQl4ZnNfZGlyMl9ibG9ja190YWlsX3QJKmJ0cDsNCi0J aW50CQkJY29tbWl0dGVkOw0KLQl4ZnNfZGlyMl9kYXRhX3QJCSpkYXRhOw0K LQl4ZnNfZGlyMl9kYl90CQlkYm5vOw0KLQl4ZnNfZGlyMl9kYXRhX2VudHJ5 X3QJKmRlcDsNCi0JeGZzX2RpcjJfZGF0YV91bnVzZWRfdAkqZHVwOw0KLQlj aGFyCQkJKmVuZHB0cjsNCi0JaW50CQkJZXJyb3I7DQotCXhmc19kaXIyX2Zy ZWVfdAkJKmZibG9jazsNCi0JeGZzX2RhYnVmX3QJCSpmYnA7DQotCXhmc19k aXIyX2RiX3QJCWZkYjsNCi0JaW50CQkJZmk7DQotCXhmc19mc2Jsb2NrX3QJ CWZpcnN0YmxvY2s7DQotCXhmc19ibWFwX2ZyZWVfdAkJZmxpc3Q7DQotCWlu dAkJCW5lZWRsb2c7DQotCWludAkJCW5lZWRzY2FuOw0KLQlpbnQJCQlucmVz Ow0KLQljaGFyCQkJKnB0cjsNCi0JeGZzX3RyYW5zX3QJCSp0cDsNCi0NCi0J aWYgKGxpYnhmc19kYV9yZWFkX2J1ZihOVUxMLCBpcCwgZGFfYm5vLCBkYV9i bm8gPT0gMCA/IC0yIDogLTEsICZicCwNCi0JCQlYRlNfREFUQV9GT1JLKSkg ew0KLQkJZG9fZXJyb3IoXygiY2FuJ3QgcmVhZCBibG9jayAldSBmb3IgZGly ZWN0b3J5IGlub2RlICVsbHVcbiIpLA0KLQkJCWRhX2JubywgaW5vKTsNCi0J CS8qIE5PVFJFQUNIRUQgKi8NCi0JfQ0KLQlpZiAoZGFfYm5vID09IDAgJiYg YnAgPT0gTlVMTCkNCi0JCS8qDQotCQkgKiBUaGUgYmxvY2sgd2FzIHB1bmNo ZWQgb3V0Lg0KLQkJICovDQotCQlyZXR1cm47DQotCUFTU0VSVChicCk7DQot CWRibm8gPSBYRlNfRElSMl9EQV9UT19EQihtcCwgZGFfYm5vKTsNCi0JZmRi ID0gWEZTX0RJUjJfREJfVE9fRkRCKG1wLCBkYm5vKTsNCi0JaWYgKGxpYnhm c19kYV9yZWFkX2J1ZihOVUxMLCBpcCwgWEZTX0RJUjJfREJfVE9fREEobXAs IGZkYiksIC0xLCAmZmJwLA0KLQkJCVhGU19EQVRBX0ZPUkspKSB7DQotCQlk b19lcnJvcihfKCJjYW4ndCByZWFkIGJsb2NrICV1IGZvciBkaXJlY3Rvcnkg aW5vZGUgJWxsdVxuIiksDQotCQkJWEZTX0RJUjJfREJfVE9fREEobXAsIGZk YiksIGlubyk7DQotCQkvKiBOT1RSRUFDSEVEICovDQotCX0NCi0JZGF0YSA9 IG1hbGxvYyhtcC0+bV9kaXJibGtzaXplKTsNCi0JaWYgKCFkYXRhKSB7DQot CQlkb19lcnJvcigNCi0JCV8oIm1hbGxvYyBmYWlsZWQgaW4gbG9uZ2Zvcm1f ZGlyMl9yZWJ1aWxkX2RhdGEgKCV1IGJ5dGVzKVxuIiksDQotCQkJbXAtPm1f ZGlyYmxrc2l6ZSk7DQotCQlleGl0KDEpOw0KLQl9DQotCWJjb3B5KGJwLT5k YXRhLCBkYXRhLCBtcC0+bV9kaXJibGtzaXplKTsNCi0JcHRyID0gKGNoYXIg KilkYXRhLT51Ow0KLQlpZiAoSU5UX0dFVChkYXRhLT5oZHIubWFnaWMsIEFS Q0hfQ09OVkVSVCkgPT0gWEZTX0RJUjJfQkxPQ0tfTUFHSUMpIHsNCi0JCWJ0 cCA9IFhGU19ESVIyX0JMT0NLX1RBSUxfUChtcCwgKHhmc19kaXIyX2Jsb2Nr X3QgKilkYXRhKTsNCi0JCWVuZHB0ciA9IChjaGFyICopWEZTX0RJUjJfQkxP Q0tfTEVBRl9QKGJ0cCk7DQotCX0gZWxzZQ0KLQkJZW5kcHRyID0gKGNoYXIg KilkYXRhICsgbXAtPm1fZGlyYmxrc2l6ZTsNCi0JZmJsb2NrID0gZmJwLT5k YXRhOw0KLQlmaSA9IFhGU19ESVIyX0RCX1RPX0ZESU5ERVgobXAsIGRibm8p Ow0KLQl0cCA9IGxpYnhmc190cmFuc19hbGxvYyhtcCwgMCk7DQotCWVycm9y ID0gbGlieGZzX3RyYW5zX3Jlc2VydmUodHAsIDAsIFhGU19DUkVBVEVfTE9H X1JFUyhtcCksIDAsDQotCQlYRlNfVFJBTlNfUEVSTV9MT0dfUkVTLCBYRlNf Q1JFQVRFX0xPR19DT1VOVCk7DQotCWlmIChlcnJvcikNCi0JCXJlc19mYWls ZWQoZXJyb3IpOw0KLQlsaWJ4ZnNfdHJhbnNfaWpvaW4odHAsIGlwLCAwKTsN Ci0JbGlieGZzX3RyYW5zX2lob2xkKHRwLCBpcCk7DQotCWxpYnhmc19kYV9i am9pbih0cCwgYnApOw0KLQlsaWJ4ZnNfZGFfYmhvbGQodHAsIGJwKTsNCi0J bGlieGZzX2RhX2Jqb2luKHRwLCBmYnApOw0KLQlsaWJ4ZnNfZGFfYmhvbGQo dHAsIGZicCk7DQotCVhGU19CTUFQX0lOSVQoJmZsaXN0LCAmZmlyc3RibG9j ayk7DQotCW5lZWRsb2cgPSBuZWVkc2NhbiA9IDA7DQotCWJ6ZXJvKCgoeGZz X2RpcjJfZGF0YV90ICopKGJwLT5kYXRhKSktPmhkci5iZXN0ZnJlZSwNCi0J CXNpemVvZihkYXRhLT5oZHIuYmVzdGZyZWUpKTsNCi0JbGlieGZzX2RpcjJf ZGF0YV9tYWtlX2ZyZWUodHAsIGJwLCAoeGZzX2RpcjJfZGF0YV9hb2ZmX3Qp c2l6ZW9mKGRhdGEtPmhkciksDQotCQltcC0+bV9kaXJibGtzaXplIC0gc2l6 ZW9mKGRhdGEtPmhkciksICZuZWVkbG9nLCAmbmVlZHNjYW4pOw0KLQlBU1NF UlQobmVlZHNjYW4gPT0gMCk7DQotCWxpYnhmc19kaXIyX2RhdGFfbG9nX2hl YWRlcih0cCwgYnApOw0KLQlJTlRfU0VUKGZibG9jay0+YmVzdHNbZmldLCBB UkNIX0NPTlZFUlQsDQotCQlJTlRfR0VUKCgoeGZzX2RpcjJfZGF0YV90ICop KGJwLT5kYXRhKSktPmhkci5iZXN0ZnJlZVswXS5sZW5ndGgsIEFSQ0hfQ09O VkVSVCkpOw0KLQlsaWJ4ZnNfZGlyMl9mcmVlX2xvZ19iZXN0cyh0cCwgZmJw LCBmaSwgZmkpOw0KLQlsaWJ4ZnNfYm1hcF9maW5pc2goJnRwLCAmZmxpc3Qs IGZpcnN0YmxvY2ssICZjb21taXR0ZWQpOw0KLQlsaWJ4ZnNfdHJhbnNfY29t bWl0KHRwLCAwLCAwKTsNCi0NCi0Jd2hpbGUgKHB0ciA8IGVuZHB0cikgew0K LQkJZHVwID0gKHhmc19kaXIyX2RhdGFfdW51c2VkX3QgKilwdHI7DQotCQlp ZiAoSU5UX0dFVChkdXAtPmZyZWV0YWcsIEFSQ0hfQ09OVkVSVCkgPT0gWEZT X0RJUjJfREFUQV9GUkVFX1RBRykgew0KLQkJCXB0ciArPSBJTlRfR0VUKGR1 cC0+bGVuZ3RoLCBBUkNIX0NPTlZFUlQpOw0KLQkJCWNvbnRpbnVlOw0KLQkJ fQ0KLQkJZGVwID0gKHhmc19kaXIyX2RhdGFfZW50cnlfdCAqKXB0cjsNCi0J CXB0ciArPSBYRlNfRElSMl9EQVRBX0VOVFNJWkUoZGVwLT5uYW1lbGVuKTsN Ci0JCWlmIChkZXAtPm5hbWVbMF0gPT0gJy8nKQ0KLQkJCWNvbnRpbnVlOw0K LQkJdHAgPSBsaWJ4ZnNfdHJhbnNfYWxsb2MobXAsIDApOw0KLQkJbnJlcyA9 IFhGU19DUkVBVEVfU1BBQ0VfUkVTKG1wLCBkZXAtPm5hbWVsZW4pOw0KLQkJ ZXJyb3IgPSBsaWJ4ZnNfdHJhbnNfcmVzZXJ2ZSh0cCwgbnJlcywgWEZTX0NS RUFURV9MT0dfUkVTKG1wKSwgMCwNCi0JCQlYRlNfVFJBTlNfUEVSTV9MT0df UkVTLCBYRlNfQ1JFQVRFX0xPR19DT1VOVCk7DQotCQlpZiAoZXJyb3IpDQot CQkJcmVzX2ZhaWxlZChlcnJvcik7DQotCQlsaWJ4ZnNfdHJhbnNfaWpvaW4o dHAsIGlwLCAwKTsNCi0JCWxpYnhmc190cmFuc19paG9sZCh0cCwgaXApOw0K LQkJbGlieGZzX2RhX2Jqb2luKHRwLCBicCk7DQotCQlsaWJ4ZnNfZGFfYmhv bGQodHAsIGJwKTsNCi0JCWxpYnhmc19kYV9iam9pbih0cCwgZmJwKTsNCi0J CWxpYnhmc19kYV9iaG9sZCh0cCwgZmJwKTsNCi0JCVhGU19CTUFQX0lOSVQo JmZsaXN0LCAmZmlyc3RibG9jayk7DQotCQllcnJvciA9IGRpcl9jcmVhdGVu YW1lKG1wLCB0cCwgaXAsIChjaGFyICopZGVwLT5uYW1lLA0KLQkJCWRlcC0+ bmFtZWxlbiwgSU5UX0dFVChkZXAtPmludW1iZXIsIEFSQ0hfQ09OVkVSVCks DQotCQkJJmZpcnN0YmxvY2ssICZmbGlzdCwgbnJlcyk7DQotCQlBU1NFUlQo ZXJyb3IgPT0gMCk7DQotCQlsaWJ4ZnNfYm1hcF9maW5pc2goJnRwLCAmZmxp c3QsIGZpcnN0YmxvY2ssICZjb21taXR0ZWQpOw0KLQkJbGlieGZzX3RyYW5z X2NvbW1pdCh0cCwgMCwgMCk7DQotCX0NCi0JbGlieGZzX2RhX2JyZWxzZShO VUxMLCBicCk7DQotCWxpYnhmc19kYV9icmVsc2UoTlVMTCwgZmJwKTsNCi0J ZnJlZShkYXRhKTsNCi19DQotDQotLyoNCi0gKiBGaW5pc2ggdGhlIHJlYnVp bGQgb2YgYSBkaXJlY3RvcnkuDQotICogU3R1ZmYgLyBpbiBhbmQgdGhlbiBy ZW1vdmUgaXQsIHRoaXMgZm9yY2VzIHRoZSBkaXJlY3RvcnkgdG8gZW5kDQot ICogdXAgaW4gdGhlIHJpZ2h0IGZvcm1hdC4NCi0gKi8NCi12b2lkDQotbG9u Z2Zvcm1fZGlyMl9yZWJ1aWxkX2ZpbmlzaCgNCi0JeGZzX21vdW50X3QJCSpt cCwNCi0JeGZzX2lub190CQlpbm8sDQotCXhmc19pbm9kZV90CQkqaXApDQot ew0KLQlpbnQJCQljb21taXR0ZWQ7DQotCWludAkJCWVycm9yOw0KLQl4ZnNf ZnNibG9ja190CQlmaXJzdGJsb2NrOw0KLQl4ZnNfYm1hcF9mcmVlX3QJCWZs aXN0Ow0KLQlpbnQJCQlucmVzOw0KLQl4ZnNfdHJhbnNfdAkJKnRwOw0KLQ0K LQl0cCA9IGxpYnhmc190cmFuc19hbGxvYyhtcCwgMCk7DQotCW5yZXMgPSBY RlNfQ1JFQVRFX1NQQUNFX1JFUyhtcCwgMSk7DQotCWVycm9yID0gbGlieGZz X3RyYW5zX3Jlc2VydmUodHAsIG5yZXMsIFhGU19DUkVBVEVfTE9HX1JFUyht cCksIDAsDQotCQlYRlNfVFJBTlNfUEVSTV9MT0dfUkVTLCBYRlNfQ1JFQVRF X0xPR19DT1VOVCk7DQotCWlmIChlcnJvcikNCi0JCXJlc19mYWlsZWQoZXJy b3IpOw0KLQlsaWJ4ZnNfdHJhbnNfaWpvaW4odHAsIGlwLCAwKTsNCi0JbGli eGZzX3RyYW5zX2lob2xkKHRwLCBpcCk7DQotCVhGU19CTUFQX0lOSVQoJmZs aXN0LCAmZmlyc3RibG9jayk7DQotCWVycm9yID0gZGlyX2NyZWF0ZW5hbWUo bXAsIHRwLCBpcCwgIi8iLCAxLCBpbm8sDQotCQkJJmZpcnN0YmxvY2ssICZm bGlzdCwgbnJlcyk7DQotCUFTU0VSVChlcnJvciA9PSAwKTsNCi0JbGlieGZz X2JtYXBfZmluaXNoKCZ0cCwgJmZsaXN0LCBmaXJzdGJsb2NrLCAmY29tbWl0 dGVkKTsNCi0JbGlieGZzX3RyYW5zX2NvbW1pdCh0cCwgMCwgMCk7DQotDQot CS8qIGNvdWxkIGtpbGwgdHJhaWxpbmcgZW1wdHkgZGF0YSBibG9ja3MgaGVy ZSAqLw0KLQ0KLQl0cCA9IGxpYnhmc190cmFuc19hbGxvYyhtcCwgMCk7DQot CW5yZXMgPSBYRlNfUkVNT1ZFX1NQQUNFX1JFUyhtcCk7DQotCWVycm9yID0g bGlieGZzX3RyYW5zX3Jlc2VydmUodHAsIG5yZXMsIFhGU19SRU1PVkVfTE9H X1JFUyhtcCksIDAsDQotCQlYRlNfVFJBTlNfUEVSTV9MT0dfUkVTLCBYRlNf UkVNT1ZFX0xPR19DT1VOVCk7DQotCWlmIChlcnJvcikNCi0JCXJlc19mYWls ZWQoZXJyb3IpOw0KLQlsaWJ4ZnNfdHJhbnNfaWpvaW4odHAsIGlwLCAwKTsN Ci0JbGlieGZzX3RyYW5zX2lob2xkKHRwLCBpcCk7DQotCVhGU19CTUFQX0lO SVQoJmZsaXN0LCAmZmlyc3RibG9jayk7DQotCWVycm9yID0gZGlyX3JlbW92 ZW5hbWUobXAsIHRwLCBpcCwgIi8iLCAxLCBpbm8sDQotCQkJJmZpcnN0Ymxv Y2ssICZmbGlzdCwgbnJlcyk7DQotCUFTU0VSVChlcnJvciA9PSAwKTsNCi0J bGlieGZzX2JtYXBfZmluaXNoKCZ0cCwgJmZsaXN0LCBmaXJzdGJsb2NrLCAm Y29tbWl0dGVkKTsNCi0JbGlieGZzX3RyYW5zX2NvbW1pdCh0cCwgMCwgMCk7 DQotfQ0KLQ0KLS8qDQotICogUmVidWlsZCBhIGRpcmVjdG9yeS4NCi0gKiBS ZW1vdmUgYWxsIHRoZSBub24tZGF0YSBibG9ja3MuDQotICogUmUtaW5pdGlh bGl6ZSB0byAoZW1wdHkpIG5vZGUgZm9ybS4NCi0gKiBMb29wIG92ZXIgdGhl IGRhdGEgYmxvY2tzIHJlaW5zZXJ0aW5nIGVhY2ggZW50cnkuDQotICogRm9y Y2UgdGhlIGRpcmVjdG9yeSBpbnRvIHRoZSByaWdodCBmb3JtYXQuDQotICov DQotdm9pZA0KLWxvbmdmb3JtX2RpcjJfcmVidWlsZCgNCi0JeGZzX21vdW50 X3QJKm1wLA0KLQl4ZnNfaW5vX3QJaW5vLA0KLQl4ZnNfaW5vZGVfdAkqaXAs DQotCWludAkJKm51bV9pbGxlZ2FsLA0KLQlmcmVldGFiX3QJKmZyZWV0YWIs DQotCWludAkJaXNibG9jaykNCi17DQotCXhmc19kYWJ1Zl90CSpicDsNCi0J eGZzX2RhYmxrX3QJZGFfYm5vOw0KLQl4ZnNfZmlsZW9mZl90CW5leHRfZGFf Ym5vOw0KLQ0KLQlkb193YXJuKF8oInJlYnVpbGRpbmcgZGlyZWN0b3J5IGlu b2RlICVsbHVcbiIpLCBpbm8pOw0KLQ0KLQkvKiBraWxsIGxlYWYgYmxvY2tz ICovDQotCWZvciAoZGFfYm5vID0gbXAtPm1fZGlybGVhZmJsaywgbmV4dF9k YV9ibm8gPSBpc2Jsb2NrID8gTlVMTEZJTEVPRkYgOiAwOw0KLQkgICAgIG5l eHRfZGFfYm5vICE9IE5VTExGSUxFT0ZGOw0KLQkgICAgIGRhX2JubyA9ICh4 ZnNfZGFibGtfdCluZXh0X2RhX2Jubykgew0KLQkJbmV4dF9kYV9ibm8gPSBk YV9ibm8gKyBtcC0+bV9kaXJibGtmc2JzIC0gMTsNCi0JCWlmIChsaWJ4ZnNf Ym1hcF9uZXh0X29mZnNldChOVUxMLCBpcCwgJm5leHRfZGFfYm5vLCBYRlNf REFUQV9GT1JLKSkNCi0JCQlicmVhazsNCi0JCWlmIChsaWJ4ZnNfZGFfZ2V0 X2J1ZihOVUxMLCBpcCwgZGFfYm5vLCAtMSwgJmJwLCBYRlNfREFUQV9GT1JL KSkgew0KLQkJCWRvX2Vycm9yKF8oImNhbid0IGdldCBibG9jayAldSBmb3Ig ZGlyZWN0b3J5IGlub2RlICINCi0JCQkJICAgIiVsbHVcbiIpLA0KLQkJCQlk YV9ibm8sIGlubyk7DQotCQkJLyogTk9UUkVBQ0hFRCAqLw0KLQkJfQ0KLQkJ ZGlyMl9raWxsX2Jsb2NrKG1wLCBpcCwgZGFfYm5vLCBicCk7DQotCX0NCi0N Ci0JLyogcmVidWlsZCBlbXB0eSBidHJlZSBhbmQgZnJlZWxpc3QgKi8NCi0J bG9uZ2Zvcm1fZGlyMl9yZWJ1aWxkX3NldHVwKG1wLCBpbm8sIGlwLCBmcmVl dGFiKTsNCi0NCi0JLyogcmVidWlsZCBkaXJlY3RvcnkgKi8NCi0JZm9yIChk YV9ibm8gPSBtcC0+bV9kaXJkYXRhYmxrLCBuZXh0X2RhX2JubyA9IDA7DQot CSAgICAgZGFfYm5vIDwgbXAtPm1fZGlybGVhZmJsayAmJiBuZXh0X2RhX2Ju byAhPSBOVUxMRklMRU9GRjsNCi0JICAgICBkYV9ibm8gPSAoeGZzX2RhYmxr X3QpbmV4dF9kYV9ibm8pIHsNCi0JCW5leHRfZGFfYm5vID0gZGFfYm5vICsg bXAtPm1fZGlyYmxrZnNicyAtIDE7DQotCQlpZiAobGlieGZzX2JtYXBfbmV4 dF9vZmZzZXQoTlVMTCwgaXAsICZuZXh0X2RhX2JubywgWEZTX0RBVEFfRk9S SykpDQotCQkJYnJlYWs7DQotCQlsb25nZm9ybV9kaXIyX3JlYnVpbGRfZGF0 YShtcCwgaW5vLCBpcCwgZGFfYm5vKTsNCi0JfQ0KLQ0KLQkvKiBwdXQgdGhl IGRpcmVjdG9yeSBpbiB0aGUgYXBwcm9wcmlhdGUgb24tZGlzayBmb3JtYXQg Ki8NCi0JbG9uZ2Zvcm1fZGlyMl9yZWJ1aWxkX2ZpbmlzaChtcCwgaW5vLCBp cCk7DQotCSpudW1faWxsZWdhbCA9IDA7DQotfQ0KLQ0KLS8qDQotICogc3Vj Y2VlZHMgb3IgZGllcywgaW5vZGUgbmV2ZXIgZ2V0cyBkaXJ0aWVkIHNpbmNl IGFsbCBjaGFuZ2VzDQotICogaGFwcGVuIGluIGZpbGUgYmxvY2tzLiAgdGhl IGlub2RlIHNpemUgYW5kIG90aGVyIGNvcmUgaW5mbw0KLSAqIGlzIGFscmVh ZHkgY29ycmVjdCwgaXQncyBqdXN0IHRoZSBsZWFmIGVudHJpZXMgdGhhdCBn ZXQgYWx0ZXJlZC4NCi0gKiBYWFggYWJvdmUgY29tbWVudCBpcyB3cm9uZyBm b3IgdjIgLSBuZWVkIHRvIHNlZSB3aHkgaXQgbWF0dGVycw0KKyAqIElmIGEg ZGlyZWN0b3J5IGlzIGNvcnJ1cHQsIHdlIG5lZWQgdG8gcmVhZCBpbiBhcyBt YW55IGVudHJpZXMgYXMgcG9zc2libGUsDQorICogZGVzdHJveSB0aGUgZW50 cnkgYW5kIGNyZWF0ZSBhIG5ldyBvbmUgd2l0aCByZWNvdmVyZWQgbmFtZS9p bm9kZSBwYWlycy4NCisgKiAoaWUuIGdldCBsaWJ4ZnMgdG8gZG8gYWxsIHRo ZSBncnVudCB3b3JrKQ0KICAqLw0KIHZvaWQNCiBsb25nZm9ybV9kaXIyX2Vu dHJ5X2NoZWNrKHhmc19tb3VudF90CSptcCwNCkBAIC0yODEwLDE1ICsyNTE5 LDE0IEBAIGxvbmdmb3JtX2RpcjJfZW50cnlfY2hlY2soeGZzX21vdW50X3QJ Km0NCiAJCQlkaXJfc3RhY2tfdAkqc3RhY2ssDQogCQkJaW5vX3RyZWVfbm9k ZV90CSppcmVjLA0KIAkJCWludAkJaW5vX29mZnNldCwNCi0JCQluYW1lX2hh c2hfdGFiX3QJKm5hbWV0YWIpDQorCQkJZGlyX2hhc2hfdGFiX3QJKmhhc2h0 YWIpDQogew0KIAl4ZnNfZGlyMl9ibG9ja190CSpibG9jazsNCiAJeGZzX2Rp cjJfbGVhZl9lbnRyeV90CSpibHA7DQotCXhmc19kYWJ1Zl90CQkqYnA7DQor CXhmc19kYWJ1Zl90CQkqKmJwbGlzdDsNCiAJeGZzX2RpcjJfYmxvY2tfdGFp bF90CSpidHA7DQogCXhmc19kYWJsa190CQlkYV9ibm87DQogCWZyZWV0YWJf dAkJKmZyZWV0YWI7DQotCWRpcl9oYXNoX3RhYl90CQkqaGFzaHRhYjsNCiAJ aW50CQkJaTsNCiAJaW50CQkJaXNibG9jazsNCiAJaW50CQkJaXNsZWFmOw0K QEAgLTI4NDAsNiArMjU0OCw3IEBAIGxvbmdmb3JtX2RpcjJfZW50cnlfY2hl Y2soeGZzX21vdW50X3QJKm0NCiAJCWZyZWV0YWItPmVudHNbaV0udiA9IE5V TExEQVRBT0ZGOw0KIAkJZnJlZXRhYi0+ZW50c1tpXS5zID0gMDsNCiAJfQ0K KwlicGxpc3QgPSBjYWxsb2MoZnJlZXRhYi0+bmFlbnRzLCBzaXplb2YoeGZz X2RhYnVmX3QqKSk7DQogCS8qIGlzIHRoaXMgYSBibG9jaywgbGVhZiwgb3Ig bm9kZSBkaXJlY3Rvcnk/ICovDQogCWxpYnhmc19kaXIyX2lzYmxvY2soTlVM TCwgaXAsICZpc2Jsb2NrKTsNCiAJbGlieGZzX2RpcjJfaXNsZWFmKE5VTEws IGlwLCAmaXNsZWFmKTsNCkBAIC0yODQ3LDUwICsyNTU2LDU4IEBAIGxvbmdm b3JtX2RpcjJfZW50cnlfY2hlY2soeGZzX21vdW50X3QJKm0NCiAJaWYgKGRv X3ByZWZldGNoICYmICFpc2Jsb2NrKQ0KIAkJcHJlZmV0Y2hfcDZfZGlyMiht cCwgaXApOw0KIA0KLQkvKiBjaGVjayBkaXJlY3RvcnkgZGF0YSAqLw0KLQlo YXNodGFiID0gZGlyX2hhc2hfaW5pdChpcC0+aV9kLmRpX3NpemUpOw0KKwkv KiBjaGVjayBkaXJlY3RvcnkgImRhdGEiIGJsb2NrcyAoaWUuIG5hbWUvaW5v ZGUgcGFpcnMpICovDQogCWZvciAoZGFfYm5vID0gMCwgbmV4dF9kYV9ibm8g PSAwOw0KIAkgICAgIG5leHRfZGFfYm5vICE9IE5VTExGSUxFT0ZGICYmIGRh X2JubyA8IG1wLT5tX2RpcmxlYWZibGs7DQogCSAgICAgZGFfYm5vID0gKHhm c19kYWJsa190KW5leHRfZGFfYm5vKSB7DQogCQluZXh0X2RhX2JubyA9IGRh X2JubyArIG1wLT5tX2RpcmJsa2ZzYnMgLSAxOw0KKwkJQVNTRVJUKFhGU19E SVIyX0RBX1RPX0RCKG1wLCBkYV9ibm8pIDwgZnJlZXRhYi0+bmFlbnRzKTsN CiAJCWlmIChsaWJ4ZnNfYm1hcF9uZXh0X29mZnNldChOVUxMLCBpcCwgJm5l eHRfZGFfYm5vLCBYRlNfREFUQV9GT1JLKSkNCiAJCQlicmVhazsNCi0JCWlm IChsaWJ4ZnNfZGFfcmVhZF9idWZyKE5VTEwsIGlwLCBkYV9ibm8sDQotCQkJ CWRhX2JubyA9PSAwID8gLTIgOiAtMSwgJmJwLCBYRlNfREFUQV9GT1JLKSkg ew0KLQkJCWRvX2Vycm9yKF8oImNhbid0IHJlYWQgYmxvY2sgJXUgZm9yIGRp cmVjdG9yeSBpbm9kZSAiDQotCQkJCSAgICIlbGx1XG4iKSwNCisJCWlmIChs aWJ4ZnNfZGFfcmVhZF9idWZyKE5VTEwsIGlwLCBkYV9ibm8sIC0xLCANCisJ CQkJJmJwbGlzdFtYRlNfRElSMl9EQV9UT19EQihtcCwgZGFfYm5vKV0sIA0K KwkJCQlYRlNfREFUQV9GT1JLKSkgew0KKwkJCWRvX3dhcm4oXygNCisJCQki Y2FuJ3QgcmVhZCBkYXRhIGJsb2NrICV1IGZvciBkaXJlY3RvcnkgaW5vZGUg JWxsdVxuIiksDQogCQkJCWRhX2JubywgaW5vKTsNCi0JCQkvKiBOT1RSRUFD SEVEICovDQorCQkJKm51bV9pbGxlZ2FsKys7DQorCQkJY29udGludWU7CS8q IHRyeSBhbmQgcmVhZCBhbGwgImRhdGEiIGJsb2NrcyAqLw0KIAkJfQ0KLQkJ LyogaXMgdGhlcmUgYSBob2xlIGF0IHRoZSBzdGFydD8gKi8NCi0JCWlmIChk YV9ibm8gPT0gMCAmJiBicCA9PSBOVUxMKQ0KLQkJCWNvbnRpbnVlOw0KIAkJ bG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVja19kYXRhKG1wLCBpcCwgbnVtX2ls bGVnYWwsIG5lZWRfZG90LA0KLQkJCXN0YWNrLCBpcmVjLCBpbm9fb2Zmc2V0 LCAmYnAsIGhhc2h0YWIsICZmcmVldGFiLCANCi0JCQluYW1ldGFiLCBkYV9i bm8sIGlzYmxvY2spOw0KLQkJLyogaXQgcmVsZWFzZXMgdGhlIGJ1ZmZlciB1 bmxlc3MgaXNibG9jayBpcyBzZXQgKi8NCisJCQkJc3RhY2ssIGlyZWMsIGlu b19vZmZzZXQsIA0KKwkJCQkmYnBsaXN0W1hGU19ESVIyX0RBX1RPX0RCKG1w LCBkYV9ibm8pXSwgaGFzaHRhYiwgIA0KKwkJCQkmZnJlZXRhYiwgZGFfYm5v LCBpc2Jsb2NrKTsNCiAJfQ0KIAlmaXhpdCA9ICgqbnVtX2lsbGVnYWwgIT0g MCkgfHwgZGlyMl9pc19iYWRpbm8oaW5vKTsNCiANCiAJLyogY2hlY2sgYnRy ZWUgYW5kIGZyZWVzcGFjZSAqLw0KIAlpZiAoaXNibG9jaykgew0KLQkJQVNT RVJUKGJwKTsNCi0JCWJsb2NrID0gYnAtPmRhdGE7DQorCQlibG9jayA9IGJw bGlzdFswXS0+ZGF0YTsNCiAJCWJ0cCA9IFhGU19ESVIyX0JMT0NLX1RBSUxf UChtcCwgYmxvY2spOw0KIAkJYmxwID0gWEZTX0RJUjJfQkxPQ0tfTEVBRl9Q KGJ0cCk7DQotCQlzZWV2YWwgPSBkaXJfaGFzaF9zZWVfYWxsKGhhc2h0YWIs IGJscCwgSU5UX0dFVChidHAtPmNvdW50LCBBUkNIX0NPTlZFUlQpLCBJTlRf R0VUKGJ0cC0+c3RhbGUsIEFSQ0hfQ09OVkVSVCkpOw0KKwkJc2VldmFsID0g ZGlyX2hhc2hfc2VlX2FsbChoYXNodGFiLCBibHAsIA0KKwkJCQlJTlRfR0VU KGJ0cC0+Y291bnQsIEFSQ0hfQ09OVkVSVCksIA0KKwkJCQlJTlRfR0VUKGJ0 cC0+c3RhbGUsIEFSQ0hfQ09OVkVSVCkpOw0KIAkJaWYgKGRpcl9oYXNoX2No ZWNrKGhhc2h0YWIsIGlwLCBzZWV2YWwpKQ0KIAkJCWZpeGl0IHw9IDE7DQot CQlsaWJ4ZnNfZGFfYnJlbHNlKE5VTEwsIGJwKTsNCiAJfSBlbHNlIGlmIChp c2xlYWYpIHsNCiAJCWZpeGl0IHw9IGxvbmdmb3JtX2RpcjJfY2hlY2tfbGVh ZihtcCwgaXAsIGhhc2h0YWIsIGZyZWV0YWIpOw0KIAl9IGVsc2Ugew0KIAkJ Zml4aXQgfD0gbG9uZ2Zvcm1fZGlyMl9jaGVja19ub2RlKG1wLCBpcCwgaGFz aHRhYiwgZnJlZXRhYik7DQogCX0NCi0JZGlyX2hhc2hfZG9uZShoYXNodGFi KTsNCi0JaWYgKCFub19tb2RpZnkgJiYgZml4aXQpDQotCQlsb25nZm9ybV9k aXIyX3JlYnVpbGQobXAsIGlubywgaXAsIG51bV9pbGxlZ2FsLCBmcmVldGFi LA0KLQkJCWlzYmxvY2spOw0KKwlpZiAoIW5vX21vZGlmeSAmJiBmaXhpdCkg ew0KKwkJZGlyX2hhc2hfZHVwX25hbWVzKGhhc2h0YWIpOw0KKwkJZm9yIChp ID0gMDsgaSA8IGZyZWV0YWItPm5hZW50czsgaSsrKSANCisJCQlpZiAoYnBs aXN0W2ldKQ0KKwkJCQlsaWJ4ZnNfZGFfYnJlbHNlKE5VTEwsIGJwbGlzdFtp XSk7DQorCQlsb25nZm9ybV9kaXIyX3JlYnVpbGQobXAsIGlubywgaXAsIGhh c2h0YWIpOw0KKwkJKm51bV9pbGxlZ2FsID0gMDsNCisJfSBlbHNlIHsNCisJ CWZvciAoaSA9IDA7IGkgPCBmcmVldGFiLT5uYWVudHM7IGkrKykgDQorCQkJ aWYgKGJwbGlzdFtpXSkNCisJCQkJbGlieGZzX2RhX2JyZWxzZShOVUxMLCBi cGxpc3RbaV0pOw0KKwl9DQorCQ0KIAlmcmVlKGZyZWV0YWIpOw0KIH0NCiAN CkBAIC0yOTA2LDcgKzI2MjMsNyBAQCBzaG9ydGZvcm1fZGlyX2VudHJ5X2No ZWNrKHhmc19tb3VudF90CSptDQogCQkJZGlyX3N0YWNrX3QJKnN0YWNrLA0K IAkJCWlub190cmVlX25vZGVfdAkqY3VycmVudF9pcmVjLA0KIAkJCWludAkJ Y3VycmVudF9pbm9fb2Zmc2V0LA0KLQkJCW5hbWVfaGFzaF90YWJfdAkqbmFt ZXRhYikNCisJCQlkaXJfaGFzaF90YWJfdAkqaGFzaHRhYikNCiB7DQogCXhm c19pbm9fdAkJbGlubzsNCiAJeGZzX2lub190CQlwYXJlbnQ7DQpAQCAtMzA0 NCw3ICsyNzYxLDcgQEAgXygiZW50cnkgXCIlc1wiIGluIHNob3J0Zm9ybSBk aXIgJWxsdSByZQ0KIAkJQVNTRVJUKGlyZWMgIT0gTlVMTCk7DQogDQogCQlp bm9fb2Zmc2V0ID0gWEZTX0lOT19UT19BR0lOTyhtcCwgbGlubykgLSBpcmVj LT5pbm9fc3RhcnRudW07DQotDQorCQkNCiAJCS8qDQogCQkgKiBpZiBpdCdz IGEgZnJlZSBpbm9kZSwgYmxvdyBvdXQgdGhlIGVudHJ5Lg0KIAkJICogYnkg bm93LCBhbnkgaW5vZGUgdGhhdCB3ZSB0aGluayBpcyBmcmVlDQpAQCAtMzA2 Niw4ICsyNzgzLDkgQEAgXygiZW50cnkgXCIlc1wiIGluIHNob3J0Zm9ybSBk aXIgaW5vZGUgJQ0KIAkJCQlkb193YXJuKF8oIndvdWxkIGp1bmsgZW50cnkg XCIlc1wiXG4iKSwNCiAJCQkJCWZuYW1lKTsNCiAJCQl9DQotCQl9IGVsc2Ug aWYgKCFuYW1lX2hhc2hfYWRkKG5hbWV0YWIsIHNmX2VudHJ5LT5uYW1lLCAN Ci0JCQkJCXNmX2VudHJ5LT5uYW1lbGVuKSkgew0KKwkJfSBlbHNlIGlmICgh ZGlyX2hhc2hfYWRkKGhhc2h0YWIsIA0KKwkJCQkoeGZzX2RpcjJfZGF0YXB0 cl90KShzZl9lbnRyeSAtICZzZi0+bGlzdFswXSksDQorCQkJCWxpbm8sIHNm X2VudHJ5LT5uYW1lbGVuLCBzZl9lbnRyeS0+bmFtZSkpIHsNCiAJCQkvKg0K IAkJCSAqIGNoZWNrIGZvciBkdXBsaWNhdGUgbmFtZXMgaW4gZGlyZWN0b3J5 Lg0KIAkJCSAqLyANCkBAIC0zMzExLDcgKzMwMjksNyBAQCBzaG9ydGZvcm1f ZGlyMl9lbnRyeV9jaGVjayh4ZnNfbW91bnRfdAkqDQogCQkJZGlyX3N0YWNr X3QJKnN0YWNrLA0KIAkJCWlub190cmVlX25vZGVfdAkqY3VycmVudF9pcmVj LA0KIAkJCWludAkJY3VycmVudF9pbm9fb2Zmc2V0LA0KLQkJCW5hbWVfaGFz aF90YWJfdAkqbmFtZXRhYikNCisJCQlkaXJfaGFzaF90YWJfdAkqaGFzaHRh YikNCiB7DQogCXhmc19pbm9fdAkJbGlubzsNCiAJeGZzX2lub190CQlwYXJl bnQ7DQpAQCAtMzQ4NCw3ICszMjAyLDkgQEAgc2hvcnRmb3JtX2RpcjJfZW50 cnlfY2hlY2soeGZzX21vdW50X3QJKg0KIAkJCQlkb193YXJuKF8oIndvdWxk IGp1bmsgZW50cnkgXCIlc1wiXG4iKSwNCiAJCQkJCWZuYW1lKTsNCiAJCQl9 DQotCQl9IGVsc2UgaWYgKCFuYW1lX2hhc2hfYWRkKG5hbWV0YWIsIHNmZXAt Pm5hbWUsIHNmZXAtPm5hbWVsZW4pKSB7DQorCQl9IGVsc2UgaWYgKCFkaXJf aGFzaF9hZGQoaGFzaHRhYiwgKHhmc19kaXIyX2RhdGFwdHJfdCkNCisJCQkJ CShzZmVwIC0gWEZTX0RJUjJfU0ZfRklSU1RFTlRSWShzZnApKSwNCisJCQkJ bGlubywgc2ZlcC0+bmFtZWxlbiwgc2ZlcC0+bmFtZSkpIHsNCiAJCQkvKg0K IAkJCSAqIGNoZWNrIGZvciBkdXBsaWNhdGUgbmFtZXMgaW4gZGlyZWN0b3J5 Lg0KIAkJCSAqLyANCkBAIC0zNjUwLDcgKzMzNzAsNyBAQCBwcm9jZXNzX2Rp cnN0YWNrKHhmc19tb3VudF90ICptcCwgZGlyX3N0DQogCXhmc190cmFuc190 CQkqdHA7DQogCXhmc19kYWhhc2hfdAkJaGFzaHZhbDsNCiAJaW5vX3RyZWVf bm9kZV90CQkqaXJlYzsNCi0JbmFtZV9oYXNoX3RhYl90CQkqbmFtZXRhYjsN CisJZGlyX2hhc2hfdGFiX3QJCSpoYXNodGFiOw0KIAlpbnQJCQlpbm9fb2Zm c2V0LCBuZWVkX2RvdCwgY29tbWl0dGVkOw0KIAlpbnQJCQlkaXJ0eSwgbnVt X2lsbGVnYWwsIGVycm9yLCBucmVzOw0KIA0KQEAgLTM3MzEsNyArMzQ1MSw3 IEBAIHByb2Nlc3NfZGlyc3RhY2soeGZzX21vdW50X3QgKm1wLCBkaXJfc3QN CiANCiAJCWFkZF9pbm9kZV9yZWZjaGVja2VkKGlubywgaXJlYywgaW5vX29m ZnNldCk7DQogDQotCQluYW1ldGFiID0gbmFtZV9oYXNoX2luaXQoaXAtPmlf ZC5kaV9zaXplKTsNCisJCWhhc2h0YWIgPSBkaXJfaGFzaF9pbml0KGlwLT5p X2QuZGlfc2l6ZSk7DQogDQogCQkvKg0KIAkJICogbG9vayBmb3IgYm9ndXMg ZW50cmllcw0KQEAgLTM3NTAsMTMgKzM0NzAsMTMgQEAgcHJvY2Vzc19kaXJz dGFjayh4ZnNfbW91bnRfdCAqbXAsIGRpcl9zdA0KIAkJCQkJCQkmbnVtX2ls bGVnYWwsICZuZWVkX2RvdCwNCiAJCQkJCQkJc3RhY2ssIGlyZWMsDQogCQkJ CQkJCWlub19vZmZzZXQsDQotCQkJCQkJCW5hbWV0YWIpOw0KKwkJCQkJCQlo YXNodGFiKTsNCiAJCQllbHNlDQogCQkJCWxvbmdmb3JtX2Rpcl9lbnRyeV9j aGVjayhtcCwgaW5vLCBpcCwNCiAJCQkJCQkJJm51bV9pbGxlZ2FsLCAmbmVl ZF9kb3QsDQogCQkJCQkJCXN0YWNrLCBpcmVjLA0KIAkJCQkJCQlpbm9fb2Zm c2V0LA0KLQkJCQkJCQluYW1ldGFiKTsNCisJCQkJCQkJaGFzaHRhYik7DQog CQkJYnJlYWs7DQogCQljYXNlIFhGU19ESU5PREVfRk1UX0xPQ0FMOg0KIAkJ CXRwID0gbGlieGZzX3RyYW5zX2FsbG9jKG1wLCAwKTsNCkBAIC0zNzgxLDEy ICszNTAxLDEyIEBAIHByb2Nlc3NfZGlyc3RhY2soeGZzX21vdW50X3QgKm1w LCBkaXJfc3QNCiAJCQkJc2hvcnRmb3JtX2RpcjJfZW50cnlfY2hlY2sobXAs IGlubywgaXAsICZkaXJ0eSwNCiAJCQkJCQkJc3RhY2ssIGlyZWMsDQogCQkJ CQkJCWlub19vZmZzZXQsDQotCQkJCQkJCW5hbWV0YWIpOw0KKwkJCQkJCQlo YXNodGFiKTsNCiAJCQllbHNlDQogCQkJCXNob3J0Zm9ybV9kaXJfZW50cnlf Y2hlY2sobXAsIGlubywgaXAsICZkaXJ0eSwNCiAJCQkJCQkJc3RhY2ssIGly ZWMsDQogCQkJCQkJCWlub19vZmZzZXQsDQotCQkJCQkJCW5hbWV0YWIpOw0K KwkJCQkJCQloYXNodGFiKTsNCiANCiAJCQlBU1NFUlQoZGlydHkgPT0gMCB8 fCAoZGlydHkgJiYgIW5vX21vZGlmeSkpOw0KIAkJCWlmIChkaXJ0eSkgIHsN CkBAIC0zODAxLDcgKzM1MjEsNyBAQCBwcm9jZXNzX2RpcnN0YWNrKHhmc19t b3VudF90ICptcCwgZGlyX3N0DQogCQlkZWZhdWx0Og0KIAkJCWJyZWFrOw0K IAkJfQ0KLQkJbmFtZV9oYXNoX2RvbmUobmFtZXRhYik7DQorCQlkaXJfaGFz aF9kb25lKGhhc2h0YWIpOw0KIA0KIAkJaGFzaHZhbCA9IDA7DQogDQoNCg0K DQo= ---1463809270-1081969773-1154236772=:4981-- From owner-xfs@oss.sgi.com Sun Jul 30 15:55:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 15:57:31 -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 k6UMtjDW019996 for ; Sun, 30 Jul 2006 15:55:56 -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 IAA22344; Mon, 31 Jul 2006 08:55:01 +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 k6UMswgw2288969; Mon, 31 Jul 2006 08:54:58 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6UMssQ92282333; Mon, 31 Jul 2006 08:54:54 +1000 (EST) Date: Mon, 31 Jul 2006 08:54:54 +1000 From: Nathan Scott To: Eric Sandeen Cc: Andi Kleen , xfs@oss.sgi.com Subject: Re: [PATCH] kill leftover WANT_FUNCS macro indirection Message-ID: <20060731085454.A2280998@wobbly.melbourne.sgi.com> References: <44CAE247.6020608@sandeen.net> <44CBDFC9.3040202@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44CBDFC9.3040202@sandeen.net>; from sandeen@sandeen.net on Sat, Jul 29, 2006 at 05:23:05PM -0500 X-archive-position: 8500 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: 1121 Lines: 33 On Sat, Jul 29, 2006 at 05:23:05PM -0500, Eric Sandeen wrote: > Andi Kleen wrote: > > Eric Sandeen writes: > > > >> This gets rid of some pointless macro defines... I had a version that > >> lower-cased it all too but Nathan liked this better, and he's the man! > >> :) > > > > Shouted function names is not exactly Linux code style at least. > > > > -Andi > > > > well, *shrug* I have both versions, Nathan can take his pick :) > > honestly, one-liner static inlines isn't exactly linux code style either, tho > the typechecking is nice. > > I guess I shouldn't have said "Nathan liked this better" - I think he was being > pragmatic about the scope of the change. Right, its more that we don't have a great track record at the moment of not introducing regressions with these cleanups (including myself), so I'm becoming more reluctant to do sweeping changes across the whole codebase. Smaller, specific, and obviously-correct things are less likely to introduce issues, so if we can achieve basically the same thing while churning the code less, I'm all for it. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 30 16:09:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 16:09:43 -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 k6UN95DW021228 for ; Sun, 30 Jul 2006 16:09:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA22638; Mon, 31 Jul 2006 09:08:20 +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 k6UN8Hgw2289730; Mon, 31 Jul 2006 09:08:18 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6UN8Frn2289102; Mon, 31 Jul 2006 09:08:15 +1000 (EST) Date: Mon, 31 Jul 2006 09:08:15 +1000 From: Nathan Scott To: Eric Sandeen , dgc@sgi.com Cc: xfs@oss.sgi.com Subject: Re: [PATCH] kill no-op buf macros Message-ID: <20060731090815.B2280998@wobbly.melbourne.sgi.com> References: <44CC2A55.6030207@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44CC2A55.6030207@sandeen.net>; from sandeen@sandeen.net on Sat, Jul 29, 2006 at 10:41:09PM -0500 X-archive-position: 8501 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: 1622 Lines: 51 On Sat, Jul 29, 2006 at 10:41:09PM -0500, Eric Sandeen wrote: > It looks like these macros are not particularly interesting... this patch kills > them. Hmm, I'm not sure about some of these.. > #define XFS_BUF_BUSY(bp) do { } while (0) > #define XFS_BUF_ISBUSY(bp) (1) This ones used on 2.4, I'd like to get Daves thoughts on whether we do the right thing here based on his buffer cache fu. > #define XFS_BUF_SHUT(bp) do { } while (0) > #define XFS_BUF_UNSHUT(bp) do { } while (0) > #define XFS_BUF_ISSHUT(bp) (0) Ditto (not used on 2.4 though, but still maybe we should be doing something here). > #define XFS_BUF_ISUNINITIAL(bp) (0) This can go, unwritten extents don't use this interface on Linux. > #define XFS_BUF_BP_ISMAPPED(bp) (1) *nod* - looks like it should go. (could you regen the patch with just these two for now? they are pretty much self-contained changes, and nice 'n small) > #define XFS_BUF_SET_START(bp) do { } while (0) Not sure what this used to do - Dave? > #define XFS_BUF_SET_VTYPE_REF(bp, type, ref) do { } while (0) > #define XFS_BUF_SET_VTYPE(bp, type) do { } while (0) > #define XFS_BUF_SET_REF(bp, ref) do { } while (0) These ones should probably be implemented properly, not removed. We currently treat all metadata buffers with an equal ranking when we're delwri flushing them to try to reclaim memory, this was a scheme to indicate some are more precious than others... we have a (currently ignored) priority passed into xfsbufd_wakeup that we could start honouring and improve our low memory handling there.. d'ya want to hack something up there? cheers. - Nathan From owner-xfs@oss.sgi.com Sun Jul 30 16:45:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 16:46:07 -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 k6UNjFDW029944 for ; Sun, 30 Jul 2006 16:45:27 -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 JAA23271; Mon, 31 Jul 2006 09:44:36 +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 k6UNiVgw2292663; Mon, 31 Jul 2006 09:44:31 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6UNiPqp2291986; Mon, 31 Jul 2006 09:44:25 +1000 (EST) Date: Mon, 31 Jul 2006 09:44:24 +1000 From: Nathan Scott To: Jan Dittmer , kernel Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS Bug null pointer dereference in xfs_free_ag_extent Message-ID: <20060731094424.E2280998@wobbly.melbourne.sgi.com> References: <44BF29CD.1000809@l4x.org> <44CB0BF7.6030204@idccenter.cn> <44CB1303.7010303@l4x.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44CB1303.7010303@l4x.org>; from jdi@l4x.org on Sat, Jul 29, 2006 at 09:49:23AM +0200 X-archive-position: 8502 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: 741 Lines: 24 Hi there, On Sat, Jul 29, 2006 at 09:49:23AM +0200, Jan Dittmer wrote: > kernel schrieb: > > I have the same problem, but it seems not have a patch right now. > > No, I got zero feedback, but let's cc the correct > mailing list. I also filed bug 6877 at kernel.org > Is this easily reproducible for you? I've not seen it before, and the only possibly related recent changes I can think of are these: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e63a3690013a475746ad2cea998ebb534d825704 http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d210a28cd851082cec9b282443f8cc0e6fc09830 Could you try reverting each of those to see if either is the cause? thanks. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 30 17:21:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 17:21:31 -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 k6V0KnDW001849 for ; Sun, 30 Jul 2006 17:20:59 -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 k6UNHmnx006498 for ; Sun, 30 Jul 2006 18:17:48 -0500 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k6V1jvJn030237; Sun, 30 Jul 2006 18:45:58 -0700 Received: from [134.14.55.232] (chatz.melbourne.sgi.com [134.14.55.232]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k6UNIusQ6908499; Mon, 31 Jul 2006 09:18:56 +1000 (AEST) Message-ID: <44CD3DF2.1010108@melbourne.sgi.com> Date: Mon, 31 Jul 2006 09:17:06 +1000 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nathan Scott CC: Eric Sandeen , Andi Kleen , xfs@oss.sgi.com Subject: Re: [PATCH] kill leftover WANT_FUNCS macro indirection References: <44CAE247.6020608@sandeen.net> <44CBDFC9.3040202@sandeen.net> <20060731085454.A2280998@wobbly.melbourne.sgi.com> In-Reply-To: <20060731085454.A2280998@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8503 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1383 Lines: 37 Nathan Scott wrote: > On Sat, Jul 29, 2006 at 05:23:05PM -0500, Eric Sandeen wrote: >> Andi Kleen wrote: >>> Eric Sandeen writes: >>> >>>> This gets rid of some pointless macro defines... I had a version that >>>> lower-cased it all too but Nathan liked this better, and he's the man! >>>> :) >>> Shouted function names is not exactly Linux code style at least. >>> >>> -Andi >>> >> well, *shrug* I have both versions, Nathan can take his pick :) >> >> honestly, one-liner static inlines isn't exactly linux code style either, tho >> the typechecking is nice. >> >> I guess I shouldn't have said "Nathan liked this better" - I think he was being >> pragmatic about the scope of the change. > > Right, its more that we don't have a great track record at the moment > of not introducing regressions with these cleanups (including myself), > so I'm becoming more reluctant to do sweeping changes across the whole > codebase. Smaller, specific, and obviously-correct things are less > likely to introduce issues, so if we can achieve basically the same > thing while churning the code less, I'm all for it. > Sam on his previous project had to do significant cleanup/macro changes and wrote some tools to help him do post-preprocessor comparisons to really look at what had changed. I'm not sure how generic these tools are, but worth considering. David From owner-xfs@oss.sgi.com Sun Jul 30 17:26:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 17:26:37 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6V0QGDW002700 for ; Sun, 30 Jul 2006 17:26:16 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 036DA18E090D0; Sun, 30 Jul 2006 19:25:49 -0500 (CDT) Message-ID: <44CD4E0F.2070905@sandeen.net> Date: Sun, 30 Jul 2006 19:25:51 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Nathan Scott Cc: dgc@sgi.com, xfs@oss.sgi.com Subject: Re: [PATCH] kill no-op buf macros References: <44CC2A55.6030207@sandeen.net> <20060731090815.B2280998@wobbly.melbourne.sgi.com> In-Reply-To: <20060731090815.B2280998@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8504 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 562 Lines: 20 Nathan Scott wrote: > On Sat, Jul 29, 2006 at 10:41:09PM -0500, Eric Sandeen wrote: >> It looks like these macros are not particularly interesting... this patch kills >> them. > > Hmm, I'm not sure about some of these.. > >> #define XFS_BUF_BUSY(bp) do { } while (0) >> #define XFS_BUF_ISBUSY(bp) (1) > > This ones used on 2.4, I'd like to get Daves thoughts on whether > we do the right thing here based on his buffer cache fu. Grr, just realized my cvs checkout didn't even pull linux-2.4 :/ Suppose I'd better re-check everything I sent. Grr! -Eric From owner-xfs@oss.sgi.com Sun Jul 30 17:32:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 17:33:06 -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 k6V0WODW003917 for ; Sun, 30 Jul 2006 17:32:36 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24238; Mon, 31 Jul 2006 10:31:40 +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 k6V0Vbgw2291268; Mon, 31 Jul 2006 10:31:37 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6V0VXgL2291649; Mon, 31 Jul 2006 10:31:33 +1000 (EST) Date: Mon, 31 Jul 2006 10:31:33 +1000 From: Nathan Scott To: Frank Patzig Cc: xfs@oss.sgi.com Subject: Re: [xfs] quota project problem Message-ID: <20060731103133.G2280998@wobbly.melbourne.sgi.com> References: <44CA1D89.3080104@mdlink.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44CA1D89.3080104@mdlink.de>; from fp@mdlink.de on Fri, Jul 28, 2006 at 04:22:01PM +0200 X-archive-position: 8505 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: 676 Lines: 27 On Fri, Jul 28, 2006 at 04:22:01PM +0200, Frank Patzig wrote: > Hallo, > > i have a problem with project quota. Can i help you. > > combolix:~ # uname -a > Linux combolix 2.6.18_rc1-jen27-default #1 Thu Jul 13 01:34:23 CEST 2006 > i686 > i686 i386 GNU/Linux > > combolix:~ # cat /etc/mtab > /dev/hdc2 / xfs rw,uquota,gquota,pquota 0 0 This isn't correct - you can have either gquota or pquota, not both. You also need to set root flags via the kernel boot option "rootflags=" - not via mtab (chicken vs egg). > Project quota state on / (/dev/hdc2) > Accounting: OFF > Enforcement: OFF > Inode: #18446744073709551615 (0 blocks, 0 extents) cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 30 17:36:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 17:37:15 -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 k6V0aaDW004720 for ; Sun, 30 Jul 2006 17:36: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 KAA24304; Mon, 31 Jul 2006 10:35:55 +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 k6V0Zrgw2286324; Mon, 31 Jul 2006 10:35:53 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6V0Zor02293743; Mon, 31 Jul 2006 10:35:50 +1000 (EST) Date: Mon, 31 Jul 2006 10:35:50 +1000 From: Nathan Scott To: Ladislav Durch?nek Cc: xfs@oss.sgi.com Subject: Re: Tree Quota error message suggestion Message-ID: <20060731103550.H2280998@wobbly.melbourne.sgi.com> References: <018a01c6b327$25bc6d40$0201a8c0@reykjavik> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <018a01c6b327$25bc6d40$0201a8c0@reykjavik>; from durchanek@gmail.com on Sat, Jul 29, 2006 at 05:53:34PM +0200 X-archive-position: 8506 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: 1169 Lines: 29 On Sat, Jul 29, 2006 at 05:53:34PM +0200, Ladislav Durch?nek wrote: > Hi everybody, > First at all I have to say that XFS is great. Especially its built-in quota > support is really nice thing. I found tree quotas extremely useful for > hosting servers where uploaded files are created with other owner than > customer is. > > But there is a one thing which could be done better I think: When I define > tree quota and user tries to exceed id, error message returned is "No space > left on device" which is not true - there is a plenty of space on device. Thats by design - project quotas are basically trying to emulate multiple little "virtual" filesystems within one large "actual" filesystem. So, they return ENOSPC on fullness and EXDEV when a cross-device (project) link is attempted. > Only when quota is totally full, next message is "Disk quota exceeded". I > think it should be better if first message will be also "Disk quota > exceeded". Hmm, you should never see EDQUOT for project quota... are you sure about that? (are you using uquota too?) Do you have a reproducible test case to demonstrate this EDQUOT-on-pquota problem? cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jul 30 17:59:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 17:59:40 -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 k6V0tlDW007357 for ; Sun, 30 Jul 2006 17:59:09 -0700 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 6EDBFF8BA; Mon, 31 Jul 2006 02:55:22 +0200 (CEST) From: Andi Kleen To: chatz@melbourne.sgi.com Subject: Re: [PATCH] kill leftover WANT_FUNCS macro indirection Date: Mon, 31 Jul 2006 02:54:27 +0200 User-Agent: KMail/1.9.3 Cc: Nathan Scott , Eric Sandeen , xfs@oss.sgi.com References: <44CAE247.6020608@sandeen.net> <20060731085454.A2280998@wobbly.melbourne.sgi.com> <44CD3DF2.1010108@melbourne.sgi.com> In-Reply-To: <44CD3DF2.1010108@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607310254.27448.ak@suse.de> X-archive-position: 8507 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: 350 Lines: 12 > > > Sam on his previous project had to do significant cleanup/macro > changes and wrote some tools to help him do post-preprocessor > comparisons to really look at what had changed. I'm not sure how > generic these tools are, but worth considering. In this particular case you can just compare .o or .s files. They should be identical. -Andi From owner-xfs@oss.sgi.com Sun Jul 30 20:53:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 20:54:05 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6V3rrDW001029 for ; Sun, 30 Jul 2006 20:53:53 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id EF99218E1C44A; Sun, 30 Jul 2006 22:53:27 -0500 (CDT) Message-ID: <44CD7EBA.2040504@sandeen.net> Date: Sun, 30 Jul 2006 22:53:30 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH] Kill off a bunch of unused macros References: <44CC28BA.7070005@sandeen.net> In-Reply-To: <44CC28BA.7070005@sandeen.net> Content-Type: multipart/mixed; boundary="------------090208020808090209090202" X-archive-position: 8508 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 25069 Lines: 657 This is a multi-part message in MIME format. --------------090208020808090209090202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > This kills off 74 unused macros; more could go but I left some in for > symmetry, bitfields, etc... *shrug* Nathan, maybe you don't want all > these to go, but surely some can. > > I left xfs_mac.h intact but it's really not used at this point either... whoops, this version has linux-2.4/ in it as well. Thanks, -Eric --------------090208020808090209090202 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="kill-unused-macros" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kill-unused-macros" nux-2.4/sv.h | 3 --- linux-2.4/xfs_buf.h | 7 ------- linux-2.4/xfs_linux.h | 7 ------- linux-2.4/xfs_vfs.h | 10 ---------- linux-2.4/xfs_vnode.h | 3 --- linux-2.6/sv.h | 4 ---- linux-2.6/xfs_buf.h | 10 ---------- linux-2.6/xfs_linux.h | 7 ------- linux-2.6/xfs_vfs.h | 10 ---------- linux-2.6/xfs_vnode.h | 3 --- quota/xfs_qm.h | 6 ------ quota/xfs_quota_priv.h | 2 -- support/radix-tree.h | 15 --------------- xfs_acl.h | 4 ---- xfs_bmap_btree.h | 3 --- xfs_cap.h | 19 ------------------- xfs_da_btree.h | 2 -- xfs_error.h | 8 -------- xfs_fs.h | 4 ---- xfs_log.h | 8 -------- xfs_log_priv.h | 4 ---- xfs_quota.h | 3 --- xfs_sb.h | 22 ---------------------- 23 files changed, 164 deletions(-) Signed-Off-By: Eric Sandeen Index: xfs-linux/linux-2.6/sv.h =================================================================== --- xfs-linux.orig/linux-2.6/sv.h +++ xfs-linux/linux-2.6/sv.h @@ -33,12 +33,8 @@ typedef struct sv_s { } sv_t; #define SV_FIFO 0x0 /* sv_t is FIFO type */ -#define SV_LIFO 0x2 /* sv_t is LIFO type */ -#define SV_PRIO 0x4 /* sv_t is PRIO type */ -#define SV_KEYED 0x6 /* sv_t is KEYED type */ #define SV_DEFAULT SV_FIFO - static inline void _sv_wait(sv_t *sv, spinlock_t *lock, int state, unsigned long timeout) { Index: xfs-linux/linux-2.6/xfs_buf.h =================================================================== --- xfs-linux.orig/linux-2.6/xfs_buf.h +++ xfs-linux/linux-2.6/xfs_buf.h @@ -275,7 +275,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_ISDONE(bp) ((bp)->b_flags & XBF_DONE) #define XFS_BUF_BUSY(bp) do { } while (0) -#define XFS_BUF_UNBUSY(bp) do { } while (0) #define XFS_BUF_ISBUSY(bp) (1) #define XFS_BUF_ASYNC(bp) ((bp)->b_flags |= XBF_ASYNC) @@ -284,7 +283,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_ORDERED(bp) ((bp)->b_flags |= XBF_ORDERED) #define XFS_BUF_UNORDERED(bp) ((bp)->b_flags &= ~XBF_ORDERED) -#define XFS_BUF_ISORDERED(bp) ((bp)->b_flags & XBF_ORDERED) #define XFS_BUF_SHUT(bp) do { } while (0) #define XFS_BUF_UNSHUT(bp) do { } while (0) @@ -297,10 +295,8 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_WRITE(bp) ((bp)->b_flags |= XBF_WRITE) #define XFS_BUF_UNWRITE(bp) ((bp)->b_flags &= ~XBF_WRITE) -#define XFS_BUF_ISWRITE(bp) ((bp)->b_flags & XBF_WRITE) #define XFS_BUF_ISUNINITIAL(bp) (0) -#define XFS_BUF_UNUNINITIAL(bp) (0) #define XFS_BUF_BP_ISMAPPED(bp) (1) @@ -323,12 +319,9 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_SET_PTR(bp, val, cnt) xfs_buf_associate_memory(bp, val, cnt) #define XFS_BUF_ADDR(bp) ((bp)->b_bn) #define XFS_BUF_SET_ADDR(bp, bno) ((bp)->b_bn = (xfs_daddr_t)(bno)) -#define XFS_BUF_OFFSET(bp) ((bp)->b_file_offset) -#define XFS_BUF_SET_OFFSET(bp, off) ((bp)->b_file_offset = (off)) #define XFS_BUF_COUNT(bp) ((bp)->b_count_desired) #define XFS_BUF_SET_COUNT(bp, cnt) ((bp)->b_count_desired = (cnt)) #define XFS_BUF_SIZE(bp) ((bp)->b_buffer_length) -#define XFS_BUF_SET_SIZE(bp, cnt) ((bp)->b_buffer_length = (cnt)) #define XFS_BUF_SET_VTYPE_REF(bp, type, ref) do { } while (0) #define XFS_BUF_SET_VTYPE(bp, type) do { } while (0) @@ -338,7 +331,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_VALUSEMA(bp) xfs_buf_lock_value(bp) #define XFS_BUF_CPSEMA(bp) (xfs_buf_cond_lock(bp) == 0) -#define XFS_BUF_VSEMA(bp) xfs_buf_unlock(bp) #define XFS_BUF_PSEMA(bp,x) xfs_buf_lock(bp) #define XFS_BUF_V_IODONESEMA(bp) up(&bp->b_iodonesema); @@ -394,8 +386,6 @@ static inline int XFS_bwrite(xfs_buf_t * return error; } -#define XFS_bdwrite(bp) xfs_buf_iostart(bp, XBF_DELWRI | XBF_ASYNC) - static inline int xfs_bdwrite(void *mp, xfs_buf_t *bp) { bp->b_strat = xfs_bdstrat_cb; Index: xfs-linux/linux-2.6/xfs_linux.h =================================================================== --- xfs-linux.orig/linux-2.6/xfs_linux.h +++ xfs-linux/linux-2.6/xfs_linux.h @@ -152,11 +152,7 @@ BUFFER_FNS(PrivateStart, unwritten); (current->flags = ((current->flags & ~(f)) | (*(sp) & (f)))) #define NBPP PAGE_SIZE -#define DPPSHFT (PAGE_SHIFT - 9) #define NDPP (1 << (PAGE_SHIFT - 9)) -#define dtop(DD) (((DD) + NDPP - 1) >> DPPSHFT) -#define dtopt(DD) ((DD) >> DPPSHFT) -#define dpoff(DD) ((DD) & (NDPP-1)) #define NBBY 8 /* number of bits per byte */ #define NBPC PAGE_SIZE /* Number of bytes per click */ @@ -176,8 +172,6 @@ BUFFER_FNS(PrivateStart, unwritten); #define btoct(x) ((__psunsigned_t)(x)>>BPCSHIFT) #define btoc64(x) (((__uint64_t)(x)+(NBPC-1))>>BPCSHIFT) #define btoct64(x) ((__uint64_t)(x)>>BPCSHIFT) -#define io_btoc(x) (((__psunsigned_t)(x)+(IO_NBPC-1))>>IO_BPCSHIFT) -#define io_btoct(x) ((__psunsigned_t)(x)>>IO_BPCSHIFT) /* off_t bytes to clicks */ #define offtoc(x) (((__uint64_t)(x)+(NBPC-1))>>BPCSHIFT) @@ -190,7 +184,6 @@ BUFFER_FNS(PrivateStart, unwritten); #define ctob(x) ((__psunsigned_t)(x)<>BPCSHIFT) #define ctob64(x) ((__uint64_t)(x)<>BPCSHIFT) Index: xfs-linux/linux-2.6/xfs_vfs.h =================================================================== --- xfs-linux.orig/linux-2.6/xfs_vfs.h +++ xfs-linux/linux-2.6/xfs_vfs.h @@ -166,18 +166,8 @@ typedef struct bhv_vfsops { #define bhv_next_vfs_mount(b, ma,cr) vfs_mount(b, ma,cr) #define bhv_next_vfs_parseargs(b, o,ma,f) vfs_parseargs(b, o,ma,f) #define bhv_next_vfs_showargs(b, m) vfs_showargs(b, m) -#define bhv_next_vfs_unmount(b, f,cr) vfs_unmount(b, f,cr) -#define bhv_next_vfs_mntupdate(b, fl,args) vfs_mntupdate(b, fl, args) -#define bhv_next_vfs_root(b, vpp) vfs_root(b, vpp) #define bhv_next_vfs_statvfs(b, sp,vp) vfs_statvfs(b, sp,vp) #define bhv_next_vfs_sync(b, flag,cr) vfs_sync(b, flag,cr) -#define bhv_next_vfs_vget(b, vpp,fidp) vfs_vget(b, vpp,fidp) -#define bhv_next_vfs_dmapiops(b, p) vfs_dmapiops(b, p) -#define bhv_next_vfs_quotactl(b, c,id,p) vfs_quotactl(b, c,id,p) -#define bhv_next_vfs_get_inode(b, ino,fl) vfs_get_inode(b, ino,fl) -#define bhv_next_vfs_init_vnode(b, vp,b2,ul) vfs_init_vnode(b, vp,b2,ul) -#define bhv_next_force_shutdown(b, fl,f,l) vfs_force_shutdown(b, fl,f,l) -#define bhv_next_vfs_freeze(b) vfs_freeze(b) extern int vfs_mount(bhv_desc_t *, struct xfs_mount_args *, struct cred *); extern int vfs_parseargs(bhv_desc_t *, char *, struct xfs_mount_args *, int); Index: xfs-linux/linux-2.6/xfs_vnode.h =================================================================== --- xfs-linux.orig/linux-2.6/xfs_vnode.h +++ xfs-linux/linux-2.6/xfs_vnode.h @@ -294,10 +294,7 @@ typedef struct bhv_vnodeops { #define bhv_vop_release(vp) VOP(vop_release, vp)(VNHEAD(vp)) #define bhv_vop_fid2(vp,fidp) VOP(vop_fid2, vp)(VNHEAD(vp),fidp) #define bhv_vop_rwlock(vp,i) VOP(vop_rwlock, vp)(VNHEAD(vp),i) -#define bhv_vop_rwlock_try(vp,i) VOP(vop_rwlock, vp)(VNHEAD(vp),i) #define bhv_vop_rwunlock(vp,i) VOP(vop_rwunlock, vp)(VNHEAD(vp),i) -#define bhv_vop_frlock(vp,c,fl,flags,offset,fr) \ - VOP(vop_frlock, vp)(VNHEAD(vp),c,fl,flags,offset,fr) #define bhv_vop_reclaim(vp) VOP(vop_reclaim, vp)(VNHEAD(vp)) #define bhv_vop_attr_get(vp, name, val, vallenp, fl, cred) \ VOP(vop_attr_get, vp)(VNHEAD(vp),name,val,vallenp,fl,cred) Index: xfs-linux/quota/xfs_quota_priv.h =================================================================== --- xfs-linux.orig/quota/xfs_quota_priv.h +++ xfs-linux/quota/xfs_quota_priv.h @@ -75,7 +75,6 @@ static inline int XQMISLCKD(struct xfs_d #define xfs_qm_freelist_lock(qm) XQMLCK(&((qm)->qm_dqfreelist)) #define xfs_qm_freelist_unlock(qm) XQMUNLCK(&((qm)->qm_dqfreelist)) -#define XFS_QM_IS_FREELIST_LOCKED(qm) XQMISLCKD(&((qm)->qm_dqfreelist)) /* * Hash into a bucket in the dquot hash table, based on . @@ -170,6 +169,5 @@ for ((dqp) = (qlist)->qh_next; (dqp) != #define DQFLAGTO_TYPESTR(d) (((d)->dq_flags & XFS_DQ_USER) ? "USR" : \ (((d)->dq_flags & XFS_DQ_GROUP) ? "GRP" : \ (((d)->dq_flags & XFS_DQ_PROJ) ? "PRJ":"???"))) -#define DQFLAGTO_DIRTYSTR(d) (XFS_DQ_IS_DIRTY(d) ? "DIRTY" : "NOTDIRTY") #endif /* __XFS_QUOTA_PRIV_H__ */ Index: xfs-linux/support/radix-tree.h =================================================================== --- xfs-linux.orig/support/radix-tree.h +++ xfs-linux/support/radix-tree.h @@ -24,20 +24,6 @@ struct radix_tree_root { struct radix_tree_node *rnode; }; -#define RADIX_TREE_INIT(mask) { \ - .height = 0, \ - .rnode = NULL, \ -} - -#define RADIX_TREE(name, mask) \ - struct radix_tree_root name = RADIX_TREE_INIT(mask) - -#define INIT_RADIX_TREE(root, mask) \ -do { \ - (root)->height = 0; \ - (root)->rnode = NULL; \ -} while (0) - #define RADIX_TREE_MAX_TAGS 2 int radix_tree_insert(struct radix_tree_root *, unsigned long, void *); @@ -47,7 +33,6 @@ void *radix_tree_delete(struct radix_tre unsigned int radix_tree_gang_lookup(struct radix_tree_root *root, void **results, unsigned long first_index, unsigned int max_items); -#define radix_tree_preload(gfp_mask) do { } while (0) void radix_tree_init(void); void *radix_tree_tag_set(struct radix_tree_root *root, unsigned long index, unsigned int tag); Index: xfs-linux/xfs_acl.h =================================================================== --- xfs-linux.orig/xfs_acl.h +++ xfs-linux/xfs_acl.h @@ -72,9 +72,7 @@ extern int xfs_acl_vremove(struct bhv_vn #define _ACL_PERM_INVALID(perm) ((perm) & ~(ACL_READ|ACL_WRITE|ACL_EXECUTE)) #define _ACL_INHERIT(c,v,d) (xfs_acl_inherit(c,v,d)) -#define _ACL_GET_ACCESS(pv,pa) (xfs_acl_vtoacl(pv,pa,NULL) == 0) #define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) -#define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access #define _ACL_DEFAULT_EXISTS xfs_acl_vhasacl_default #define _ACL_XFS_IACCESS(i,m,c) (XFS_IFORK_Q(i) ? xfs_acl_iaccess(i,m,c) : -1) @@ -92,9 +90,7 @@ extern int xfs_acl_vremove(struct bhv_vn #define _ACL_ALLOC(a) (1) /* successfully allocate nothing */ #define _ACL_FREE(a) ((void)0) #define _ACL_INHERIT(c,v,d) (0) -#define _ACL_GET_ACCESS(pv,pa) (0) #define _ACL_GET_DEFAULT(pv,pd) (0) -#define _ACL_ACCESS_EXISTS (NULL) #define _ACL_DEFAULT_EXISTS (NULL) #define _ACL_XFS_IACCESS(i,m,c) (-1) #endif Index: xfs-linux/xfs_bmap_btree.h =================================================================== --- xfs-linux.orig/xfs_bmap_btree.h +++ xfs-linux/xfs_bmap_btree.h @@ -74,9 +74,6 @@ typedef struct xfs_bmdr_block { #endif /* XFS_NATIVE_HOST */ - -#define BMBT_USE_64 1 - typedef struct xfs_bmbt_rec_32 { __uint32_t l0, l1, l2, l3; Index: xfs-linux/xfs_cap.h =================================================================== --- xfs-linux.orig/xfs_cap.h +++ xfs-linux/xfs_cap.h @@ -29,12 +29,6 @@ typedef struct xfs_cap_set { xfs_cap_value_t cap_inheritable;/* pass through exec */ } xfs_cap_set_t; -/* On-disk XFS extended attribute names */ -#define SGI_CAP_FILE "SGI_CAP_FILE" -#define SGI_CAP_FILE_SIZE (sizeof(SGI_CAP_FILE)-1) -#define SGI_CAP_LINUX "SGI_CAP_LINUX" -#define SGI_CAP_LINUX_SIZE (sizeof(SGI_CAP_LINUX)-1) - /* * For Linux, we take the bitfields directly from capability.h * and no longer attempt to keep this attribute ondisk compatible @@ -50,19 +44,6 @@ typedef struct xfs_cap_set { #include struct bhv_vnode; - -extern int xfs_cap_vhascap(struct bhv_vnode *); -extern int xfs_cap_vset(struct bhv_vnode *, void *, size_t); -extern int xfs_cap_vget(struct bhv_vnode *, void *, size_t); -extern int xfs_cap_vremove(struct bhv_vnode *); - -#define _CAP_EXISTS xfs_cap_vhascap - -#else -#define xfs_cap_vset(v,p,sz) (-EOPNOTSUPP) -#define xfs_cap_vget(v,p,sz) (-EOPNOTSUPP) -#define xfs_cap_vremove(v) (-EOPNOTSUPP) -#define _CAP_EXISTS (NULL) #endif #endif /* __KERNEL__ */ Index: xfs-linux/xfs_da_btree.h =================================================================== --- xfs-linux.orig/xfs_da_btree.h +++ xfs-linux/xfs_da_btree.h @@ -72,8 +72,6 @@ typedef struct xfs_da_intnode { typedef struct xfs_da_node_hdr xfs_da_node_hdr_t; typedef struct xfs_da_node_entry xfs_da_node_entry_t; -#define XFS_DA_MAXHASH ((xfs_dahash_t)-1) /* largest valid hash value */ - #define XFS_LBSIZE(mp) (mp)->m_sb.sb_blocksize #define XFS_LBLOG(mp) (mp)->m_sb.sb_blocklog Index: xfs-linux/xfs_error.h =================================================================== --- xfs-linux.orig/xfs_error.h +++ xfs-linux/xfs_error.h @@ -18,14 +18,6 @@ #ifndef __XFS_ERROR_H__ #define __XFS_ERROR_H__ -#define XFS_ERECOVER 1 /* Failure to recover log */ -#define XFS_ELOGSTAT 2 /* Failure to stat log in user space */ -#define XFS_ENOLOGSPACE 3 /* Reservation too large */ -#define XFS_ENOTSUP 4 /* Operation not supported */ -#define XFS_ENOLSN 5 /* Can't find the lsn you asked for */ -#define XFS_ENOTFOUND 6 -#define XFS_ENOTXFS 7 /* Not XFS filesystem */ - #ifdef DEBUG #define XFS_ERROR_NTRAP 10 extern int xfs_etrap[XFS_ERROR_NTRAP]; Index: xfs-linux/xfs_fs.h =================================================================== --- xfs-linux.orig/xfs_fs.h +++ xfs-linux/xfs_fs.h @@ -22,8 +22,6 @@ * SGI's XFS filesystem's major stuff (constants, structures) */ -#define XFS_NAME "xfs" - /* * Direct I/O attribute record used with XFS_IOC_DIOINFO * d_miniosz is the min xfer size, xfer size multiple and file seek offset @@ -428,8 +426,6 @@ typedef struct xfs_handle { #define XFS_HANDLE_CMP(h1, h2) memcmp(h1, h2, sizeof(xfs_handle_t)) -#define FSHSIZE sizeof(fsid_t) - /* * Flags for going down operation */ Index: xfs-linux/xfs_sb.h =================================================================== --- xfs-linux.orig/xfs_sb.h +++ xfs-linux/xfs_sb.h @@ -60,10 +60,6 @@ struct xfs_mount; XFS_SB_VERSION_LOGV2BIT | \ XFS_SB_VERSION_SECTORBIT | \ XFS_SB_VERSION_MOREBITSBIT) -#define XFS_SB_VERSION_OKSASHBITS \ - (XFS_SB_VERSION_NUMBITS | \ - XFS_SB_VERSION_REALFBITS | \ - XFS_SB_VERSION_OKSASHFBITS) #define XFS_SB_VERSION_OKREALBITS \ (XFS_SB_VERSION_NUMBITS | \ XFS_SB_VERSION_OKREALFBITS | \ @@ -81,9 +77,6 @@ struct xfs_mount; #define XFS_SB_VERSION2_RESERVED2BIT 0x00000002 #define XFS_SB_VERSION2_RESERVED4BIT 0x00000004 #define XFS_SB_VERSION2_ATTR2BIT 0x00000008 /* Inline attr rework */ -#define XFS_SB_VERSION2_SASHFBITS 0xff000000 /* Mask: features that - require changing - PROM and SASH */ #define XFS_SB_VERSION2_OKREALFBITS \ (XFS_SB_VERSION2_ATTR2BIT) @@ -237,12 +230,6 @@ static inline int XFS_SB_GOOD_VERSION(xf } #endif /* __KERNEL__ */ -#define XFS_SB_GOOD_SASH_VERSION(sbp) \ - ((((sbp)->sb_versionnum >= XFS_SB_VERSION_1) && \ - ((sbp)->sb_versionnum <= XFS_SB_VERSION_3)) || \ - ((XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ - !((sbp)->sb_versionnum & ~XFS_SB_VERSION_OKSASHBITS))) - static inline unsigned XFS_SB_VERSION_TONEW(unsigned v) { return ((((v) == XFS_SB_VERSION_1) ? \ @@ -436,15 +423,6 @@ static inline void XFS_SB_VERSION_ADDATT * File system sector to basic block conversions. */ #define XFS_FSS_TO_BB(mp,sec) ((sec) << (mp)->m_sectbb_log) -#define XFS_BB_TO_FSS(mp,bb) \ - (((bb) + (XFS_FSS_TO_BB(mp,1) - 1)) >> (mp)->m_sectbb_log) -#define XFS_BB_TO_FSST(mp,bb) ((bb) >> (mp)->m_sectbb_log) - -/* - * File system sector to byte conversions. - */ -#define XFS_FSS_TO_B(mp,sectno) ((xfs_fsize_t)(sectno) << (mp)->m_sb.sb_sectlog) -#define XFS_B_TO_FSST(mp,b) (((__uint64_t)(b)) >> (mp)->m_sb.sb_sectlog) /* * File system block to basic block conversions. Index: xfs-linux/quota/xfs_qm.h =================================================================== --- xfs-linux.orig/quota/xfs_qm.h +++ xfs-linux/quota/xfs_qm.h @@ -56,12 +56,6 @@ extern kmem_zone_t *qm_dqtrxzone; #define XFS_QM_HASHSIZE_HIGH ((NBPP * 4) / sizeof(xfs_dqhash_t)) /* - * We output a cmn_err when quotachecking a quota file with more than - * this many fsbs. - */ -#define XFS_QM_BIG_QCHECK_NBLKS 500 - -/* * This defines the unit of allocation of dquots. * Currently, it is just one file system block, and a 4K blk contains 30 * (136 * 30 = 4080) dquots. It's probably not worth trying to make Index: xfs-linux/xfs_log.h =================================================================== --- xfs-linux.orig/xfs_log.h +++ xfs-linux/xfs_log.h @@ -48,16 +48,10 @@ static inline xfs_lsn_t _lsn_cmp(xfs_lsn */ /* - * Flags to xfs_log_mount - */ -#define XFS_LOG_RECOVER 0x1 - -/* * Flags to xfs_log_done() */ #define XFS_LOG_REL_PERM_RESERV 0x1 - /* * Flags to xfs_log_reserve() * @@ -70,8 +64,6 @@ static inline xfs_lsn_t _lsn_cmp(xfs_lsn #define XFS_LOG_SLEEP 0x0 #define XFS_LOG_NOSLEEP 0x1 #define XFS_LOG_PERM_RESERV 0x2 -#define XFS_LOG_RESV_ALL (XFS_LOG_NOSLEEP|XFS_LOG_PERM_RESERV) - /* * Flags to xfs_log_force() Index: xfs-linux/xfs_log_priv.h =================================================================== --- xfs-linux.orig/xfs_log_priv.h +++ xfs-linux/xfs_log_priv.h @@ -32,7 +32,6 @@ struct xfs_mount; #define XLOG_MIN_ICLOGS 2 #define XLOG_MED_ICLOGS 4 #define XLOG_MAX_ICLOGS 8 -#define XLOG_CALLBACK_SIZE 10 #define XLOG_HEADER_MAGIC_NUM 0xFEEDbabe /* Invalid cycle number */ #define XLOG_VERSION_1 1 #define XLOG_VERSION_2 2 /* Large IClogs, Log sunit */ @@ -149,9 +148,6 @@ struct xfs_mount; #define XLOG_WAS_CONT_TRANS 0x08 /* Cont this trans into new region */ #define XLOG_END_TRANS 0x10 /* End a continued transaction */ #define XLOG_UNMOUNT_TRANS 0x20 /* Unmount a filesystem transaction */ -#define XLOG_SKIP_TRANS (XLOG_COMMIT_TRANS | XLOG_CONTINUE_TRANS | \ - XLOG_WAS_CONT_TRANS | XLOG_END_TRANS | \ - XLOG_UNMOUNT_TRANS) #ifdef __KERNEL__ /* Index: xfs-linux/xfs_quota.h =================================================================== --- xfs-linux.orig/xfs_quota.h +++ xfs-linux/xfs_quota.h @@ -281,9 +281,6 @@ typedef struct xfs_qoff_logformat { XFS_UQUOTA_CHKD|XFS_PQUOTA_ACCT|\ XFS_OQUOTA_ENFD|XFS_OQUOTA_CHKD|\ XFS_GQUOTA_ACCT) -#define XFS_MOUNT_QUOTA_MASK (XFS_MOUNT_QUOTA_ALL | XFS_UQUOTA_ACTIVE | \ - XFS_GQUOTA_ACTIVE | XFS_PQUOTA_ACTIVE) - /* * The structure kept inside the xfs_trans_t keep track of dquot changes Index: xfs-linux/linux-2.4/sv.h =================================================================== --- xfs-linux.orig/linux-2.4/sv.h +++ xfs-linux/linux-2.4/sv.h @@ -33,9 +33,6 @@ typedef struct sv_s { } sv_t; #define SV_FIFO 0x0 /* sv_t is FIFO type */ -#define SV_LIFO 0x2 /* sv_t is LIFO type */ -#define SV_PRIO 0x4 /* sv_t is PRIO type */ -#define SV_KEYED 0x6 /* sv_t is KEYED type */ #define SV_DEFAULT SV_FIFO Index: xfs-linux/linux-2.4/xfs_buf.h =================================================================== --- xfs-linux.orig/linux-2.4/xfs_buf.h +++ xfs-linux/linux-2.4/xfs_buf.h @@ -359,7 +359,6 @@ BUFFER_FNS(Delay, delay) #define XFS_BUF_ISDONE(bp) (!(XBF_NOT_DONE(bp))) #define XFS_BUF_BUSY(bp) ((bp)->b_flags |= XBF_FORCEIO) -#define XFS_BUF_UNBUSY(bp) ((bp)->b_flags &= ~XBF_FORCEIO) #define XFS_BUF_ISBUSY(bp) (1) #define XFS_BUF_ASYNC(bp) ((bp)->b_flags |= XBF_ASYNC) @@ -368,7 +367,6 @@ BUFFER_FNS(Delay, delay) #define XFS_BUF_ORDERED(bp) ((bp)->b_flags |= XBF_ORDERED) #define XFS_BUF_UNORDERED(bp) ((bp)->b_flags &= ~XBF_ORDERED) -#define XFS_BUF_ISORDERED(bp) ((bp)->b_flags & XBF_ORDERED) #define XFS_BUF_SHUT(bp) do { } while (0) #define XFS_BUF_UNSHUT(bp) do { } while (0) @@ -381,10 +379,8 @@ BUFFER_FNS(Delay, delay) #define XFS_BUF_WRITE(bp) ((bp)->b_flags |= XBF_WRITE) #define XFS_BUF_UNWRITE(bp) ((bp)->b_flags &= ~XBF_WRITE) -#define XFS_BUF_ISWRITE(bp) ((bp)->b_flags & XBF_WRITE) #define XFS_BUF_ISUNINITIAL(bp) (0) -#define XFS_BUF_UNUNINITIAL(bp) (0) #define XFS_BUF_BP_ISMAPPED(bp) (1) @@ -425,7 +421,6 @@ BUFFER_FNS(Delay, delay) #define XFS_BUF_VALUSEMA(bp) xfs_buf_lock_value(bp) #define XFS_BUF_CPSEMA(bp) (xfs_buf_cond_lock(bp) == 0) -#define XFS_BUF_VSEMA(bp) xfs_buf_unlock(bp) #define XFS_BUF_PSEMA(bp,x) xfs_buf_lock(bp) #define XFS_BUF_V_IODONESEMA(bp) up(&bp->b_iodonesema); @@ -482,8 +477,6 @@ static inline int XFS_bwrite(xfs_buf_t * return error; } -#define XFS_bdwrite(bp) xfs_buf_iostart(bp, XBF_DELWRI | XBF_ASYNC) - static inline int xfs_bdwrite(void *mp, xfs_buf_t *bp) { bp->b_strat = xfs_bdstrat_cb; Index: xfs-linux/linux-2.4/xfs_linux.h =================================================================== --- xfs-linux.orig/linux-2.4/xfs_linux.h +++ xfs-linux/linux-2.4/xfs_linux.h @@ -182,11 +182,7 @@ BUFFER_FNS(Unwritten, unwritten) (current->flags = ((current->flags & ~(f)) | (*(sp) & (f)))) #define NBPP PAGE_SIZE -#define DPPSHFT (PAGE_SHIFT - 9) #define NDPP (1 << (PAGE_SHIFT - 9)) -#define dtop(DD) (((DD) + NDPP - 1) >> DPPSHFT) -#define dtopt(DD) ((DD) >> DPPSHFT) -#define dpoff(DD) ((DD) & (NDPP-1)) #define NBBY 8 /* number of bits per byte */ #define NBPC PAGE_SIZE /* Number of bytes per click */ @@ -206,8 +202,6 @@ BUFFER_FNS(Unwritten, unwritten) #define btoct(x) ((__psunsigned_t)(x)>>BPCSHIFT) #define btoc64(x) (((__uint64_t)(x)+(NBPC-1))>>BPCSHIFT) #define btoct64(x) ((__uint64_t)(x)>>BPCSHIFT) -#define io_btoc(x) (((__psunsigned_t)(x)+(IO_NBPC-1))>>IO_BPCSHIFT) -#define io_btoct(x) ((__psunsigned_t)(x)>>IO_BPCSHIFT) /* off_t bytes to clicks */ #define offtoc(x) (((__uint64_t)(x)+(NBPC-1))>>BPCSHIFT) @@ -220,7 +214,6 @@ BUFFER_FNS(Unwritten, unwritten) #define ctob(x) ((__psunsigned_t)(x)<>BPCSHIFT) #define ctob64(x) ((__uint64_t)(x)<>BPCSHIFT) Index: xfs-linux/linux-2.4/xfs_vfs.h =================================================================== --- xfs-linux.orig/linux-2.4/xfs_vfs.h +++ xfs-linux/linux-2.4/xfs_vfs.h @@ -171,18 +171,8 @@ typedef struct bhv_vfsops { #define bhv_next_vfs_mount(b, ma,cr) vfs_mount(b, ma,cr) #define bhv_next_vfs_parseargs(b, o,ma,f) vfs_parseargs(b, o,ma,f) #define bhv_next_vfs_showargs(b, m) vfs_showargs(b, m) -#define bhv_next_vfs_unmount(b, f,cr) vfs_unmount(b, f,cr) -#define bhv_next_vfs_mntupdate(b, fl,args) vfs_mntupdate(b, fl, args) -#define bhv_next_vfs_root(b, vpp) vfs_root(b, vpp) #define bhv_next_vfs_statvfs(b, sp,vp) vfs_statvfs(b, sp,vp) #define bhv_next_vfs_sync(b, flag,cr) vfs_sync(b, flag,cr) -#define bhv_next_vfs_vget(b, vpp,fidp) vfs_vget(b, vpp,fidp) -#define bhv_next_vfs_dmapiops(b, p) vfs_dmapiops(b, p) -#define bhv_next_vfs_quotactl(b, c,id,p) vfs_quotactl(b, c,id,p) -#define bhv_next_vfs_get_inode(b, ino,fl) vfs_get_inode(b, ino,fl) -#define bhv_next_vfs_init_vnode(b, vp,b2,ul) vfs_init_vnode(b, vp,b2,ul) -#define bhv_next_force_shutdown(b, fl,f,l) vfs_force_shutdown(b, fl,f,l) -#define bhv_next_vfs_freeze(b) vfs_freeze(b) extern int vfs_mount(bhv_desc_t *, struct xfs_mount_args *, struct cred *); extern int vfs_parseargs(bhv_desc_t *, char *, struct xfs_mount_args *, int); Index: xfs-linux/linux-2.4/xfs_vnode.h =================================================================== --- xfs-linux.orig/linux-2.4/xfs_vnode.h +++ xfs-linux/linux-2.4/xfs_vnode.h @@ -271,10 +271,7 @@ typedef struct bhv_vnodeops { #define bhv_vop_release(vp) VOP(vop_release, vp)(VNHEAD(vp)) #define bhv_vop_fid2(vp,fidp) VOP(vop_fid2, vp)(VNHEAD(vp),fidp) #define bhv_vop_rwlock(vp,i) VOP(vop_rwlock, vp)(VNHEAD(vp),i) -#define bhv_vop_rwlock_try(vp,i) VOP(vop_rwlock, vp)(VNHEAD(vp),i) #define bhv_vop_rwunlock(vp,i) VOP(vop_rwunlock, vp)(VNHEAD(vp),i) -#define bhv_vop_frlock(vp,c,fl,flags,offset,fr) \ - VOP(vop_frlock, vp)(VNHEAD(vp),c,fl,flags,offset,fr) #define bhv_vop_reclaim(vp) VOP(vop_reclaim, vp)(VNHEAD(vp)) #define bhv_vop_attr_get(vp, name,val,vallenp,fl,cred) \ VOP(vop_attr_get, vp)(VNHEAD(vp),name,val,vallenp,fl,cred) --------------090208020808090209090202-- From owner-xfs@oss.sgi.com Sun Jul 30 21:03:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Jul 2006 21:03:52 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6V43VDW002458 for ; Sun, 30 Jul 2006 21:03:32 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id F229F18DE2F33; Sun, 30 Jul 2006 23:03:06 -0500 (CDT) Message-ID: <44CD80FD.5060101@sandeen.net> Date: Sun, 30 Jul 2006 23:03:09 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Nathan Scott Cc: dgc@sgi.com, xfs@oss.sgi.com Subject: Re: [PATCH] kill no-op buf macros References: <44CC2A55.6030207@sandeen.net> <20060731090815.B2280998@wobbly.melbourne.sgi.com> In-Reply-To: <20060731090815.B2280998@wobbly.melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------010804020903080006020305" X-archive-position: 8509 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 2758 Lines: 86 This is a multi-part message in MIME format. --------------010804020903080006020305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nathan Scott wrote: >> #define XFS_BUF_ISUNINITIAL(bp) (0) > > This can go, unwritten extents don't use this interface on Linux. > >> #define XFS_BUF_BP_ISMAPPED(bp) (1) > > *nod* - looks like it should go. > > (could you regen the patch with just these two for now? they are > pretty much self-contained changes, and nice 'n small) Ok, here it is, not so interesting :) -Eric --------------010804020903080006020305 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="kill-BUF_ISUNINITIAL_and_ISMAPPED" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kill-BUF_ISUNINITIAL_and_ISMAPPED" Remove a couple of unused BUF macros Signed-Off-By: Eric Sandeen Index: xfs-linux/linux-2.4/xfs_buf.h =================================================================== --- xfs-linux.orig/linux-2.4/xfs_buf.h +++ xfs-linux/linux-2.4/xfs_buf.h @@ -380,10 +380,6 @@ BUFFER_FNS(Delay, delay) #define XFS_BUF_WRITE(bp) ((bp)->b_flags |= XBF_WRITE) #define XFS_BUF_UNWRITE(bp) ((bp)->b_flags &= ~XBF_WRITE) -#define XFS_BUF_ISUNINITIAL(bp) (0) - -#define XFS_BUF_BP_ISMAPPED(bp) (1) - #define XFS_BUF_DATAIO(bp) ((bp)->b_flags |= XBF_FS_DATAIOD) #define XFS_BUF_UNDATAIO(bp) ((bp)->b_flags &= ~XBF_FS_DATAIOD) Index: xfs-linux/linux-2.6/xfs_buf.h =================================================================== --- xfs-linux.orig/linux-2.6/xfs_buf.h +++ xfs-linux/linux-2.6/xfs_buf.h @@ -296,10 +296,6 @@ extern void xfs_buf_trace(xfs_buf_t *, c #define XFS_BUF_WRITE(bp) ((bp)->b_flags |= XBF_WRITE) #define XFS_BUF_UNWRITE(bp) ((bp)->b_flags &= ~XBF_WRITE) -#define XFS_BUF_ISUNINITIAL(bp) (0) - -#define XFS_BUF_BP_ISMAPPED(bp) (1) - #define XFS_BUF_IODONE_FUNC(bp) ((bp)->b_iodone) #define XFS_BUF_SET_IODONE_FUNC(bp, func) ((bp)->b_iodone = (func)) #define XFS_BUF_CLR_IODONE_FUNC(bp) ((bp)->b_iodone = NULL) Index: xfs-linux/xfs_buf_item.c =================================================================== --- xfs-linux.orig/xfs_buf_item.c +++ xfs-linux/xfs_buf_item.c @@ -234,7 +234,6 @@ xfs_buf_item_format( ASSERT((bip->bli_flags & XFS_BLI_LOGGED) || (bip->bli_flags & XFS_BLI_STALE)); bp = bip->bli_buf; - ASSERT(XFS_BUF_BP_ISMAPPED(bp)); vecp = log_vector; /* @@ -901,7 +900,6 @@ xfs_buf_item_relse( XFS_BUF_SET_FSPRIVATE(bp, bip->bli_item.li_bio_list); if ((XFS_BUF_FSPRIVATE(bp, void *) == NULL) && (XFS_BUF_IODONE_FUNC(bp) != NULL)) { - ASSERT((XFS_BUF_ISUNINITIAL(bp)) == 0); XFS_BUF_CLR_IODONE_FUNC(bp); } --------------010804020903080006020305-- From owner-xfs@oss.sgi.com Mon Jul 31 02:59:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 02:59:55 -0700 (PDT) Received: from mail.mdlink.de (hydra.mdlink.de [213.211.192.38]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6V9xXDW000667 for ; Mon, 31 Jul 2006 02:59:35 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.de (Postfix) with ESMTP id A09D480EC281; Mon, 31 Jul 2006 11:39:24 +0200 (CEST) Received: from [213.211.192.21] (premium.mdlink.de [213.211.192.21]) by mail.mdlink.de (Postfix) with ESMTP id 31AC280EC27B; Mon, 31 Jul 2006 11:39:24 +0200 (CEST) Message-ID: <44CDD03D.3060809@mdlink.de> Date: Mon, 31 Jul 2006 11:41:17 +0200 From: Frank Patzig User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: [xfs] quota project problem References: <44CA1D89.3080104@mdlink.de> <20060731103133.G2280998@wobbly.melbourne.sgi.com> In-Reply-To: <20060731103133.G2280998@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8512 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: fp@mdlink.de Precedence: bulk X-list: xfs Content-Length: 752 Lines: 32 Hallo, thanks, work fine. Frank Nathan Scott schrieb: > On Fri, Jul 28, 2006 at 04:22:01PM +0200, Frank Patzig wrote: >> Hallo, >> >> i have a problem with project quota. Can i help you. >> >> combolix:~ # uname -a >> Linux combolix 2.6.18_rc1-jen27-default #1 Thu Jul 13 01:34:23 CEST 2006 >> i686 >> i686 i386 GNU/Linux >> >> combolix:~ # cat /etc/mtab >> /dev/hdc2 / xfs rw,uquota,gquota,pquota 0 0 > > This isn't correct - you can have either gquota or pquota, > not both. You also need to set root flags via the kernel > boot option "rootflags=" - not via mtab (chicken vs egg). > >> Project quota state on / (/dev/hdc2) >> Accounting: OFF >> Enforcement: OFF >> Inode: #18446744073709551615 (0 blocks, 0 extents) > > cheers. > From owner-xfs@oss.sgi.com Mon Jul 31 05:39:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 05:39:28 -0700 (PDT) Received: from web31713.mail.mud.yahoo.com (web31713.mail.mud.yahoo.com [68.142.201.193]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k6VCd4DW002324 for ; Mon, 31 Jul 2006 05:39:04 -0700 Received: (qmail 28246 invoked by uid 60001); 31 Jul 2006 12:38:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0+zPasNcEyhQen+/eZmXeD2QQNEgRmlx3Eiwyh621txhXYmU47i3NoJosYhE+1llUDb7pkaSyyVNI0FkotcQfdbl+ESdC6W46CD91Ac2+NdFzKRTtQRHJ0q2pPivPNS9XZ9cLP2cf/cClussEepKViByrsfzhTIcc603JI9uKYg= ; Message-ID: <20060731123837.28243.qmail@web31713.mail.mud.yahoo.com> Received: from [212.150.66.71] by web31713.mail.mud.yahoo.com via HTTP; Mon, 31 Jul 2006 05:38:37 PDT Date: Mon, 31 Jul 2006 05:38:37 -0700 (PDT) From: Heilige Gheist Subject: Re: XFS setting custom extent size: real-time section only? To: Nathan Scott Cc: xfs@oss.sgi.com In-Reply-To: <20060726090051.C2118045@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8513 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hgheist@yahoo.com Precedence: bulk X-list: xfs Content-Length: 1671 Lines: 48 [..] > Hmm. > > > When you speak of pre-allocation, do you suggest using > XFS_IOC_RESVSP > > ioctl interface to explicitly reserve blocks in advance? > Yes, thats the one. > > > Can it guarantee contiguous chunk allocation? > No, but it does the best it can under the circumstances, > which is usually pretty good. > > > management, isn't it? Basically you pay for unfragmented contiguous > > block layout with extra disk space reserved for unwritten data. > But its not really "extra" if you know you're going to use it, > right? > > > If so, why offer custom extent size in the first place? > Its a different concept, solving different problems really. One is > at the extent level, the other is at (typically large) ranges of > bytes that can be more than an extent. > One is a "harder" guarantee than the the other of getting contiguous > space, as they call into the allocator in different ways. I think that I'll go for the custom extent size as the harder guarantee against fragmentation. It also looks to me that custom extent is easier for application to implement. Are there any other reasons why NOT use custom extent size? > > > [..] > > > > Do I have to have non-realtime regular section? > > > Yes. All metadata is stored there. > > Is there any way I can do sizing of the meta-data? > > I'm not sure what you're asking there...? Provided I have 150G real-time section, how can I estimate a size of data section that I need to allocate in order to store filesystem meta-data? --alan. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Mon Jul 31 09:26:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 09:26:13 -0700 (PDT) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6VGQ2DW010380 for ; Mon, 31 Jul 2006 09:26:03 -0700 Received: from mail01dn.adic.com ([172.16.40.35]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 08:23:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 MIME-Version: 1.0 Subject: Where are superblocks stored? Date: Mon, 31 Jul 2006 09:23:27 -0600 Message-ID: <51A9A4FCBC06324F8BFE956A551B58E0056A4CA3@mail01dn.adic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Where are superblocks stored? Thread-Index: Aca0tUVqPeeHZoibTJCsxa38S3o5dg== From: "Rishi Malik" To: X-OriginalArrivalTime: 31 Jul 2006 15:23:28.0141 (UTC) FILETIME=[45E5DBD0:01C6B4B5] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8514 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rishi.malik@adic.com Precedence: bulk X-list: xfs Content-Length: 832 Lines: 36 Hi All, I'm investigating some compact flash failures we've had. We run XFS on the CF. I've been getting a lot of I/O errors around logical block 543080. These are 512MB compact flash cards, and I think that block puts it at about halfway through the CF. I know the I/O errors indicate an error at a lower level then XFS. What I'm wondering, is if there's a superblock stored there? Maybe we're hammering that area a lot, and because of other problems with the card, we're getting these errors. I know that XFS stores its primary superblock at 0, but I haven't found out where the secondary superblocks are stored. Any help is appreciated. Rishi Malik Rishi Malik::Firmware Engineer::Rishi.Malik@adic.com ::o720-249-5932::c303-396-3568 [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Jul 31 09:38:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 09:39:17 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6VGcpDW012758 for ; Mon, 31 Jul 2006 09:38:52 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 611F3616D162; Mon, 31 Jul 2006 12:38:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 5BB7D16195E6B; Mon, 31 Jul 2006 12:38:24 -0400 (EDT) Date: Mon, 31 Jul 2006 12:38:24 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Jan Kasprzak cc: Nathan Scott , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: FAQ updated (was Re: XFS breakage...) In-Reply-To: <20060731162535.GA15555@fi.muni.cz> Message-ID: References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <20060731162535.GA15555@fi.muni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8515 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 3840 Lines: 64 On Mon, 31 Jul 2006, Jan Kasprzak wrote: > Nathan Scott wrote: > : I've captured the state of this issue here, with options and ways > : to correct the problem: > : http://oss.sgi.com/projects/xfs/faq.html#dir2 > : > : Hope this helps. > > I have been hit with this bug as well - I tried to clear the > two corrupted directory inodes with xfs_db (as the FAQ entry says), then ran > xfs_repair (lots of files ended up in lost+found), but apparently > the volume is still not OK - when I tried to use it (this volume > is a public FTP archive), I got the following traces: > > Jul 30 16:04:49 odysseus kernel: Filesystem "md5": XFS internal error xfs_da_do_buf(2) at line 2212 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff80324221 > Jul 30 16:04:49 odysseus kernel: > Jul 30 16:04:49 odysseus kernel: Call Trace: {xfs_corruption_error+228} > Jul 30 16:04:49 odysseus kernel: {kmem_zone_alloc+86} {xfs_da_do_buf+1359} > Jul 30 16:04:49 odysseus kernel: {xfs_da_read_buf+22} {xfs_da_buf_make+31} > Jul 30 16:04:49 odysseus kernel: {xfs_da_read_buf+22} {xfs_da_node_lookup_int+112} > Jul 30 16:04:49 odysseus kernel: {xfs_da_node_lookup_int+112} {xfs_dir2_node_lookup+70} > Jul 30 16:04:50 odysseus kernel: {xfs_dir2_isleaf+25} {xfs_dir2_lookup+256} > Jul 30 16:04:51 odysseus kernel: {xfs_dir_lookup_int+55} {xfs_lookup+79} > Jul 30 16:04:51 odysseus kernel: {xfs_vn_lo7b35>{xfs_dir2_isleaf+25} {xfs_dir2_lookup+256} > Jul 30 16:04:52 odysseus kernel: {xfs_dir_lookup_int+55} {xfs_lookup+79} > Jul 30 16:04:53 odysseus kernel: {xfs_vn_lookup+48} {do_lookup+196} > Jul 30 16:04:53 odysseus rpc.statd[3145]: Caught signal 15, un-registering and exiting. > Jul 30 16:04:53 odysseus kernel: {__link_path_walk+2435} {link_path_walk+89} > Jul 30 16:04:53 odysseus kernel: {__sched_text_start+290} {do_path_lookup+614} > Jul 30 16:04:53 odysseus kernel: {getname+347} {__user_walk_fd+55} > Jul 30 16:04:53 odysseus kernel: {vfs_lstat_fd+21} {__sched_text_start+290} > Jul 30 16:04:53 odysseus kernel: {sys_newlstat+25} {vfs_write+283} > Jul 30 16:04:53 odysseus kernel: {sys_write+69} {system_call+126} > Jul 30 16:04:53 odysseus kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > This is 2.6.17.7 dual x86_64 (Fedora Core 5). It has been unfortunately > running 2.6.17.1 for some time. > > I will probably have to recreate the volume and restore its > contents from backups. Or is there any better solution? > > Thanks, > > -Yenya > > -- > | Jan "Yenya" Kasprzak | > | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | > | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | >> I will never go to meetings again because I think face to face meetings < >> are the biggest waste of time you can ever have. --Linus Torvalds < > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > If you unmount, xfs_repair -n /dev/md5, what does it show currently? From owner-xfs@oss.sgi.com Mon Jul 31 10:35:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 10:35:55 -0700 (PDT) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6VHZFDW022778 for ; Mon, 31 Jul 2006 10:35:33 -0700 Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by tirith.ics.muni.cz (8.13.5.20060308/8.13.4/Debian-3) with ESMTP id k6VGPZnK029880; Mon, 31 Jul 2006 18:25:36 +0200 Received: by anxur.fi.muni.cz (Postfix, from userid 11561) id B55F122AFA4; Mon, 31 Jul 2006 18:25:35 +0200 (CEST) Date: Mon, 31 Jul 2006 18:25:35 +0200 From: Jan Kasprzak To: Nathan Scott Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060731162535.GA15555@fi.muni.cz> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060720171310.B1970528@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Envelope-From: kas@fi.muni.cz X-Muni-Virus-Test: Clean X-archive-position: 8516 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kas@fi.muni.cz Precedence: bulk X-list: xfs Content-Length: 3378 Lines: 52 Nathan Scott wrote: : I've captured the state of this issue here, with options and ways : to correct the problem: : http://oss.sgi.com/projects/xfs/faq.html#dir2 : : Hope this helps. I have been hit with this bug as well - I tried to clear the two corrupted directory inodes with xfs_db (as the FAQ entry says), then ran xfs_repair (lots of files ended up in lost+found), but apparently the volume is still not OK - when I tried to use it (this volume is a public FTP archive), I got the following traces: Jul 30 16:04:49 odysseus kernel: Filesystem "md5": XFS internal error xfs_da_do_buf(2) at line 2212 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff80324221 Jul 30 16:04:49 odysseus kernel: Jul 30 16:04:49 odysseus kernel: Call Trace: {xfs_corruption_error+228} Jul 30 16:04:49 odysseus kernel: {kmem_zone_alloc+86} {xfs_da_do_buf+1359} Jul 30 16:04:49 odysseus kernel: {xfs_da_read_buf+22} {xfs_da_buf_make+31} Jul 30 16:04:49 odysseus kernel: {xfs_da_read_buf+22} {xfs_da_node_lookup_int+112} Jul 30 16:04:49 odysseus kernel: {xfs_da_node_lookup_int+112} {xfs_dir2_node_lookup+70} Jul 30 16:04:50 odysseus kernel: {xfs_dir2_isleaf+25} {xfs_dir2_lookup+256} Jul 30 16:04:51 odysseus kernel: {xfs_dir_lookup_int+55} {xfs_lookup+79} Jul 30 16:04:51 odysseus kernel: {xfs_vn_lo7b35>{xfs_dir2_isleaf+25} {xfs_dir2_lookup+256} Jul 30 16:04:52 odysseus kernel: {xfs_dir_lookup_int+55} {xfs_lookup+79} Jul 30 16:04:53 odysseus kernel: {xfs_vn_lookup+48} {do_lookup+196} Jul 30 16:04:53 odysseus rpc.statd[3145]: Caught signal 15, un-registering and exiting. Jul 30 16:04:53 odysseus kernel: {__link_path_walk+2435} {link_path_walk+89} Jul 30 16:04:53 odysseus kernel: {__sched_text_start+290} {do_path_lookup+614} Jul 30 16:04:53 odysseus kernel: {getname+347} {__user_walk_fd+55} Jul 30 16:04:53 odysseus kernel: {vfs_lstat_fd+21} {__sched_text_start+290} Jul 30 16:04:53 odysseus kernel: {sys_newlstat+25} {vfs_write+283} Jul 30 16:04:53 odysseus kernel: {sys_write+69} {system_call+126} Jul 30 16:04:53 odysseus kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This is 2.6.17.7 dual x86_64 (Fedora Core 5). It has been unfortunately running 2.6.17.1 for some time. I will probably have to recreate the volume and restore its contents from backups. Or is there any better solution? Thanks, -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | > I will never go to meetings again because I think face to face meetings < > are the biggest waste of time you can ever have. --Linus Torvalds < From owner-xfs@oss.sgi.com Mon Jul 31 15:28:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 15:29:22 -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 k6VMSbDW000514 for ; Mon, 31 Jul 2006 15:28:48 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA21718; Tue, 1 Aug 2006 08:27:53 +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 k6VMRpgw2318910; Tue, 1 Aug 2006 08:27:51 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6VMRlVS2318417; Tue, 1 Aug 2006 08:27:47 +1000 (EST) Date: Tue, 1 Aug 2006 08:27:47 +1000 From: Nathan Scott To: Rishi Malik Cc: xfs@oss.sgi.com Subject: Re: Where are superblocks stored? Message-ID: <20060801082747.B2286470@wobbly.melbourne.sgi.com> References: <51A9A4FCBC06324F8BFE956A551B58E0056A4CA3@mail01dn.adic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <51A9A4FCBC06324F8BFE956A551B58E0056A4CA3@mail01dn.adic.com>; from rishi.malik@adic.com on Mon, Jul 31, 2006 at 09:23:27AM -0600 X-archive-position: 8519 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: 907 Lines: 25 On Mon, Jul 31, 2006 at 09:23:27AM -0600, Rishi Malik wrote: > Hi All, > > I'm investigating some compact flash failures we've had. We run XFS on > the CF. I've been getting a lot of I/O errors around logical block > 543080. These are 512MB compact flash cards, and I think that block puts > it at about halfway through the CF. I know the I/O errors indicate an That would be the journal. > error at a lower level then XFS. What I'm wondering, is if there's a > superblock stored there? Maybe we're hammering that area a lot, and > because of other problems with the card, we're getting these errors. > > I know that XFS stores its primary superblock at 0, but I haven't found > out where the secondary superblocks are stored. Any help is appreciated. The secondary superblocks are very rarely touched (repair, and growfs only IIRC), they will be unrelated to your problem here. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 31 15:30:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 15:31: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 k6VMUgDW000972 for ; Mon, 31 Jul 2006 15:30:53 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA21736; Tue, 1 Aug 2006 08:29: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 k6VMTugw2304316; Tue, 1 Aug 2006 08:29:57 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k6VMTsx82317655; Tue, 1 Aug 2006 08:29:54 +1000 (EST) Date: Tue, 1 Aug 2006 08:29:54 +1000 From: Nathan Scott To: Heilige Gheist Cc: xfs@oss.sgi.com Subject: Re: XFS setting custom extent size: real-time section only? Message-ID: <20060801082953.C2286470@wobbly.melbourne.sgi.com> References: <20060726090051.C2118045@wobbly.melbourne.sgi.com> <20060731123837.28243.qmail@web31713.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060731123837.28243.qmail@web31713.mail.mud.yahoo.com>; from hgheist@yahoo.com on Mon, Jul 31, 2006 at 05:38:37AM -0700 X-archive-position: 8520 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: 1954 Lines: 55 On Mon, Jul 31, 2006 at 05:38:37AM -0700, Heilige Gheist wrote: > I think that I'll go for the custom extent size as the harder guarantee > against fragmentation. It also looks to me that custom extent is easier > for application to implement. > Are there any other reasons why NOT use custom extent size? Not really... only things like "its not there in old kernels", and "its not seen the level of testing and exposure of other XFS features, like preallocation", etc. > > > > > Do I have to have non-realtime regular section? > > > > Yes. All metadata is stored there. > > > Is there any way I can do sizing of the meta-data? > > > > I'm not sure what you're asking there...? > Provided I have 150G real-time section, how can I estimate a size of > data section that I need to allocate in order to store filesystem > meta-data? Oh, I see. You don't need to estimate, you can fairly quickly tell like this (all realtime space management is done up-front during mkfs/growfs)... [note: need a very recent xfsprogs to use the -rfile option] $ mkfs.xfs -d file,size=200m,name=/tmp/meta -r file,size=150g,name=/tmp/real meta-data=/tmp/meta isize=256 agcount=8, agsize=6400 blks = sectsz=512 attr=0 data = bsize=4096 blocks=51200, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =/tmp/real extsz=65536 blocks=39321600, rtextents=2457600 $ xfs_db /tmp/meta xfs_db> sb xfs_db> p rbmino rbmino = 129 xfs_db> p rsumino rsumino = 130 xfs_db> inode 129 xfs_db> p core.size core.size = 307200 xfs_db> inode 130 xfs_db> p core.size core.size = 8192 xfs_db> So, it takes ~300k of metadata space to manage that realtime 150g. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jul 31 19:36:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 19:36:20 -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 k712ZoDW006273 for ; Mon, 31 Jul 2006 19:36:00 -0700 Received: from soarer.melbourne.sgi.com (soarer.melbourne.sgi.com [134.14.55.89]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k6VNXQnx025096 for ; Mon, 31 Jul 2006 18:33:27 -0500 Received: by soarer.melbourne.sgi.com (Postfix, from userid 16344) id B69D138BD6; Tue, 1 Aug 2006 09:34:16 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.melbourne.sgi.com Subject: TAKE 953687 - Message-Id: <20060731233416.B69D138BD6@soarer.melbourne.sgi.com> Date: Tue, 1 Aug 2006 09:34:16 +1000 (EST) From: vapo@soarer.melbourne.sgi.com (Vlad Apostolov) X-archive-position: 8527 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@soarer.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 451 Lines: 16 pass file mode on DMAPI remove events Date: Tue Aug 1 09:32:45 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26639a fs/xfs/xfs_vnodeops.c - 1.682 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.682&r2=text&tr2=1.681&f=h From owner-xfs@oss.sgi.com Mon Jul 31 19:36:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Jul 2006 19:36:45 -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 k712aBDW006361 for ; Mon, 31 Jul 2006 19:36:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id k710NGnx029951 for ; Mon, 31 Jul 2006 19:23:17 -0500 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24290; Tue, 1 Aug 2006 10:23:09 +1000 Message-ID: <44CE9F23.7000605@sgi.com> Date: Tue, 01 Aug 2006 10:24:03 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 953687 - [SUSE#182691]The current XFS kernel does not pass the file mode on remove events Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8528 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 451 Lines: 16 pass file mode on DMAPI remove events Date: Tue Aug 1 09:32:45 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26639a fs/xfs/xfs_vnodeops.c - 1.682 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.682&r2=text&tr2=1.681&f=h